Standartizing Tag Semantics

striatic has been leading for several months a brave attempt on the Flickr discussion board to standardize the usage of certain tags.

Several similar discussions went on in the del.icio.us discussion list. Suggestions for a wiki-like solution to organize such an effort keep coming up.

There are some things that tagging systems could do to reduce the effort associated with this, without losing the value of free-form, tag-with-whatever-comes-to-mind tagging.

Some of them can be done in the backend, when searching for tags (like stemming). However, there are probably more things that such systems can do to encourage users to choose the more standard tags.

For example, using the same logic used by the Flickr clustering algorithm, when a user tags an item with "SF", the system could - after letting me use the SF tag - make a suggestion:

The "SF" tag often stands for "San Francisco". The "SF" tag was used 36,717 times, while the "San Francisco" tag was used 214,347 times. Would you like to add the "San Francisco" tag as well?

As more and more users join the tagging circles, thought should be given to the scalability of the model - it is in everyone's best interest to reduce the number of tags in the tag space. Well. Except maybe for Oracle and MySQL :)

Technorati : delicious, flickr, semantic, standard, striatic, tag, tagging
Del.icio.us : delicious, flickr, semantic, standard, striatic, tag, tagging

tagstd:recap <tagstd:recap>

I've had some interesting comments from several folks regarding the tagging standard ( & follow up) I've proposed a few days ago - thank you! I'd like to try to address some of them here.

• On a general note, I'd like to note that the list of predefined values for the rel attribute is defined in the HTML4 specification. Obviously it does not include "tag" as predefined value.
  The specification however explicitly permits defining new values for the rel attribute (though it recommends that in this case the conventions used will be cited in the profile attribute of the head element).
  So, technically speaking, using rel="tag" is OK from HTML point of view. But, putting aside the spec, why take the risk of using a non-universally-accepted value when we don't have to? I don't really see why "
  <a tagstd:rel="tag" href=..."
  is significantly more usable then
  "<a rel="tag" href=... "
  and that would already be a big improvement in the robustness of RelTag.

Kevin Marks (from Technorati, and who is credited with the concept of Rel-Tag) raised some great points:

Mixing data and representation is by design. If the tags are embedded in the content they don't get detached (link)

I agree, this is a worthy cause. But, there are several different options for embedding the tag in the contents, and some of them provide the ability to embed the tag in the content without mixing data and representation. For example, using
<span tagstd:tags="tag1 tag2 tag3">content here</span>
would get the job done just as well. (though using span has other drawbacks though).

Redundancy is not a problem in practice (I have 18 million examples). (link)

While it's hard to argue with 18 million examples :), it'd be interesting to know - does the Technorati crawler verifies a match between the tag as indicated by the URL postfix and the tag as indicated by the link text?

When you do cut-and-paste, you get cut-and-paste errors, that's one of life's most basic truths, second only to "if you use 1.0, it will crash".

Usability: straw man argument here. Bloggers know how to make links. Adding rel="tag" is very easy to remember. In any case, if a tool is generating it this is moot. XML is no more robust. (link)

Hmpff. I beg to differ. Bloggers != HTML coders.

For people who click "new post", write their thoughts, and then click "Post", the rel="tag" is not only not easy to remember, it's also.. well. They pretty much have no idea what we're talking about :)

Now this of course could be solved by tools. But, if we rely on a tool, why don't we choose a format that assumes a tool (though it can still be added manually).

I am not sure why you're saying that XML is not more robust. XML can be validated against a schema, assuring 100% match between the expected syntax and the actual syntax. And even if a schema is not used, the mere fact that XML supports namespaces solves a lot of problems. Even just defining your own tagstd:rel attribute instead of using the HTML standard rel attribute would be a huge improvement in robustness IMO.

Tag Spaces: these are there for disambiguation, and to provide alternatives. You should pick an appropriate one for each tag, bearing in mind that it should make sense to your readers if clicked on. See your own complaint of redundancy supra. (link)

I am not clear on this point, disambiguation of what? and alternatives to what?

Let's keep in mind that the whole tagging thing is about a flat namespace, in which all tags start as equals. That's the beauty of tagging. And, when we do want to disambiguate them, I doubt it will be done by URLs.

Let's admit it, everyone reading this blog is probably an early adopter to some extent. Let's try to imagine what will the tagging world look like when the dust settles down a bit. I'd guess we'll have 3-4 "tag collections" web sites, with direct tagging and tag-lookup support integrated into the browsers, and lots of non-technical people using this.

I'd guess that for them, the right thing to do is that when you'd like to look up a tag (e.g. find all "things of type X" associated with this tag), they'd want that it would be them who decides - at "run time" - which repository to use to look up the tag, not the one determined by the author.

Scope: this is deliberately left unspecified in the rel="tag" definition.

Just wondering, what is the issue that not defining scope was meant to avoid? Also, as pointed out by Kevin, while the Rel-Tag spec avoid this, the other microformats use facilities such as the class attributeto define the scope. Again, according to the specs, this is ok. But there are practical questions to ask... what would prevent a CSS developer from defining a CSS class "tag" and using it? How would the tools and the browser resolve the conflict? and the biggest question... why not reduce the chances of a conflict from happening at the spec level. A very simple solution would be to use class="tagstd:tag".

