Before DC-2004, I posted a summary of several problems/issues with the
DC XML Schemas
http://www.ukoln.ac.uk/metadata/dcmi/xmls-issues/
And these were discussed in the WG meeting at DC-2004. See Andy's report
at
http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0410&L=dc-architecture&
T=0&F=&S=&P=4565
This message makes a proposal to address the first (and _only_ the
first) of those issues. i.e. the provision of a set of URIrefs which
support the referencing of a "current version" of each schema (and
changes to the inter-schema referencing necessary to support that).
Apologies for the length and complexity of this message but I think it
is important that I try to explain the background and the options
available.
Current Position
================
The current position is that
http://dublincore.org/schemas/xmls/
points to
[1] http://dublincore.org/schemas/xmls/qdc/2003/04/02/dc.xsd
[2] http://dublincore.org/schemas/xmls/qdc/2003/04/02/dcterms.xsd
[3] http://dublincore.org/schemas/xmls/qdc/2003/04/02/dcmitype.xsd
[4] http://dublincore.org/schemas/xmls/qdc/2003/04/02/simpledc.xsd
[5 http://dublincore.org/schemas/xmls/qdc/2003/04/02/qualifieddc.xsd
[1] contains a reference to the W3C xml.xsd schema, using an absolute
URI reference
[2] contains references to [1] and [3], using relative URI references
(same directory)
[3] contains no external references
[4] contains a reference to [1], using a relative URI reference (same
directory)
[5] contains a reference to [2], using a relative URI reference (same
directory)
[1], [2] and [3] are certainly referenced by implementer schemas so
these URIs _must_ continue to dereference to these schemas.
[4] and [5] are probably referenced by implementer schemas so these URIs
_must_ continue to dereference to these schemas.
The following more recent versions exist - they were never announced or
linked to from http://dublincore.org/schemas/xmls/ but some implementers
found them
[6] http://dublincore.org/schemas/xmls/qdc/2004/06/14/dcterms.xsd
(as [2], but amended to include XML elements for the license and
rightsHolder properties)
[7] http://dublincore.org/schemas/xmls/qdc/2004/06/14/dcmitype.xsd
(as [3] but amended to include enumerated values for the MovingImage and
StillImage classes)
[6] contains a reference to "dc.xsd" and to [7], using relative URI
references (same directory)
[7] contains no external references.
As dc.xsd doesn't exist in this directory, it seems to me that [6] is
essentially unusable, and I'm inclined to say we should delete it.
[7] contains no external references so is usable, and although it was
never announced, some implementers found it, and it may be referenced by
implemeter schemas so that URI _must_ continue to dereference to that
schema.
Note: there have been no DCMI-supplied XML schemas issued to provide an
XML element reflecting the approval of the dcterms:provenance property.
Proposal 1(a): Issuing New Versions
====================================
I suggest we now create
[8] http://dublincore.org/schemas/xmls/qdc/2005/01/25/dcterms.xsd
(as [2], but amended to
(a) include XML elements for the license, rightsHolder, & provenance
properties; and
(b) contain references to [1] and [7] using relative URIs giving
absolute paths (/schemas/xmls/qdc/2003/04/02/dc.xsd and
/schemas/xmls/qdc/2004/06/14/dcmitype.xsd) (so that the references will
resolve on the mirror sites)
A schema corresponding to [8] is currently available at
http://homes.ukoln.ac.uk/~lispj/dc-xmls/schemas/xmls/qdc/2005/01/25a/dct
erms.xsd
(N.B. That is not usable because the relative URIs don't resolve from
that location.)
This approach suggests that we create new versions of a schema when the
content of that schema changes, and also when it is necessary to update
references to specific date-stamped versions of the other schemas. i.e.
- any change to dc.xsd results in
- a new date-stamped dc.xsd
- a new date-stamped dcterms.xsd referencing the new dc.xsd
- (see also below re latest versions)
- any change to dcterms.xsd results in
- a new date-stamped dcterms.xsd
- (see also below re latest versions)
- any change to dcmitype.xsd results in
- a new date-stamped dcmitype.xsd
- a new date-stamped dcterms.xsd referencing the new dcmitype.xsd
- (see also below re latest versions)
The advantage of 1(a) over 1(b) is that there are redundant versions of
schemas are not created; the disadvantage is that it requires careful
management of the inter-schema references.
Proposal 1(b): Issuing New Versions
====================================
An alternative to the above would be to create new versions of all three
schemas each time any one of the three is changed i.e. we now create
[9] http://dublincore.org/schemas/xmls/qdc/2005/01/25/dc.xsd (as [1])
[10] http://dublincore.org/schemas/xmls/qdc/2005/01/25/dcterms.xsd
(as [2], but amended to include XML elements for the license,
rightsHolder, & provenance properties)
[11] http://dublincore.org/schemas/xmls/qdc/2005/01/25/dcmitype.xsd (as
[7])
[10] contains references to [9] and [11], using relative URI references
(same directory)
Schemas corresponding to [9], [10], [11] are currently available at
http://homes.ukoln.ac.uk/~lispj/dc-xmls/schemas/xmls/qdc/2005/01/25b/dc.
xsd
http://homes.ukoln.ac.uk/~lispj/dc-xmls/schemas/xmls/qdc/2005/01/25b/dct
erms.xsd
http://homes.ukoln.ac.uk/~lispj/dc-xmls/schemas/xmls/qdc/2005/01/25b/dcm
itype.xsd
Following this approach
- any change to dc.xsd results in
- a new date-stamped dc.xsd
- a new date-stamped dcterms.xsd
- a new date-stamped dcmitype.xsd
- (see also below re latest versions)
- any change to dcterms.xsd results in
- a new date-stamped dcterms.xsd
- a new date-stamped dc.xsd
- a new date-stamped dcmitype.xsd
- (see also below re latest versions)
- any change to dcmitype.xsd results in
- a new date-stamped dcmitype.xsd
- a new date-stamped dcterms.xsd
- a new date-stamped dc.xsd
- (see also below re latest versions)
The advantage of 1(b) over 1(a) is that it is less complex to manage the
inter-schema references: dcterms.xsd always uses same directory relative
URI references; the disadvantage is that there are redundant
versions/copies of schemas.
Proposal Two: Access to Latest Versions
=======================================
I suggest we also introduce three new "non-date-stamped" URI references
[12] http://dublincore.org/schemas/xmls/qdc/dc.xsd
[13] http://dublincore.org/schemas/xmls/qdc/dcterms.xsd
[14] http://dublincore.org/schemas/xmls/qdc/dcmitype.xsd
to refer to the latest versions of dc.xsd, dcterms.xsd and dcmitype.xsd.
I _think_ these can simply be redirects to the latest dc.xsd,
dcterms.xsd, and dcmitype.xsd respectively. And those redirects would
require updating when changes were made to those target schemas. (Under
Proposal 1(b), all three redirects would change whenever a change was
made because all three target schemasa are re-issued; under 1(a) a
change to dcterms.xsd only would require a change to only that redirect)
Container Elements
===================
Note that I propose that we do _not_ create new versions of [4] or [5]
or corresponding redirect references, because we agreed in the WG
meeting in Shanghai to develop schemas with XML-namespace-qualified
container elements. I'll post a separate message regarding that,
probably at the start of next week.
But for now I'd like to try to establish
(a) whether what I've proposed here will work, or whether I've missed
something(!)
(b) whether we should adopt 1(a) or 1(b)
(I started off in favour of 1(a) to avoid generating redundant copies,
but I think I'm now in favour of 1(b) to simplify the maintainance of
the cross-references).
Pete
-------
Pete Johnston
Research Officer (Interoperability)
UKOLN, University of Bath, Bath BA2 7AY, UK
tel: +44 (0)1225 383619 fax: +44 (0)1225 386838
mailto:[log in to unmask]
http://www.ukoln.ac.uk/ukoln/staff/p.johnston/
|
