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

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

From: Bill de hÓra <dehora@eircom.net>
Date: Sun, 02 Feb 2003 20:01:24 +0000
Message-ID: <3E3D7914.4050108@eircom.net>
To: Patrick.Stickler@nokia.com
CC: sandro@w3.org, www-tag@w3.org

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 
would be like asking about differentiating between Literals and 
Resources in RDF. You need to name the representation with another 
URI before you can start to get confused.

> 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.

> 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 

> 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.

Bill de hÓra
Received on Sunday, 2 February 2003 15:03:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:36 UTC