Thomas G. Habing
Mon, 30 Apr 2001 13:35:42 -0500
We've been looking at passing RDF via OAI protocols. Much of our metadata
is currently stored in RDF syntax with Dublin Core, Dublin Core Qualified,
and Dublin Core Agent semantics (see for example
However there are a couple of key issues that we're still trying to overcome
and that may make doing this more trouble than it's worth.
1) There is no authoritative RDF XSD available (that we've know of) such as
would be required to conform to OAI validation requirements (nor for that
matter are there authoritative and extensible DCQ or DCA XSDs presently
available, and the available OAI DC XSD might not be extensible enough --
see below). There is presently considerable debate within the RDF community
as to whether XSD is sufficient to describe RDF -- so you might be skating
on thin ice here. One of the problems is that the true, allowable content
model for a given RDF element really varies based RDF attribute values
(e.g., RDF:parseType) -- something that's difficult to represent rigorously
enough in XSD.
An additional complication is that OAI wants only a single pointer to an XSD
to be used for validation. We've looked at a couple of approaches to
dealing with this issue and the one we'd prefer to implement would be to
create an XSD for use by OAI that in turn points to XSDs for each of the
namespaces used. We feel this would maintain modularity and flexibility,
but it means a proliferation of umbrella-level (proxy?) XSDs. The proxy XSD
<xsd:import namespace="..." schemaLocation="..."/> for each namespace
In any event this still requires creating an XSD for RDF and any other
namespaces used. To embed RDF attributes properly (as in your example) also
requires that the other namespaces used (e.g., DC, Alex) have XSDs that
allow for inclusion of attributes from an arbitrary namespace (e.g. RDF).
The OAI XSD for DC doesn't actually allow that kind of extensibility, so
you'd also need to create an alternative DC XSD as well.
2) There are also a number of issues about how best to use RDF. There's a
lot of debate as to the usefulness of RDF in general. We find RDF useful as
a way to identify in a semantic neutral fashion each "granule" of metadata,
but you do get into a number of nesting and attribute reuse issues. Thus we
use RDF in the following manner to encapsulate DC:Date data:
And we use it to encapsulate DC:Creator data as follows:
Université de Montréal...
(To go to full example see URL above -- Note we also embedded MathML
namespace in this example.) These parse using SiRPAC, but are not the only
approach. (In particular many might take issue with the way we've chosen to
use DCQ and DCA semantics and with the degree of RDF nesting.)
The bottom-line is that there's a fair amount of work to be done to create
multi-namespace RDF files that can be validated using XSD as envisioned by
OAI. We'll be interested in any conclusions you reach. We'll pass along
what we learn as well.
Eric Lease Morgan wrote:
> Eric Lease Morgan <firstname.lastname@example.org> wrote:
> > <?xml version="1.0"?>
> > <GetRecord xmlns="http://www.openarchives.org/OAI/1.0/OAI_GetRecord"
> > xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
> > xsi:schemaLocation="http://www.openarchives.org/OAI/1.0/OAI_GetRecord
> > http://www.openarchives.org/OAI/1.0/OAI_GetRecord.xsd">
> > <responseDate>2001-04-30T07:24:56-7:00</responseDate>
> > <requestURL>http://www.infomotio...30-44</requestURL>
> > <record>
> > <header>
> > <identifier>twain-30-44</identifier>
> > <datestamp>1999</datestamp>
> > </header>
> > <metadata>
> > <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> > xmlns:dc="http://purl.org/dc/elements/1.1/"
> > ...
> > </GetRecord>
> I have saved my proto GetRecord response as a file:
> I then fed this URL to SiRPAC:
> It parsed correctly! :-)
> Eric Lease Morgan
> Digital Library Initiatives, NCSU Libraries
> OAI-implementers mailing list
Thomas G. Habing
Research Programmer, Digital Library Initiative
University of Illinois at Urbana-Champaign
052 Grainger Engineering Library, MC-274
email@example.com, (217) 244-7809