W3C home > Mailing lists > Public > www-rdf-interest@w3.org > March 2004

Re: Making MGET more GET-friendly?

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Wed, 10 Mar 2004 11:52:20 +0200
Message-Id: <9F9EBC0A-7278-11D8-964D-000A95EAFCEA@nokia.com>
Cc: www-rdf-interest@w3.org, Dirk-Willem van Gulik <dirkx@asemantics.com>
To: David Powell <djpowell@djpowell.net>

On Mar 10, 2004, at 10:52, ext David Powell wrote:

> Hello Dirk-Willem,
> Wednesday, March 10, 2004, 7:56:38 AM, dirkx@asemantics.com wrote in 
> mid:757E8FAE-7268-11D8-B93F-000A95CDA38A@asemantics.com :
>> ...
>>> 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
> 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.

The present Nokia implementation does just that, and has done so since
the first implementation. I consider this to be responsible URIQA
server behavior (but not manditory).

> This still assumes a 1:1 relationship between data and metadata,

URIQA presumes a 1:1 relationship between a resource and a concise
bounded description of that resource. There is no reason why a given
resource could not have other kinds of metadata associated with it,
with those relationships indicated even in the concise bounded

> but
> it makes getting metadata, and getting remain separate operations
> which could have independent access controls.

Right. And separate access rights could be defined for distinct
representations, the concise bounded description, and any other
related resources.



Patrick Stickler
Nokia, Finland
Received on Wednesday, 10 March 2004 05:13:46 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:50 UTC