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

[talvinm.livejournal.com]

Could this be tunable? Could the owner/moderator of a particular area set a limit on "number of tags per Thing" (sometimes tagging gets WAY out of control, too!) with possible values of Zero to Foo?

[jducoeur]

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

[talvinm.livejournal.com]

I'll admit, I am not wed to the concept myself. It just popped into my head as a possibly useful compromise.

[jducoeur]

It is, and sorry if I came across as negative. Not sure whether it'll be worth adding or not, but it has the nice advantage that, since it is a tweak of TagSet, it could be added later, instead of being something I have to include upfront...

[talvinm.livejournal.com]

No, not overly negative. :) While not on your scale, I have written code before. I have also had to document products, trying to write the user's manual even as the product was being built, and being redesigned as it was being built. I understand and applaud the desire to avoid Feeping Creatures.

[goldsquare.livejournal.com]

I'm not sure I am fully understanding the issues, but it seems to me that you have answered your own question.

I'm reminded of a comment made by one of my co-workers at SUN, defining when one implementation is more powerful than another. "If you can implement B using A, but cannot implement A using B, A is more powerful". I'd opt for the more powerful, TagSet, in all areas.

Talvin's question is a good one, though. Do you want to be able to create TagSets whose sizes are pre-limited for any reason? I see no reason not to do so - except that it introduces a set of error conditions around both the limit value and what happens when you hit a limit.

That is an increase in complexity of code and time of implementation. I lack the knowledge to advise you on that, as I am not as versed in the usage model as you are.

(I'm inclined to say "no" - as long as your TagSet contains an ordinal count of tags, you can always implement a subclass of TagSet called LimitedTagSet. Or, from what you have been saying about Scala, you can create something that has an ordinal-cap sort of property, and associate that with all your collections or sets, should you choose to do so. I did buy, but still haven't cracked, Scala for the Impatient. The irony is not lost on me. I've been reading on law instead.)

[jducoeur]

That is an increase in complexity of code and time of implementation. I lack the knowledge to advise you on that, as I am not as versed in the usage model as you are.

Actually, neither of those is a major concern. The real issue is, literally, screen space. Or perhaps more accurately, mental space.

The thing is, I'm trying hard to avoid the classic "Microsoft disease" -- including every possible feature, with the result that *finding* the features you actually want becomes more difficult. So features have to fight for their lives, less because they are hard to implement and more because they increase the amount that a user might have to understand in setting up a Space.

And yes, the implication is that Querki is trying to be lowest-common-denominator in many ways -- again, in a very Appleish sort of way. There are going to be a hell of a lot of features in this tool, so I want to make sure they are the *necessary* features, so as not to overwhelm users. (This is part of why I'm so focused on use cases: no feature gets into the system unless it's justified by a use case, and no use case gets implemented unless I believe I have specific people who will want to use it.)

Note that the Scala end of things is largely irrelevant. This is, indeed, near-trivial to implement in Scala. But end users aren't working in Scala, they working in what amounts to a database/language/UI implemented *in* Scala. While that will use a lot of Scala structures under the hood, I'm not assuming that the end-user view has much of anything to do with that -- we're going to focus on what the users need, and figure out how to map that to the underlying language and database.

[be-well-lowell.livejournal.com]

A limit on number of tags makes sense. A special category for exactly one tag doesn't clearly fit into that sense.

If it's the by-far-most-common case, it deserves some optimizations in the user interface (but not in the underlying implementation unless there's a technical win involved).

[goldsquare.livejournal.com]

Ah.

So the question is whether a user would want to limit the number of tags on something, and have Querki enforce that limit.

I'd say no, because retrofitting that is easy: objects from before the retrofit continue to have unlimited TagSets, objects afterward have a range.

Dan's point about proliferation of "near tags" is important as well, and the Merge feature he suggests would be useful, if likely secondary to your initial implementation.

What may be useful, to address his concerns, is to find a useful UI that urges the user to use existing tags over having them create a near-duplicate without care.

We are now far afield from your question. :-)

[jducoeur]

Definitely, but there's been some useful food for thought here. I think the tag-limit suggestion is clearly the right approach to my question, and lets me see whether it's a real problem before I worry about it.

As I just replied to Dan, I very much agree about the UI for reusing existing tags. Not sure exactly what that's going to look like yet, but I may get fairly heavy-handed about it. Tagslop is such a common problem that I suspect it's worth very strong encouragement to avoid it.

And yes, I agree about Merge, although I think it needs to be viewed more holistically -- I suspect we're eventually going to want a Tag Management UI that lets you see the full tag hierarchy in your space and shove things around quickly and easily. Possibly even drag-and-drop, but I'll need to see some realistic examples before I start designing. Regardless, it's probably a year or two off.

[kihou.livejournal.com]

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.

[goldsquare.livejournal.com]

But in that case, why not have a primary name, and tag it with a set (0-infinite) of nicknames?

