- From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
- Date: Wed, 6 Feb 2008 17:30:57 +0000
- To: Richard Cyganiak <richard@cyganiak.de>
- CC: "www-tag@w3.org" <www-tag@w3.org>, Graham Klyne <GK@ninebynine.org>, Jonathan Borden <jonathan@openhealth.org>
Hello Richard, > -----Original Message----- > From: Richard Cyganiak [mailto:richard@cyganiak.de] > Sent: 06 February 2008 16:31 > To: Williams, Stuart (HP Labs, Bristol) > Cc: www-tag@w3.org; Graham Klyne; Jonathan Borden > Subject: Re: [httpRedirections-57] Resource-Decription > Header: a possible proposal to consider. > > Stuart, > > There's also the > > Link: site.rdf;rel=meta > > pattern, which seems more or less the same as > Resource-Description (except that AFAIK it is intended for > use on information resources only). Ok.. that's interesting, I hadn't come across that - probably looking (or not) in the wrong places - don't remember seeing it in the versions "Cool URIs for Semantic Web" that I've read. It almost goes as far as a property (rel=meta) value (site.rdf) pair cf Resource-PropertyValue: meta site.rdf except that meta is not a URI (AFAIK) which makes it difficult to connect with RDF. > Personally I'm uneasy about cramming too much semantics into > the transport layer. I think HTTP is about efficiently moving > representations of resources back and forth over the network. > It is not about describing the nature of resources or their > relationships. > That's what representations are for. I don't see how > Resource-Type, Resource-Description and similar headers > improve HTTP's ability to efficiently exchange representations. Firstly, I'm not so bothered about Resource-Type:... it was what was mentioned in Jonathans post. Secondly, it was not about solving a problem of efficent exchange of representation - but about providing a means of, given <?u> (a URI) finding a description of ?u (a resource/thing) (which may be definitive or not) rather than a representation of <?u>. Compared to 303, Resource-Description: works uniformly for both 200 responses (=>IRs) and 303 (=>not known to be IR) - which is nice. Some have been complaining that the httpRange-14 resolution does not reliably allow you to find metadata *about* an IR (unless it is self-describing) - this is away of getting to metadata about ?u. > Your argument seems to be that 303 redirects are too weak; > that the redirect doesn't imply anything more than > "try-over-there". There are some who make that complaint about 303. They want to be able to make stronger assertions at least about what is at the end of the redirect chain - in particular they like to be able to assert that some (architectural) conformance requirement has been violated *if* following the chain does not yield a description of (amongst other things) ?u. IMO 303 does not and cannot give such an assurance. > I would like to know why more than this > weak implication is necessary on the transport layer. Others will have to speak up on that... but roughly AFAIUI its about what it would mean to conform and detecting when a source has failed to conform. > Strong > "aboutness" and similar relationships can be expressed, if > necessary, in a representation made available at the > redirection target URI. > > ... I agree... but if no such expressions are found after diligently following such a chain, one has no basis for complaint, no stick to wield to say that any one did anything wrong... one can only complain that they weren't as helpful as the could have been. > Regarding the Resource-PropertyValue header, I propose to > generalize it into a Subject-Predicate-Object header. We > could build the Semantic Web using only HTTP HEAD. I also > propose new HTTP verbs HEADPOST, HEADPUT and HEADDELETE to > modify all those new HTTP headers. :-) I trust that you are joking! > > Best, > Richard > Regards Stuart -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England (Tracker, this is ISSUE-57)
Received on Wednesday, 6 February 2008 17:33:43 UTC