Eric Lease Morgan
Wed, 02 May 2001 09:01:58 -0400
firstname.lastname@example.org <email@example.com> wrote:
> My colleague Jane Hunter did an excellent job comparing the functionality of
> the tool schema mechanisms in a paper she is presenting at WWW10 this week in
> Hong Kong, it is available at
I have briefly taken a look at this paper. It clarifies the distinction
between XML "schema" and RDF "schema", and well as presenting possibilities
of combining their strengths to "enhance metadata interoperability". Thank
you for passing it along.
> Now onto the issue of "passing RDF metadata in OAI responses", in particular.
> I need to understand the motivation for this as I evaluate, with Herbert and
> other people in the OAI community, our choices in OAI. Is it:
> 1. A desire to mix multiple namespaces in a metadata record (e.g., mix dc tags
> with GEM tags). In the DC community this is currently called devising an
> "application profile"....
> 3. The fact that some places have metadata stored in XML RDF and just want to
> expose that without further processing. By this I mean that the metadata
> looks like...
> 4. A desire to use other primitives in the RDF and/or RDFS namespace such as
> the container primitives (alt, seq, etc.).
> Adressing each of these:
> 1. It is not necessary to use RDF to mix elements from multiple namespaces.
> One can write an XML schema to allow this....
> 3. Wrapping a metadata in RDF tags doesn't make it "RDF". As said earlier,
> RDF is really much more than a set of XML tags. IF this is indeed the
> motivation here, I'd humbly suggest stripping off the outer RDF tags before
> embedding in an OAI response.
> 4. The use of other RDF primitives in the metadata description starts to make
> this more interesting and I'd like to understand more of the particulars.
> In closing, creating an XML schema for an RDF stream so it can embedded
> in an OAI protocol requests seems, in my opinion, to not be the best
> approach. It has the flavor of mixing apples and oranges. If, indeed,
> the desire is to use some of the semantic expression functinality of
> RDF, then we in the OAI community need to consider our rather tight
> commitment to XML schema. I'd love to see continued discussion about
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.
I am rather new to this whole thing, so please excuse my ignorance. I am not
interested, at the present time, in any AI applications. AI has come and
gone so many times since computers were used predict where bombs would fall
that I am a bit jaded by the whole idea.
As a librarian who does applied R&D I am interested in exploring how to
collect, organize, archive, and disseminate data and information. RDF
provides guidelines for describing data/information -- the triples. It seems
to provide these guidelines in an extensible manner, and it is not tied to
any particular vocabulary. In fact, it provides the means for extending
existing vocabularies. It is used as a container for metadata. OAI provides
a means for querying a repository and getting back sets of metadata.
Why couldn't the metadata returned by a GetRecords response be represented
in an RDF format? If RDF is a good way to describe metadata, and databases
were designed to hold this metadata, then OAI harvesters could directly save
RDF from the GetRecords response to the these databases.
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?
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