> 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.
[snip]
> <dc:identifier>http://example.org/foobar</dc:identifier>
> ...
> and they have defined in an XML Schema that dc:identifier
> is a URI.
[snip]
> <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.
I'd say dc:identifier should be defined in a DCMI-controlled schema, ideally
reflected in an XML file hosted on purl.org, and defined as having a type of
either anySimpleType or anyType (I'd favour the latter, but I'm not 100%
sure I'd still favour it after some more thought).
Schema defining schemes for use with DC elements (which should be defined in
other namespaces, probably as QNames) should define a type appropriate to
the use of that modifier. xsi:type could then be used, although in the
absence of xsi:type information interpreters should attempt to ascertain the
type based on the namespace of the format, prior knowledge of the format,
etc.
The very concept behind having more than one acceptable format for a given
element means that more than one namespace will be used in both the
traditional and XML-specific meaning of that term.
Of course information about items in a namespace may not necessarily be
defined solely through XML-Schema, indeed the Schema for Schemas doesn't
define all of the rules pertaining to the schema namespaces.
> 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?
I would imagine so. Perhaps otherwise something like the following could be
used as a kludge:
<foo:person id = "personFred">
<foo:personalName>Fred</foo:personalName>
<foo:email>[log in to unmask]</foo:email>
</foo:person>
<dc:creator>#personFred</dc:creator>
But it's not pretty!
> 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">...
I second that, indeed that coincides nicely with my reply to point 1.
NCNames used for schemes could be assumed to belong to the
http://purl.org/dc/elements/1.1/ namespace (or a replacement, anyway the
namespace that the scheme attribute belongs to).
> 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.
Perhaps it should be a MUST for Dublin core element refinements and a SHOULD
for non-DC element refinements created with interoperability with DC in
mind.
My ?.02 anyway.
Jon Hanna
Spin Solutions
Dublin, Ireland.
PGP http://www.spin.ie/jon.asc
PGP Fingerprint 707E 5E39 3BF5 533A D1DD 2083 8169 BFD7 F532 BD18
"...it has been truly said that hackers have even more words for equipment
failures than Yiddish has for obnoxious people." - jargon.txt
|