?

Log in

No account? Create an account
Previous Entry Share Next Entry
Singleton tags?
device
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?
Tags:

  • 1
(Deleted comment)
That's possible, yes -- wouldn't be terribly hard for me to allow a meta-property that lets you say how many Tags are permitted in a given Property.

But as always, that needs to fight for its life: it's an extra complication in the UI, which I'm only going to add if it actually appears to be useful in the real world. I'm trying to be very acid about this: Querki is aimed at the general public, so my design example is Apple rather than Microsoft. Every feature has to be clearly valuable to end users before I spend pixels on it.

So the question is, how often does this happen, and how severe a problem is it when it does? I confess, I don't remember seeing it happen myself, so I suspect it's unusual.

That said, I'll add it as a possible approach. Thanks -- that viewpoint hadn't occurred to me...

(Deleted comment)
(Deleted comment)
(Deleted comment)
In my LARP usecase, there are definitely things I'd want to be able to enforce as one tag per object, so that my fellow GMs don't break things accidentally. (Each character or item has a one primary name that goes on the sheet/card, each ability card has one effect, etc.)

It'd be totally fine for this to just be an optional constraint on a tag set, as long as the syntax for using this singleton tag's value wasn't made more awkward by it internally being a set.

(Deleted comment)
Well, *all* processing is being done in terms of collections, so that wouldn't be an issue. Even fields that are explicitly singletons are implemented as an ExactlyOne collection.

(Basically, the QL language is going to be monadic down to its socks -- everything is about passing collections through pipeline stages. Sometimes, those collections will have only one item, or zero items; that's fine. The notion is to make the collections so universal that you don't even think about them.)

Anyway, it's a good point, although I suspect that Tags per se aren't the right way to handle most of your examples. Mind, Tags are only one of a dozen data types designed so far -- an important one, but not the right tool for every job. I suspect that Name is of type ExactlyOne[Text], and Ability is the same, or maybe ExactlyOne[Link[Effect]], where Effect is a separate Model (class). (Actually, Name and DisplayName are built into the system -- all Things have both as semi-optional-but-encouraged properties.)

But yes -- at this point I'm leaning towards the optional-constraint suggestion as the best way to handle this, if and when it turns out to actually be necessary...

Let me offer an alternate notion instead.

Don't limit the number of Tags that can be set. Instead, offer the ability to only use existing Tags on an object.

There are many times that I have seen items with similar but non-identical tags where that clearly wasn't intended. Recipe and Recipes. Geek and Geekery and GeekStuff. Bibliography and Attribution and Biblio and...

Come to think of it, a Tag Merge operation would be great. Hard to undo, I think, but could come with a suitable warning.

Yeah, I've been pondering that one. I probably won't implement it at first, because the access-control implications get a little complicated (it isn't really that *nobody* can add Tags, it's that only *some* people can add Tags), but I'm open to this idea if it proves necessary.

Mind, I'm going to try to make it less necessary. The medium-term UI design is that tags will be a bit more menu-pick, rather than simply typing -- you will be *encouraged* to choose from existing tags, maybe strongly encouraged. But we'll see how well that works.

All this isn't quite what I'm asking, though. There's no real point in limiting the number of different possible Tags -- rather, the question is how many Tags you can assign to a given field. Most systems just have a general "tags" field, and you can place more or less an arbitrary number of tags into that. The question is, are there any use cases where you would only allow people to pick a *single* Tag from the available set, as opposed to allowing multi-selection? So far, I haven't come up with any examples I believe in, at least where I think Tags are the right tool for the job.

As for Tag Merge -- that one's kind of interesting. I agree that it'll sometimes be very useful for curating a Space, but I'll have to think about how it would work.

Undo shouldn't be an issue, though: Querki is planned to have what amounts to a full VCS under the hood, with every operation recorded. The notion is that it should be dead-easy to say, "Let me poke around in my Space the way it was last Tuesday", and full undo is planned to be universal. (Partial undo is much trickier, but it's something we'll explore down the line.) All easier said than done, of course, but it's in the designs, and I consider it a requirement before public release...

(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
(Deleted comment)
Are there non-strawman cases where you would specifically want to only allow a single Tag on something?

Before I can answer that question, I need to know - what is the functional difference between a tag and any other data field?

Lots, and it mostly boils down to "tags work a lot like they do in most other online systems". A few points:

-- Tag values can be added at runtime, at will.

-- Tags are text, but very limited text. (Pure alphanumeric plus spaces; for technical reasons, I may not allow more than that. Essentially, they have the same restrictions as Thing names, so that they may easily be placed inside URLs. Ordinary text, by contrast, is extremely free-form, and much more powerful.)

-- Tags are (optionally) hierarchical; eg, a period recipe Space might have the tag "Sources/16th century/Scappi".

-- The UI of a tag will encourage you to reuse existing tags, rather than inventing new ones willy-nilly.

-- A tag is automatically clickable: clicking on it brings you to a page that lists all Things containing that tag in this Space.

-- Those pages can be customized. (Technically, a tag can be reified into a Thing simply by editing it.) This is intended so that you can add additional details and semantics describing this tag.

So they are *kind* of like short text fields. They're very restricted in the text you can put in them, but they have additional features intended to make them useful for run-time categorization. They are *intended* for categorization, and everything will be optimized for that use case. But "categorization" is a loose enough concept that I expect the reality to be somewhat fuzzy.

Or to put it another way: a collection of tags is intended to be a hierarchical collection of *names*. Regardless of design intent, that is technically what they basically are. (But note: each Thing has an official Name property built in. Tags are not a replacement for that, and basically can't be used as such. Rather, they are other names that are, in some form, relevant to this Thing.)

How do Tags differ from Fields and from Things?

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?

Check the threads below -- I think I've hit most of that, although maybe not all of it.

I'm heading out the door, but feel free to hit me with followup questions beyond the below discussion...

(Deleted comment)
I can certainly think of situations in which I would want to limit tags for a particular field to be chosen from a particular short list, without the ability (for Joe Schmoe user) to add new ones. But that's not about the number of tags in the field.

I guess the primary question is whether there are things where there's value in making -sure- an attribute only appears once in a given object. The two uses (keeping in mind that I'm not sure what the problem domain for Querki is) that come to mind are unique IDs (where even if they're a secondary key, there are often good reason not to allow a given object to have more than one -- for instance, letting traversal work properly) and for linear data structures, next/previous.

  • 1