- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Wed, 10 Mar 2004 12:03:47 +0200
- To: "ext Dirk-Willem van Gulik" <dirkx@asemantics.com>
- Cc: www-rdf-interest@w3.org, David Powell <djpowell@djpowell.net>
On Mar 10, 2004, at 11:18, ext Dirk-Willem van Gulik wrote: > > > > On Mar 10, 2004, at 9:52 AM, David Powell wrote: > >>>> How about if it was MANDATORY for responses to MGET to have a >> >>> s/MGET/GET/ perhaps ? >> >> No, I meant MGET here. I was proposing that you could continue to get > > Ok - so you still need some code in the agents. No more so than for GET, POST, PUT, DELETE, etc. etc. URIQA does not increase implementational burden on the client side. > >> the resource using GET http://www.example.com/ex , and that you could >> get the resources metadata using MGET http://www.example.com/ex , but >> that the MGET would also return a Content-Location header pointing to >> http://www.example.com/ex.rdf or >> http://sw.example.com/metadata.cgi?url=http:%2f%2fwww.example.com%2fex >> which could then be used by GET requests for agents that didn't >> support MGET. This would help MGET data to still be part of the wider >> web. > .... >> This still assumes a 1:1 relationship between data and metadata, but >> it makes getting metadata, and getting remain separate operations >> which could have independent access controls. > > If you assume that - and given the above 1:1; would it not be simpler > to simply > postulate an extra header: > > Characteristics-Location: http://www.example.com/ex.rdf > > in the reply of any GET ? In particular that of the GET of > http://www.example.com/ex. > And making sure you -also- get it when a cheaper HEAD is done ? Or > does that > not accomplish all you want ? No. It doesn't (for me). Please see the URIQA FAQ about the shortcomings of the header approach... Patrick -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Wednesday, 10 March 2004 05:13:46 UTC