JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for DC-LIBRARIES Archives


DC-LIBRARIES Archives

DC-LIBRARIES Archives


DC-LIBRARIES@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DC-LIBRARIES Home

DC-LIBRARIES Home

DC-LIBRARIES  February 2005

DC-LIBRARIES February 2005

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

XML schema

From:

Ann Apps <[log in to unmask]>

Reply-To:

DC-Libraries Working Group <[log in to unmask]>

Date:

Wed, 9 Feb 2005 15:43:14 +0000

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (116 lines)

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
--------------------------------------------------------------------------

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
July 2016
June 2016
May 2016
April 2016
March 2016
January 2016
December 2015
October 2015
June 2015
May 2015
March 2015
September 2014
July 2014
June 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
December 2012
November 2012
September 2012
August 2012
March 2012
February 2012
November 2011
October 2011
September 2011
July 2011
June 2011
January 2011
November 2010
October 2010
September 2010
August 2010
June 2010
May 2010
April 2010
March 2010
February 2010
October 2009
September 2009
June 2009
May 2009
March 2009
February 2009
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
February 2008
October 2007
September 2007
August 2007
July 2007
June 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
December 2005
November 2005
October 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
April 2004
March 2004
February 2004
December 2003
November 2003
October 2003
September 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
November 2002
October 2002
September 2002
July 2002
May 2002
April 2002
March 2002
January 2002
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
July 2000
June 2000
April 2000
March 2000
February 2000
January 2000
December 1999


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager