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.

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.

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: