Dear all,
I have attached below a revised version of the decision for
"Provenance" and "Is Available At". In this revised version,
I replace the explanation of the issues around "Is Available
At" as discussed over the past week in previous postings.
In addition to those changes, I would like to propose two more
changes.
1. As Pete has pointed out, creating a new top-level element
for location information would not necessarily provide
a sufficient solution because that element would not,
by definition, be part of Simple Dublin Core and would
therefore be lost in any context which used Simple Dublin
Core schemas or dumbed down to Simple Dublin Core.
I propose the following re-write, which is already reflected
in the draft attached below:
Existing-draft: Rather, information about the information service
Existing-draft: should be provided in some other manner -- either by
Existing-draft: a new top-level DCMI element, by an existing property
Existing-draft: from a namespace such as AGLS or MODS, or possibly
Existing-draft: by dc:publisher.
Proposed-rewrite: Rather, information about the service should be provided in
Proposed-rewrite: some other manner. This information could be provided by a
Proposed-rewrite: a new top-level DCMI element, by using an existing property
Proposed-rewrite: from another namespace, or possibly by dc:publisher.
Proposed-rewrite:
Proposed-rewrite: Future proposals should also consider the possibility
Proposed-rewrite: that elements beyond the fifteen elements of DCMES 1.1
Proposed-rewrite: may not be quickly adopted due to the widespread use of
Proposed-rewrite: "Simple Dublin Core" as the shared schema of many content
Proposed-rewrite: federations and therefore as the target of dumb-down.
2. It occurred to me that the brief description of the issue
of whether or not XML elements could be used as RDF
properties was missing a reference to why this might be
problematic, so I suggest we allude to their "inherent
differences (in modeling terms)", as below:
Existing-draft: An additional point is that the MODS element set contains
Existing-draft: a location element which may have the same function as
Existing-draft: "isAvailableAt". The issue here is the general one of the
Existing-draft: re-use of existing properties that already exist in other
Existing-draft: namespaces.
Existing-draft: This discussion led on to a broader consideration of the
Existing-draft: more general fundamental issues of the difference between
Existing-draft: an XML element and an RDF property, and the reuse of terms
Existing-draft: existing in other namespaces. Should the UB allow the reuse of
Existing-draft: elements existing in other namespaces if they are expressed
Existing-draft: as XML elements and not as RDF properties, or should reuse
Existing-draft: be restricted?
Existing-draft: The Usage Board decided not to accept the proposed refinement
Existing-draft: "isAvailableAt". Usage Board agreed there was a need to develop
Existing-draft: and write up a policy on XML elements and RDF properties,
Existing-draft: to be circulated to DCMI at a later date.
Proposed-rewrite: There was some discussion about the MODS element for location,
Proposed-rewrite: which arguably has the same function as "isAvailableAt". The
Proposed-rewrite: issue here is the general one of the re-use of
Proposed-rewrite: properties that already exist in other namespaces.
Proposed-rewrite: This discussion led on to a broader consideration of the
Proposed-rewrite: difference between an XML element and an RDF property,
Proposed-rewrite: and whether the inherent differences (in modeling terms)
Proposed-rewrite: between XML elements and RDF properties means that XML
Proposed-rewrite: elements should be recommended for reuse as RDF properties
Proposed-rewrite: only under certain conditions. The Usage Board agreed there
Proposed-rewrite: was a need to develop and write up a policy on XML elements
Proposed-rewrite: and RDF properties to be discussed in DCMI at a later date.
Unless there are further issues, I would very much like to
finalize this decision by Friday, 2 July at the very latest.
Tom
------
Title: Decision on proposal for a Collection Description profile
Shepherd: Andrew Wilson
Identifier: http://dublincore.org/usage/decisions/2004/2004-02.shtml
Date: 2004-06-28
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 consider the possibility
that elements beyond the fifteen elements of DCMES 1.1
may not 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.
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-05-17
Decision: http://dublincore.org/usage/decisions/#Decision-2004-02
-------------------------------------------------------------------------
Approved text - end
|
