innovation in metadata design, implementation & best practices

Title: Decision on proposal for a Collection Description profile
Shepherd: Andrew Wilson
Identifier: http://dublincore.org/usage/decisions/2004/2004-02.Collection-terms.shtml
Date: 2004-09-03
Description: The decisions documented here refer to proposals
               considered at the Usage Board meeting of March 2004 in Bath UK.

Text of proposals:
-- http://www.ukoln.ac.uk/metadata/dcmi/collection-provenance/2004-02-10/
-- http://www.ukoln.ac.uk/metadata/dcmi/collection-isAvailableAt/2004-01-24/

Decision: The Usage Board approves the addition of a new
element -- "Provenance" -- as a Conforming term in the dcterms
namespace. The Usage Board does not approve the proposed new
element refinement "isAvailableAt".

Discussion

The Collection Description Working Group proposed the
addition of two new terms: "provenance" as a refinement
of dc:description; and "isAvailableAt" as a refinement of
dc:relation. The DCMI Usage Board reviewed the proposal at a
meeting in Bath UK on Sunday, 14 March 2004. Members present
were Tom Baker (chair), Diane Hillmann, Akira Miyazawa, Andy
Powell, Roland Schwaenzl, Stuart Sutton, Rebecca Guenther,
and Andrew Wilson (designated shepherd of the Collection
Description terms proposal).

Discussion of "provenance" centred around the definition,
and whether the proposal of "provenance" as a refinement of
dc:description was appropriate. The UB agreed on a revised
definition of "provenance" with additional information in
the comment field of the proposal text. UB decided that
"provenance" had wider resource discovery application than
just within the collection description domain and agreed to
approve "provenance" as a new conforming element (property)
in its own right in the dcterms namespace.

In the UB discussion of the proposed refinement
"isAvailableAt" -- both at the Bath meeting and
subsequently on the mailing list -- the following points
were made:

-- The Collection Description working group would like to
   distinguish between an "identifier" for a resource
   (i.e., a string designating the resource described)
   and a "locator" usable for accessing that resource.

-- The Collection Description working group also would like
   to be able to describe a service which "provides access
   to" that resource as an entity in its own right -- with,
   in principle, its own set of attributes (i.e., as a
   "related resource" related to the resource described).
   This was the rationale for proposing "isAvailableAt"
   as a refinement of dc:relation.

-- Metadata aggregators such as NSDL and AGLS find that,
   in practice, the value of dc:identifier is very commonly
   not an "identifier" in the purest sense of the word
   (i.e., a unique string not necessarily resolvable to a
   Web address), but rather a URL by which the resource
   can be accessed (i.e., a "locator"). In doing so,
   metadata authors are merely reflecting the endemic
   ambiguity between "identification" and "location"
   in the context of the Web.

-- Although the intention of the proposers of "Is
   Available At" was to point to "a service"
   making the resource available, it was feared that
   dct:isAvailableAt might be used for the "locator" of
   the resource itself. Such usage would merely compound
   the ambiguity already surrounding dc:identifier with
   a new ambiguity with respect to dct:isAvailableAt.

-- Specifically, it was feared that if metadata authors
   were to put the locators of resources into a refinement
   of dc:relation, then the fact that those URIs were
   locators of the resource would be lost in the process
   of dumbing down. After dumb-down, an aggregator might
   be left with multiple values for dc:relation and have
   no way of knowing or inferring which ones were usable
   as locators for the resource.

-- It was pointed out that the proposed definition of
   "Is Available At" ("The referenced resource provides
   access to the described resource") is difficult to
   distinguish in its intent from the definition of the
   existing element dc:publisher ("An entity responsible
   for making the resource available").

In sum, future proposals addressing these issues should
consider the following:

-- As argued by the Collection Description Working Group,
   it may be desirable to distinguish more cleanly
   between identifiers and locators for the resource
   described. Any proposal to do so, however, should
   address the ambiguity inherent in the existing usage
   of dc:identifier.

-- It may be desirable to have a property specifically for
   information services so that those services can be pointed
   to or described as "related resources" -- i.e., as entities
   in their own right.

   For the practical purposes of aggregators, however,
   it is not desirable that locators for those services be
   associated with properties that are subject to dumb-down
   to very broad and generic properties such as dc:relation.

   Rather, information about the service should be provided in
   some other manner. This information could be provided by a
   a new top-level DCMI element, by using an existing property
   from another namespace, or possibly by dc:publisher.

   Future proposals should also be aware that elements beyond
   the fifteen elements of DCMES 1.1 are likely not to be quickly
   adopted due to the widespread use of "Simple Dublin Core" as
   the shared schema of many content federations, and therefore as
   the target of dumb-down. Proposals should, therefore, consider
   the possibility that suggestions for putting significant
   location information somewhere other than in one of the
   original DC-15 elements may suffer from the risk that users
   who (for whatever reason) limit their view to the DC-15 will
   not see that location information.

There was some discussion about the MODS element for location,
which arguably has the same function as "isAvailableAt". The
issue here is the general one of the re-use of
properties that already exist in other namespaces.
This discussion led on to a broader consideration of the
difference between an XML element and an RDF property,
and whether the inherent differences (in modeling terms)
between XML elements and RDF properties means that XML
elements should be recommended for reuse as RDF properties
only under certain conditions. The Usage Board agreed there
was a need to develop and write up a policy on XML elements
and RDF properties to be discussed in DCMI at a later date.

Approved text - beginning
-------------------------------------------------------------------------
VMS-ID: provenance-001
Name: provenance
URI: http://purl.org/dc/terms/provenance
Namespace: http://purl.org/dc/terms/
Label: Provenance
Definition: A statement of any changes in ownership and custody
              of the resource since its creation that are
              significant for its authenticity, integrity and
              interpretation.
Comment: The statement may include a description of any
              changes successive custodians made to the resource.
Type of term: http://dublincore.org/usage/documents/principles/#element
Status: http://dublincore.org/usage/documents/process/#conforming
Date issued: 2004-09-20
Decision: http://dublincore.org/usage/decisions/#Decision-2004-02
-------------------------------------------------------------------------
Approved text - end