Fwd: Beyond CURIEs

FYI.

Begin forwarded message:

> Resent-From: www-tag@w3.org
> From: Mark Nottingham <mnot@yahoo-inc.com>
> Date: 2 June 2006 12:58:06 PM
> To: www-tag@w3.org
> Cc: Joe Gregorio <joe.gregorio@gmail.com>, Marc Hadley  
> <Marc.Hadley@Sun.COM>
> Subject: Beyond CURIEs
> X-Archived-At: http://www.w3.org/mid/ 
> 90CB8848-1BBE-49F7-9237-292DC3C354DE@yahoo-inc.com
>
>
> 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
>
>
>
>


--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 7 June 2006 15:23:05 UTC