Entry tags:
Singleton tags?
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
I can think of reasons for a Thing to have a unique field (one and only one Full Proper Name, one and only one ID number, one and only one Current Location for a physical object). Are these unique fields examples of Tags or something else?
What are the values stored in a TagSet? Do I name a TagSet (this tag set is all the Nicknames for this thing), or is a TagSet a collection of name/value pairs (This thing has a TagSet, which includes Nickname/name pairs)? If the latter, can a TagSet be marked to allow only Unique Name v. Multi-entry Names (This can have many nicknames, but only one CurrentLocation)?
For that matter, what is a Tag? Is it limited to a simple string, or is it a fully qualified Thing as well?
no subject
I'm heading out the door, but feel free to hit me with followup questions beyond the below discussion...
no subject
no subject
Note my comment to umbran elsethread -- perhaps the most accurate way to think about tags is that they are *names*. By and large, you just use them as arbitrary names, and don't worry about having anything behind them. But the plan is to allow those names to point to actual Things, of any sort. My expectation is that these would most often be simple unstructured wiki-style pages, providing additional information of what this name is talking about. But they could be anything, including fully-structured Things of particular types...