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]

I may not be appreciating your ideas in EXACTLY the way you appreciate them.

My general thinking is that there are many "pools of things". A person creates a pool, with a new type of thing, and every "player" can make mashups of things, by creating tuples of things or associations of things or annotations on things.

To me, Tags are just another duple of things, but a particularly less powerful tuple.

[jducoeur]

Hmm -- interesting, but a bit more at odds with the general concept. While Querki is radical, it's not *that* radical: it's a very strange database, but is still basically a database. Indeed, the QL language that you do queries in is probably going to turn out to be mostly isomorphic to SQL, although it breaks problems down in a very different way.

The way I often describe Querki is that it is to, eg, Rails just as a wiki is to a conventional website. It's a bit oversimplified, and not as powerful as the lower-level approach, but it's conceptually similar and much easier to use. The high-level concept is that there are many, many problems that are appropriate for a cloud-based database-centric website, but that aren't anywhere near complicated enough for such a big hammer. Those are the problems I'm mainly focused on -- the ones where a programmer goes, "But you should do that in a database!", but which people in practice mostly just throw into a spreadsheet, because they're not worth a huge amount of effort.

I'm kind of seeing what you're saying, but I'm not sure it's the problem I'm trying to solve here. At least not right now -- I could be convinced that it's worth tackling further down the road, but I'd need compelling use cases first. (One thing about a one-person company like this is that I am being *utterly* strict about not building anything unless I can understand the usage, and preferably the business case, very clearly.)

What you're describing is along the lines of some high-level concepts I'm playing with, where we start to treat all the descendant Spaces of an App as a larger pool of objects, but there are many more basic problems to solve before we get to that...