All,

I've composed a summary of the comments received on the "Expressing
Dublin Core metadata using XML" (DC-XML) working draft of 2006-05-29
[1]. See

http://dublincore.org/architecturewiki/DCXMLRevision/Comments

Some of the comments are really questions about the DCMI Abstract Model
(DCAM) and/or about DCMI term definitions. Some are (fairly minor)
"stylistic" questions about conventions and names used within the XML
format.

I think the two main issues arising are:

1. The use of abbreviated forms for URIs
========================================

(a) Should DC-XML support a mechanism for abbreviating the URIs used in
DC metadata description sets?
(b) Should such such a mechanism be provided for all the "types" of URIs
used in DC metadata description sets (i.e. resource URI/value
URI/property URI/VES URI/SES URI), or just for some of them?
(c) Should the same mechanism be used for all "types" of URIs used in DC
metadata description sets, or is the use of multiple mechanisms
acceptable?
(d) Should (any of) the mechanism(s) for abbreviating URIs be based on
XML QNames?
(e) Should DC-XML make use of XML QNames in XML element content and XML
attribute values?

The current draft does use a mechanism based on XML Qnames, with a
mapping between URIs to XML QNames, in two different contexts: 
- property URIs are always represented as XML QNames used as XML element
names; 
- vocabulary encoding scheme URIs and syntax encoding scheme URIs may be
represented as XML QNames used in attribute values 

The possible problems associated with the use of XML QNames in XML
element content and XML attribute values are currently a matter of some
debate, and it may be advisable to find a solution that avoids these
issues.

FWIW, I had a go at drafting a solution for a "same mechanism for all
URIs"/"qualified name but not XML QName" solution as suggested at [2]
N.B. At present at least, this is really just an illustration of the
concept, rather than a concrete "next working draft". See

http://dublincore.org/architecturewiki/DCXMLRevision/DCXMLGuidelines/200
6-07-04

It uses what I - for want of a better label - called "DC-XML Qualified
Names" (the separator used is a hyphen - I chose hyphen rather than
period because it may be more useful for encoding URIs that include
period-separated filenames) but it was a fairly arbitrary choice and a
different character or a different convention for separating prefix and
local name could be used. (Also I haven't introduced a DC-XML Qualified
Name option for "representation URIs", which for consistency we probably
should do)

A W3C XML Schema is attached to

http://dublincore.org/architecturewiki/DCXMLRevision/DCXMLBaseSchemas/20
06-07-04

(needs tweaking to make e.g. ...URI and ...QualName attributes mutually
exclusive)

There are some example instances attached to

http://dublincore.org/architecturewiki/DCXMLRevision/DCXMLInstances/2006
-07-04

I've created parallel examples 

(i) using URIs in full, 
(ii) using URIS abbreviated using XML entity references and 
(iii) URIs abbreviated using "DC-XML Qualified Names"

to illustrate the different mechanisms for representing URIs.

Note that because property URIs are no longer represented as the names
of XML elements there is no longer a requirement to define additional
W3C XML schemas for other XML Namespaces.

There's an updated GRDDL XSLT transform (some points - e.g. making use
of base URIs, comparing URIs and Qual Names, etc - need a bit more work)
attached to

http://dublincore.org/architecturewiki/DCXMLRevision/DCXMLXSLT/2006-07-0
4

Also there is a transform which illustrates how you might use XSLT to
"validate" a DC-XML instance against a DCAP. That example is
"hard-wired" for Simple DC, but I think it would be relatively easy to
create a more generic transform that worked by reading an XML
description of the DCAP (I've played around a bit with that but I
haven't got it to a point where I've got something usable).


2. Possible changes to the DCAM
===============================
As Mikael has already highlighted in his recent messages, some issues
have been raised about the constructs and components described by the
DCAM and this has generated some tentative suggestions for changes to
the DCAM, particularly relating to the concept of a Vocabulary Encoding
Scheme and the nature of the relationship between a Value and a
Vocabulary Encoding Scheme. 

If, as seems likely, such changes to the DCAM are required, they would
have an impact on DC-XML. It would be preferable to finalise any such
changes to the DCAM before finalising the DC-XML draft - though of
course that does not stop us making progress with issues that are
orthogonal to the DCAM itself  (e.g. (1) above).

Cheers
Pete

[1] http://dublincore.org/documents/2006/05/29/dc-xml/
[2]
http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0606&L=dc-architectureP
=3878

---
Pete Johnston
Technical Researcher, Eduserv Foundation
Web: http://www.eduserv.org.uk/foundation/
Email: [log in to unmask] 
Tel: +44 (0)1225 474323