Equals Drummond

I just got back from Internet Identity Workshop 2006A (the “A” because a second one is planned later this year). I want to echo the praises others (Phil Windley, Kim Cameron) have heaped on it. In particular, Kaliya was amazing. You want to do an unconference? She’s the one to call. The whole unconference format showed just how effective it can be to let a motivated audience self-organize.

Following are a few highlights from the sessions which I was able to attend (my only complaint was that there were so many I couldn’t attend ’cause there just wasn’t enough time!)

• The i-tags session, wonderfully blogged by Christine Herron, produced some excellent ideas and feedback about the third draft spec. Ben Laurie had some great suggestions too. It’s finally time to ramp up a mailing list, which we’ll be doing shortly.
• The identity rights agreements session, which I’d been anticipating for several months now, was every bit as fascinating as I thought it would be. Again, see Christine’s post for a summary. The biggest frustration was that after an hour and fifteen minutes we were just really getting started – we needed a good half-day on the subject. But we agreed to begin moving the work forward on the Identity Rights wiki and mailing list. I’m also planning another blog post inspired by the final part of the discussion.
• Dale Olds of Novell led an eye-opening session on all the open source projects related to digital identity. See this blog post by Phil for more info.
• Phil did a great session on the reputation system he and his BYU students have created. It shows just how difficult reputation can be — and how valuable if we get it right.
• The XRI and SAML Single Sign-On (ISSO) session given by Peter Davis produced excellent feedback on the draft spec (to be posted on the XDI.org wiki as soon as Peter can deal with some formatting issues) from such SAML experts as Bob Morgan, Eve Maler, Jeff Hodges, and Nick Ragouzis.
• A testiment to just how densely packed the sessions were was the fact that I missed the session on Identity Commons 2.0! But reports from those who made it are that the ball moved further forward and the necessary organizational steps are already underway.
• The final highlight — which we couldn’t even squeeze in until after the conference was over — was being able to get in front of a whiteboard with Paul Trevithick and Andy Dale and produce a picture of how Higgins and XDI fit together (captured by Phil when he and Doc and Kaliya joined us). The conclusions we reached were a real eye-opener, one for which I’m going to do a separate post to do it justice.

Net net: as Phil Becker summed up in the Digital ID World newsletter (as quoted by Kim):

“…it was, in my opinion, a tremendously significant moment in the evolution of the identity conversation, and one that will have many significant ramifications going forward – though these will likely take another year to become clear to those not paying close attention.”

It’s been six months since I’ve posted anything about i-tags but the spec has been steadily evolving. Working Draft 03 has been posted on the i-tag wiki and there are some great new features. Quick highlights:

• The underlying RDF model has now been abstracted so it can be represented as either as microformat XHTML or as micro content XML (although only the former is defined in Working Draft 03 because the latter still lacks sufficient documentation).
• The new microformat defintion uses the XHTML div tag and class attribute to structure the tag as a series of links. This pattern, which editor Andy Dale suggested several months ago, has become a widely-used microformat design pattern.
• An i-tag is now divided into a header section and a body section. The header section consists of a set of links that use pre-defined classes (id, subject, author, publisher, verifier, date) to describe the i-tag itself (the RDF subject). The body section consists of a series of nested links that use globally-unique identifiers to identify the RDF predicate (the tag type) and RDF object (the tag value). This means i-tags can express an infinite variety of tag types all using the same simple format. See the spec for examples.
• All the globally-unique identifiers used for subjects, predicates, and objects in i-tags can be either URIs, IRIs, or XRIs.
• I-tag verification is now defined in detail, including both direct authentication using Yadis for authentication service discovery and third-party verification using an independent verification authority such as Opinity.

I-tags will be a topic at this week’s Internet Identity Workshop in Mountain View, CA. All the spec editors (Mary Hodder, Kaliya Hamlin, Andy Dale, and myself) will be there. Please join the session if you can, or send us feedback if you can’t attend in person.

A conversation with Stowe Boyd reminded my of Clay Shirky’s recent piece called “Ontology is Overrated — Categories, Links, and Tags“.

I can’t recommend this highly enough to anyone interested in open tagging. Clay makes a great case why the del.icio.us-style approach to social tagging is inevitable (and smarter than any central authority could ever be).

