Dublin Core
Dublin Core
About DCMI Themes Members Governing Board Usage Board Directorate
Bluesky Twitter YouTube GitHub RSS Feed

DCMI Collection Description Community

DC Collection Description

Report of Working Group Meeting,

Wednesday 1 October 2003, DC-2003, Seattle

Introduction

The DC CD WG met on Wednesday 1 October 2003 at DC-2003 in Seattle and the meeting attracted about 15-20 participants.

Andy Powell and Pete Johnston introduced the work of the WG with some brief background about CLD, and then the meeting focused on the "current issues" with the 2003-08-25 draft of the application profile [2]. The slides presented are available 3].

The meeting made the following decisions

1. Collection-Service/Location relation

  • It was Agreed to use a _single_ property for the relation between a Collection and a (Physical) Location and between a Collection and a (Digital/Network) Service.
  • It was Agreed to use a property name that indicated the nature of the relationship rather than the type of the object resource. The name suggested is "isAvailableAt" (with inverse "makesAvailable") (URI/namespace to be confirmed).
    Note: Should also check the status of the property "location" (from the MODS vocabulary) used by the DC Libraries AP.
  • It was Agreed not to use encoding schemes for the interfaces implemented by a Service.

2. Rights

  • It was Agreed that "Legal Status" (legalStatus) not required as a distinct property. Information on legal status should be recorded as part of the value of dc:rights (see below) or dcterms:accessRights, as appropriate.
  • It was Agreed to include a statement of the rights held in/over the collection, using the dc:rights property (in addition to the description of access rights/restrictions, using dcterms:accessRights.)

3. Subject

  • It was Agreed to list explicitly only those encoding schemes for dc:subject included by DCMI in the dcterms namespace, but to include a clause that indicated that other subject schemes were permissible.
  • It was Agreed that separate subject sub-properties "Object" (objectName), "Name" (agentName) were not required i.e. to use only the dc:subject property for all subject terms.
    Note: This does not prevent other application profiles from making this distinction, as the current RSLP CD Schema does. Such applications are encouraged to indicate that their objectName and agentName (or equivalent) properties are refinements for dc:subject.

4. Format

  • It was Agreed to add "Size of collection" (dcterms:extent) and to amend the description of "Physical Characteristics" (dc:format) accordingly.
  • The meeting recognised the usefulness of capturing the media-type of the items in the Collection (e.g. to indicate that a Digital Collection is a collection of MP3s, JPEGs etc). However, it was felt that using dc:format with scheme dcterms:IMT as a property of the Collection was _not_ appropriate. Addressing this requirement may require a separate property to record the format of the Items in the Collection (itemFormat?, itemLevelFormat?).
    No consensus reached: further discussion required.
  • It was Agreed to add a property "Logo" (logo) (URI/namespace to be confirmed).

6. Strength

  • It was Agreed that the property "Strength" (strength) was not required. Description of collection strength should be captured as part of dc:description.
    Note: It may be useful to include Conspectus as an encoding scheme for dc:description in the future. Also, (as in the case of the subject sub-properties), this does not prevent other application profiles from using a distinct strength subproperty.

7. Date

  • Date-related problems had been raised by a number of sources and it was reported that DCMI is considering re-chartering a Date WG to investigate. DC CD WG should provide input to those discussions and follow the recommendations of that WG.

8. URI/namespace/vocabulary issues

  • The meeting did not have time to discuss in detail which terms may be suitable for general resource discovery (and therefore potential candidates for inclusion in the dcterms vocabulary/namespace), but it was recognised that was the case.
  • The meeting requested that the WG Chairs request the guidance of the Advisory Board on the choice of URIs for terms that are either collection-specific or not considered appropriate for the dcterms vocabulary/namespace.

9. Status/management of APs created by DCMI WGs

  • The meeting requested that the WG Chairs request the guidance of the Advisory Board on the satus of APs developed by DCMI WGs.

References

[1] DC Collection Description WG meeting, Wednesday 1 October, 13.30-15.00. Agenda http://dc2003.ischool.washington.edu/collectionDescription.html

[2] Dublin Core™ Collection Description Application Profile, Working Draft 2003-08-25 http://www.ukoln.ac.uk/metadata/dcmi/collection-application-profile/2003-08-25/

[3] DC Collection Description http://www.ukoln.ac.uk/metadata/dcmi/dc2003/cdwg/slides.htm