innovation in metadata design, implementation & best practices

Dublin Core Collection Description Application Profile: Data Model

Creator: Dublin Core Collection Description Working Group
Date Issued: 2004-07-11
Identifier: http://dublincore.org/groups/collections/collection-model/2004-07-11/
Replaces: http://dublincore.org/groups/collections/collection-model/2004-07-04/
Is Replaced By: http://dublincore.org/groups/collections/collection-model/2004-08-06/
Latest Version: http://dublincore.org/groups/collections/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:

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:

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:

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:

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

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?

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)?

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?

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"?