Revisions to Usage guidelines for dc:type and dcterms:type

[baskaufs]

Introduction

During the 2019-08-29 Maintenance Group Call, the group approved moving forward on revisions to the Audubon Core Usage guidelines for dc:type and dcterms:type. There are a number of problems with the current Usage and Notes fields, including redundant text, text not appropriately placed between the Usage and Notes sections, unclosed parentheses, broken URLs, reference to unminted Audubon Core terms, lack of clarity about whether RFC 2119 keyword usage is intended, and unclear text. In addition, the Usage recommendations are at odds with the practice of Darwin Core and previous Executive committee decisions. It is the intention of this proposal to resolve all of these problems in a single revision.

Background

Soon after the adoption of Darwin Core (October 2009), there was an extensive discussion on tdwg-content about the appropriate use of dcterms:type, more or less beginning with this email. Refer to the archived thread for details, but the final message in the thread concluded that the values used for dcterms:type in Darwin Core should be limited to those found in the DCMI type vocabulary. This conclusion was reflected in Executive decisions 1 through 3 of 2009-12-07 and later.

When Audubon Core was adopted, it broke with this precedent by suggesting that communities of practice could add additional values for the term. For dcterms:type, it suggested values of ac:PanAndZoomImage, ac:3DStillImage, and ac:3DMovingImage, but did not actually mint those terms. In addition, Audubon Core created the term ac:subtype that could be used to refine types that are more specific than those used for dcterms:type. It is not clear why ac:PanAndZoomImage and ac:3DStillImage were suggested as values for dcterms:type rather than as subtypes of dctype:StillImage or why ac:3DMovingImage was not suggested as a subtype of dctype:MovingImage.

Proposal

The gist of this proposal is to follow the precedent set by Darwin Core and limit the values of dc:type and dcterms:type to those present in the DCMI type vocabulary. The unminted ac: namespace type terms would be removed from the recommendations and could be suggested as values for ac:subtype if there were community demand. There are a number of other changes to the term Usage (normative) and Notes (non-normative) fields intended to fix the various other problems mentioned in the Introduction. See the proposed revisions below for details. Please note that as non-normative content, changes to the Notes field do not necessarily require inclusion in the Change process outlined in Section 3 of the TDWG Vocabulary Maintenance Specification (VMS). However, they are included in this proposal due to the rearrangement of content between the Notes and Usage fields. See Section 3.4.3 of the VMS for distinctions between normative and non-normative content.

Also noted that the revised text includes appropriate use of RFC 2119 keywords. This was not included in the original text, but the Audubon Core Maintenance Group is working to bring its documents that contain normative content into conformance with Section 3.2.5 of the TDWG Standards Documentation Specification with respect to the use of RFC 2119 key words. See Issue #133.

Changes to dc:type

Definition from DCMI (unchanged):

The nature or genre of the resource.

Current Usage text:

