> Resent-From: [hidden email] > From: Mark Nottingham <[hidden email]>
> Date: 2 June 2006 12:58:06 PM
> To: [hidden email] > Cc: Joe Gregorio <[hidden email]>, Marc Hadley
> <[hidden email]>
> Subject: Beyond CURIEs
> X-Archived-At: http://www.w3.org/mid/ > [hidden email] >
> CURIEs are a great step forward from QNames, and I like them very
> 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
> 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://
> 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.
> 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
> [hidden email] >