RE: Valid representations, canonical representations, and what the SW needs from the Web...

> -----Original Message-----
> From: ext Bill de hÓra [mailto:dehora@eircom.net]
> Sent: 02 February, 2003 22:01
> To: Stickler Patrick (NMP/Tampere)
> Cc: sandro@w3.org; www-tag@w3.org
> Subject: Re: Valid representations, canonical 
> representations, and what
> the SW needs from the Web...
> 
> 
> Patrick.Stickler@nokia.com wrote:
> 
> > Well, the problem is that the concept of representation is too fuzzy
> > to be sure whether one solution or another would be valid according
> > to the Web and SW architecture. 
> > 
> > The above noted issue is an excellent case in point. If I modified
> > my server so that HEAD returned the metadata describing the resource
> > (not the representation) would that be valid? What if I needed 
> > metadata about both? How would I differentiate? 
> 
> Reask the question. You can't differentiate between a resource and a 
> representation since you can't talk about representations. 

That was not my question. I was asking about differentiating between
*metadata* which describes a resource versus that which describes a
representation, if HEAD were used.

Question: Does the metadata in the HEAD describe the resource or the
representation?

I understand RFC 2616 as answering 'yes' to this question.

[
9.4 HEAD

   The HEAD method ... can
   be used for obtaining metainformation about the entity implied by the
   request ...
]
and
[
   entity
      The information transferred as the payload of a request or
      response. ...
]

So understanding the above as "the entity implied by the request" being
the representation, this seems to preclude using HEAD to return metadata 
about the resource, since the entity in question is the representation 
not the resource, and the metainformation returned by HEAD describes the
representation, not the resource.

Including metainformation describing the resource would then be a
deviation from HTTP.
 
> > And what about
> > structured values? HTTP headers would be ackward to use to return
> > an RDF list structure (though it could be done, e.g. as an RDF/XML 
> > fragment). Could I return RDF in the body of a HEAD response?
> 
> Yes, if you really wanted to, but that wouls suck (entity 
> tunneling). You could just link out to RDF.

Right, so now I have two requests rather than one for each and every
access of metadata. Yuck. That's hardly a good design. Yes, it would
work, but...

> > I would think that there would be an analogous relationship between
> > a META request and a META-HEAD request as between GET and HEAD
> > where META returns metadata describing the resource (not 
> representation)
> > and META-HEAD returns an HTTP header describing the content returned
> > by a META request, just as HEAD returns an HTTP header 
> describing the
> > content returned by a GET request.
> 
> I don't see the issue yet, as there's nothing in HTTP that describes 
> representations so that you might confuse it with the resource in 
> question.

See above. It seems to me to be that HEAD metainformation describes
the representation, not the resource, so one couldn't use HEAD to
obtain metadata about the resource.

> > Given the representation-centric view of the Web architecture, I
> > don't see how you can support the additional needs of the SW without
> > extending HTTP in some fashion. The current functionality 
> just cannot
> > be stretched far enough to do double duty (that I can see).
> 
> Off the cuff, I agree, but you have a genuine uptake problem when 
> you go and try to add new methods to HTTP. Headers are an easier sell.

Well, sure, *iff* one is able to differentiate between metadata
describing the representation (entity returned) and the actual
resource denoted by the URI.

Otherwise, we're going to have to do something different.

Patrick

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

Received on Monday, 3 February 2003 03:25:04 UTC