Singleton tags?
Nov. 21st, 2012 09:53 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
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?
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?
(no subject)
Date: 2012-11-22 03:58 am (UTC)In general, I think of tags as being fields on the Thing, much like any other field. That being the case, I expect it to be based on the same ACLs as everything else on the Thing -- if you can edit the Thing, you can edit its tags. I suspect that that's the only sensible approach in most cases.
That said, you raise an interesting idea, of essentially "private tags". I'm not 100% enthusiastic, mostly for technical reasons -- while I can see one or two ways I might implement them, they would rub along uneasily with the architecture. (At least, to provide the functionality that I think you'd want. These tags ideally wouldn't want to be scoped by the Space, the way that most of Querki is.)
So I'm not jumping at it. But OTOH, I've sometimes argued for the same idea in other systems -- I do see the appeal. So we'll see: if it seems like it would be useful to folks, I'd figure out a way to make it work...