Beyond CURIEs

CURIEs are a great step forward from QNames, and I like them very much.

However, they limit the abbreviation that you can do to the front of  
the URI -- e.g., they allow abbreviation of the scheme, authority,  
and path together, but not just the path.

Several use cases would benefit from having a standard syntax to  
abbreviate *any* part of a URI -- not just the front.

For example, I've been experimenting with doing client-side variable  
interpolation into URL templates <http://www.mnot.net/javascript/ 
url_template.html>. Here, it's useful to vary the end, rather than  
the beginning, of the URL.

Joe Gregorio previously published a similar article <http:// 
www.xml.com/pub/a/2005/04/06/restful.html> explaining how to  
construct URIs dynamically in Python.

Mark Hadley's WADL <http://research.sun.com/techrep/2006/ 
abstract-153.html> would also benefit from such a shorthand syntax.

In general, it seems like CURIEs are tantalisingly close, but just  
short, of supporting generative URIs <http://rest.blueoxen.net/cgi- 
bin/wiki.pl?GenerativeNaming><http://www.mnot.net/blog/2004/04/16/ 
generative>.

By only allowing abbreviation at the front of URIs, they constrain  
the types of URIs that you can create; for example, if you want to  
have a CURIE for a particular book's author, you're forced into a URI  
like http://www.example.com/getAuthor?isbn=0321154991, rather than  
the more natural, structured http://www.example.com/0321154991/ 
author. In many ways, they share the limitations of other prefix  
mechanisms, as discussed in the background of URISpace <http:// 
www.w3.org/TR/urispace>.

The pattern that I see very often is the use of braces -- which are  
not allowed in URIs (being neither reserved nor unreserved) -- to  
delimit a variable name, which is then interpolated from context. E.g.,

   http://www.example.com/{isbn}/author
or
   {book_site}0321154991

which is unambiguous (because there's no conflict with existing URI  
syntax) and easy to process, and only one character longer than the  
current CURIE.

I'd very much like to see such a thing standardised, along with  
mechanisms to populate the context in common situations (e.g., XML).

This doesn't necessarily conflict with CURIEs; indeed, they don't  
meet one of their primary requirements; to be backwards-compatible  
with QNames. CURIEs fill an important gap in the current  
architecture, and address a lot of the pain with QNames by offering a  
transition path. There are cases, however that CURIEs don't address,  
but some people will misuse to try to; hence this approach.

The only thing I'm missing is a zippy name...

--
Mark Nottingham
mnot@yahoo-inc.com

Received on Friday, 2 June 2006 19:59:05 UTC