Stowe Boyd makes a good point about the key adoption hurdle for open tagging:

However, the assertion that we can start merrily open tagging (tra la) with XRIs fails one critical test: I would like to have taggregators like Technorati accept these tags as equivalent to the closed URL-based tags currently in use. Without that major shift in the tag ecology, XRIs have a long road before migrating into general use.

I couldn’t agree more – XRI can solve the technical part of the open tagging challenge, but not the social part. I would offer this thought: given that almost by definition any Open Tagging standard (de facto or official) must not require a single central dictionary authority, it presents the classic open systems challenge: which of the current taggregators is going to migrate to a truly open dictionary until they are forced to? And if so, what would that forcing function be?

Until that question is answered, Stowe’s right — we won’t have open tagging.

In response to my post yesterday on using XRIs for “open tagging”, Darren Chamberlain had this comment:

I wonder why simply using urn: URIs is not sufficient to identify a tag. From your example, the Thai tag could be:

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

Tag-aware services such Technorati could simply extract these URIs and treat them like appropriately. (I haven’t seen anyone suggest using urns for tags, although I would be surprised if someone hasn’t already thought of it.)

Darren’s point is well taken, and indeed one of the most frequent questions about XRIs is “how do they differ from URNs?” The short answer is that although they don’t use the “urn:” scheme name or scheme format, XRIs are effectively a superset of URNs. To quote directly from the XRI Syntax 2.0 Committee Draft specification:

Although an XRI is not a Uniform Resource Name (URN) as defined in URN Syntax [RFC2141], an XRI consisting entirely of persistent segments is designed to meet the requirements set out in Functional Requirements for Uniform Resource Names [RFC1737].

I could go on at great length about the differences between XRIs and URNs, but the easiest way to sum it up is that URNs were designed to meet the requirements for a specific type of abstract identifier — one that is persistent for all time and will never change — while XRIs are designed to satisfy the requirements for all types of abstract identifiers, both persistent and reassignable.

That means XRIs offer several additional features that URNs don’t, such as:

• Synonyms. The XRI resolution protocol has explicit support for identifying the other XRI synonyms (either persistent and reassignable) for a resource.
• Global context symbols (GCS). XRIs support five standard symbols that extablish the global context of an identifier authority (for example, “+” is the GCS for generic concepts, i.e., the “dictionary” or “tag” space).
• Cross-references. XRIs offer syntax that allows any XRI (or a URI) to be expressed in the context of another XRI. I gave an example of this in the previous post where I showed how an open tag could be expressed either in a global context (first example below) or in the context of a specific dictionary authority (second example below).

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

• Generic, extensible HTTP-based resolution protocol. While some URNs do not need to be resolvable (such as ISBN numbers, in many cases), others do. But there is no generic URN resolution protocol — only specialized resolution protocols for specific URN namespaces. Thus if we wanted to create a “urn:tag” namespace and it needed resolution (and there are many good reasons you may want to resolve a tag), then it would mean defining yet another URN resolution protocol. XRI infrastructure solves that by providing a generic HTTP-based resolution protocol that is extensible to the many different types of metadata and services that one might want to associate with an abstract identifier, and which will work for all XRIs, not just URNs.

So, while Darren is absolutely right that URN syntax could be used for open tagging, XRIs are (in my highly biased opinion) even better suited for the job.

In my previous post I summarized a way to use XRIs for “open tagging” of blog entries and other content due to numerous pings from other bloggers about this subject — only to find out that my XRI TC co-chair Gabe Wachob had already blogged the exact same answer lastJanuary!

As usual, Gabe’s two steps ahead of me. That’s why he makes such a great co-chair.

Incidentially, for those who might be wondering, the XRI TC is currently incorporating feedback from several very interested parties on the XRI 2.0 Committee Drafts published in March. One of the main subjects being expanded on in the revision is backwards-compatability of XRIs with HTTP infrastructure using HTTP proxy resolvers. Since this has everything to do with making XRI adoption easy and painless (including adoption of XRIs for open tagging), it makes sense to do it thoroughly. But we expect to be done soon and into a full OASIS vote this fall.

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.