W3C home > Mailing lists > Public > www-rdf-interest@w3.org > January 2004

RE: URI: Name or Network Location?

From: Hammond, Tony (ELSLON) <T.Hammond@elsevier.com>
Date: Fri, 23 Jan 2004 10:44:36 -0000
Message-ID: <54A600C436EA694581B93E4BD4D4788A06B73F42@elslonexc004.eslo.co.uk>
To: 'Patrick Stickler' <patrick.stickler@nokia.com>
Cc: www-rdf-interest@w3.org

Hi Patrick:

> There is no need to introduce yet another URI scheme just to handle
> (more) persistent naming and redirection.

I would just like to point out that INFO expressly excludes dereference - so
no redirection available. There are multiple reasons why we have positioned
INFO thus. I would invite you to consult the FAQ at
<http://info-uri.info/registry/docs/misc/faq.html> which goes into the
details of why we have made this design choice. Bottom line is that we are
looking for a lightweight scheme for conferring identity (alone) of public
namespaces onto the Web. We do not support the idea of overloading the HTTP
document retrieval functionality with an independent naming functionality.
(By retrieval I intend the full set of CRUD actions.) Also any reliance on
DNS is inherently fragile and unnecessary - and frankly confusing.

> I am personally saddened to see the info: URI scheme emerge
> rather than a similar solution based on http: URIs, 

Without intending to be facetious, I also am personally saddened to see all
URIs collapsed to a single HTTP scheme. That would seem to me to be the
undoing of URI as a generic identifier architecture. The possibilities that
URI presents as a federeated namespace for identifying resources is too
great not to want to see it further elaborated so as to incorporate legacy
naming systems.

Tony



> -----Original Message-----
> From: www-rdf-interest-request@w3.org
> [mailto:www-rdf-interest-request@w3.org]On Behalf Of Patrick Stickler
> Sent: 23 January 2004 07:38
> To: ext Hammond, Tony (ELSLON)
> Cc: ext Sandro Hawke; Thomas B. Passin; 'Phil Dawes'; ext Jeremy
> Carroll; www-rdf-interest@w3.org
> Subject: Re: URI: Name or Network Location?
> 
> 
> 
> 
> 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 05:44:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:52:04 GMT