RE: Best practices using URIs

Hi Stefano:

I hope I can add some insights into our thinking here. IMO the terms URL and
URN are not very conducive to a good understanding of URI. Rather, the
difference between an HTTP URI say and a URN URI is that the former has a
location-dependent resolution mechanism (i.e. a location is expressed in
terms of a network authority component), while the latter has a
location-independent resolution mechanism. A URN URI resolution mechanism is
/not/ application dependent, as you assert,  but is (or should be) specified
in the URN NID template. For example, RFC 2648 specifies a URN NID for IETF
documents and proposes a resolution mechanism via HTTP using a set of Perl
scripts annexed in that document. So, both location-dependent and
location-independent URIs are fundamentally premised on resolution at the
URI scheme level. At the instance level, of course, (or even at the URN NID
level) URIs may or may not be resolvable, but that is another matter.

The "info" URI scheme as a class of URIs specifically eschews resolution. Or
to quote from the FAQ that we are currently compiling:

===== "info" FAQ =====

	"info" is focused exclusively on supporting identity alone. As such,
this 

		* dramatically simplifies "info" resolution behaviours, and
consequently the operational expectations of an "info" URI 

		* avoids overhead in new "info" namespace registrations by
rejecting any notion of resolution mechanisms 

		* avoids overhead in the management of a resolution
infrastructure and maintenance of resolution targets for "info" URIs 

		* requires that a Namespace Authority make an independent
URI or URN NID application if services or other functionalities are required
(e.g. authority metadata) 

		* does not interfere with the mantra "many URI schemes
considered harmful" as this is primarily concerned with the need for
applications to support resolution mechanisms 

	Note that this stance on non-dereference is in contrast to other URI
schemes which are generally dereferenceable, even if not all examples within
a particular scheme are actually dereferenceable. This holds true for both
location-dependent URIs (e.g. HTTP URIs) as well as for location-independent
URIs (e.g. URN URIs). 

===== "info" FAQ =====

The rationale behind the "info" URI scheme is to support legacy (or
otherwise non-URI) public identification systems within a URI naming
environment so that Web description technologies like RDF or the OpenURL
Framework, can make use of identifiers from these naming systems as globally
unique references. The intent is to provide a lightweight, early URI
registration mechanism which will not compromise any possible future URI
registrations by the namespace authorities concerned. For example, DOI could
be registered now under "info" to allow this example URI to be used

	info:doi/10.1234/567

In the meantime the IDF is also proceeding with an independent URI
application and at some future point in time would expect to be able to get
the "doi" namespace entered into the IANA registry, so that the same
resource could also be referred to as 

	doi:10.1234/567

Note however that the former URI confers identity only while the latter is
capable of supporting resolution behaviours, e.g. one could imagine URIs of
the form

	doi:10.1234/567?service=pdf

This is just a clumsy example to show how a "doi" URI scheme could be used
for addressing into a set of resource representations.

Tony


-----Original Message-----
From: Stefano Mazzocchi [mailto:stefano@apache.org]
Sent: 13 November 2003 13:33
To: Nick Matsakis
Cc: Hammond, Tony (ELSLON); SIMILE public list
Subject: 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.

Received on Thursday, 13 November 2003 10:06:08 UTC