I just added a new category called “Open Tagging” because I’ve been having so many discussions with XRI-savvy bloggers (starting with Kaliya Hamlin and Mary Hodder) about how XRIs might be a solution for an open, distributed way of tagging content that does not rely on a single centralized “dictionary” provider (e.g., Technorati, PubSub, etc.) The open tag concept is well described in two recent posts by Stowe Boyd of Corante – the first one describing the basic Open Tag concept, and the second one going into greater detail about the requirements.

To quickly illustrate, Stowe provides this example of current tag link structure:

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

The issue, as Stowe puts it, is:

What I really want is a way to define the tags that should be associated with the post — such as “Thai”, “Cohiba Churchill”, “Restaurant”, “Gruet Blanc de Noirs”, and “Reston” — but to defer the identity of the service or services that are supposed to support the tags. (Note for programmers: this is a classic ‘late-binding’ issue as dealt with in many programming languages approaches to type-binding.)

My vision of open tags are designed to avoid the identity of Technorati-style services I might want to index my posts. For example, the Technorati tag “http://technorati.com/tags/thai” denotes Technorati as the service to handle the tag, as well as pointing to a specific page on the Internet generated by the Technorati system either on demand or in advance of an attempt to access it. Instead, my idea of an open tag relies on a relative address, like “/tags/thai”.

Stowe then provides an example of the type of what such an “open tag” might look like using existing HTTP URI (commonly called “URL”) syntax:

<a href="/tags/thai" rel="tag">Thai</a>

However a reader of Stowe’s quickly pointed out the obvious problem with this approach. Because it is a relative URL…

…the browser resolves the relative address in the URL to be a hypothetical address at the Corante server — “http://www.corante.com/getreal/tags/thai” — which doesn’t exist. Hence, a 404 message: file not found.

So what’s the XRI solution? Switch from an HTTP URI to an identifier syntax specifically developed for abstract identifiers (including generic concepts like “Thai” that don’t exist as definitive HTTP URI resources). For example, the XRI-based open tag would look like this:

<a href="xri://+thai" rel="tag">Thai</a>

What’s the “+” stand for? It’s the XRI global context symbol for generic identifiers – identifiers that represent generic subjects, topics, or concepts for which there is no central authority, any more than there is any one authoritative dictionary for the meaning of the word “Thai” in the English language.

So how would an XRI-aware browser (or search engine) deal with this tag? Exactly the way Stowe intends. Because the author of the tag did not put “+Thai” in the context of any specific dictionary service, the instruction to all service providers is: “interpret this tag as the generic meaning of the concept ‘Thai’.” Each service provider can then consult their own dictionary service to provide further understanding/mapping/linking of this term. Or they can use a shared community dictionary service from organizations like Wikipedia or XDI.ORG.

Better still, XRI syntax allows an author to declare a explicit dictionary authority for a +word if they choose to. For example…

<a href="xri://technorati.com/(+thai)" rel="tag">Thai</a>

…would tell interpreters of this tag that the author is referring to the generic concept of “Thai” in the specific context of the dictionary provided by the authority “technorati.com”. The author can cite any authority they want, including themselves. For example, the following two examples would be two different ways of citing myself as the dictionary authority (the first using a DNS domain name address and the second an XRI i-name address):

<a href="xri://equalsdrummond.name/(+thai)" rel="tag">Thai</a>
<a href="xri://=drummond/(+thai)" rel="tag">Thai</a>

Finally, to provide backwards-compatability with existing HTTP URI infrastructure (i.e., until the XRI scheme is understood natively by browsers), any XRI can be transformed into an HTTP URI using an XRI proxy resolver such as the one publicly available at XDI.ORG. For example, the second XRI above could be turned into a “clickable” link today using this proxy resolver by expressing it as:

<a href="http://public.xdi.org/=drummond/(+thai)" rel="tag">Thai</a>

There are even more features that XRI brings to the complex problems of tags, ontologies, and shared meaning (especially the concept of synonyms, for establishing equivalence of concepts across communities and even across human languages), but that’s enough for one post. The best part is that XRI syntax is quite mature. The OASIS XRI TC is preparing the second Committee Draft of the XRI 2.0 specs right now for a full OASIS vote this fall. Identity Commons has already started to i-name enable WordPress. Since no registration authority is required for the XRI + space, open tagging with XRIs could start happening organically as fast as taggers decide to start using it.

To discuss open tagging with XRIs, contact me via my i-name contact page at =drummond.