dc:type may take as value any type term from the DCMI Type Vocabulary, http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary. Recommended terms are Collection, StillImage, Sound, MovingImage, InteractiveResource, Text. Values may be used either in their literal form, or with a full namespace (e. g. from a controlled vocabulary, but the best practice is to use the literal form when using dc:type and use dcterms:type when you can supply the URI from a controlled vocabulary and implementers may require this practice. At least one of dc:type and dcterms:type must be supplied but, when feasible, supplying both may make the metadata more widely useful. The values of each should designate the same type, but in case of ambiguity dcterms:type prevails.

Current Notes text:

A Collection should be given type "Collection" when using dc:type. If the resource is a Collection, this item does not identify what types of objects it may contain. Following the DC recommendations for the Text type, http://purl.org/dc/terms/DCMIType, images of text should be marked given as the string Text when provided as a string. See also the entry for dcterms:type in the Audubon Core term list document and see the DCMI FAQ on DC and DCTERMS Namespaces, https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md, for discussion of the rationale for terms in two namespaces. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions.

Proposed Usage text

The value of dc:type SHOULD be a term name of any term from the DCMI Type Vocabulary, https://www.dublincore.org/specifications/dublin-core/dcmi-type-vocabulary/ . RECOMMENDED term names for media items are "Collection", "StillImage", "Sound", "MovingImage", "InteractiveResource", and "Text". A Collection MUST be given a value of "Collection". Following the DC recommendations at http://purl.org/dc/dcmitype/Text, images of text SHOULD be given a value of "Text" for dc:type. A value for at least one of dc:type and dcterms:type MUST be supplied in an Audubon Core record but when feasible, supplying both can make the metadata more widely useful. The values of dc:type and dcterms:type SHOULD designate the same type, but in case of ambiguity dcterms:type prevails.

Proposed Notes text:

If the resource is a Collection, this term does not identify what types of objects it may contain. See also the entry for dcterms:type in the Audubon Core term list document and see the DCMI FAQ on DC and DCTERMS Namespaces, https://web.archive.org/web/20171126043657/https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md, for discussion of the rationale for terms in two namespaces. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions.

Changes to dcterms:type

Definition from DCMI (unchanged):

The nature or genre of the resource.

Current Usage text:

A full URI preferably from among the type URIs specified in the DCMI Type Vocabulary, http://dublincore.org/documents/dcmi-type-vocabulary/#section-7-dcmi-type-vocabulary. Recommended terms are those URIs whose labels are Collection, StillImage, Sound, MovingImage, InteractiveResource, or Text (e.g. . Also recommended are the full URIs of ac:PanAndZoomImage, ac:3DStillImage, and ac: 3DMovingImage. Values MUST NOT be a string, but a URI with full namespace (e. g. from a controlled vocabulary. Implementers and communities of practice may determine whether specific controlled vocabularies must be used. If the resource is a Collection, this item does not identify what types of objects it may contain. Following the DC recommendations at http://purl.org/dc/dcmitype/Text, images of text should be with this URI.

Current Notes text:

Following the DC recommendations for the Text type, http://purl.org/dc/terms/DCMIType, images of text should be given as http://purl.org/dc/dcmitype/Text when given as a URI. See also the entry for dc:type in the Audubon Core term list document and see the DCMI FAQ on DC and DCTERMS Namespaces, https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md, for discussion of the rationale for terms in two namespaces. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions. At least one of dc:type and dcterms:type must be supplied but, when feasible, supplying both may make the metadata more widely useful. The values of each should designate the same type, but in case of ambiguity dcterms:type prevails.

Proposed Usage text:

The value of dcterms:type SHOULD be an IRI of any term from the DCMI Type Vocabulary, https://www.dublincore.org/specifications/dublin-core/dcmi-type-vocabulary/ . In text-based systems (e.g. spreadsheets) the value MUST be an IRI with an unabbreviated namespace. Machine-readable systems MAY use any form of the IRI (e.g. compact URIs; CURIEs) that can be determined to be equivalent to the unabbreviated IRI. RECOMMENDED values for media items are those IRIs whose term names are "Collection", "StillImage", "Sound", "MovingImage", "InteractiveResource", and "Text". A Collection MUST be given a value of http://purl.org/dc/dcmitype/Collection. Following the DC recommendations at http://purl.org/dc/dcmitype/Text, images of text SHOULD be given a value of http://purl.org/dc/dcmitype/Text for dcterms:type. A value for at least one of dc:type and dcterms:type MUST be supplied in an Audubon Core record but when feasible, supplying both can make the metadata more widely useful. The values of dc:type and dcterms:type SHOULD designate the same type, but in case of ambiguity dcterms:type prevails.

Proposed Notes text:

If the resource is a Collection, this term does not identify what types of objects it may contain. See also the entry for dc:type in the Audubon Core term list document and see the DCMI FAQ on DC and DCTERMS Namespaces, https://web.archive.org/web/20171126043657/https://github.com/dcmi/repository/blob/master/mediawiki_wiki/FAQ/DC_and_DCTERMS_Namespaces.md, for discussion of the rationale for terms in two namespaces. Normal practice is to use the same Label if both are provided. Labels have no effect on information discovery and are only suggestions.

[baskaufs]

The 30 day public comment period for this proposal begins on 2019-09-24 and will end 2019-10-24. To comment on this proposal, comment on this issue.

[tucotuco]

I approve of these recommended changes.

[MattBlissett]

i also approve, thanks Steve.

[baskaufs]

Since the 30 day comment period is over and there is no dissent on this proposal, I'm closing the comment period.

[baskaufs]

This change was approved by the Executive committee as of 2019-12-02