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

Dublin Core™ Collection Description Application Profile: Data Model

Creator: Dublin Core™ Collection Description Working Group
Date Issued: 2004-08-16
Identifier: http://dublincore.org/specifications/dublin-core/collection-description/collection-model/2004-08-06/
Replaces: http://dublincore.org/specifications/dublin-core/collection-description/collection-model/2004-07-11/
Is Replaced By: Not applicable
Latest Version: http://dublincore.org/specifications/dublin-core/collection-description/collection-model/
Description of Document: This document discusses the data model used within the Dublin Core™ Collection Description Application Profile.

1. The Data Model

This document summarises a subset of the data model described in An Analytical Model of Collections and their Catalogues [1], and proposes the addition of a new entity type, Service.

E-R model

2. Entity Types

2.1 Item

A concrete realisation of Content. An Item may be physical or electronic.

The DC CD AP does not provide for the description of the Item so does not provide a corresponding class.

2.2 Collection

An aggregation of one or more Items.

Examples of a Collection include:

  • a library collection
  • a museum collection
  • an archive
  • a collection of digital images
  • a catalogue

In the DC CD AP, this entity type corresponds to the class dcmitype:Collection.

2.3 Location

A place where a Collection is held.

Examples of a Location include:

  • a library
  • a museum
  • an archival repository

The DC CD AP does not provide for the description of the Location so does not provide a corresponding class. The DC CD AP should, however, provide a property to describe the relation between Collection and Location (see below).

2.4 Service

The provision of, or system of supplying, one or more functions of interest to an end-user or software application.

Examples of a Service include:

  • a cash withdrawal service provided by a bank
  • an online book purchasing service like Amazon.com
  • a format conversion service that generates PDF documents from Postscript files

This entity type corresponds to the class dcmitype:Service.

In the context of the DC CD AP, the services of interest are that sub-class which provide access to Collections:

2.4.1 Informational Service

An Informational Service is a service that provides access to a Collection (and/or the Items within a Collection?).

Examples of an Informational Service include:

  • a lending service provided by a library
  • the visiting facility provided by a museum
  • an inter-library loan service provided by a library
  • a Web site that allows a user to browse an image library
  • a Web site that allows a user to search a library catalogue
  • a Z39.50 target that allows a software application to search a catalogue
  • an OAI-PMH repository that allows a software application to harvest a collection of metadata records

The DC CD AP does not provide for the description of the Informational Service so does not provide a corresponding class. The DC CD AP should, however, provide a property to describe the relation between Collection and Informational Service (see below).

2.5 Agent

An Agent is an entity capable of action.

The DC CD AP does not provide for the description of the Agent so does not provide a corresponding class. The DC CD AP does, however, provide properties to describe the "collector" and "owner" relations between Collection and Agent (see below).

2.6 Collection-Description

A resource that provides information about a Collection.

The Analytical Model [1] identifies four sub-classes of Collection Description:

2.6.1 Unitary Finding Aid

A Collection-Description which consists only of information about
the Collection as a whole and does not provide information about
the individual Items within it.

Unitary finding aids include "collection-level" descriptions such as those created using the RSLP CD Schema and "top-level" archival descriptions created using ISAD(G).

2.6.2 Hierarchic Finding Aid

A Collection-Description which consists of information about the
Collection as a whole, together with information about the
individual Items within it and their Content, including contextual
information about the relation of the Items and their Content to the
Collection as a whole.

An archival finding aids such as a multi-level ISAD(G) description or an EAD document is a Hierarchical Finding Aid.

A Hierarchic Finding Aid is itself a Collection, and may be described by a Unitary Finding Aid.

2.6.3 Analytic Finding Aid

A Collection-Description which consists of information about the
individual Items within it and their Content.

A library catalogue is typically an Analytic Finding Aid.

An Analytic Finding Aid is itself a Collection, and may be described by a Unitary Finding Aid.

2.6.4 Indexing Finding Aid

A Collection-Description which consists of information derived
from the individual Items within it.

The index created by a full-text search engine is an example of an Indexing Finding Aid.

An Indexing Finding Aid is itself a Collection, and may be described by a Unitary Finding Aid.

3. Relationship Types

Note: in the Analytic Model relationships may carry attributes; in the DC CD AP, relationships are represented as simple properties and do not themselves carry attributes, so some of the expressivity of the model is lost in the metadata schema.

