Private URI Schemes

This page contains a draft proposal for a framework whereby private URI schemes used in TEI attributes with datatypes of data.pointer can be documented and dereferenced.

The Problem

For some time now, we have been discussing the use of "magic tokens" in attributes such as @key. Magic tokens are problematic because they are meaningful only within the context of a specific project (@key "provides an externally-defined means of identifying the entity (or entities) being named, using a coded value of some kind"). We currently suggest that @key attributes be documented through the use of a <taxonomy> element in the TEI header. However, documentation in this way does not provide a machine-readable method of dereferencing a key.

Actually, the recommendation to use <taxonomy> was removed in revision 10404 per offline discussion with Lou. I had inserted this based on the Best Practices for TEI in Libraries but have made a note at Future changes to Best Practices for TEI in Libraries to revisit that as well. (Kshawkin 23:15, 27 June 2012 (EDT))

On several occasions, Council has discussed discouraging the use of @key and friends in future, and encourage instead the use of private URI schemes instead. There are many good arguments against the use of private URI schemes (see for instance URI Schemes at the W3C -- but as long as they are restricted to a specific project and well documented in that project, the approach seems a reasonable alternative to magic tokens.

The new preferred approach are "tag URIs" as described in RFC 4151. See comments on soft deprecation of @key. (Kshawkin 23:15, 27 June 2012 (EDT))

Except that without a solid dereferencing scheme, they're actually no different from magic tokens. There's not much difference between <name key="FRED"> and <name ref="myproj:FRED">.

A Possible Solution

The primary value in using a project-specific key-style attribute is that it's short and simple. In many projects, @key is used when a perfectly straightforward and reliable pointer could be provided, because that pointer would be too long to be manageable by encoders. For instance, the Colonial Despatches project uses keys like this:

 <name key="mills">John Powell Mills</name>

when what is actually meant is something like this:

 <name ref="../bios/bios.xml#mills">John Powell Mills</name>

Where the key value corresponds to a unique @xml:id within the project, and the project data is stored in an XML database, dereferencing the key to look up the <person> element to which it corresponds is simple. But if the XML data is removed from the context of the XML database and associated XQuery which enables the simple lookup, the relationship between the key and the target element becomes opaque, and any researcher working with the data will have to read the encoding description and reconstruct it.

The proposed solution is to create a method of documenting this relationship which can be mechanically dereferenced as well as being described in human readable text. This would enable a processor to reconstruct the actual path of a link without human intervention. This can be done with a search-and-replace operation, encoded in a manner similar to XPath 2.0's replace() function. Imagine this in the encodingDesc of a document:

 <listPrivateUri>
   <privateUri prefix="bios" pattern="([a-z]+)" replacement="../bios/bios.xml#$1">
     <p>In the context of this project, private URIs with the prefix "bios" point to <person> elements in the project's bios/bios.xml file.</p>
   </privateUri>
 </listPrivateUri>

Any processor, presented with the "bios" prefix in a private URI, can look it up in the header, and apply a search/replace operation using the @pattern and @replacement attributes to arrive at a full working URI.

The same approach can be used with external references. In the Map of Early Modern London, we use a private URI scheme like this:

 <pb facs="moleebo:18464|1"/>

This expands into a full URL that looks like this:

 <pb facs="http://eebo.chadwyck.com/fetchimage?vid=18464&page=1&width=1200"/>

It's pointless and error-prone to reproduce the entire URL in every @facs attribute when the only two pieces of information that matter are the document number on EEBO (here 18464) and the page number (here 1). So we could document our moleebo prefix like this:

 <listPrivateUri>
   <privateUri prefix="moleebo" pattern="([0-9]+)|([0-9]+)" replacement="http://eebo.chadwyck.com/fetchimage?vid=$1&page=$2&width=1200">
     <p>In the context of this project, private URIs with the prefix "moleebo" point to facsimile pages on the EEBO website.</p>
   </privateUri>
 </listPrivateUri>

Since this dereferencing can be processed using XSLT 2.0 with the replace() function, this handling could easily be built into the standard TEI stylesheets.