- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Tue, 07 Oct 2003 10:28:07 +0300
- To: ext David Menendez <zednenem@psualum.com>, Garret Wilson <garret@globalmentor.com>
- Cc: "ext Hammond, Tony (ELSLON)" <T.Hammond@elsevier.com>, <www-rdf-interest@w3.org>, <uri@w3.org>
On 2003-10-05 07:53, "ext David Menendez" <zednenem@psualum.com> wrote: > Garret Wilson writes: > >> Fine---there needs to be a standard solution for finding out "where >> authoritative descriptive metadata resides." We can all agree that >> this is a problem. So? > > For resources retrieved via HTTP, my preference would be for a header > like See-Also or Description, which contains a URI reference indicating > a resource providing a machine-readable description of the requested > resource. There are two shortcomings to this approach: (1) it requires two server requests to obtain metadata about a resource, making SW agents who will be operating almost exclusively on metadata, "second class web citizens"; and (2) it does not define any constraints on what might be obtainable at that special metadata URI. It may very well denote a schema defining thousands of resources, yet the SW only needs to know about one of them. One of the key components (if not *the* key component) of URIQA is the definition of the concise bounded resource description. It's other key feature is the ability to obtain such a concise bounded resource description, by the URI alone, in a single server request. Both are IMO critical to the efficient operation of the SW. >> "Everything HTTP" is one answer that has the side-effect of confusing >> the resource with its metadata. There are surely thousands of other >> answers. Here are a few off the top of my head. (I'm not proposing >> them---I'm just pointing out that there are thousands of other answers >> that don't have the same semantic deficiencies.) > > While it's possible to interpret HTTP URIs in inconsistent ways, there's > no requirement that you have to. As an example, let's say > <http://example.com/joe> denotes Joe Example. When you dereference you > might get a picture or a web page or some RDF, depending on how the > request is phrased. In all cases, the actual response would include a > Content-Location header telling you that the picture, say, can be found > at <http://example.org/joe.jpg>. Thus, there is no confusion between Joe > and his picture, bio, and FOAF file. Exactly. Representations of resources are, themselves, resources and should have distinct URIs. Certainly, in the case of a digital resource, it may (and typically will) have a representation that is a bit-equal copy of itself -- and in such a case, what is returned by a GET request can be considered to be the actual resource denoted by the request URI -- but that is a special case. The HTTP specs already say that servers should indicate the distinct URI of representations returned when they don't correspond to the resource denoted by the request URI. Now, granted, the editors may have been thinking from a slightly different perspective, but it's interesting to see how well that meshes with the REST approach. Cheers, Patrick
Received on Tuesday, 7 October 2003 03:28:17 UTC