RE: RDF, OAI, and application within Libraries

Dave,  Thanks for this clear note.  I especially like the point:

> It is perfectly possible to define a simple XML syntax for 
> RDF which is
> XML-schema validatable, so long as you don't want any deep 
> meaning to the
> validation (e.g. serialize property names just as text, into 
> attribute values
> or into element bodies).

This more succinctly expresses my, as usual, long-winded comments in
[1].  As you say, yes we certainly could come up with an XML schema for
a XML encoding of RDF triples, but the result would oddly impose a
strongly contrained data format tool onto a data model whose raison
d'etre is flexible ontology and relationship intermixing.  

A few more comments:

1. As stated in the earlier note, I think that we in OAI need to be open
to questioning our use of XML schema for defining and validating the
metadata passed back in responses to OAI requests (distinct from using
XML schema as means of defining the format of the packaging protocol
response itself).  It may be that such a strict data formating approach
may indeed be inappropriate and too constraining and we should examine
and possibly provide the option for permitting other validation
definition mechanisms for the metadata - e.g., schematron, relax, RDF
schema, etc. all of which have numerous attributes that have been
discussed in xmlhack, etc.  
2. At the same time that we examine other options we need to be prudent
about the tradeoffs between providing choices and flexibility (e.g.,
allowing multiple schema mechanisms for metadata) vs. the ease of use
for the average user.  The two are not necessarily incompatible but it
is certainly true that each option or choice that you make available to
the user community makes it more difficult for them to use/implement
(all of our feature rich Microsoft goodies demonstrate this well!).  Our
choice in OAI was to aim as low-barrier as possible while providing a
reasonable level of functionality for the broadest application.  Such a
choice necessarily excludes a portion of the user community interested
in richer applications. Obviously, we need to understand whether the OAI
has, by choosing single solutions like XML schema, made the
feature/complexity choice at the wrong place.  

That all said, let's keep discussing the positioning of RDF vis-a-vis
OAI. We have, after all, made a public commitment to a 12-18 month
experimentation period with the existing OAI protocol, and such
questions are extremely relevant to the experiement.  An outstanding
question for me is to understand where RDF sits in the OAI data provider
and service provider dichotomy.  It may be that the vast majority of
data providers don't need (or even understand) RDF and are mainly
interested in exposing metadata as simple attribute value pairs or
simple trees for which XML is perfectly appropriate.  It may be that
some service providers want then to combine that relatively fixed data
from multiple data providers, process it into some triple store, and use
the power of RDF to express relationships among the distributed data.
This reflects of my thinking of how OAI fits into the Harmony
(http://www.ilrt.bris.ac.uk/discovery/harmony/) project, in which Jane
Hunter Dan Brickley and I are working on modeling and metadata
interoperability and using RDF as the mechanism for doing this.  It may
be that my perception is wrong and that RDF is indeed much more
appropriate at the data provider level in which case we should
reconsider some of our choices in OAI.

Carl

[1]
http://oaisrv.nsdl.cornell.edu/pipermail/oai-implementers/2001-May/00011
6.html

> -----Original Message-----
> From: Dave Reynolds [mailto:der@hplb.hpl.hp.com]
> Sent: Thursday, May 17, 2001 4:50 AM
> To: Peter Breton
> Cc: Mick Bass; www-rdf-dspace@w3.org; Brian McBride (E-mail)
> Subject: Re: RDF, OAI, and application within Libraries
> 
> 
> Peter Breton wrote:
> 
> > It seems to me that at least part of the problem seems to 
> be that RDF is
> > format-agnostic (RDF is the same whether it's expressed as 
> triples, in a
> > visual graph, or in XML serialization -- and there are 
> multiple possible
> > XML serializations), whereas the intent of OAI is to be directly
> > parsable and usable.
> 
> Actually I'm not sure that that is the main problem with RDF in OAI.
> 
> The problem, as I see it, is that OAI requires not just 
> well-formed XML but
> XML validatable by a fixed XML-Schema. The whole point of RDF 
> is to be able
> to combine metadata formats and thus properties drawn from different
> namespaces can appear in the same set of assertions. So while 
> is it possible
> to define an XML-Schema for, say, Dublin Core in RDF it is 
> not obvious that
> you can have a fixed XML-Schema that would validate arbitrary 
> RDF conforming
> to the M&S spec. It is this flexibility of property name 
> spaces rather than
> format-agnosticism which I see as the issue. The latter is 
> actually the
> solution.
> 
> > Would a specific OAI-blessed canonical XMLserialization 
> fly, d'you think?
> 
> Exactly.
> 
> It is perfectly possible to define a simple XML syntax for 
> RDF which is
> XML-schema validatable, so long as you don't want any deep 
> meaning to the
> validation (e.g. serialize property names just as text, into 
> attribute values
> or into element bodies). Both Sergey Melnik and Brian McBride 
> (and probably
> others) have proposed raw RDF-triple-in-XML syntaxes which 
> either do, or
> could easily be adapted to, meet this need.
> 
> It is conceivable that the new W3C RDF Core working group 
> might specify a raw
> triple syntax which meets the constraints of XML Schema 
> validation. OAI could
> define/bless such a serialization anyway.
> 
> Dave
> 
>

Received on Thursday, 17 May 2001 07:23:18 UTC