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: <Patrick.Stickler@nokia.com>
Date: Sun, 2 Feb 2003 19:06:12 +0200
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B5FBAFB@trebe006.europe.nokia.com>
To: <dehora@eircom.net>
Cc: <sandro@w3.org>, <www-tag@w3.org>

> -----Original Message-----
> From: ext Bill de hÓra [mailto:dehora@eircom.net]
> Sent: 02 February, 2003 15:37
> 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:
> > 
> >>-----Original Message-----
> >>From: ext Bill de hÓra [mailto:dehora@eircom.net]
> >>
> >>Better to use HEAD and define some headers.
> > 
> > 
> > Well, *I* can do all kinds of things on *my* server. But 
> what is needed
> > is a common solution that (nearly) *everybody* uses so that 
> I can ask
> > about resources on *other* folks servers and expect with reasonable
> > confidence that the server will know what I'm asking for and provide
> > what I need.
> > 
> > I.e. we need a *standardized* solution for accessing 
> resource metadata
> > on the Web, and that solution is a key component of the 
> interface between
> > the SW and Web.
> I mention using HEAD, because it probably takes less effort to get 
> some new HTTP headers deployed than a new method. WebDAV/DASL has 
> almost everything you need, but it requires new methods atop HTTP.

Well, as Julian pointed out, both HEAD and PROPFIND fail to distinguish
between metadata describing the resource from that describing the
representation -- though interestingly enough, I would myself presume
that the results of PROPFIND describe the resource and HEAD describes
the representation (though it's not as clear to me as it should be in either
case -- though pointers to any clarifying text is very welcome).

> So yes, by all means standardize it. And one of the best ways to 
> standardize something on the web is to implment on your server, to 
> solve your problem. Then try to persuade others to follow suit.

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

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.

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

So, some essential clarification is needed before one can proceed
even with experimental solutions.

The relationship between resource and representation, the range
of valid representations of a resource, the means by which one
differentiates between resource and representation, and how one
can create/store/access knowledge about both resources and
representations needs alot clearer definition.

Not to mention the need for the concept of canonical representation
for digital resources, being a bit-equal copy of the resource.


Patrick Stickler, Nokia/Finland, (+358 40) 801 9690, patrick.stickler@nokia.com
Received on Sunday, 2 February 2003 12:06:16 UTC

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