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

Re: URI: Name or Network Location?

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Fri, 23 Jan 2004 09:17:51 +0200
Message-Id: <41791E6E-4D74-11D8-87BF-000A95EAFCEA@nokia.com>
Cc: www-rdf-interest@w3.org, "Thomas B. Passin" <tpassin@comcast.net>, "ext Sandro Hawke" <sandro@w3.org>, "ext Jeremy Carroll" <jjc@hplb.hpl.hp.com>
To: "ext Phil Dawes" <pdawes@users.sourceforge.net>


On Jan 21, 2004, at 23:16, ext Phil Dawes wrote:

> 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.
>

The http: URI scheme is indeed a very attractive scheme to use to
name resources -- because, as you point out, one can (optionally)
employ HTTP to provide access to representations of that resource.

But the generic, URI scheme and protocol agnostic view that URIs
name resources, and protocols *might* resolve those URIs to
representations of those resources liberates the web architecture
from any particular URI scheme or protocol (even if a few key
schemes and protocols continue to do the lion's share of the work,
which is simply to be expected, per the requirements of economy).

> 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

I think that one reason why we don't have a plethora of competing
protocols is that it's not practical, nor necessary.

> 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.

I believe this is compatible with REST (as I understand it). I.e.
A URI names a resource (anything; digital, physical, abstract, real,
imaginary, whatever). The particular choice of URI scheme determines
the protocols for which that URI is resolvable to some representation.
One may choose a particular URI scheme because one wishes to both
name a resource as well as provide for representations of that resource
via that URI (and/or may be motivated by other concerns/goals).

A given resource may be named (denoted) by more than one URI, and those
URIs may be of different schemes, for whatever reason, and thus, the 
means
by which representations of those resources are accessed may differ from
alias to alias (from URI to URI).

One can use SW machinery (e.g. owl:sameAs) to relate these various
alias URIs having equivalent denotation, so having multiple URIs
denoting the same resource is no big deal.

Patrick


>
> Cheers,
>
> Phil
>
> * or the representation of that resource
>
>

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com
Received on Friday, 23 January 2004 02:17:52 GMT

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