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

[jducoeur]

Lots, and it mostly boils down to "tags work a lot like they do in most other online systems". A few points:

-- Tag values can be added at runtime, at will.

-- Tags are text, but very limited text. (Pure alphanumeric plus spaces; for technical reasons, I may not allow more than that. Essentially, they have the same restrictions as Thing names, so that they may easily be placed inside URLs. Ordinary text, by contrast, is extremely free-form, and much more powerful.)

-- Tags are (optionally) hierarchical; eg, a period recipe Space might have the tag "Sources/16th century/Scappi".

-- The UI of a tag will encourage you to reuse existing tags, rather than inventing new ones willy-nilly.

-- A tag is automatically clickable: clicking on it brings you to a page that lists all Things containing that tag in this Space.

-- Those pages can be customized. (Technically, a tag can be reified into a Thing simply by editing it.) This is intended so that you can add additional details and semantics describing this tag.

So they are *kind* of like short text fields. They're very restricted in the text you can put in them, but they have additional features intended to make them useful for run-time categorization. They are *intended* for categorization, and everything will be optimized for that use case. But "categorization" is a loose enough concept that I expect the reality to be somewhat fuzzy.

Or to put it another way: a collection of tags is intended to be a hierarchical collection of *names*. Regardless of design intent, that is technically what they basically are. (But note: each Thing has an official Name property built in. Tags are not a replacement for that, and basically can't be used as such. Rather, they are other names that are, in some form, relevant to this Thing.)