Singleton tags?

[jducoeur]

Okay, here's a question for thought and discussion. I'm currently designing the Tag feature. Every Thing in Querki can have fields that are "tags", in the usual sense -- they contain whatever short text you would like. Tags will be hierarchical (because that is sometimes useful). And here's the interesting question: should tags *always* be multi-value?

One of the great failings of older databases is that they tend to be single-valued -- you can have only one Author for a Book, and such silliness. The real world is typically much messier, and that's reflected in the fact that most modern systems use Tags as sets of values: you can generally have any number of tags for a given item. Tags are remarkably powerful, and I expect them to be much-used in Querki.

So I'm clearly going to implement TagSet. Is there any reason to have a data type that is only a *single* Tag? The engineer in me says that of course such a thing should exist, since conceptually it's obvious, but the UX designer in me says not to, since you shouldn't expose a concept that is always a bad idea to use.

Opinions? Are there non-strawman cases where you would specifically want to only allow a single Tag on something? Or is it more bother than it's worth to expose this through the UI -- should I just have TagSet as the type that you always use?

Comments

[talvinm.livejournal.com]

Could this be tunable? Could the owner/moderator of a particular area set a limit on "number of tags per Thing" (sometimes tagging gets WAY out of control, too!) with possible values of Zero to Foo?

[kihou.livejournal.com]

In my LARP usecase, there are definitely things I'd want to be able to enforce as one tag per object, so that my fellow GMs don't break things accidentally. (Each character or item has a one primary name that goes on the sheet/card, each ability card has one effect, etc.)

It'd be totally fine for this to just be an optional constraint on a tag set, as long as the syntax for using this singleton tag's value wasn't made more awkward by it internally being a set.

[dsrtao]

Let me offer an alternate notion instead.

Don't limit the number of Tags that can be set. Instead, offer the ability to only use existing Tags on an object.

There are many times that I have seen items with similar but non-identical tags where that clearly wasn't intended. Recipe and Recipes. Geek and Geekery and GeekStuff. Bibliography and Attribution and Biblio and...

Come to think of it, a Tag Merge operation would be great. Hard to undo, I think, but could come with a suitable warning.

[umbran.livejournal.com]

Are there non-strawman cases where you would specifically want to only allow a single Tag on something?

Before I can answer that question, I need to know - what is the functional difference between a tag and any other data field?

[marphod.livejournal.com]

How do Tags differ from Fields and from Things?

I can think of reasons for a Thing to have a unique field (one and only one Full Proper Name, one and only one ID number, one and only one Current Location for a physical object). Are these unique fields examples of Tags or something else?

What are the values stored in a TagSet? Do I name a TagSet (this tag set is all the Nicknames for this thing), or is a TagSet a collection of name/value pairs (This thing has a TagSet, which includes Nickname/name pairs)? If the latter, can a TagSet be marked to allow only Unique Name v. Multi-entry Names (This can have many nicknames, but only one CurrentLocation)?

For that matter, what is a Tag? Is it limited to a simple string, or is it a fully qualified Thing as well?

[hudebnik.livejournal.com]

I can certainly think of situations in which I would want to limit tags for a particular field to be chosen from a particular short list, without the ability (for Joe Schmoe user) to add new ones. But that's not about the number of tags in the field.

[mneme]

I guess the primary question is whether there are things where there's value in making -sure- an attribute only appears once in a given object. The two uses (keeping in mind that I'm not sure what the problem domain for Querki is) that come to mind are unique IDs (where even if they're a secondary key, there are often good reason not to allow a given object to have more than one -- for instance, letting traversal work properly) and for linear data structures, next/previous.