Kevin Marks wades in on the discussion about open tags at Many-to-Many:

Jeff Jarvis called for decentralised tags and restaurant reviews, and Stowe Boyd posted some ideas about how to achieve this.

Unfortunately, Stowe misunderstood how the existing open, decentralised tagging model works, and went off into a design dead-end because of this.

Hmmm. I'm not sure that it is a dead end, although it's clear that what I am proposing as an open tag model is currently not what has been implemented by Technorati and other tag services.

Kevin goes on:

Stowe confuses the tagspace linked to (which provides the context for the meaning of the tag), with the services that can index the tag. These are completely independent. You can link to Technorati, your own site, Wikipedia or anyone who provides a tagspace with a URL that ends in the tag you want - for example:

<a href="http://www.corante.com/getreal" rel="tag">Get real</a>

<a href="http://en.wikipedia.org/wiki/decentralisation" rel="tag" >decentralisation</a>,

<a href="http://technorati.com/tag/Stowe Boyd" rel="tag" >Stowe Boyd</a>

Actually, I never said that wasn't how today's tag URLs work, I just never explored all the flavors that Kevin identifies, because generally I don't think they are what people want to do.

Mostly, people have been using tag URLs that point to a term in the Technorati or other tag services, like so:

<a href="http://technorati.com/tags/thai" rel="tag">Thai</a>

or alternatively, they might collapse categories and tags at their blogs:

<a href="http://www.corante.com/getreal/tags/thai" rel="tag">Thai</a>

This other sort of declarative tags, one that points to some other place on the web while allowing a service like Technorati to discover the relation being asserted -- like the "Decentralization" tag being associated with a decentralization entry in Wikipedia -- is potentially helpful, but like the more usual forms of tag declaration, they suffer from the same problems:

1. The use of a URL to define the tag means that it has to point to somewhere, and that somewhere is defined at the time of writing. What I am striving for is a means to assert the relationship between the posting and the tag, not a place for a URL to point to. Using a URL as the denotation for a tag has boxed us into the need for it to point somewhere. Telling me that I can have it point anywhere doesn't help, because I don't really want to point anywhere.
2. The overwhelming volume of tags that have been created in blog posts are of the 'points to Technorati tagspace' form. This basically cedes control of the tags to Technorati and other services.
3. The second most common form of tag declaration is within bookmarking services, like Del.icio.us, where the user asserts a tag relationship between a tag, like "Thai", and some location on the web, or a similar sort of association between a tag and a picture, at a photo service like Flickr. But there is no manual creation of the tag in the URL: the bookmarking service handles the links, behind the scenes. [Note: I looked at the page source for a Del.icio.us tag, and there are no 'rel="tag"' elements there, so presumably they aren't using the microformat style for tagging.] This likewise puts the tag in the control of the bookmarking or photo service. Note that there is no way that I could adopt this Del.icio.us model for tagging my own posts, because then there would be no reference in my post to the tag.

Kevin also suggests I am approaching the problem in a wrongheaded way:

Stowe then spends a lot of space worrying about the problem of where he links to, as if this is set in stone at the time of posting. This is not just premature optimisation, it's optimising for a nonexistent problem. Because you control your own data on your own blog, if you later decide to link to a different tagspace, you can change your own links; you don't need an elaborate and fragile RSS hybrid with mandated behaviour to do so.

I think Kevin is too close to the problem that he doesn't see what it is. He is set on telling me that I don't understand how tags work, and how bloggers can use them. I am trying to explain a model of how services like Technorati should -- no, must -- work in the future for tagging to scale up to what we need it to be.

He states that since I control the text at my blog where I am making the tag declarations, then I have control of the 'data', and later, I can decide to link to a different tagspace. The problem is simply that I don't want to have to change the text that declare tags later to have them work for other tagspaces: I want the other tagspaces to point at my blog entry without me editing anything.

And, yes, I grant that the tag services of today and tomorrow can read and make sense of explicit tag declarations that point to Technorati or other services, to my own collapsed tags/categories tagspace at Corante, or even to random locations on the web like the Wikipedia example, but given that I am really trying to create a link to the tag, hanging in a universal tagspace, not a physical location on the web per se, why are we using hyperlinks in the first place? (Although I have built this entire argument based on the premise that we have already come too far with tags to rethink that questionable notion.)

And Kevin -- and various others (see Ryan King's comment on Jeff's post, for example) -- seem to ignore the second part of the proposed open tags model: the operational model of the tag services is backward. I don't want to encode a link from my blog to a tag entry at Technorati, or an entry at a Dinnerbuzz restaurant review page: I want those services to a/ create the links from those entries to my blog (which Technorati and others do, so long as I ping them), and then b/ create the trackbacks at my blog that point to those Technorati or Dinnerbuzz entries (which they do not do, today).

Let me dig into that last point more deeply, because I think it is a core element of the transition that I am advocating. In the open tag approach I am advocating a tag I create in my blog entry is the declaration of a relationship between that entry and that universal tag: a link between my blog post and "Thai", now and forever, independent of the services that may or may not acknowledge that link. Later on, immediately after I write the post or perhaps years from now, sevices may discover the declared link, and take action on it: creating a Dinnerbuzz entry in the list of entries associated with that specific Thai restaurant I wrote about, for example. The second half of the convenant between the service and the writers that declare the tags should be this: the tag service should create both an explicit link to the blog post being referenced, and a trackback ping should be sent to the corresponding blog entry.

That trackback will automate the second part of the tag link: and it is a one to many relationship. I create a tag declaration in a post and that can lead to an unlimited number of pointers to other, who-knows-what-they-are tag service entries, lists, or whatevers. (Yes, I know that many blog technologies don't implement trackback. Well, it is another immensely useful standard, and they should, and they all will in time, I suspect.)

Today's services expect us to either do all the work of linking from our posts to their tagspaces explicitly and manually if we want the references to exist in the post. I have to point to the "http://technorati.com/tags/thai" if I want readers of my writing to know that Technorati is pointing back at my entry.

The restaurant review also sheds light on another complexity that today's tag model handles badly. I can safely assert the Technorati tag "http://technorati.com/tags/thai" in a post, because I know that Technorati will create a tag list once it spiders my blog entry, and the URL will resolve appropriately. But when I write a review with what are intended to resolve to a unique identifier for a "Thai" "restaurant" called "Thai Luang" in "Reston" "Virginia" and say it was a "4 out of 5", there is no possible way I can guess what the actual, physical location on some hypothetical, or many hypothetical, tag-based restaurant review services will be. But when the idealized Dinnerbuzz finally begins to collate reviews of my favorite Thai restaurant, it will have a physical location: perhaps a dynamic one like "http://www.dinnerbuzz.com/query?reston+virginia+thai+thailuang" or a static one like "http://www.dinnerbuzz.com/US/virginia/reston/thai/thailuang". But I don't know what that location is at the time of writing, nor should I have to. And I don't want to manually go back and add it to the post years from now. The idealized Dinnerbuzz, or a future Technorati, should acknowledge the creation of the link pointing to my entry by sending the appropriate trackblack ping, and that will put the URL in my blog post automatically.

I also think that the current model of registering the tags -- pinging Technorati, and waiting for the service to spider the site -- is silly. We should use a simple RSS registration model, and provide the tags in the feed, explicitly marked. This would make things simply and faster. (As an interesting sidebar, the implication is that authors can limit the exploitation of their tags only to services to which they have explicitly registered. I'll leave that for another post, though.)

Instead of grappling with the big picture dynamics of the model I propose -- the problems in static and closed tag declarations, and the need for a trackback-based tag acknowledgement, in particular -- Kevin seems to be suggesting that everything is fine, just leave it to him and the other experts who have concocted the current mechanism that they have implemented in services like Technorati.

Marc Canter comes to my defense:

[from Hey Kevin]

[...] if smart people like Jeff Jarvis and Stowe are calling for it - then there must be something to their complaints. By defintion is somebody bitches about something - there has to be SOMETHING there - right?

Your retort implies (as I happen to know) that Technorati has figured out that having the Technorati domain in the tag URL is not the ONLY way to do it - so you're speaking the right line - now.

But that's NOT how it was launched and so subsequently - everyone still uses the original code you guys distributed which DID use the Tehcnorati domain in it. No amount of backpeddling will change that.

So now you have the problem of the mis-conceptions that Jeff and Stowe have harped on. Sorry - it's not my fault, I'm just pointing out - what's up. (This is where I say "Don't shoot the messenger" - I love Technorati - and I'm just trying to make sure you realize what it's like - for us.)

Thirdly - though I totally understand you and grok you and have been through this with Tantek, Matt, Rohit and others - I STILL wanna point out that the technique you refer to - is just ONE way to use, store and access micro-content.

I sure hope you guys and gals are open minded to OTHER techniques for sharing, tagging, aggregating and in general - pushing RSS beyond it's current limits. I call it micro-content. Others do too.

Somewhere in there - your cult decided to call it microformats. Kevin - you and I have been around too long to care about what it's called - 'cause we ARE talking about the same thing! Right?

Briefly stated - we need microcontent feeds.

We need shared servers.

Life isn't ONLY about search engines spidering and indexing microformats. That's an approach a SEARCH ENGINE company would take - DUH! But to me - I want MORE than just search engines storing micro-content and that means they have to access, store and index this m-c via feeds, pages and legacy systems - as well.

Well, I haven't swallowed the microcontent kool-aid, either, but I concur with Mark on the thrust of his comments: this stuff is too important to leave it in the hands of the engineers and entrepreneurs. This has to be a solution that works for us, does what we need it to: the bloggers, the individuals, the hypothetical beneficiaries of this social architecture we are busy creating one tag at a time. If we leave it to others, however benvolent they may be individually, collectively their interests are not ours, their motives and needs are not ours, and we will get something other than what we want, especially when we aren't sure of what we want. And perhaps what is implemented will serve our needs, but perhaps it won't. And then, they may not turn out to be benevolent, and we may wind up with something that serves their needs, and ours not at all.

So we need to have a truly open tag model, which I define as one that meets the implicit convenant with the tag creator: a covenant that we will need to make much more explicit. But it will not be condensed, as one critic to my earlier post stated, into "RTFM" (read the fucking manual). We need to create the operating manual of what we need, and hand that to the engineers, not the engineers telling us what they have implemented and how good for us it is.

This discussion is a big step forward toward that, but we have a long way to go, judging by the positions that are being taken in this and the related posts and comments in the thread.