W3C home > Mailing lists > Public > www-tag@w3.org > February 2003

Re: Site metadata; my preference

From: <Patrick.Stickler@nokia.com>
Date: Tue, 18 Feb 2003 10:28:54 +0200
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B5FBB2A@trebe006.europe.nokia.com>
To: <timbl@w3.org>, <distobj@acm.org>, <www-tag@w3.org>



> -----Original Message-----
> From: ext Tim Berners-Lee [mailto:timbl@w3.org]
> Sent: 16 February, 2003 00:37
> To: Stickler Patrick (NMP/Tampere); distobj@acm.org; www-tag@w3.org
> Subject: Re: Site metadata; my preference
> 
> 
> 
> ----- Original Message -----
> From: <Patrick.Stickler@nokia.com>
> Sent: Wednesday, February 12, 2003 1:08 PM
> Subject: RE: Site metadata; my preference
> 
> Mark Baker:
> >> 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.
> 
> This is a crazy argument!   I assume you were serious.

I'm very serious. And I've not been the only one to make this point.

It seems to me that your proposal makes SW applications second
class citizens of the web since it takes twice the work to
get their native content, metadata rather than representations.

> The URIs don't have any overhead on eth server, as the
> resources are virtual documents generated in response to
> a get in just the same way as you would generate  a response to
> your MGET.  

Fair enough. But there still is the need to have some means
of autogenerating those metadata denoting URIs and if one can
simply not need to, that is simpler.

> > 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 think actually htere is a falacy in teh thinking there - that
> the information about one thing will naturally be
> well bounded, and everyone will want the same information.

Have you missed my definition about what "bounded" is? It is,
that every statement in the description either has the
resource specified in the request as the subject, or, for all
blank node values, recursively, all statements having that
blank node as its subject.

Thus, the description is bounded to what is known about that
resource alone, or anonymous resources bound to that resource.

I.e., if I ask about xhtml:head I don't get RDF describing
the entire XHTML vocabulary, all schemas, style sheets, etc.
*Only* statements about xhtml:head. If those statements refer
to other resources, I can MGET knowledge about them as well,
repeating until I have all the knowledge I need.

> But in practice, a server has a huge amount of information it
> *could* give: Privacy and IPR information, persistence information,
> change history, acces control information, access control history,
> schema validity, workflow state and robot control are some 
> things which come
> to mind but that's just thinking about w3.org.

As I've already said several times, MGET should function similarly
to PROPFIND in allowing one to include a simple selection query
to specify precisely which properties are of interest.

C.f. http://lists.w3.org/Archives/Public/www-tag/2003Feb/0127.html

Thus, any application is free to ask for the specific knowledge it
needs/wants about a given resource -- and need only ask once, using
the URI denoting the resource, to get a very precise, bounded
description of the resource alone, in RDF.

No other URIs needed. No double or more system calls. No mystery
representation returned that could be anything. No complex and
problemmatic overloading of existing HTTP semantics. 

> > > 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.
> 
> Evry finding which deals with eth Web deals with the semantic Web,
> just as every finding whcih deals with the Internet deals 
> with the Web.
> One is built using the other, not in contrast to it.

But not every finding that deals with some feature of the web
applies to every single feature of the web or the semantic
web!

The quote doesn't apply to MGET! MGET denotes resources using
URIs. The quote was about GET being perferred to POST because
POST didn't specify a URI in the request. It's no
more relevant than arguing MGET is bad because 2 out of 3
dentists recommend a toothpaste with flouride...

Patrick
Received on Tuesday, 18 February 2003 03:29:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:16 GMT