- From: Jonathan Rees <jar@creativecommons.org>
- Date: Wed, 6 Feb 2008 15:00:17 -0500
- To: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
- Cc: "www-tag@w3.org" <www-tag@w3.org>, Graham Klyne <GK@ninebynine.org>, Jonathan Borden <jonathan@openhealth.org>
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