Re: [httpRedirections-57] Resource-Decription Header: a possible proposal to consider.

On Feb 6, 2008, at 8:11 AM, Williams, Stuart (HP Labs, Bristol) wrote:
> Resource-Description: http://example.org/site.rdf
...
> This is stronger than the "303 'try-over-there <Location:>' 'hint'"  
> because the intention of the Resource-Description: is (or would be)  
> clear.
...
> (Tracker, this is ISSUE-57)

I think Link: as suggested by Richard is very similar, and has the  
advantage that it is already part of an HTTP spec. The suggestion has  
come up before. Unfortunately Link: disappeared in the move from 1.0  
to 1.1, if I remember my previous research on this correctly.

The other advantage over 303, to me probably more important than the  
ability to adopt a rule saying that the target is supposed to be a  
description, is that it gives you a standard channel for  
communicating metadata for information resources (200) that don't or  
can't carry their own. This would be important for a wide variety of  
applications, including provenance, versioning, licensing, and site  
policy, that currently have to be layered in awkward ways on top of  
HTTP.

To help bolster my case I'll point to the sad story of the LSID  
protocol [1]. Lack of a metadata channel was, I think, an important  
reason that the LSID project snubbed web architecture and sallied off  
on its own. (I won't pretend that was the only reason; this is a long  
and depressing debate.) In the LSID protocol, there are separate  
methods, getData and getMetadata, corresponding to GET and {GET of  
the description-carrying document}. These are implemented as web  
services, but that's not relevant. The important thing to observe is  
that the protocol designers felt that information resources require  
two distinct channels - one for content, and another for description.

I haven't examined OASIS protocols but I imagine similar things are  
going on there. The handle protocol, another incompatible Internet  
document-nation, certainly has this flavor to it. I guess I'm making  
a grand claim here: Establish a standard way to access document  
metadata, and you're on the road to a more useful and unified web  
(and semantic web). The details are not so important.

The HTTP analog of LSID getMetadata would be a new HTTP method that  
you might call GETMETA or GETDESCRIPTION, and while such a thing  
would save a HEAD round trip, as Richard C has pointed out [2] it  
would not be orthogonal design. The only other route I can think of  
(other than variant GETs, which have been ruled out) is a  
deterministic syntactic rule to go from a thing's URI to the URI of a  
description of the thing, in the situation where the first URI has no  
#. You would then "go" from the first URI to the second on the  
client, and do a GET of the second. I think it's probably too late in  
the game for this.

Jonathan

[1] http://lsids.sourceforge.net/
[2] http://www.w3.org/mid/C53F35F8-D04B-49FB- 
ABBE-5CA1EF1BE8C7@cyganiak.de

Received on Wednesday, 6 February 2008 20:00:56 UTC