On tags (in the taxonomy sense) in Atom
In Tag Scheme?, Tim Bray wonders how to make it explicit that a particular
atom:category element is a tag (in the taxonomy sense – i.e. he wants to tag an entry “tagging” or “ethiopia” or “lisp”). This leads him to come up with a new URI scheme,
urn:tag:. I didn’t comment on his post initially because the idea seemed so obviously ill-conceived that I assumed there must be something I’m missing. But after following the comments and seeing his update and comment, I still can’t see the merit.
Above all, I fail to see what kind of information one can infer from the presence of a scheme attribute with
urn:tag: in it that is in any way distinguishable from the information inferrable from the absence of a scheme attribute. Given that Atom provides no way to specify any relationship whatsoever between two category elements, I fail to see how you can express anything other than tags with an
atom:category element in the general case (where the consumer has no knowledge of the scheme built in).
Incidentally, for my del.icio.us-API-to-Atom converter I chose to associate each tag with the entry for a link in the following way:
<category scheme="http://del.icio.us/ap/" term="atom" />
That seems far more useful to me than using
urn:tag: would be, because tags really convey two different pieces of information – primarily their string value, but secondarily which person used it to describe a particular thing. Losing the secondary piece of information makes the primary piece much less interesting. Even the mere knowledge that a particular tag was used by someone on del.icio.us vs someone on YouTube is still valuable because the major audience at each site is quite different. For this reason,
http://www.tbray.org/ongoing/Tag/ in Tim’s feed would be far more useful than the mute and featureless
Aside from that, it seems to me the entire argument has been conclusively debunked by Norm Walsh. I think the sort of desire that Norm argues against arises because HTTP URIs are explicitly opaque and people are told they shouldn’t try to parse them; so the desire arises for a way to communicate that, say,
http://isbn.nu/1558607013 refers to ISBN 1558607013, or likewise that
http://www.tbray.org/ongoing/Tag/Tagging refers to the tag “Tagging.” Such uses are probably more appropriately addressed in the general case by providing a URI template to specify how to extract the embedded information.
But in this specific case there is another possibility: to do the same thing as in HTML:
<a rel="tag" href="http://www.tbray.org/ongoing/Tag/Tagging">Tagging</a>
This translates directly to Atom:
<link rel="tag" href="http://www.tbray.org/ongoing/Tag/Tagging" title="Tagging" />
tag relationship effectively implies a URI template which says the last part of the path component is the tag.
Of course, there is no registered
tag relationship in Atom, and since RFC 4287 is stricter that the HTML recommendation about relationships, in reality it would either have to be registered first (which is the same overhead as for conjuring the
urn:tag: scheme into existence) or everyone would have to agree on a particular full URI to use for the relationship. Well, and there’s the minor detail that no current aggregator on the planet would support this type of link for a while to come… however, support for special treatment of categories with the
urn:tag: scheme (if, as I wrote above, there even is any useful support to provide) wouldn’t spread any sooner anyway. The only difference is that one style has a default presentation in aggregators and the other does not.
In the meantime, however, no one says you can’t simply put the HTML version right there in the entry content (which, hey, gives you Technorati support as a bonus, right this instant) and a schemeless category tag in the entry next to the link (which, hey, gives you as much aggregator support as you’ll ever get in the category element, right this instant).