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]

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