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

[goldsquare.livejournal.com]

Ah.

So the question is whether a user would want to limit the number of tags on something, and have Querki enforce that limit.

I'd say no, because retrofitting that is easy: objects from before the retrofit continue to have unlimited TagSets, objects afterward have a range.

Dan's point about proliferation of "near tags" is important as well, and the Merge feature he suggests would be useful, if likely secondary to your initial implementation.

What may be useful, to address his concerns, is to find a useful UI that urges the user to use existing tags over having them create a near-duplicate without care.

We are now far afield from your question. :-)

[jducoeur]

Definitely, but there's been some useful food for thought here. I think the tag-limit suggestion is clearly the right approach to my question, and lets me see whether it's a real problem before I worry about it.

As I just replied to Dan, I very much agree about the UI for reusing existing tags. Not sure exactly what that's going to look like yet, but I may get fairly heavy-handed about it. Tagslop is such a common problem that I suspect it's worth very strong encouragement to avoid it.

And yes, I agree about Merge, although I think it needs to be viewed more holistically -- I suspect we're eventually going to want a Tag Management UI that lets you see the full tag hierarchy in your space and shove things around quickly and easily. Possibly even drag-and-drop, but I'll need to see some realistic examples before I start designing. Regardless, it's probably a year or two off.