Re: Announcement: The "info" URI Scheme

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