Also, it should be noted that the input from Priyantha, from Zoundry, which is the tool I'm using the write this post, express confidence in the Rel-Tag (and the other microformats). Also, Hendrik responded to Eran's comments indicating that in his opinion, a tagging standard should not assume any changes in the (X)HTML specs, and should in fact be independent from HTML.

Technorati : KevinMarks, Technorati, Zoundry, blogger, folksonomy, html, relTag, specification, standard, tag, tagging, tagstd.org, technorati, web2.0, xml
Del.icio.us : KevinMarks, Technorati, Zoundry, blogger, folksonomy, html, relTag, specification, standard, tag, tagging, tagstd.org, technorati, web2.0, xml

More on a tagging standard

More on a tagging standard.

Rel-Tag (a.k.a relTag) is a de-facto standard for tagging a specific page. Rel-Tag was defined by Tantek Çelik, following a concept from Derek Powazek and Kevin Marks. It is part of a larger collection of microformats - a wonderfully practical approach to building a practical semantic web.

To tag your page with a Rel-Tag, you just include a link and use the attribute rel="tag" on the link:

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

It doesn't matter what page the URL points to, as long as it ends with the tag name.

Incredibly simple. Paste this piece of HTML into your page, and your page is tagged, and indexed as such by services that support this convention, such as Technorati.

I do share Kevin Burton's feeling though, that the Rel-Tag specification is somewhat lacking (or, as Kevin defined it, under-specified).

Points to consider:

• Mixing Data and Representation
• • relTags are easy to create by hand (at least, assuming that you know HTML). They're even easier to generate by an application that supports them (such as Zoundry). But once generated, relTags are not just metadata, they're actually part of your content. So it becomes very hard to build a tool that edits them. You might have used these links in your content. You might have moved them around. You might want to change the link text but keep the tag. It becomes messy. Last time checked the problem of separating data from representation in a practical, widely supported manner was already solved.
• Redundancy
• • The tag is repeated twice, once in the URL and once in the text. Wanna bet how quickly these two get out of sync?
• Usability
• • relTags are very easy to use, if you know how to access and edit your HTML. But, if you know that, there isn't much difference between editing a "<a href" tag to add the rel="tag", and between cutting and pasting a piece of XML to achieve the same goal. And if you don't know HTML, both are equally inaccessible. So, end-user usability being pretty much the same, why not choose a more robust solution?
• Tag Spaces
• • According to relTag, the actual URL you use point to any page, as long as that page is a "tag space", loosely defined as "a place that collates or defines tags". The spec goes on to inst that tag spaces can be used to provide a specific meaning to the tag. What does this mean? Is it a method to tag tags? A categorization system? A meaningless technical detail? These questions are too big to be left unspecified. The obscurity of this is leading to people (e.g. me :) repeating the tags multiple times, for each one of their favorite "tag spaces" (and to some cool gizmos).
• Scope definition
• • relTags are used to tag the text that includes them. They do not carry with them a scope definition, so it would be hard for tools (or people as a matter of fact) to understand if these tags refer to the entire page, or to a specific section in the page (or post in a blog).

It'd be great if a more general and robust tagging standard would support relTags for backward compatibility.

I've been playing with the tagging format I've suggested in a previous post, and found some changes that should be applied to it in order to make it more useful. But this post is already getting way too long, so more on that later :)

Technorati : KevinBurton, Rel-Tag, Tantek, Technorati, Zoundry, folksonomy, microformats, relTag, semantic web, standard, tag, tagging, standard, specification
Del.icio.us : KevinBurton, Rel-Tag, Tantek, Technorati, Zoundry, folksonomy, microformats, relTag, semantic web, standard, tag, tagging, standard, specification

Toward a tagging standard

How come we still don't have a standard for associating tags with content?

We've got delicious and friends tagging entire web pages, and Technorati tagging blog posts. Flickr tags pictures. But how different are they really from each other in this aspect? Do we really need a propriety way to express the association of a piece of content with tags?

How's about something along the following lines:

Tag a piece of content:

<tagstd:tagged tagstd:scope="children" xmlns:tagstd="http://tagstd.org">
<taglist xmlns="http://tagstd.org">
<tag>tagging</tag>
<tag>folksonomy</tag>
</taglist>
<p>This is a long blurb about our favorite topics:</p>
<ul><li>tagging</li><li>taxonomy</li><li>web 2.0</li></ul>
</tagstd:tagged>

(scope="children" indicates that the tagged content is the children element of the tagged tag).

Tag a link (in fact, tag the resource that the link is pointing to):

<tagstd:tagged tagstd:scope="resource" xmlns:tagstd="http://tagstd.org">
<taglist xmlns="http://tagstd.org">
<tag>tagging</tag>
<tag>folksonomy</tag>
</taglist>
<a href="http://www.hyperorg.com/">Joho the Blog</a>
</tagstd:tagged>

(scope="resource" indicates that the tagged content is the resouce expressed by the first non-comment element, which is a child of the tagged element.

What do you think? Good? Bad? Reinventing the wheel?

Let me know.

Technorati : blogger, delicious, flickr, folksonomy, html, standard, tag, tagging, tagstd.org, xhtml, xml
Del.icio.us : blogger, delicious, flickr, folksonomy, html, standard, tag, tagging, tagstd.org, xhtml, xml