RE: Proposal: new top level domain '.urn' alleviates all need for urn: URIs

> -----Original Message-----
> From: ext Bill de hÓra [mailto:dehora@eircom.net]
> Sent: 07 July, 2003 12:18
> To: Stickler Patrick (NMP/Tampere)
> Cc: uri@w3.org; www-rdf-interest@w3.org
> Subject: Re: Proposal: new top level domain '.urn' alleviates all need
> for urn: URIs
> 
> 
> Patrick.Stickler@nokia.com wrote:
> > 
> > Hi folks,
> > 
> > The following is a proposal for an alternative solution
> > meeting the goals of urn: URIs but with http: URIs so
> > that the full richness of the web architecture can be
> > exploited.
> > 
> > (sincerest apologies to all the folks who have worked long
> >  and hard on DDDS... perhaps now to no avail)
> 
> 
> I don't think the DDDS folks will be too worried about this.

I didn't think so, given the broad applicability of DDDS,
but I just thought I'd be nice anyway ;-)

> But if you insist on going forward, then:
> 
>   http://urn.X.Y/
> 
> is a sufficient hack. 

I think it's a rather elegant solution, not really a hack. It
simply uses the existing domain and subdomain name registration
infrastructure, guidelines, and general practices to partition
the URI space into distinct managed subsets, which is what the
urn: URI scheme is intended to do.

But it does so in a manner that exploits the deployed HTTP
infrastructure rather than require further machinery for URI
resolution.

Had someone thought of this approach back when URNs were first
being concieved, we'd probably have countless such HTTP-URNs
in use today.

> It also doesn't require inventing new points 
> of failure in the web architecture*, doing DDDS badly, or the costs 
> of dealing with ICANN and whoever provides this service.

Quite.

> Bill de hÓra
> 
> * As for the full richness of the web archiecture, think about how 
> the provider would scale this service. - I suspect purl works 
> because not many people use it.

Well, the worst case scenario would be that an organization
would obtain a .urn subdomain (in the same manner as they would
register an urn: subscheme) and would not provide any services
whatsoever relating to URIs minted in that subdomain. That's
no worse than the present situation with urn: URIs.

However, in the best case scenario, and one which I expect will
be the norm, the managing organization will provide an effective
PURL or PURL like service for their customers.

Granted, there will surely be a middle ground, which will have
partial or even sporadic support for URIs minted in those
namespaces, but at least the general architecture will not be to
blame for that, and customers wanting HTTP-URNs will make their
choices according to cost versus benefit.

Resolution of HTTP-URNs thus becomes a business/social issue,
not a technical issue -- in just the same way as publication
of and support for metadata descriptions of resources will be,
presuming widespread adoption of a unifying standard such as 
URIQA.

Use of certain HTTP-URN domains may cost more than others,
but the services may be both better and more reliable. A 
commercially based HTTP-URN service can then distinguish itself
based on the quality and range of its services.

Cheers,

Patrick

Received on Monday, 7 July 2003 05:38:51 UTC