Pete,
Comment below.
On Thu, Aug 10, 2006 at 12:20:08PM +0100, Pete Johnston wrote:
> > 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.)
I agree with your interpretation, and I agree about the slight
ambiguity regarding vocabulary terms (e.g., is "Deposit" a
"term" in [1]?).
I also agree with your proposed wording -- i.e., instead of saying
under 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.
the process document should say:
Application profiles must specify the URI of each property,
class, vocabulary encoding scheme and syntax encoding
scheme referenced in the profile.
Does everyone agree with this? I propose we add this to the
list of changes to the process document to discuss and approve
at the next meeting.
> 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.
Agreed.
Tom
[1] http://www.ukoln.ac.uk/metadata/dcmi/collection-DCCDAccrualMethod/
--
Dr. Thomas Baker <[log in to unmask]>
Director, Specifications and Documentation
Dublin Core Metadata Initiative
