W3C home > Mailing lists > Public > www-tag@w3.org > November 2002

Re: Opacity and resource metadata (was Re: proposed TAG issues: uniform resource version info and access of resource metadata

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Wed, 27 Nov 2002 16:40:11 +0100
Cc: Mark Baker <distobj@acm.org>, www-tag@w3.org
To: Ossi Nykänen <onykane@butler.cc.tut.fi>
Message-Id: <83C04583-021E-11D7-B002-00039384827E@greenbytes.de>

Perhaps I can shed some light on the WebDAV/DeltaV view of this:

Am Mittwoch, 27.11.02, um 12:02 Uhr (Europe/Berlin) schrieb Ossi 
Nykänen:

>
> On Tue, 26 Nov 2002, Mark Baker wrote:
>
>> ...
>> I'd suggest that asserting the relationship between those resources
>> would best be done with a triple, rather than naming conventions.  If
>> done with an HTTP header, you might get these headers in a response 
>> to a
>> GET or HEAD on http://www.w3.org/TR/1998/REC-xml-19980210;
>>
>>   HTTP/1.1 200 Ok
>>   Metadata: http://www.w3.org/TR/1998/REC-xml/meta.rdf
>>   Up-to-date: http://www.w3.org/TR/1998/REC-xml
>>
>> Note that you can run out and write up an I-D to define these headers
>> right now if you want to; Web architecture already supports this form
>> of extension.  IMO, I don't think this is anything requiring TAG
>> attention.
>
> This is true. In fact, no naming convention, nor HTTP extension to 
> explain
> version information would be required if there was a common agreement 
> how
> to refer to metadata of a declared by a resource in the first place 
> (and
> thus the statement "I'm a version resource of [2]" would simple be one
> part of [1]'s metadata). The idea of placing pointer to the uniform
> metadata access point to HTTP header sounds a reasonable technical
> solution to me, but the common agreement is the thing I'm really 
> looking
> for.

WebDAV defines properties for a resource. There are "dead" properties 
which
do not have server defined semantics and "live" properties which do have
defined semantics.
DeltaV extends the set of live properties to allow handling of 
verisioning.
The properties define the relationship between and types of resources.
There are HTTP methods like PROPFIND and REPORT to retrieve these
properties with special reports for specific use cases.

So, instead of special headers on GET, WebDAV "meta data" is retrieved
"on the side" using other methods. Manipulation of this data is either
implicit by performing operations (like CHECKIN) or explicit by setting
property values (PROPPATCH).

Resource content is totally opaque to a WebDAV/DeltaV server. Of
course one could implement a server which does meta data extraction
out of xhtml, but that is outside of WebDAV/DeltaV specifications.

> In other words, the point that I'm trying to make is that if we all use
> our _own_ ways to give references to our metadata (that's what we're 
> doing
> today), we face great difficulties in practise. You use "Up-to-date:", 
> I
> use "Version-controlled-resource:", Zaphney uses element <meta> in the
> content, etc. If there was a clear, W3C-endorsed recommendation about
> which policy to follow, making SW/WS applications would simplify a 
> great
> deal (a uniform reference to "all" metadata declared by a resource, 
> i.e.,
> a single access point where to look metadata from). If WebDAV+DeltaV is
> (will be) such policy, it would be nice if it was clearly stated
> somewhere.

I am not very familiar with the specifics of rdf, but maybe it is of
interest that WebDAV is using XML. Especially all properties are
defined in XML. A property name is an XML element name
(XML namespace and local name), property content is XML as
well. So maybe RDF meta data and WebDAV properities go along
rather nicely.

> I bet these issues (and priorities) are something publishers, 
> librarians,
> archiving organisations etc. would have something worth hearing to say
> about!
> [...]

Best Regards, Stefan
Received on Thursday, 28 November 2002 04:20:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:13 GMT