Hi Tom,
Just on one point of this...
> ----------------------------------------------------------------------
> Appendix A: Excerpts from 2006 UB process
> http://dublincore.org/usage/documents/2006/02/13/process/
>
> 6. Proposals for registration of application profiles
>
> 6.1. Application Profiles subject to review. Application
> profiles emanating from DCMI Strategic Activities may
> be reviewed by the Usage Board. Metadata implementers
> (established projects, communities or research groups)
> may also request review, subject to approval by the UB
> Chair. /Point to information regarding DCMI Strategic
> Activities when available./
>
> 6.2. Documentation of Application Profiles. Application
> profiles must provide, for each term, an identifier of the
> element set where it is defined, ideally in the form of
> URIs for individual terms.
I wasn't sure about the use of "ideally" here ;-)
A DCAP is a specification for how to construct DC metadata description
sets, and to be usable in DC metadata description sets, all properties,
classes, vocabulary encoding schemes and syntax encoding schemes _must_
be individually identified by URIs - no "ideally" about it. ;-)
I guess this text is suggesting that the identifier of an "element set"
allows you to derive/infer the identifier of an individual term, but
there's nothing in the DCMI Abstract Model (or in the RDF model) to
support this - and I think we risk slipping back into the murk of
namespaces, XML or otherwise, by suggesting that is the case. ;-)
I guess there may be an argument that the things that make up a
vocabulary encoding scheme (but which aren't themselves properties,
classes, VES, or SES - I'm not sure whether these constitute "terms" in
this context or not - the DCMI Type Vocabulary is a slightly unusual
case because the member things are themselves classes) don't necessarily
have to have URIs, and that we can refer to those things via their
"label" (e.g. using that label as a value string in statements, but not
using a value URI), but even in that case I think there's an argument
that providing URIs is a good idea.
Anyway I think you could sidestep that particular argument by leaving
that question open and saying simply:
> Application profiles must specify the URI of each property, class,
vocabulary encoding scheme and syntax encoding scheme referenced in the
profile.
(I used "specify" rather than "provide" to try to avoid implying that
the URI is "assigned" by the DCAP.)
Also, this _might_ help clarify that the components in MODS and other
XML Schemas are not suitable candidates for use as
properties/classes/VES, as the sorts of "term" defined in those specs
don't have URIs. Even if they did have URIs, they still wouldn't be
usable in DC application profiles because they are different types of
"term" from those specified by the DCAM. But the fact that no term URIs
are immediately visible in the MODS (etc) specs would at least give DCAP
designers a heavy clue that they were barking up the wrong tree.
Pete
|