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

> -----Original Message-----
> From: ext Graham Klyne [mailto:GK@ninebynine.org]
> Sent: 07 July, 2003 14:18
> To: Stickler Patrick (NMP/Tampere); uri@w3.org
> Cc: www-rdf-interest@w3.org
> Subject: Re: Proposal: new top level domain '.urn' alleviates all need
> for urn: URIs
> 
> 
> I rather think these are the wrong forums in which to promote 
> a new top 
> level domain.  And given the state of Internet politics, I 
> don't expect to 
> see this happen anytime soon.
> 
> #g
> --



I'm sorry you feel that way Graham.

My thoughts were that (a) it directly applies to URNs, for
which uri@wg.org is a key discussion list and also follows
from discussions I have had with Eric Miller and others
in the RDF community about the synergy of PURL and URIQA 
for knowledge discovery, including for URN denoted resources,
for which www-rdf-interest@w3.org is an optimal place.

So, aside from whether or not a top level domain is a 
realistic expectation in the short term, the posting was
IMO very much on topic for both lists in question.

As to the possibility of a new top level domain, we'll see...

Cheers,

Patrick


> At 10:33 07/07/03 +0300, 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)
> >
> >The combination of HTTP, PURLs, URIQA and a new top level
> >domain make for a powerful solution that completely eliminates
> >any need for the urn: URI scheme, or anything similar, as
> >well as provides an immediate migratory path for all urn:
> >schemes to http: URIs.
> >
> >The long term integrity of URN schemes are dependent on the longevity
> >of the managing authority, though one would also hope that URNs
> >would remain valid long after a given managing authority has ceased
> >to exist and mint new URNs for that scheme.
> >
> >The greatest argument for urn: URIs over http: URIs is that
> >(a) domain names do not last forever and and if the managing
> >authority changes, the function and meaning of URIs grounded
> >in that domain might change or become ambiguous; and
> >(b) domain names reflect legal entities that one may not wish
> >reflected in ones URI, if the denote resources that can be
> >transferred to new owners.
> >
> >Well, this can be addressed with a very simple solution.
> >
> >I propose that a new top level domain .urn should be defined,
> >managed by the same folks that manage the registration of urn:
> >subschemes, whereby for any URN subscheme urn:X: there would rather
> >be issued a subdomain X.urn. Then, the managing authority of that
> >subdomain can mint http: URIs (URNs) based on that subdomain
> >(regardless as to any services that might be offered by any web
> >server operating in that subdomain).
> >
> >Thus rather than, e.g.
> >
> >    urn:issn:1560-1560
> >
> >you'd have something like
> >
> >    http://issn.urn/1560-1560
> >
> >and the need for solutions such as DDDS disappears, since
> >HTTP now does the job quite nicely.
> >
> >The managing authority for the ISSN URN scheme could then host
> >a server at http://issn.urn to provide access to representations
> >and descriptions of the resources, or simply information about
> >the owner of the URI -- or even nothing, which is no worse than
> >present urn: URIs now.
> >
> >And since domains can be subdivided, and subpaths of URIs
> >redirected to entirely different servers, the managing authority
> >has a tremendous amount of flexibility in how it organizes its
> >namespace and services provided for accessing representations
> >and descriptions of the resources denoted by the URNs in question.
> >
> >A given managing authority could simply maintain a PURL like
> >redirection service to customer-specific URIs, providing a
> >consistent, opaque point of access to the resource that is
> >nevertheless managed by the resource owner.
> >
> >E.g. if Example Inc. was issued ISSN 1560-1560, then an HTTP
> >request to
> >
> >    http://issn.urn/1560-1560
> >
> >could be automatically redirected to
> >
> >    http://example.com/issn/1560-1560
> >
> >providing exactly the functionality that DDDS promises, but using
> >the existing and proven web infrastructure.
> >
> >If Example Inc. later transferred ownership of that resource to
> >e.g. Wombat Inc. then the redirection could be redefined to something
> >like
> >
> >    http://issn.wombat.org/1560-1560
> >
> >etc. and agents would continue to interact with the resource
> >in terms of its HTTP-URN transparently, with no manditory 
> impact from the
> >change in ownership.
> >
> >This solution also allows URIQA to be used for obtaining descriptions
> >of such HTTP-URN denoted resources in a standardized manner, since
> >in the same way as requests for representations would be redirected
> >to the customer-specific servers, likewise, requests for descriptions
> >would also be redirected.
> >
> >Note that the creation of the .urn top level domain is based
> >purely on practical considerations, not technical ones, as this
> >HTTP+PURL+URIQA approach will work equally well regardless of the
> >domain name.
> >
> >Creating the top level domain .urn also allows for every
> >URN subscheme now in existence to immediately be provided an HTTP
> >resolvable namespace which has a regular transformation from
> >the URN structure, allowing agents to work effectively with
> >legacy content containing urn: URIs.
> >
> >Thus, the mapping
> >
> >    urn:X:Y -> http://X.urn/Y
> >
> >becomes a poor-man's DDDS.
> >
> >And this approach likely has application to a number of other URI
> >schemes as well...
> >
> >Simple. Eh?
> >
> >Cheers,
> >
> >Patrick
> >
> >--
> >Patrick Stickler
> >Nokia, Finland
> >patrick.stickler@nokia.com
> >
> 
> -------------------
> Graham Klyne
> <GK@NineByNine.org>
> PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E
> 
>

Received on Monday, 7 July 2003 08:51:10 UTC