Issues in the current draft
Issue 1: Functionality/Scope
Problem
The proposed format supports the whole of the "description model" described by the DCAM. Often implementers require only a subset of that model (e.g. they require the capacity to specify only a single value string as value representation in each statement). As the proposed format supports the whole of the DCAM, it supports any subset, but at the cost of some complexity/"verbosity" in the syntax which may be perceived as redundant by implementers interested only in some subset.
Solutions
-
Design "shortcut" features within a single format? But then processors/consumers have to handle multiple ways of encoding single construct
-
Offer alternate formats for full DCAM and subset of DCAM? But what subset? Also challenge of documenting/managing/disseminating multiple formats, parallel schemas etc. Processors/consumers have to handle multiple formats
Proposal
Circulate "full description model" proposal for comment in first instance.
Issue 2: URIs and XML QNames
Problem
The proposed format allows the representation of some URIs only as QNames (property URIs), some URIs either in full or as QNames (vocabulary and syntax encoding scheme URIs), and some URIs only in full (resource and value URIs). This may be perceived as inconsistent.
The capacity to encode URIs in full is required as not all URIs can be represented as QNames.
Metadata creators/providers may prefer the convenience/flexibility of using QNames for URIs, but allowing both full URI and URI-as-QName encodings increases complexity for the metadata processor/consumer.
Also limitations in processing XML QNames in XSLT 1.0.
Solutions
-
Adopt current version
-
Remove option for QName representation for Vocab/Syntax Encoding Scheme URIs
-
Allow QNames representations and URIs for resource URIs and value URIs (though additional XML attributes)
-
Allow QNames representations and URIs for resource URIs, value URIs and property URIs (using XML attributes for property URIs rather than XML element names)
Proposal
Circulate current proposal for comment; revise in response to coomments if necessary.
Issue 3: Names of XML elements/attributes
Problem
Some of the XML element type names/XML attribute names are quite long. While this may make individual names more comprehensible to a human reader, it makes XML instances longer.
Solutions
-
Abbreviate element/attribute names (e.g. dcx:vesURI etc)
Proposal
Circulate current proposal for comment; revise in response to coomments if necessary.
Issue 4: Relationship of new specification to ''Guidelines for implementing Dublin Core in XML''
Problem
The XML format described by Guidelines for implementing Dublin Core in XML was not based on the DCMI Abstract Model, but rather on a simpler model. That simpler model is not a subset of the DCAM, and there is no unambiguous mapping of that format to the DCAM.
Solutions
-
Explanation of rationale for DC-XML
Proposal
Issue 5: GRDDL
Problem
DC-XML -> RDF/XML XSLT transform is still work-in-progress. Needs to be updated in line with work on DC in RDF.
Can associate transform with instance via "namespace document" rather than embedding reference in each instance. Probably better solution once XML Namespace Names confirmed/stable etc.
Solutions
* Complete XSLT transform to reflect DC in RDF spec; and set up GRDDL from "namespace document" - implementers can choose whether to refer to transform in instance.
Proposal
Note to readers that current examples incomplete. May change once specs complete/stable.
Issue 6: Validation Issues
Problem
XML Schema validation: Default content models permissive. Tighter validation requires creation of derived complexTypes. Then either
-
(in schema) declare new element (using derived complexType); or
-
(in instance) reference derived complexType using xsi:type
Have to do second where XML element name fixed by format. Results in lots of complexType definitions; lots of xsi:type attributes in instance. Could use xs:redefine (in schema)?
Schematron validation: XPath-based, more flexibility etc
RELAX NG: Pattern-based
Solutions
Proposal
Issue 7: Use of xs:appinfo for "term descriptions"
Problem
DC-XML applications requiring "Schema Model" information about DCMI terms have to obtain that information from elsewhere (e.g. by de-referencing the "term URI" or from a metadata registry service). Is it possible/useful to embed that information in the XML Schemas?
Solutions
Could include RDF/XML descriptions of the properties in the corresponding XML element declarations using xs:annotation/xs:appinfo? Even so, would not be included as part of PSVI, so application still has to access/parse XML Schema.
Proposal
Omit from first draft, but discuss and include if required.