- From: <Patrick.Stickler@nokia.com>
- Date: Mon, 7 Jul 2003 12:38:46 +0300
- To: <dehora@eircom.net>
- Cc: <uri@w3.org>, <www-rdf-interest@w3.org>
> -----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