- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Fri, 23 Jan 2004 09:37:37 +0200
- To: "ext Hammond, Tony (ELSLON)" <T.Hammond@elsevier.com>
- Cc: ext Sandro Hawke <sandro@w3.org>, "Thomas B. Passin" <tpassin@comcast.net>, "'Phil Dawes'" <pdawes@users.sourceforge.net>, ext Jeremy Carroll <jjc@hplb.hpl.hp.com>, www-rdf-interest@w3.org
On Jan 22, 2004, at 17:38, ext Hammond, Tony (ELSLON) wrote: >> It seems to me >> that the most obvious way of addressing this is to use a URI to denote >> the thing (i.e. a name) and a seperate way of talking about the >> numerous ways of locating information about it. > > Hence INFO, see <http://info-uri.info/> ... There is no need to introduce yet another URI scheme just to handle (more) persistent naming and redirection. http: based PURLs work just fine. As I've pointed out before, you can accomplish all that you aim to accomplish with the info: URI scheme by simply using http: URIs grounded in your top level domain, delegating control of subtrees of that namespace to the various managing entities per each subscheme (the same is true of urn: URIs). Then each http: URI can be associated with an alias to which it redirects, as well as allow for access to metadata descriptions via solutions such as URIQA[1]. E.g. rather than info:lccn/n78890351 you'd have http://info-uri.info/lccn/n78890351 thus providing just as robust and long lived an identifier (since one would think that if info-uri.info dissappeared, so too would all integrity for any info: URI) yet still allow existing web protocols such as HTTP to be employed to provide access to descriptions and representations; either directly or via redirections of various sorts. Even if some particular info subscheme had no intention of providing any representations or descriptions *now*, if ever the decision were changed, it would be possible with *no* impact to any usage of those URIs as names. I am personally saddened to see the info: URI scheme emerge rather than a similar solution based on http: URIs, dispite my appreciation that the definition of standardized URIs for so many important vocabularies has been sorely needed for far too long. Patrick [1] http://sw.nokia.com/uriqa/URIQA.html > > Tony > > >> -----Original Message----- >> From: www-rdf-interest-request@w3.org >> [mailto:www-rdf-interest-request@w3.org]On Behalf Of Phil Dawes >> Sent: 22 January 2004 15:23 >> To: Patrick Stickler >> Cc: ext Sandro Hawke; www-rdf-interest@w3.org; Thomas B. Passin; ext >> Jeremy Carroll >> Subject: Re: URI: Name or Network Location? >> >> >> >> Hi Patrick, >> >> Patrick Stickler writes: >>> >>> Per your view, most URIs do not denote web pages, images, >>> video streams, services, etc. but all denote "locations" and >>> if we ever want to describe all those web-accessible resources, >>> we need an entirely different set of URIs for them if we wish >>> to talk about them. >>> >> >> But surely the only reason this argument has weight is because there >> is usually only 1 way of retrieving that web resource* - i.e. HTTP. >> Thus it becomes an attractive choice for naming it. >> >> If the web hadn't turned out the way it has, and there were lots of >> protocols vying on equal footing for supremacy, then the 'it's a name' >> argument wouldn't seem so obvious. We would, as you say, probably have >> a way of talking about the web resource itself, and a seperate way of >> talking about the numerous ways of locating it. >> >> The problem now is that we are attempting to use HTTP URIs to describe >> abstract concepts and physical objects, and so the 'it's a name' >> argument for HTTP URIs is suddenly non-obvious again. It seems to me >> that the most obvious way of addressing this is to use a URI to denote >> the thing (i.e. a name) and a seperate way of talking about the >> numerous ways of locating information about it. >> >> Cheers, >> >> Phil >> >> * or the representation of that resource >> > > -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Friday, 23 January 2004 02:37:38 UTC