[kihou.livejournal.com]

For names, I'd be fine having any number of names with one marked as a unique primary, though that seems more complicated than a single-value name tag and a multi-value nickname tag. For, like, ability effects, it doesn't make sense for there to be more than one, at least with the standard way of typesetting them. And either way, I'd want it to be clean to refer to the unique primary name.

[jducoeur]

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

[dsrtao]

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.

[jducoeur]

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

[goldsquare.livejournal.com]

For that sort of versioning, look at some of the freeware code that once was the Interbase database. (Which I worked on) It's transactional model was unique.

You can't think of a tag limit issue that requires a set number of tags, only, like one? Could you use Querki to build a database of friends, say, and plan a wedding, say, and want to do assigned seating to only one table?

[be-well-lowell.livejournal.com]

My question is why "one" should be a special case in a way that "two" isn't. In my professional world, it often is because I'm dealing directly with hardware, but in this kind of UI world, a boolean choice is probably going to be represented as multiple bits anyway, so making a special case of "one" needs specific support.

[goldsquare.livejournal.com]

If you look at my earlier comments, I was suggesting there are two cases: unlimited and limited to a maximal integer quantity.

So we agree, largely.

[jducoeur]

Hmm -- interesting example. Mind, I don't think I'd use Tags per se for that: I suspect that Table should be a Model (class, essentially), and it should have a Set of Links to People. You could do it with Tags, but it would probably be more work.

(Tangent: the *intent* of Tags is mainly free-form categorization as you go. While it can be used for more structured purposes, there are lots of other types that are more optimized for those. That said, it'll be interesting to see how people use this stuff in practice, and whether Tags turn into more of a catch-all; if so, I'll probably have to do some re-analysis and re-optimization.)

But in the more general case, this is a nice argument for having the ability to limit the size of a Set, regardless of the type contained *in* that Set; Set[Tag] would just be a special case of that. I'll chew on that...

[goldsquare.livejournal.com]

Can you characterize for me the sort of relationships that a Tag might typify? Is it just to be a free-form annotation, or used to create ad-hoc collections via run-time query, or create relationships (1:1, 1:many, many:1)?

[jducoeur]

Not precisely any of the above, although the ad-hoc collections is fairly close to the mark.

A tag is, technically speaking, just a bit of short text with some restrictions on the character set. It automatically defines a page that looks much like any other Thing, which defaults to its most common use -- listing all of the Things that contain that tag. Thus, tags make it easy to navigate around via ad-hoc relationships.

Really, tags are fairly limited compared to some of the other types (especially Text, which is fairly powerful), but it has one crucial characteristic: end users can add values, and thus, add categorizations that weren't baked into the Space by the person who designed it.

The heart of the point is that tags aren't *about* relationships, although they do define some -- they're primarily about categorization, on the theory that categories in the real world are usually better discovered than pre-designed. They can be used in other ways (and based on this conversation, I suspect they will be), but that's the original design intent. That matches the way tags are commonly used around the Web today, albeit with a fair sprinkling of extra power...

[goldsquare.livejournal.com]

and thus, add categorizations that weren't baked into the Space by the person who designed it.

I think I'd revisit Tags in general, frankly, from what you've said.

But, also, from what you've said: under what circumstances would you want to restrict a Thing into having only ONE ad hoc category? Why would you want to remove a Thing from full participation in the free-for-all-party that is Tagging?

And would you want that to be one per Thing, or one per User/Thing, or whatever? The only model that pops immediately to mind is "Voting" or something like that, and that seems to be a bit of an abuse of the notion of categorization.

To me, it makes more sense, if you wanted to control what people can do with your Things, to say that "this sort of Thing cannot be tagged". And that starts to defeat some of the fun that you have described about Querki.

Looking at it another way: who does a Tag "belong" to? Who owns it? Can I, for example, decide that I want to categorize the photos that you keep in a space as "Lameass" and "Cool"? They are your photos, they are my tags - or is that not the case?

[jducoeur]

Good question, and it's a bit complicated.

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

[jducoeur]

Thinking about it overnight -- I think that I would express this "private tags" notion as "bookmarks" or "favorites". That more clearly says that these are *my* links to *your* stuff, and are private to me.

Looking at it that way, it's actually a more compelling story: I suspect we'll eventually want to implement it, and I've put it onto the Features list. Thanks for the suggestion -- that one hadn't occurred to me before. But it'll probably be a ways off...

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

[umbran.livejournal.com]

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?

[jducoeur]

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

[marphod.livejournal.com]

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?

[jducoeur]

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

[goldsquare.livejournal.com]

I was wondering that last as well. Imagine the power if Tags were Things, turtles-all-the-way-down... even if that Thing was a deliberately over-simplified Thing.

[jducoeur]

They kinda-sorta are, at least in the plan.

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

[hudebnik.livejournal.com]

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.

[mneme]

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.