Dublin Core™ Collection Description Application Profile: Data Model
| Creator: | Dublin Core™ Collection Description Working Group |
|---|---|
| Date Issued: | 2004-07-11 |
| Identifier: | //www.voudr.com/specifications/dublin-core/collection-description/collection-model/2004-07-11/ |
| Replaces: | //www.voudr.com/specifications/dublin-core/collection-description/collection-model/2004-07-04/ |
| Is Replaced By: | //www.voudr.com/specifications/dublin-core/collection-description/collection-model/2004-08-06/ |
| Latest Version: | //www.voudr.com/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 inAn Analytical Model of Collections and their Catalogues[1], and proposes the addition of a new entity type, Service.
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:
- 一个图书馆collection
- a museum collection
- an archive
- a collection of digital images
- a catalogue
In the DC CD AP, this entity type corresponds to the classdcmitype:Collection.
2.3 Location
A place where a Collection is held.
Examples of a Location include:
- 一个图书馆
- 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 classdcmitype: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
AnInformational Serviceis 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
AnAgentis 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.
TheAnalytical Model[1] identifies four sub-classes of Collection Description:
2.6.1 Unitary Finding Aid
一个Collection-Description由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
一个Collection-Description由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
一个Collection-Description由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索引找到援助
一个Collection-Description由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
AnItem*is-gathered-into_ one or moreCollections.
ACollection*is-a-gathering-of_ one or moreItems.
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
ACollection*is-located-in_ one or moreLocations.
ALocation*is-location-of_ one or moreCollections.
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
ALocation*is-administered-by_ one or moreAgentswho have responsibility for the physical or digital environment.
AnAgent*administers_ zero or moreLocations.
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
ACollection*is-accessed-via_ one or moreInformational Services.
AnInformational Service*provides-access-to_ exactly oneCollection.
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
AService*is-provided-by_ one or moreAgents.
AnAgent*provides_ zero or moreServices.
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
ACollection*is-described-by_ zero or moreCollection Descriptions.
ACollection Description*describes_ exactly oneCollection.
In the DC CD AP, the Is-Described-By relationship type corresponds to the propertydc: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
(跟随)
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?
或数字集合,我们谈谈e 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 ofdc:identifier), particularly in association with "dumb-down" to "Simple DC"?