Re: RDF Description Services - and WebDAV

Dan Brickley wrote:
> I was asked by a few people what exactly needs doing. In brief, I think we
> need a comparison of the metadata / property models of RDF and WebDAV to
> be written down for discussion. I suspect one way to achieve this is for
> the few of you with experience of both RDF and WebDAV (however
> sketchy!) to send a quick mesg to the list. Then someone (possibly but
> hopefully not me ;-) can summarise and we can start to pull together a doc
> that might usefully be sent to the webdav list for discussion.

Okay, here's the message I promised to write a couple of months ago. We have
a little experience with using WebDAV, Apache mod_dav in particular.  We
also have a little experience, in a separate project, with using RDF to
represent metadata "about this document", using Dublin Core, translated
IPTC, etc.  I'm familiar with both projects and can do a little
compare/contrast.

Question: is WebDAV a suitable protocol for exposing a resource discovery
service based on RDF?

Short answer: It's possible to use WebDAV as a protocol between an RDF-aware
client and an RDF-aware server, but I don't think WebDAV is suitable as a
"lingua franca" for communicating with non-RDF-aware clients.

The data model for WebDAV properties is flat key/value pairs, though the
values can be arbitrarily complex XML.  The WebDAV protocol has rudimentary
operators for getting resources that have properties set to a specified
value. The property is associated with a resource by virtue of the protocol,
and is sometimes implied.  For example, the side-effect of doing a GET
request is that you can also get all the properties associated with that
resource.

Request:

... <!- ellipses indicates omitted protocol boilerplate -->
GET http://www.w3.org/~danbri HTTP/1.1
...

Reply:
...
    <D:prop>
	<dc:creator>Dan Brickley</dc:creator>
    </D:prop>
...

The data model for RDF you already know.  If I had to summarize it for a
non-RDF audience, I'd say something like: it is based on Statements. Each
Statement is a triple consisting of a Property, a Resource, and a Value. The
association of the property and the resource is intrinsically part of the
data model.

Example: {dc:creator, http://www.w3.org/~danbri, "Dan Brickley"}

The Value of a property may also be a Resource, and a Resource may be
created anonymously to act as a structural binding for properties and
values.  This enables the expression of structures that are more complex
than flat key/value, including sub-properties, qualified values, and
structured containers.  You can even have Statements about Statements.

For example, to express the width and height of an image together as a unit:

{img:dimensions, http://www.w3.org/logo.gif, anonymous:123}
{img:width, anonymous:123, "640"}
{img:height, anonymous:123, "480"}

========================================

At first blush, it appears that WebDAV is too narrow a protocol to allow an
RDF-aware client to communicate with an RDF-aware server.  However, consider
a mapping from RDF triples to WebDAV flat key/value pairs:

* Each RDF Property becomes a WebDAV key.
* Each Value becomes a WebDAV value with an indication of whether the value
is a resource or a literal.
* Each RDF Resource is identified with a URL.

The RDF data model can be fully tranversed with unextended WebDAV protocol. 
It might take multiple requests, and the burden of naming and managing
anonymous resources would fall completely onto clients, but it would work.

Of course, non-RDF aware clients would not know what to do with a property
value of "<flatRDF:resource>anonymous:123</flatRDF:resource>", or how to
interpret rdf:type, and so on.  Fundamentally, an ordinary WebDAV client
expects to find a literal value for every property.  When an ordinary client
looks up the dc:title of a document, it doesn't expect to get an object
which describes an alternation of text values by language (rdf:Alt,
xml:lang), it just expects some text!

There's no hope for passing the unalterered RDF syntax in this scenario. 
Both client and server might be RDF-aware, but the protocol prevents direct
usage of the syntax, except for an escape-hatch, such as defining a
"special" URL which returns the entire RDF model in a single property, as a
full RDF serialization.  Even this escape-hatch is problematic: the mod_dav
implementation of WebDAV transforms the XML used to represent a property
value.  This transformation could damage RDF.  For example, comments and
PI's are thrown away, which could cause loss of fidelity for
parseType='Literal' values.

The good news is that there is a new HTTP extension on the horizon that is
intended to address the rudimentary nature of the property search mechanism
in WebDAV.  This extension, called DASL, could be exploited to allow better
access to the RDF model.

DASL is a close-to-being proposed working draft protocol for DAV Searching &
Locating.
	<http://www.webdav.org/dasl/>

DASL is a framework protocol.  It does not directly implement searching.
Rather, its a standard transport and manager for a variety of query
grammars. Included with the base DASL protocol is a default query grammar,
called DAV:basicsearch.  DAV:basicsearch is an SQL-like query language which
operates over WebDAV properties.  Every DASL-extended server MUST implement
DAV:basicsearch, and MAY support additional query grammars.  A client can
query for the supported grammars, as well as the "schema" for a query in a
particular grammar.  That's DASL in a nutshell.

Obviously, an "RDF Search" grammar could be defined and implemented by
servers wishing to expose the unadulerated RDF model. In addition, we can
still transform the RDF model into the flat key/value WebDAV model, and use
a nested DAV:basicsearch query (in some cases) to reduce multiple
rudimentary WebDAV property requests into a single DASL search request.

Perry A. Caro
Advanced Technology Group
Adobe Systems Incorporated

Received on Monday, 7 February 2000 21:20:52 UTC