Clay Shirky was the first to come up with the idea of “augmented tags”. He said it was time to upgrade from tag to “tag molecules”, adding few additional bits of information to the simple tag, like a timestamp and the dictionary authority. Then, in my previous post, I suggested to build tag molecules without inventing a new microformat like RelTag, but using the , and fields of the regular RSS 2.0 syntax.

The untold assumption was that you shouldn’t scrape tag information from html pages, tags should be defined in a more convenient environment: the RSS feed.

Later Drummond Reed suggested to define tags via XRI, a concept that lays at the core of Mary Hodder’s proposal.

The idea is that a user could tag an object […] where the tag, and the object, would then go out through the RSS feed or be spidered, with some additional information that doesn’t now exist in tags. That tag and object would include the user’s identity, the licensing for that object […] if needed, and the tag. It would remove the requirement for a tag to be coupled with the originating URL (blog post URL) because identity would be inside it.

An iTag will look like this:

<a href="http://xri.dictionary.com/=user.name*(+dog)/dog" rel="tag">dog</a>

where

• The domain name can be the DNS host name of any tag dictionary source that is able to resolve the XRI i-name following the DNS name (the string beginning with the = sign). This allows the author to completely control resolution of the tag — it can resolve to their own tag dictionary in their blog, to a community tag dictionary, or to a general tag dictionary (a la Wikipedia).
• The string starting with the equals sign (“=user.name”) and ending with the star is the i-name of the tag dictionary author.
• The string in parentheses following the star (“(+dog)”) is the name of the tag in the dictionary. By having a formal dictionary name, the dictionary can establish synonyms that software or spiders can use.
• The final segment (“/dog”) is the rel-tag-compliant tag name corresponding to this dictionary entry.

Brilliant! But this wiki page about iTags only defines them as links within an html page. Since it’s not nice to require blog search engines to go scraping the html of every single post, it’s advisable to move (or mirror) such definition of iTag in the RSS domain. Here is my not-well-thought-through idea about how a generic blog post, enriched with iTags, could look like within the RSS feed.

<item>
    <title>Tag camp</title>
    <link>http://napsterization.org/stories/archives/000564.html</link>
    <author>http://public.xdi.org/=mary.hodder</author>
    <pubDate>Fri, 28 october 2005 16:21:36 UTC-9</pubDate>
    <category domain="http://xri.napsterization.org/=mary.hodder*(+itag)/itag"</category>
    <category domain="http://xri.technorati.com/@technorati.inc*(+tagging)/tagging"</category>
</item>

The blogger of this example decided to attach two different iTags with two different dictionary authorities: herself and Technorati. It’s not difficult to envision add-ons for blog platforms that will make a snap the creation of such iTags. Think of preferences that set default dictionary authorities, think of built-in i-name resolver, …

Looking forward to have a nice module for Drupal, maybe from Autowitch, the same guy that gave us awTags.

UPDATE

Kevin Marks, from Technorati, sent in a very pertinent comment. He spotted a mistake due to the evil cut-and-paste demon in my example code. The error also prevented from understanding the chance to create synonyms with iTags. Here is my answer and here is the revised version:

<item>
    <title>Tag camp</title>
    <link>http://napsterization.org/stories/archives/000564.html</link>
    <author>http://public.xdi.org/=mary.hodder</author>
    <pubDate>Fri, 28 october 2005 16:21:36 UTC-9</pubDate>
    <category domain="http://xri.napsterization.org/=mary.hodder*(+itag)">itag</category>
    <category domain="http://xri.technorati.com/@technorati.inc*(+tagging)">tagging</category>
</item>