Re: Making MGET more GET-friendly?

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
description.

> 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

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Wednesday, 10 March 2004 05:13:46 UTC