[OAI-implementers] rdf

[lagoze@cs.cornell.edu]

Comments inserted below and some text deleted.

> -----Original Message-----
> From: Eric Lease Morgan [mailto:eric_morgan@ncsu.edu]
> Sent: Wednesday, May 02, 2001 9:02 AM
> To: oai-implementers@oaisrv.nsdl.cornell.edu
> Subject: Re: [OAI-implementers] rdf
> 
> 
> 
> I am interested in passing RDF in the metadata element of an 
> OAI GetRecords
> response so when I write a harvesting application and can 
> pass the content
> of the metadata element off to an RDF storage tool (like 
> Redland, RDFStore,
> or rdfdb) without further processing.

You are going to have to do some processing anyway, right?  You'll have
to pull out the metadata package from the larger OAI protocol response.
The step of "turning that into RDF", wrapping it in the RDF tags, is
minimal.  

I think the idea of exploiting RDF is sensible, I don't think that
embedding the XML data in an OAI response in RDF tags is a great idea.

Let me be more specific.  In OAI we have essentially established a
protocol for the Warwick Framework concept, explained in
http://cs-tr.cs.cornell.edu/Dienst/UI/2.0/Describe/ncstrl.cornell/TR96-1
593?abstract= - making distinct packages of metadata available.  What we
haven't done is dealt at all with the relationships among those multiple
packages - e.g., what does a MARC xxx field have to do with a DC foobar
element.  IMHO, this is an issue better left to the service level rather
than the provider leve.  Why?  1) Because there are possibly multiple
intepretations of such relationships 2) Because understanding and
expressing such ontological thingies is usually not the area of
expertise of the average archive/repository manager.  OAI is targeted at
the kind of folks who usually don't dwell at that level.  

Now, I think that it is entirely reasonable to create a metadata
integrator service.  Such a service might devise a set of RDF schema (or
other mechanism) that express metadata vocabulary interrelationships.
That service could then harvest different metadata packages (in diff.
vocabs.) from data providers and populate a database of canonicalized
metadata, that could then be expressed in other formats or vocabularies
(again derived via something like RDF schema).  

This is actually the kind of thing we have been playing with in our
Harmony project http://www.ilrt.bris.ac.uk/discovery/harmony/ and in a
metadata model called ABC.

> For example, it seems possible for me to convert the entire 
> corpus of the
> Open Directory Project into RDF. I could then save this data 
> into some sort
> of database application such as Redland, RDFStore, or rdfdb. 
> Once in one of
> these sorts of applications I can provide searching and 
> reporting mechanisms
> against them. I could then use OAI to harvest the content of 
> the "deep Web"
> -- the content of databases, have the metadata returned in 
> RDF, and then
> save this data to Redland, RDFStore, or rdfdb as well. OAI 
> strengths seems
> to be the provision of an API for querying remote resources for their
> metadata. RDF's strength lies in describing how that metadata 
> is structured.
> Why not combine them?

RDF doesn't describe how "metadata is structured".  It merely provides a
set of primitives for modeling resource relationships and types.  As
said above, its not that I think that RDF is a bad idea - I think it
makes great sense.  However, it may be more appropriate at a higher
level (service level) than what we've defined OAI for.

Carl

> 
> More to the point, I believe I am more interested in #1, #3, 
> and #4 above. I
> would like to leverage the ability to mix and enhance Dublin 
> Core tags, akin
> to the use of exploiting RDF primitives, and I would like to expose my
> metadata in RDF for further processing.
> 
> -- 
> Eric Lease Morgan
> Digital Library Initiatives, NCSU Libraries
> http://www.lib.ncsu.edu/staff/morgan/
> 
> 
> _______________________________________________
> OAI-implementers mailing list
> OAI-implementers@oaisrv.nsdl.cornell.edu
> http://oaisrv.nsdl.cornell.edu/mailman/listinfo/oai-implementers
>