3.1 Is-Gathered-Into/Is-Gathering-Of

An Item*is-gathered-into_ one or more Collections.

A Collection*is-a-gathering-of_ one or more Items.

The DC CD AP does not describe these relationships between Item and Collection, so does not provide corresponding properties.

3.2 Is-Located-In/Is-Location-Of

A Collection*is-located-in_ one or more Locations.

A Location*is-location-of_ one or more Collections.

In the DC CD AP, the Is-Located-In relationship type corresponds to the property (gen:isLocatedIn?, gen:location?); the DC CD AP does not provide a property to represent the inverse relationship type.

3.3 Is-Administered-By/Administers

A Location*is-administered-by_ one or more Agents who have responsibility for the physical or digital environment.

An Agent*administers_ zero or more Locations.

The DC CD AP does not describe these relationships between Location and Agent, so does not provide corresponding properties.

3.4 Is-Accessed-Via/Provides-Access-To

A Collection*is-accessed-via_ one or more Informational Services.

An Informational Service*provides-access-to_ exactly one Collection.

In the DC CD AP, the Is-Accessed-By relationship type corresponds to the property (gen:isAccessedVia? gen:access?); the DC CD AP does not provide a property to represent the inverse relationship type.

3.5 Is-Provided-By/Provides

A Service*is-provided-by_ one or more Agents.

An Agent*provides_ zero or more Services.

The DC CD AP does not describe these relationships between Service and Agent, so does not provide corresponding properties.

3.6 Is-Described-By/Describes

A Collection*is-described-by_ zero or more Collection Descriptions.

A Collection Description*describes_ exactly one Collection.

In the DC CD AP, the Is-Described-By relationship type corresponds to the property dc:description; the DC CD AP does not provide a property to represent the inverse relationship type.

4. Examples

4.1 Collection of Physical Items

A physical collection (e.g. a library collection) is located at a physical location (a library).

The location is administered by the library-as-institution.

Access to the collection is provided by several physical services (e.g. a reference service, a lending service).

Each service is provided by the library-as-institution (or some subgroup of the library-as-institution).

The physical collection is described by the library catalogue (an analytical finding aid).

Access to the library catalogue is provided by several digital services (e.g. a Web OPAC interface, a Z39.50 target).

Each service is provided by the library-as-institution (or some subgroup of the library-as-institution).

4.2 Collection of Digital Items

[to follow]

5. Questions

5.1 Location and Service

Is there a relation between Location and Service? e.g. Is a Service accessed-at a Location? Or is a Service independent of Location?

5.2 Digital Location and Service

Is it possible to describe a digital Location that is distinct from a digital Service?

Or for digital Collections, do we describe only digital Services (and not digital Locations)?

5.3 Generalising the Model

Can the Resource-Location-Service model be generalised to classes of resource other than Collections?

  • For a physical Item, the distinction between Item, Location and Service is still valid (e.g. book, shelf location, lending service).
  • For a digital Item, the distinction between Item and Service can still be made (e.g. a single digital object might be accessed via an HTTP server and an FTP server

Are there classes of resource to which the Resource-Location-Service model does not apply? Events, Agents, "abstract"/conceptual resources? Does it apply only to "Informational Resources" (however they are defined)?

How does the Resource-Location-Service distinction fit with the REST architectural style (where the identifier of a resource may be de-referenced to obtain a representation of the resource)?

  • For a physical Collection, it may be possible to provide distinct representations of the Collection, Location and Service e.g. three distinct human-readable HTML documents.
  • For a digital Collection, it may be possible to provide distinct representations of the Collection, and Service e.g. two distinct human-readable HTML documents.
  • For a physical Item, it may be possible to provide distinct representations of the Item, Location and Service e.g. three distinct human-readable HTML documents.
  • But for a digital Item?

5.4 Representation in DC

How should the (two different) relations between Collection and Service (is-Available-Via) and between Collection and Location (is-Located-In) be represented in DC metadata?

  • by existing DC elements or element refinements?
  • by new elements for the dcterms vocabulary?
  • by new refinements of dc:relation?
  • by new refinements of some other DC element(s)?

What are the implications for existing practice in DC metadata (e.g. existing use of dc:identifier), particularly in association with "dumb-down" to "Simple DC"?