|
|||||||
Global navigation options: |
|||||||
| Creator: | Thomas Baker DCMI |
|---|---|
| Date Issued: | 2010-10-11 |
| Identifier: | http://dublincore.org/usage/decisions/2010/dcterms-changes/ |
| Description of Document: | This set of editorial clarifications to descriptions of DCMI metadata terms was approved by the DCMI Usage Board. |
The current release of "DCMI Metadata Terms" reflects editorial changes approved since January 2008, notably:
Resolved:
=========
(i) For the property dcterms:contributor, delete the following sentence
from the "Comment"
Typically, the name of a Contributor should be used to indicate the entity.
(ii) For the property dcterms:creator, delete the following sentence
from the "Comment"
Typically, the name of a Creator should be used to indicate the entity.
(iii) For the property dcterms:publisher, delete the following sentence
from the "Comment"
Typically, the name of a Publisher should be used to indicate the entity.
Note that no change is proposed for the descriptions of the properties
dc:contributor, dc:creator, dc:publisher
Rationale:
==========
Issue 1: Range of Properties
The three properties above were defined with a range of the class
dcterms:Agent - this is the characteristic which distinguishes the
properties from their dc:* counterparts.
i.e. the intent is that, from the perspective of the DCAM, they are used
with non-literal values, rather than literal values, or, from the
perspective of the RDF model, when one of these properties is referred
to in an RDF predicate the object should be a URI or blank node, but not
a literal. i.e. the intent is that the properties are to be used in
constructs of the form
(DCAM-1)
Description (
Statement (
PropertyURI (dcterms:creator )
ValueString ( "Jim Jarmusch" )
)
)
(RDF-Turtle-1)
_:filmF dcterms:creator _:personP .
_:personP rdf:value "Jim Jarmusch" .
However, the presence of the comment above introduces a contradiction,
or at least an element of ambiguity, because the phrase "the name ...
should be used to indicate the entity" might be read as encouraging the
use of the forms:
(DCAM-2)
Description (
Statement (
PropertyURI (dcterms:creator )
LiteralValueString ( "Jim Jarmusch" )
)
)
(RDF-Turtle-2)
_:filmF dcterms:creator "Jim Jarmusch" .
These two constructs (DCAM-2, RDF-Turtle-2) are
inconsistent with the intent that the property not be used
with literal values. One of the primary motivations for
creating these three dcterms:* properties - apart from
the "why can't we just use one namespace?" issue - was
to try to achieve a consistent usage of these properties,
i.e. to declare/describe the properties in such a way that
implementers would use the forms DCAM-1 and RDF-Turtle-1,
and the forms DCAM-2 and RDF-Turtle-2 were not used.
But in the RDF case, to an RDF implementer, the phrase
"the name ... should be used to indicate the entity"
strongly implies strongly implies that the property be
used with a literal object, which is not its intended use.
Issue 2: A Name is not Required
It is not a requirement that a name is provided when using these
properties: it is quite acceptable when using these properties to
provide only a "value URI"/URI as object, or to describe the value/use a
blank node, and provide various properties of the agent (email address,
home page, whatever), without providing a name of the agent as a value
string.
Issue 3: Consistency with other DCMI term descriptions
The form of words "the name ... should be used to indicate the entity"
is not used with the dcterms:rightsHolder property, which was defined
after the original dc:* properties and before the three dcterms:*
properties discussed here.
In conclusion, deleting the sentence
(i) takes a step towards removing the ambiguity; it doesn't stop people
ignoring the range and using literal objects, but it avoids making the
implication that this is an option;
(ii) removes the requirement that a name "should" be provided;
(iii) makes the definitions of these three properties consistent with
that of dcterms:rightsHolder
(iv) has no effect on the definitions of the dc:* properties.
Method:
=======
-- Edit
http://dublincore.org/usage/xml/dcterms-properties.xml
to create new term versions for the three properties
-- Commit to VMT for next documentation build
Resolved:
=========
To specify the range "Literal" for dcterms:title and
dcterms:alternative in DCMI Metadata Terms
("rdfs:range rdfs:Literal").
This resolution confirms an earlier decision discussed
in December 2008 [1] and not implemented.
Rationale:
==========
The DCMI Usage Board is specifying the range of
dcterms:title, and of its subproperty
dcterms:alternative, as "literal" because, to the best
of our knowledge, most applications currently use
"title" with literal values, and because a literal
values are simple to implement.
The Usage Board Use acknowledges important cases
which require "title" (or "alternative") to be used with
a non-literal value - i.e., to consider the title as a
resource in its own right, with multiple properties and
values beyond just one text string. For example, a
single title in Japanese may need to be rendered in
more than one script.
Implementers wishing to use titles with non-literal
values have the option of using the legacy properties
http://purl.org/dc/elements/1.1/title and
http://purl.org/dc/elements/1.1/alternative - or of
coining a new, non-DCMI properties with non-literal
ranges. The Usage Board notes that for reasons of
interoperability, such new properties could be declared
as sub-properties of http://purl.org/dc/elements/1.1/title.
Resolved:
=========
To correct references to ANSI/NISO Z39.85 and ISO 15836, which was
re-issued in 2009 as ISO Standard 15836:2009 (note the colon).
The correct references are:
Files affected:
Resolved:
=========
To correct the URI for properties with domain dcmitype:Collection.
Method:
=======
-- Change the source file used to generate Web pages and RDF schemas,
http://dublincore.org/usage/xml/dcterms-properties.xml
Create new versions of dcterms:accrualMethod, dcterms:accrualPeriodicity,
and dcterms:accrualPolicy to correct:
dcterms:accrualMethod rdfs:domain http://purl.org/dc/terms/Collection
dcterms:accrualPeriodicity rdfs:domain http://purl.org/dc/terms/Collection
dcterms:accrualPolicy rdfs:domain http://purl.org/dc/terms/Collection
to read
dcterms:accrualMethod rdfs:domain http://purl.org/dc/dcmitype/Collection
dcterms:accrualPeriodicity rdfs:domain http://purl.org/dc/dcmitype/Collection
dcterms:accrualPolicy rdfs:domain http://purl.org/dc/dcmitype/Collection
Resolved:
=========
RESOLVED: To coin the property
http://purl.org/dc/terms/RFC5646
following the precedents of
http://purl.org/dc/terms/RFC1766
http://purl.org/dc/terms/RFC3066
http://purl.org/dc/terms/RFC4646.
Term Name: RFC5646
URI: http://purl.org/dc/terms/RFC5646
Label: RFC 5646
Definition: The set of tags constructed according to RFC 5646 for the identification of languages.
Comment: RFC 5646 obsoletes RFC 4646.
See: http://www.ietf.org/rfc/rfc5646.txt
Type of Term: Datatype
Resolved:
=========
To add a "See:" reference to the definition of dcterms:DCMIType, pointing to
http://purl.org/dc/dcmitype/.
Method:
=======
-- In file http://dublincore.org/usage/xml/dcterms-ves.xml
Add "See:" reference to:
http://purl.org/dc/dcmitype/ (note final slash!)
Global navigation utility links: |
Unless indicated otherwise, DCMI documents are licensed under a Creative Commons Attribution 3.0 Unported License. Please see the DCMI Document Notice for further instructions.
Metadata associated with this resource: http://dublincore.org/usage/decisions/2010/dcterms-changes/index.shtml.rdf
Copyright © 1995-2013 DCMI. All Rights Reserved. DCMI liability, trademark/service mark, document use and software licensing rules apply. Your interactions with this site are in accordance with our privacy statements.
The Dublin Core Metadata Initiative (DCMI) is a project of ASIS&T—a U.S. 501(c)(3) nonprofit under the U.S. Internal Revenue Code. Contributions to DCMI through ASIS&T are tax-deductible to the full extent of the law in the United States.
The DCMI Web site is hosted by the National Library of Korea.
The Dublin Core Metadata Registry is hosted by the Research Center for Knowledge Communities at the University Of Tsukuba, Japan.
Copyright © 1995-2013 DCMI. All Rights Reserved.