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:45:10 +0200
Message-Id: <9F58A50C-7277-11D8-964D-000A95EAFCEA@nokia.com>
Cc: www-rdf-interest@w3.org
To: David Powell <djpowell@djpowell.net>

On Mar 10, 2004, at 00:11, ext David Powell wrote:

> I'm unsure about MGET because it seems to segment URI space, so that
> applications that deal with data and metadata need to know whether
> they should be using GET or MGET.

Er. Sorta like applications knowing whether to use GET or PUT
depending on whether they are requesting a representation or
submitting a representation?

Seems that the distinction between (arbitrary) representation
of a resource and concise bounded description of a resource
is pretty straightforward for applications to keep clear about.

> This isn't possible for applications
> such as HTML, XSLT, Babelfish, archive.org, etc..


I don't follow. Example?

> I think that it is valuable for metadata to be obtainable via GET,
> because there are a lot more agents in the wild that support GET than
> However I agree that some sort of extension is needed to allow clients
> to obtain metadata about a resource, so I was thinking about how MGET
> could be made more GET-friendly, so that the metadata is really part
> of the web.
> How about if it was MANDATORY for responses to MGET to have a
> Content-Location header giving a URL which could be used to retrieve
> the metadata via GET.

Please see the FAQ section of the URIQA spec 
which addresses this and other alternative methods, and why they don't
work, or are less optimal than the present definition of URIQA.

> In practise the URIQA implementation provides GET'able URIs for the
> metadata anyway, and I imagine that this would be a fairly common
> technique to ensure compatibility with browsers so it should be cheap
> to implement.
> Ensuring GET access to MGET content has a number of advantages.
> It wouldn't solve the problem of how to discover metadata for legacy
> clients, but it would allow clients incapable of performing MGET
> requests to still be able to access and process metadata if the URL
> for it is discovered on the client's behalf by an MGET-enabled client.

Then why couldn't that intermediary simply provide the description?

Also, any *client* that can execute a GET and consume RDF/XML in
the response can also execute an MGET and consume the RDF/XML

(granted, there are some issues with some SDKs which hobble
clients to not be able to execute arbitrary requests, but that's
a problem with those SDKs, not with the URIQA design)

> It allows dual-implementations of metadata discovery, eg a webpage
> could support MGET, and use one of the other methods such as a <link>
> tag.
> It also makes it possible to obtain meta-metadata by performing an
> MGET on the URL given as the Content-Location. In this scenario,
> perhaps an MHEAD method would be useful?

I have no problem with URIQA proxies, serving clients via GET/POST.

Though this seems to me to be a matter of implementational preference,
rather than something pertaining to the design of URIQA in general
(or have I missed something?)




Patrick Stickler
Nokia, Finland
Received on Wednesday, 10 March 2004 05:03:19 UTC

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