RE: Site metadata; my preference

> -----Original Message-----
> From: ext Paul Prescod [mailto:paul@prescod.net]
> Sent: 19 February, 2003 04:08
> To: Stickler Patrick (NMP/Tampere)
> Cc: timbl@w3.org; distobj@acm.org; www-archive@w3.org
> Subject: Re: Site metadata; my preference
> 
> 
> I'm tryign to keep this off of www-archive.
> 
> Patrick.Stickler@nokia.com wrote:
> > 
> > ...
> 
> > 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.
> 
> That's not true. It takes exactly one dereference of a URI to get the 
> REPRESENTATION of the metadata of URI X.

But if I want a DESCRIPTION of the resource denoted by a URI, it
takes *two* system calls. One to get a HEAD that has the URI
denoting the metadata, and one to get the metadata.

If all I care about is gathering descriptions of resources (and
many SW agents will be doing just that for many applications)
it is twice as expensive for them to navigate the SW as it is
for web agents to navigate the Web.

> Sometimes, you need a previous URI dereference to know _what_ URI 
> identifies the metadata of URI X, but heck, you very seldom 
> care about 
> the metadata of URI X without caring about URI X itself, so you are 
> going to do two network transactions anyhow.

I frequently care about the metadata without caring about the
representations -- especially when I am dealing with resources
that have *no* representation, such as abstract or non-web-accessible
resources.

Folks need to stop thinking that the SW is limited to web resources.

It is for *anything*, whether there is a web-accessible representation
or not.

Binding the SW to mechanisms optimized for accessing representations
is simply lopsided.

> Furthermore, there is a big problem with the MGET proposal. 
> It does not 
> provide a way for a browser to be told that there is metadata 
> available 
> with a particular URI. This implies you need a header that says 
> "MGET-available: true".

Eh? Why?! 

How does a browser know that a particular representation is available?
It asks for it.

I see no difference here.

And the browser doesn't have to be given some different URI from that
of the resource to get the metadata. It just does an MGET on the *same*
URI, and if it gets something, great. If not, so what.

> >>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.
> 
> This "autogeneration" is what thousands of marginally skilled CGI 
> programmers do every day. Furthermore, the data that comprises the 
> metadata lives somewhere. Unless we presume some complicated metadata 
> management system, I think that that metadata will live in 
> hand-authored 
> text files with names (.metadata.xml) that the HTTP server knows is 
> magic (alongside .htaccess and /index.html). Therefore the 
> "autogenerated" URI is merely uri/.metadata.xml

On the contrary. I think that very quickly metadata will live
in metadata management systems, not in individual files, and any
solution that presumes that there will be a *separate* file for
*every* resource named on a given site is kidding themselves.

The header tag approach is strongly biased towards large, monolithic
files describing large sets of resources. If I ask about some
resource, I don't want 8000% of the information I need. But that's
what I'm going to get when each tag for e.g. a DC term points to
a single massive RDF Schema defining the entire vocabulary.

> > 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...
> 
> You are incorrect. POST _does_ specify a URI in the request. 
> The problem 
> is that POST-abuses use the same URI to "tunnel" requests to various 
> resources. When SOAP is used to abuse HTTP, you look at the 
> SOAP method 
> and one or more parameters to figure out what the "real" object is. 
> Similarly, with MGET, you must look at the method to know whether the 
> data you see going across the wire is the representation of 
> the resource 
> or the representation of the metadata of the resource.

No. It is always the metadata of the resource. Always.

Patrick

Received on Wednesday, 19 February 2003 03:36:39 UTC