RE: Site metadata; my preference

> -----Original Message-----
> From: ext Mark Baker [mailto:distobj@acm.org]
> Sent: 12 February, 2003 19:04
> To: www-tag@w3.org
> Subject: Site metadata; my preference
> 
> 
> 
> Wow, step away from your email for a few hours, and whammo ...

Apologies for my contributions to that tidal wave of discussion ;-)

> My preference would be for an optional response header, "Metadata" or
> some such, returned via GET and HEAD.

Fair enough, but this is inefficient, as it requires two system
calls to get metadata, and requires the doubling of URIs on the Web,
one to denote resources and one to denote its metadata.

And because of the burden of minting new URIs, it encourages 
the creation of monolithic schemas which describe large numbers
of resources, and therefore can easily cause a new form of
infoglut for semantic web agents.

The semantic web architecture should provide for a formal
definition of concise, bounded descriptions of specific
resources which are accessible by the URI that denotes the
resource in question.

> I don't like MGET for the reasons explained in the TAG finding on
> "URIs, Addressability, and the use of HTTP GET";
> 
>   "Safe operations (read, query, view, ask, lookup, etc.) on HTTP
>    resources SHOULD be implemented using GET because that allows the
>    result documents to be identified by URI, while using POST 
> does not."
>     -- http://www.w3.org/2001/tag/doc/get7#principles-summary

But surely this is a completely disjunct issue.

MGET does identify resources by URI, the resources being described,
and servers are free to return a URI denoting the body of knowledge
returned, if they see fit.

The above finding deals with the behavior of the Web, not the
behavior of the Semantic Web.

All the more reason to have distinct verbs to capture Semantic
Web behavior.

> I don't like GET+Meta because I feel it violates a good practice
> suggestion of Webarch;
> 
>   "Consistent representations: It is confusing and costly when, for a
>    given URI, representations vary in unpredictable ways."
>     -- http://www.w3.org/TR/webarch/#pr-rep-ambiguity

I agree.

Though, descriptions are not representations -- and for this reason,
I think it's not quite kosher to use GET to provide descriptions
(or anything other than representations).

> And moreover, if representations were to vary in the way that GET+Meta
> requires, that suggests to me that we're dealing with two 
> resources, not
> one.  

Yes, we are dealing with two resources. What is returned by MGET
is not a representation of the resource denoted by the URI in the
request.

> Hence my preference for the response header solution, which uses
> two URIs.

I understand and respect your preference, but I don't see that such
a solution is the optimal foundation for the semantic web for
reasons I've stated previously in this thread.

Cheers,

Patrick

Received on Wednesday, 12 February 2003 13:08:52 UTC