Re: Best practices using URIs

On 11 Nov 2003, at 19:45, Nick Matsakis wrote:

> On Tue, 11 Nov 2003, Hammond, Tony (ELSLON) wrote:
>
>> Not sure how appropriate (or relevant) this is to SIMILE, but thought 
>> I
>> would just mention the "info" URI scheme
>
> This is a great idea, as it allows unconnected people to give the same
> URIs to items, provided the items have previously been given a unique
> identifier such as a Dewey Decimal code or Library of Congress number.
> However, the URL given for NISO, http://info-uri.niso.org failes to
> resolve.  Is there a comprehensive list of proposed info-namespaces 
> about?

how would this differ from urn: ? or DOI, for that matter? DOI is 
already a namespaced URN. What's the point of having yet another 
namespace on top?

it seems to me that a URI like

  info:doi:isbn/0465026567

would be completely equivalent a URI like

  urn:isbn:0465026567

for any use.

Note, however, that there is a general tendency in the XML world to 
stay away from URIs that are no "potentially dereferencable". I made 
the mistake of creating my URI scheme in the past and, as TBL 
suggested, URN are poor substitutes for dereferencable URI because any 
lookup and discovery mechanism would be a poor mimic of HTTP anyway.

Keep in mind that the difference between

  urn:isbn:0465026567

  http://www.iso.org/ISBN/0465026567

even if treated as URI, is that the second *could* be used as a URL to 
lookup and discovery information on that particular resource, while the 
first does *NOT* include a methodology to do the above and it's left as 
application dependent.

It is true that the use of dereferencable URIs is generally harder 
because it requires two contracts: one with the URI and one with the 
potential addressing space of your web domain, and these must be kept 
in synch, while URN allow a completely separate management of the 
identification and the discovery.... but leave the discovery method 
unspecified.

One could be tempted to say that using HTTP as a discovery mechanism 
could be poor, as it forces one distribution and this looks like a 
potential bottleneck or single point of failure, but it should be noted 
that HTTP transparently leverages the TCP/IP decoupling from address 
identifier and actual IP address thru DNS.

As www.google.com rather eminently shows (or akamai, for that matter), 
it is possible to keep a single address space but distribute its 
implementation massively and in a completely transparent fashion. 
Looking it from this angle, it is clear why URN are poor sustitutes for 
http: based URIs.

In case the management of the URL address space cannot be monitored 
directly by the group that issues the URI, it is possible to follow the 
pattern used by the folks at Dublin Core and use PURL 
(http://purl.org/) which allows URL to be persistent and be redirected 
later without forcing contracts to brake.

for example, asking for http://purl.org/dc/elements/1.1/ (the DC 
namespace) currently redirects to 
http://dublincore.org/2003/03/24/dces# which discovers an RDFSchema for 
DC, but since the practice of what should be on the other side of a 
namespace is not yet reccommended, they could, in the future, redirect 
to another document without breaking any contract.

I personally tend to be against PURLs and in favor of a better 
management of private URL address spaces, but I understand that there 
are cases where political issues tend to get in the way of purely 
technical design (as I think it was the case before the DC group 
acquired their dublincore.org domain)

HTH

--
Stefano.