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

[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.

[goldsquare.livejournal.com]

But in that case, why not have a primary name, and tag it with a set (0-infinite) of nicknames?

[kihou.livejournal.com]

For names, I'd be fine having any number of names with one marked as a unique primary, though that seems more complicated than a single-value name tag and a multi-value nickname tag. For, like, ability effects, it doesn't make sense for there to be more than one, at least with the standard way of typesetting them. And either way, I'd want it to be clean to refer to the unique primary name.

[jducoeur]

Well, *all* processing is being done in terms of collections, so that wouldn't be an issue. Even fields that are explicitly singletons are implemented as an ExactlyOne collection.

(Basically, the QL language is going to be monadic down to its socks -- everything is about passing collections through pipeline stages. Sometimes, those collections will have only one item, or zero items; that's fine. The notion is to make the collections so universal that you don't even think about them.)

Anyway, it's a good point, although I suspect that Tags per se aren't the right way to handle most of your examples. Mind, Tags are only one of a dozen data types designed so far -- an important one, but not the right tool for every job. I suspect that Name is of type ExactlyOne[Text], and Ability is the same, or maybe ExactlyOne[Link[Effect]], where Effect is a separate Model (class). (Actually, Name and DisplayName are built into the system -- all Things have both as semi-optional-but-encouraged properties.)

But yes -- at this point I'm leaning towards the optional-constraint suggestion as the best way to handle this, if and when it turns out to actually be necessary...