- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Fri, 23 Jan 2004 09:17:51 +0200
- To: "ext Phil Dawes" <pdawes@users.sourceforge.net>
- 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>
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 UTC