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

> -----Original Message-----
> From: ext Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> Sent: 03 February, 2003 13:01
> To: Stickler Patrick (NMP/Tampere)
> Cc: julian.reschke@gmx.de; www-tag@w3.org
> Subject: Re: Valid representations, canonical 
> representations, and what
> the SW needs from the Web...
> 
> 
> 
> Am Montag, 03.02.03, um 09:52 Uhr (Europe/Berlin) schrieb 
> Patrick.Stickler@nokia.com:
> >
> >> -----Original Message-----
> >> From: ext Julian Reschke [mailto:julian.reschke@gmx.de]
> >> Sent: 02 February, 2003 23:00
> >>>> [...]
> >>>> What's not really possible right now is to have metadata for
> >>>> a resource
> >>>> (PROPFIND succeeds) with no representation (GET/HEAD fail),
> >>>> because that's
> >>>> not really compatible with the underlying model (PROPFIND for
> >>>> non-collection
> >>>> resources basically being an extended HEAD method with XML
> >>>> marshalling).
> >>>
> >>> Well, if that's true, then WebDAV definitely fails as a solution
> >>> to standardized access to resource metadata, since one 
> would expect
> >>> to be able to use the same solution for all resources, whether or
> >>> not any representation is available.
> >>>
> >>> Pity...
> >>
> >> OK. So how do we expect HEAD to behave when no representation
> >> is available?
> >
> > Well, as it appears that HEAD only returns metadata describing
> > the representation, and not metadata describing the resource,
> > then neither HEAD nor PROPFIND are acceptable solutions to this
> > problem.
> >
> > It looks like we need something new. Such as a new set of methods,
> > GET-META, PUT-META, POST-META, which would by definition deal with
> > metadata describing the resource itself, and would also ideally
> > by definition accept/return RDF.
> >
> > Patrick
> >
> 
> WebDAV offers this and, yes, one could store RDF data in a single
> or several properties as WebDAV properties can keep arbitrary XML.

Well, perhaps. But I think it would be rather kludgy to
force RDF into the WebDAV prop content model, but maybe
I'm being too pessimistic. Perhaps it could be made to work
without too much ugliness. I'll have to think on that some
more...

> What Julian mentioned is that one has to define what the result
> of GET/HEAD on a "meta-only" resource would be. Maybe a 404
> is approriate, maybe not. 

I would expect a HEAD request to work fine even for resources
with no representation, since you're not asking for a body, 
so whether a body exists or not shouldn't matter (though current
servers may balk, not being used to non-web-resources).

> WebDAV has no answer to that currently
> and I'm not sure what the correct behaviour should be. Maybe a
> 406 could also work.
> 
> But that issue needs to be solved by *any* out-of-GET-band
> method which returns meta data for resources without representations.

Exactly. The mechanisms for interacting with a server to obtain/manipulate
metadata about resources rather than representations needs to be
addressed at a fundamental level of the web/sw architecture.

And those mechanisms for interacting with metadata need to be disjunct
from the mechanisms for interacting with representations, and those
standardized mechanisms should serve as the solution for access to
information that RDDL now aims to address.

Here's a use case: (presuming HTTP URIs, for now)

1. Client encounters element in XML instance named with a term it doesn't recognize
2. Does an HTTP META-GET on the term URI (to the server indicated in the http: URI)
3. Gets an RDF graph in response describing the term, including
   relations to vocabularies, models, schemas in which it is used
   and other related resources (e.g. rdfs:isDefinedBy, rdfs:seeAlso)
4. Client wishes to utilize an XML Schema, if available, to validate element
5. Does an HTTP META-GET on each schema URI
6. Based on descriptions of schema resources, selects one
7. Does an HTTP GET on the schema URI to obtain representation of schema
8. Validates the element

Now in the above use case, the term itself is abstract. It is not
a web resource. But one can inquire about it, and determine what 
it means, or how to validate it, or how to display it, etc. without
any recourse whatsoever to any namespace! 

Let me stress this point: the namespace itself has no significance
to the relationships between term, vocabulary, model, schema, stylesheet,
etc. The namespace is simply punctuation. And the resolution architecture
described above works equally well whether all terms in a model or
schema share a common namespace or are each from a different namespace;
which facilitates reuse of common content models without concern about
namespaces, only term names, by eliminating (ignoring) the artificial and 
needless partitioning that namespaces are percieved to impose because
folks think they have functional significance at the higher levels
of the web architecture (which they do not).

What matters are functional vocabularies, models, concepts, etc. not
the insignificant punctuation that we use to ensure globally unique
names, and the mechanisms by which we organize and interact with
knowledge about all resources needs to be independent of the
blurring, practical machinery of representations and consistent for
all kinds of resources, web-accessible or otherwise.

The above scenario accomplishes that.

It should also be noted that it accomplishes that for the SW and
not just XML, since a term in an RDF (or XTM) knowledgebase is
denoted by a URI, not a qname, and hence one cannot even *know*
what namespace it might have been grounded in, even if one might
make a good guess (but guessing is a rather bad architectural
principle, whatever the discipline). So even if one could GET a
RDDL document from a namespace URI, one doesn't know what that
namespace URI definitely is, just given the term URI.

Namespaces don't exist in RDF, and hence are not first class
concepts upon which the SW can be built.

Whether or not the WebDAV machinery can be evolved to meet these needs,
or whether something new need be added is a separate question. Certainly
the less change and the greatest use of existing infrastructure, the better.

The RDF'ization of WebDAV seems like a possible fruitfull path. If that
is not a reasonable option, then specific SW extensions to HTTP seem
the next obvious approach.

Cheers,

Patrick

--
               
Patrick Stickler
Chief Technology Specialist
Forum Nokia, Nokia Mobile Phones
patrick.stickler@nokia.com
(+358 40) 801 9690

Received on Monday, 3 February 2003 07:17:58 UTC