RE: Proposed issue: site metadata hook (slight variation)

> -----Original Message-----
> From: ext Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
> Sent: 12 February, 2003 17:39
> To: Stickler Patrick (NMP/Tampere); www-tag@w3.org
> Subject: RE: Proposed issue: site metadata hook (slight variation)
> 
> 
> Ok, I think I understand.  Still, if they are 
> different resources, one being a descriptive 
> document about the other, you seem to be 
> saying that you want to be able to get 
> different resources with the same name; 
> or really, use one name but depending on 
> the method, get different resources.
> 
> You do this by using a different method 
> so the selector discriminates not by 
> what is asked for but by how.  It is 
> as if you went to the library and 
> asked for a book, but depending on 
> how you asked, the librarian brings 
> you a book or the card catalog entry.

Yes. Exactly.

The Web methods GET, PUT, etc. enable you to interact
with the book.

The SW methods MGET, MPUT, etc. enable you to interact
with the description of the book, with the card from
the card catalog, so to speak.

If you *want* to give that card its own name, fine, but
usually folks just say "the card for book X". It's
normal behavior to refer to such bodies of knowledge
indirectly. That doesn't mean you have to, but it's
reasonable for the default mode of operation to do so.

> I can see that working well.  I'm not 
> convinced it is necessary but I leave 
> that to those more familiar with the 
> issues of fielding new verbs. 

I can appreciate that new HTTP verbs are expensive.

But we are not talking here about just yet another
web application.

We are talking about a new layer to the web architecture,
an extension to the fabric of the web itself which will
enable us to realize the semantic web.

And I think that's worth the expense of a few choice nre
verbs...

The only seeming "issue" with this proposal is that
some folks (perhaps rightly) feel that the cost of these
new verbs is too expensive.

If another means of accomlishing the same thing can be
found that works with the existing verbs and other machinery
of HTTP, great, but I've yet to see another approach that
achieves the same ends with the same clarity and safety
of interpretation.

> Thanks for the explanation!

Your most welcome.

Cheers,

Patrick
 
> len
> 
> 
> From: Patrick.Stickler@nokia.com [mailto:Patrick.Stickler@nokia.com]
> 
> > From: ext Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
> 
> > Why are representations of documents 
> > about other documents not just documents?
> 
> They are. But they need not be named documents. And in most
> cases, when speaking of the body of knowledge known by a 
> server about a resource, they will not be named.
> 
> > What is the advantage of separate but equal resources?
> 
> There are no separate but equal resources.
> 
> If you want to name the resource corresponding to the body
> of knowledge known about another resource, go ahead. But
> why do so if you don't ever need to?
> 
> The part that is distinct is the behavior of the HTTP server.
> 
> If I ask for a description of a resource, it is not returning
> a representation of that resource, but rather a representation
> of *another* resource, which is the body of knowledge known
> about the resource denoted by the URI in the request to the
> server.
> 
> It is this distinction between interacting with respresentations,
> per the Web, versus interacting with descriptions, per the 
> Semantic Web which must be kept distinct.
> 
> And the semantics of HTTP methods at present deal only with 
> interacting
> with representations, and trying to overload them to also support
> interacting with descriptions does not seem to be possible, and even
> if possible, not optimal and certainly not straightforward.
> 
> What is needed, IMO, are new methods specialized for interacting
> with descriptions. Hence my proposal for MGET, MPUT, MDELETE, etc.
> 
>

Received on Wednesday, 12 February 2003 11:39:22 UTC