Dear All,

At the DC-Library meeting in Shanghai I agreed to produce an XML
schema for the DCMI Library Application Profile (DCLibAP).

There is a first draft at:

http://epub.mimas.ac.uk/DC/dc-lib/xsd/dclib.xsd

(in reality at .../dc-lib/2005/02/09/dclib.xsd) At the same location
are a couple of (very noddy) examples: dleg1.xml and dleg2.xml.
The first is a set of descriptions (well 2!), the second is a single
description.

I've validated the schema and the examples with XSV
(http://www.w3.org/2001/03/webdata/xsv)

Various issues:

This XML schema relates to the latest version of the DCLibAP
available on the DCMI web site, dated 2004-09-10. Obviously the
XML schema will need updating when outstanding issues with the
AP are decided. But it seemed a good idea to make a start on the
XML schema with this draft version of the AP.

As far as I know there is not yet an agreed URI for a 'dclib'
namespace, or a location for the XML schema. This probably
needs discussion / decision by DCMI for APs developed by
Working Groups in general: where they should be defined and who
is responsible for their maintenance when the WG has finished. For
this draft schema I have used http://example.com/dclib/ as the
namespace URI and its location is on my server at the above
address (so not persistent!).

Issues with using DC XML schemas:

Because of the way DC element refinements are defined in the
dcterms XML schema, they cannot be explicitly referenced in this
AP schema as well as their parent elements. Thus I've included
them as XML comments in the schema. From the examples you
can see that using an element refinement (eg. dcterms:alternative)
is valid in a DCLibAP description.

The current DC-in-XML specification uses an attribute 'xsi:type' to
capture the encoding scheme used. 'xsi:type' is built in to XML
schemas. Any element may optionally have an xsi:type attribute.
And it isn't possible to constrain its value within a schema for a
particular element to specify a particular encoding scheme. Thus
I've included requirements for values of xsi:type in the annotation
part of elements where it is significant according to the AP.

The recent publication of the DCMI Abstract Model will impact on
the DC-in-XML recommendations. This will alter the encoding for
DC properties in XML, so is likely to imply a need to update this
schema. However the changes are not yet clear, and will need
discussion and decisions by the DC-Architecture Working Group.

Issues using MODS terms:

There are 3 MODS terms in the DCLibAP: location, edition and
dateCaptured.

edition and dateCaptured are sub-elements of mods:originInfo.
Thus I've included mods:originInfo in the XML schema and
commented out edition and dateCaptured. This means that
potentially you could use any other of the sub-elements from
originInfo as well even though they are not in the AP.

The way of encoding these MODS terms is different from, and not
really consistent with, DC practice to date. They have to include
nested elements, eg:

<mods:location>
  <mods:url>http://example.org/myurl</mods:url>
<mods:location>

<mods:originInfo>
  <mods:edition>Version 1</mods:edition>
</mods:originInfo>

<mods:originInfo>
  <mods:dateCaptured>2005-02-09<mods:dateCaptured>
<mods:originInfo>

Also mods:dateCaptured cannnot have an attribute
'xsi:type="dcterms:W3CDTF"'.

Issues with XML schemas:

Any element may have an 'xml:lang' attribute to specify the
language of its value. This is consistent with a general note in the
DCLibAP that any property may have a language attribute. (Good -
that's one problem less!). I've noted this in one of the annotations in
the XML schema.

It is not possible in an XML schema to make obligation and
occurrence requirements on the elements and at the same time
make their order unimportant. That is you can: either define the
order of the elements (which is not correct for a DC AP) and
include occurrence constraints; or allow the properties to be in any
order and allow every property to be optional and repeatable. I don't
believe there is any way round this. Thus I've taken the second
option - all properties optional and repeatable and in any order -
which is also consistent with general DC practice. So I've included
obligation / occurrence details in element annotations.

Best wishes,
        Ann

--------------------------------------------------------------------------
Ann Apps. IT Specialist (Research & Development), MIMAS,
     The University of Manchester, Oxford Road, Manchester, M13 9PL, UK
Tel: +44 (0) 161 275 6039    Fax: +44 (0) 0161 275 6040
Email: [log in to unmask]  WWW: http://epub.mimas.ac.uk/ann.html
--------------------------------------------------------------------------