Douglas-
Our experiences were similar to yours (see our DC-2001 paper
[http://www.nii.ac.jp/dc2001/proceedings/product/paper-36.pdf] and paper in
latest issue [vol. 18, no. 2] of OCLC Systems & Services Journal).
A couple of additional points beyond those already made, primarily in regard
to existing XML schemas:
----- Original Message -----
From: "Douglas Campbell" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Thursday, July 25, 2002 6:24 PM
Subject: Implementing the DCQ RDF/XML proposal
> Kia ora,
> ...
> We are using qualified DC and storing in XML (using Endeavor Information
Systems' "ENCompass" product [2] ). We looked at Andy Powell and Pete
Johnson's guidelines [3], but felt if you follow those guidelines you're
only a couple of steps away from the RDF/XML proposal, so we decided to take
the plunge and give RDF a go.
>
Actually Andy, Pete, and a few others of us have done some additional work
since the guidelines you reference were released. A revision was posted 23
July http://dublincore.org/documents/2002/07/23/dc-xml-guidelines/.
This revision was stimulated in part by additional work that led to creation
of modular XML Schema Definitions for the dc and dcterms namespaces and
might be of some relevance to your application. (See Carl Lagoze's post to
this list July 15, also the Website he mentions
http://www.ukoln.ac.uk/metadata/dcmi/xmlschema/). We did these XML schemas
in such a way that they could be imported or included in other XML schemas,
including those that might at some future date take advantage of RDF, and/or
add local extensions, such as you're doing -- though we don't necessarily
recommend doing so right now since the additional tagging and structure
(necessarily done locally in absence of cannonical XSD for RDF) might impact
on scope of interoperability. Long-term thought is that it would be
desirable if RDF and non-RDF XML implementations of DC and DCQ can co-exist
with a minimum of redundant XSDs for the dc and dcterms namespaces. This
would facilitate transformations using XSLT and would reduce redundant work.
XML Schema is strong on reuse of XSDs, and it'd be nice if we could exploit
that strength to our advantage. (Hopelessly optimistic, aren't I?)
> We don't use any RDF engines, so for us it is a case of using the proposal
purely as a DTD/schema for our XML - we use XSLT stylesheets to interrogate
the XML as XML (not RDF tuples). The benefit is we get XML encoding usable
by XSLT which is also RDF compliant. Incidentally, I couldn't find any DTD
or schema for RDF/XML except for one created by Rick Jelliffe two years ago
[4] - is this the only one?
>
As you probably noted the Jelliffe XSD dates from early 2000 and is
therefore not compatible with later releases of XSD documentation. There's
at least one other XSD for RDF we came across, but in the end, like you, we
generated our own XSD for RDF for our own experimentation as well as
creating RDFSs and XSDs documenting local extensions we wanted to use. We
would hesitate to hang a production implementation on our own local XSD for
RDF however. Maybe we'll see a more widely accepted, cannonical XSD for RDF
soon?
> We have a number of local (non-DCMI) elements and qualifiers, so we
created an RDF schema [5], which we modelled on the DCMI proposal and more
recently Roland Schwaenzl's version of the DCQ RDF/XML Schema [6], to
declare these. We tested some sample records [7] against the W3C RDF
Validation Service [8] and they seemed OK (NB: Not all our handles [9] are
operational yet). As our system uses DTDs not XML Schema, we created a DTD
too [10].
>
We stuck with XSDs throughout in part to support better data typing. You'll
note in particular that the approach used in the XSDs for the dcterms
namespaces proposed in http://www.ukoln.ac.uk/metadata/dcmi/xmlschema/
allows the XML parser to do much of the data type checking for dcterms
encodings.
Tim Cole
University of Illinois at Urbana-Champaign
|