Hoylen,
> I've been looking over the "Guidelines for implementing
> Dublin Core in XML". It's a good and clear document however
> I have some queries and comments about some things in it.
Thanks for the comments.
> 1. Rec 2: should use XML Namespaces to uniquely identify DC properties
>
> Since these are guidelines, different implementations may
> choose to define their XML constructs differently for the
> same DC property. This will cause problems for tools
> expecting that an XML Namespace corresponds to exactly one
> XML Schema definition.
>
> For example, one implementation may use:
>
> <metadata1 xmlns:dc="http://purl.org/dc/elements/1.1/">
> ...
> <dc:identifier>http://example.org/foobar</dc:identifier>
> ...
> and they have defined in an XML Schema that dc:identifier
> is a URI.
>
> Someone else uses this implementation
>
> <metadata2 xmlns:dc="http://purl.org/dc/elements/1.1/">
> ...
> <dc:identifier>335-300-323-3</dc:identifier>
> ...
>
> and they have defined in an XML Schema that dc:identifier
> is a xsd:string with some pattern facet.
>
> Both would satisfy the guidelines, but will cause problems
> for an integration tool that deals with both formats, since
> it will see two different XML Schema definitions for the same element.
>
> This problem seems to stem from the use of the URI that
> identifies a DC property as a XML Namespace item - for which
> XML Schema processing places a stricter demand on.
>
> Has anyone given thought to this?
An earlier version of this document included reference to a set of W3C
XML Schemas. After considerable discussion on dc-architecture:
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A1=ind0201&L=dc-architecture
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A1=ind0202&L=dc-architecture
and our attempt to summarise a lot of discussion here:
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0203&L=dc-architecture&F=
&S=&P=13450
Andy and I decided the schemas needed more work and we removed the
explicit reference to the schemas from the Guidelines document. However
a working group is presently developing a new set of schemas to support
the Guidelines document. We're hoping to put that work out to
dc-architecture for discussion in the very near future. I'm not sure
this fully answers your question, but I'd prefer to wait until that work
on the schemas is made available before pursuing this further.
See comments on your next point too...
> 2. Rec 3. should encode properties as XML elements and values as the
> contents of those elements.
>
> The example shows the "values" as plain strings. My
> interpretation of this recommendation is that it does not
> precluded structured values as well (even though the examples
> don't show it.).
>
> That is, it is is not a violation of this guideline to do something
> like:
> <dc:creator>
> <foo:personalName>Fred</foo:personalName>
> <foo:email>[log in to unmask]</foo:email>
> <dc:creator>
>
> Is this a correct interpretation of this recommendation?
No. The description of "Simple DC" in Section 4.1 and the description of
"Qualified DC" in section 5.1 both include the point "Each value is a
literal string" i.e. the XML elements representing DC properties can
_not_ contain child elements, so your example would contravene the
Guidelines.
But please note: these Guidelines are _not_ saying that implementers
can't do the sort of thing you describe above in their applications of
Dublin Core. These Guidelines are _not_ intended to describe every
possible use of Dublin Core in XML. Rather they seek to describe XML
representations of two defined applications/"usages" of the Dublin Core
element set, and those usages are defined/described by the "abstract
models" in sections 4.1 and 5.1.
The models for these usages _are_ quite restrictive, but (hopefully)
they are still useful, particularly in providing some base level of
interoperability between services.
> 3. Rec 7. encoding scheme
>
> Is it possible to additionally stipulate that the values of
> the schemes should be URIs (or QNames?). This way there will
> be globally unique scheme identifiers and elminate the
> possible of duplication and conflicts.
>
> That is, instead of just:
> <dc:identifier scheme="mypartcode">...
>
> recommend that implementors should use
> <dc:identifier
> scheme="http://partsRus.example.com/ns/mypartcode">...
The current Guidelines document does not support this (i.e.
recommendation 7 specifies that the permitted values of the scheme
attribute are drawn from the list of "encoding scheme names" in the DCQ
specification).
But I think this is a good point, and (at the risk of pre-empting
discussions which haven't taken place yet!) I think it's fair to say our
work on the schemas points in this direction too.
> 4. Rec 8. element refinement names may be mixed-case
>
> Perhaps this should be clarified to say "Dublin core element
> refinement names may be mixed-case", so that it does not have
> to apply to non-DC element refinements. This would match
> the meaning of Recommendation 4, which applies for DC element
> names only.
OK, I guess this document is silent on practice for representations of
non-DCMI endorsed element refinements to DC elements, so the implication
here is (as I think you suggest) that the document is talking about
DCMI-recommended element refinements. But I take your point that perhaps
this should be more explicit in recommendation 8.
Regards
Pete Johnston
-------
Pete Johnston
Interoperability Research Officer
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/
|