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

The Perfect Tagging UI

Enough whining. I'm going to try to be constructive by listing what are the behaviors that will make me fall in love with a tagging thingie:

1. Clearly mark the tag boundaries
   
   • Why? we still have a mess with different conventions regarding what separates tags - spaces, commas, semicolon, ... until we figure out it, we need a way to provide a visual hint to the user whether they got it right or wrong.
   • Reasonable: Flock. Tags are comma-separated; whenever you type the comma, the previous tag is visually surrounded by a gray bubble indicating that it's a "single unit".
     
   • Bad but not awful: Flickr. You can't tell as you type the tags if you got it right or wrong, but when you click the "Add" button, you get immediate visual feedback by inspecting the tags list above the entry line.
   • Terrible: Zoundry (which other then this is a pretty cool product, I am using it to write this post :). You won't know if you did it right or wrong until you see your post
     on the blog...


2. Support copy and paste of tags
   
   • there, and paste them here. Using a standard copy-and-paste interface, mind you.
   • list, but selecting the tags in the list is hard, and pasting them results in a mess.
   • Good: delicious.


3. Auto-complete
   
   • Why? I love tagging, they make life easier. I don't like typing, it makes life shorter.
   • Reasonable: blinklist.
   • Bad: RawSugar. The auto-suggest does not follow well with the typing process. I can't press enter to choose the currently selected auto-complete suggestion and then proceed to type the next tag. I am forced to leave my typing context to select the tag, and after it's selected, to use the mouse to move back to where I was in the tagging line.
     
   
   
4. Auto-suggest
   
   • Why? I'm not always in the mood to generate tags. Sometimes I am feeling lazy. Comeon, you know so much about me and about other users, use it to make my life easier, not just the search engine life :)
     
     • Based on tags that I've often used together with the tags I've already typed
     • Based on tags that other users often use together with the tags I've already typed
     • Based on tags that other people who tagged this page used
       
   • Good: delicious
   • Bad: Flickr


5. No hierarchy, classification, or anything else that disrupts the cognitive process
   
   • Why? Because I find it distracting. And I have a good excuse for this :)
   • Good: Flickr
   • Bad: RawSugar
     


6. Ability to edit tags like text
   
   • Why? because I make typos and change my mind, and I want to be able to quickly go back during the tagging process (or later) and fix it
     
   • Good: Flickr, Delicious. Though none of them makes it too easy to edit the tags once they are submitted.
     
   • Bad: Flock. The visual bubble around the tags, which I mention in #1, really gets in the way when you see a typo in a tag you just typed and you want to fix it.
     


7. Search previously tagged items with an already-typed tag without disrupting the tagging process
   
   • Why? Because I'd like to borrow the tags I used when I tagged related items in the past
   • Good: Flickr. Modless tagging interface, I can always open a new window and search.
   • Bad: Flock (modal dialog...), Microsoft Live Favorites.
     

Funny, if you scan the "Bad:" examples, you'll note that the application that I am pretty much addicted to - Flickr - scores pretty high on the Bad list. Which kinda puts my rumbling in perspective :)

Technorati : Zoundry, delicious,favorites, flickr, flock,folksonomy, microsoft live,rawsugar, tag,tagging, web2.0
Del.icio.us : Zoundry, delicious,favorites, flickr, flock,folksonomy, microsoft live, rawsugar,tag, tagging, web2.0