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]

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