Re: Making MGET more GET-friendly?

On Mar 9, 2004, at 11:11 PM, David Powell wrote:

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

No matter on how you look at this - clients will have do have some
extra code somewhere.

However it is the case that the protocol line (GET/MGET) is typical
hidden in an API and not accessible from a client side language. Where
as headers tend to be a tad easier to get access to. Of course the
CreativeCommons and XMP method are even 'easier' as there you
simply need to parse the payload - which even more accessible.

> How about if it was MANDATORY for responses to MGET to have a

s/MGET/GET/ perhaps ?

> Content-Location header giving a URL which could be used to retrieve
> the metadata via GET.
>
There are two assumptions hidden in here which in my experience do
not always hold

A->	That someone who has access to the data can also access
	the metadata and vise versa; and that there is such a
	1:1 mapping.

B->	That the world revoles around HTTP or RESTfullnes.

With respect to A to give some examples; in some financial and medical
organisations some of the raw data is very tightly controlled, sometimes
even the existence of it; whereas (aggregate) metadata about it may be 
a lot less
privacy invasive. And the vectors for each are vasty different. Another
example is in intelligence; where the raw data is fairly worthless; but
some of the annotations are not. And the final example comes from
the archive/library field where you have complex relations betweens
levels of data and metadata; i.e. consider a serial publication, an 
issue
of it, the articles inside it, etc. There the 1:1 mapping does not hold 
so
easily.

Now I am _not_ saying that the above is impossible; just that the model
is more geared towards 1 on 1 relations between data and metadata
and that it sort of assums very similar access vectors.

Dw

Received on Wednesday, 10 March 2004 02:56:49 UTC