RE: Proposed issue: site metadata hook

> -----Original Message-----
> From: ext Tim Berners-Lee [mailto:timbl@w3.org]
> Sent: 13 February, 2003 00:58
> To: Stickler Patrick (NMP/Tampere)
> Cc: jos.deroo@agfa.com; www-tag@w3.org; www-tag-request@w3.org
> Subject: Re: Proposed issue: site metadata hook
> 
> 
> 
> On Wednesday, Feb 12, 2003, at 07:27 US/Pacific, 
> Patrick.Stickler@nokia.com wrote:
> 
> >
> >
> >> -----Original Message-----
> >> From: ext Jos De_Roo [mailto:jos.deroo@agfa.com]
> >> Sent: 12 February, 2003 17:22
> >> To: Stickler Patrick (NMP/Tampere)
> >> Cc: timbl@w3.org; www-tag@w3.org; www-tag-request@w3.org
> >> Subject: RE: Proposed issue: site metadata hook
> >>
> >>
> >>
> >> Sorry to stumble in and maybe I'm totally lost in all this
> >> threads, but right now I fail to see the need for MGET...
> >
> > Then please read the entire thread ;-)
> >
> 
> Maybe you should yourself :-)
> 
> This thread is NOT about how to extend the web for semantic 
> web engines.
> It is a thread about how to get site metadata, such as robots.txt
> and /w3c/p3p and /favico, without using "well known"  pathnames.

Well, forgive me for disagreeing, but IMO the *best* way to
get site metadata is to treat the site the same as any other
resource denoted by a URI and obtain a description about that
resource in the same manner that one would obtain a description
about any resource -- based on semantic web machinery.

This is a *prime* example of where the semantic web is needed
and the kind of functionality provided by something like MGET.

> > Jos, what if I have a URI <http://example.com/foo> and nothing
> > more, and want to know what it means and want to ask the server
> > http://example.com to tell me. How do I do that?
> >
> 
> You do an HTTP GET.  That will give you a representation of 
> the document
> <http://example.com/foo>.  It will give you enough HTTP metadata
> to decode that representation.

Nonesense. A description about a resource is *not* a representation
of the resource. If you want knowlege about the resource, GET will
provide you *nothing* but a representation.

Here's a use case to demonstrate this:

You have a resource named http://example.com/foo.rdf which happens
to be an RDF/XML instance defining some knowledge.

Now, I want some information about that RDF/XML instance. 

If I do an HTTP GET on http://example.com/foo.rdf, I get a representation
of that RDF/XML instance, *not* information *about* that RDF/XML instance.

If I try to use content negotiation and say Content-Type: text/rdf
that doesn't help, since the GET is already returning that content type!

Representations and descriptions are *disjunct* and we need distinct
machinery to interact with both, based on the same URI.

Now, if I were to do an MGET on http://example.com/foo.rdf, *then* I
would recieve an RDF/XML instance that *describes* rather than represents
the specified resource.

Now, it is true that if one added an http tag such as Meta-Location
and included it in every GET, HEAD, OPTION, etc. response then *if*
the body of knowledge known by a server had a distinct URI defined,
then that could be communicated by that tag. So if 
http://example.com/META/foo.rdf or the like denoted the body of
knowledge known about http://example.com/foo.rdf then e.g. 
HEAD http://example.com/foo.rdf could include in its response

   Meta-Location: http://example.com/META/foo.rdf

and the agent could then

GET http://example.com/META/foo.rdf

and, yes, that could be made to work, BUT:

1. It requires two system calls to obtain the metadata
2. It requires two URIs for every resource on the web
3. The agent has no idea what kind of representation it will
   get for the description, not even that it will be RDF
4. It encourages voluminous, monolithic documents describing
   large numbers of resources rather than descriptions
   specific to the resource indicated

In short, it's a hack. Sure it can work, but it's hardly what I
would consider an elegant solution.

The opportunities for both technical and practical problems 
are great.
 
> > That is what this thread is about. How to obtain a description of
> > a resource when all one has is the URI denoting it and *nothing*
> > else.
> 
> No, it was originally a thread about how to get metadata about the 
> entire site.

I consider everything I have written to be precisely about that
issue, and consider this issue to be exactly about how one
obtains knowledge about resources -- whether those resources
are a web site, or anything else.

> If the hook can be used for metadata about arbitrary pages in general,
> then so well and good, 

Not just "pages" but *any* arbitrary resource denoted by a URI.

Why would we not want to kill a trillion birds with the same
stone rather than just one?

> but that is not the proposed TAG issue 
> for this 
> thread.

Fair enough.

If you still think I'm talking about something else, then
I formally propose a new TAG issue -- addressing which formal
and official extensions to HTTP are required to achieve a seamless
and efficient interface between the Web and the Semantic Web.

And this new issue IMO fully subsumes the issue that you are
proposing.

Regards,

Patrick

--
Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com

Received on Thursday, 13 February 2003 03:05:07 UTC