CIDOC
Conceptual Reference Model
Information Groups

 

Produced by the ICOM/CIDOC 
Documentation Standards Group
 
Editors: Nick Crofts, Ifigenia Dionissiadou, Martin Doerr, Pat Reed.
 
September 1998

 
 
Copyright © 1998 ICOM/CIDOC Documentation Standards Group

Contents
Introduction 
Symbols used in the model
Acquisition Information
Condition Information
Deaccession and Disposal Information
Description Information
Image Information
Institution Information
Location information
Mark and Inscription Information
Material and technique Information
Measurement Information
Object Association information
Object collection information
Object Entry Information
Object Name Information
Object Number Information
Object Production Information
Object Title information
Part and component Information
Recorder Information
Reference information
Reproduction Rights Information
Subject depicted information
CRM class hierarchy
Documentation

 
Introduction
The CIDOC Conceptual Reference Model (CRM) is a formal ontology for the documentation of cultural heritage. It has been developed by the ICOM/CIDOC documentation standards group (DSG) over a period of several years. The complete model is quite complex and not easily presented in graphic format. The current document aims to provides an accessible introduction based on the CIDOC International Guidelines for Museum Object Information : The CIDOC Information Categories (CIC). The CRM is presented as a series of sub models each of which maps directly onto one of the 'information groups' defined by the CIC. In each case brief scope notes are included which explain the thinking behind the reference model and which make explicit the position of individual information items. Naturally, we recommend reading the current document in conjunction with the CIC.
 
The scope of the presentation of the model is deliberately restricted in a number of respects.
 
•	The model adopts the conceptual frame of its intended users (scholars, museum professionals and museum visitors, etc.). It does not aim to represent all possible points of view. 
•	The model is focused on common museum activities (collections management and conservation, research and analysis, promotion and communication). Organisation-specific management procedures are not incorporated into the model, although possible implementation schemes are suggested which maintain compatibility with the reference model.
•	The model concentrates on aspects of cultural documentation incorporated in the CIC.
•	The model deals primarily with objects collected by museums
•	The model aims to provide a level of detail and precision required to provide an adequate quality of service. More detailed modelling is certainly possible, but probably not useful.
•	The need to avoid unnecessary technical complexity has also influenced the model.
 
It is not possible in the context of this document to provide a exhaustive exposition of the CRM. Please refer to the reference documentation for more details. A complete set of reference documents is available at the DSG Web site:
 
http://www.ville-ge.ch/musinfo/cidoc/oomodel/
 
It is important to bear in mind that the CIDOC reference model is ongoing work. The present document represents the current state of the model resulting from a working meeting which took place in March 1998 in Crete. Although the broad outlines are now well established, some questions of detail still need to be dealt with. Your comments and suggestions are welcome.
 
Nick Crofts
Pat Reed
CIDOC Documentation Standards Group
September 1998

Symbols used in the model
 
The symbols used in this document are derived from the French analysis and design methodology Merise.
 
Classes are represented as rectangles. The name of the class is at the top of the class and the attributes are listed beneath it, separated by a horizontal line. 

 
Relations, or links, are represented by ovals and lines drawn between classes. The name of the representation is at the top of the oval and the attributes are listed beneath it, separated by a horizontal line. We have adopted a bidirectional naming convention : reading from left to right the main label is used. A second name, in brackets, is used when reading from right to left.

 
Cardinalities are represented as pairs of numbers, written on links between entities. Common values are o,n (none or many), 1,n (at least one), 1,1 (exactly one).

 
Inheritance (Isa) relations between classes are represented by lines drawn between classes and a half circle. A cross in the half circle indicates that the inheritance is exclusive.

 
We have adopted three further conventions to simplify the presentation of the diagrams.
 
1.	The full Isa hierarchy is sometimes truncated or omitted altogether. We have used dotted lines for the inheritance links in such cases. 
 
1.	Dotted lines are also used to represent 'short cut' links (A different colour is also used to differentiate shortcut links, but this may not be visible on black and white prints.) Shortcuts are intended as a semantically simplified alternative to a fully developed chain of links. Relations between objects and people, for example, are often handled in this way. The Acquisition Information diagram provides both a fully developed link from object to owner via an acquisition event and a simplified 'shortcut' link to the current owner. The fully developed link allows a detailed ownership history to be recorded. However, this information may not always be required so the shortcut allows for a simplified implementation. Normally, only one of the alternative schema would be implemented. The CRM defines ways in which information can be transferred consistently between 'richer' or 'poorer' systems.
 
1.	Entities in the 'type' hierarchy are represented with a magenta outline. (This may not be visible on documents printed in black and white). Put briefly, the type hierarchy serves as an authority list which enhances the granularity of the class hierarchy. For more information about the function of the type hierarchy please refer to Electronic Communication on Diverse Data - The Role of the oo CIDOC Reference Model (August 1998). 

Acquisition Information

 
Acquisition Information	 	Acquisition by the institution is an instance of transfer of legal title.	
 	Acquisition method	Acquisition method is the acquisition type, inherited from CIDOC ENTITY.	
 	Acquisition date	Time-span attribute inherited from Period	
 	Acquisition source	Source is the transfers title from link	

Condition Information

 
Condition Information	 	 	
 	Condition	Type attribute of condition state	
 	Condition summary	Textual note on condition state, inherited from CIDOC ENTITY. 	
 	Condition date	Time-span of condition state inherited from Period.	

 

Deaccession and Disposal Information
No model 

Deaccession and Disposal Information	 	We have adopted the following distinctions :
•	Legal title (ownership)
•	Physical custody (who keeps the object)
•	Accessioned - formally recognised as part of the collection.
We have decided not to model accessioning explicitly. In our opinion accessioning is best modelled as an extension to the CRM in order to reflect local practice. (e.g. does the museum 'accession' objects to which it does not have legal title ?) It is the responsibility of each institution and local implementation to declare how their notions of accession and disposal imply transfer of legal title and or physical custody, in order to maintain compatibility.
 	
 	Deaccession date	Time-span of 'deaccessioning' event inherited from Period.	
 	Disposal date	Time-span of 'disposal' event inherited from Period.	
 	Disposal method	 	
 	Disposal recipient	 	

Description Information
No model

Description Information	 	 	
 	Physical description	Text attribute of the object. (All CIDOC entities automatically inherit a text field attribute.)	
 	Specimen status	Type, holotype, paratype, etc. This notion is specific to natural history and is currently beyond the scope of the CRM. NB The 'type' status of a specimen does not depend on its physical attributes.
Could be considered as the type attribute of the object. However, standard biological taxonomy usually identifies the author and date of the taxon as well.
Specimen status is a candidates for domain specific extensions for the future. 	

Image Information
 
No model 

Image Information	 	Images are specialised cases of objects. (A collection object may be an image of another object).
 
The implicit prescription of the CIC that objects should be photographed is not represented in the model. However, constraints could be included to enforce good practice. 
 
Sound recordings are a sub-class of reproductions. Reproductions or references are two types of relation between objects.	
 	Image type	Image type is a specialisation of object type.	
 	Image reference number	Images are objects related to museum objects. A persistent link exists between the two. This link effectively means that a photograph or picture is a 'faithful' representation. (Information about the event leading to the creation of the photo is implicit, ie author and date, etc.). The reference number itself is a specialisation of object number.	

Institution Information

 
Institution Information	 	The CIC is unclear as to whether this information refers to the current owner of the object, the current keeper of the object, or possibly the recorder of the object information. All of these are modelled elsewhere.
 
Institution is a subclass of Actor	
 	Institution name	Name attribute of the actor	
 	Institution sub-body name	idem	
 	Institution address	Place (Address) attribute of the actor	
 	Institution country	idem	

Location information

 
Location Information	 	A history of 'move' events.	
 	Current location	Derived from the location history or as a 'shortcut' relation between object and location.	
 	Current location date	Time-span attribute of a Move event	
 	Current location type	Inherited Type attribute of location (!)	
 	Normal location	Current permanent location short cut link.	

Mark and Inscription Information

 Mark and Inscription Information	 	Marks and inscriptions are interpreted as 'conceptual objects' ie intellectual information which is carried by a physical object. The CIC does not deal with marks such as scratches which have no semantic significance.	
 	Mark/inscription text	Textual transcription of the mark or inscription. Clear rules need to be stated as to how marks should be transcribed or transliterated.	
 	Mark/inscription type	A distinction is made in the model between marks in general and inscriptions, which have linguistic attributes. Further classification of inscription types could use the class 'type' field.	
 	Mark/inscription description	Text field attribute of the mark.	
 	Mark/inscription technique	This information could be included as part of the text attribute of the 'shows visual item' link. Alternatively a specific attribute might be used if the information is used as an access point. 	
 	Mark/inscription position	This information could be included as an attribute of the 'shows visual item' link. A specialised piece of information if used as an access point.	
 	Mark/inscription language	Language attribute of the inscription.	
 	Mark/inscription translation	Translation attribute of the inscription.	

Material and technique Information

Material and Technique Information	 	 	
 	Material	Material class form the type hierarchy	
 	Technique	Common techniques can be handled through the general technique link as Types. Specific techniques can be documented using the Design or Procedure class. This defines or describes the way in which a production activity is carried out and the materials used.
 
e.g. architectural plans, assembly instructions, recipes, designs, traditional techniques.	
 	Part or component description	Parts can be of different types.. integral, separable, etc. 	

Measurement Information
q
  
Measurement Information	 	Measuring something is interpreted as an act of attribute assignment. The measurement history could be recorded as a textual object if not required as an access point.	
 	Dimension	'Value' attribute of the Dimension entity	
 	Measurement	 	
 	Measurement unit	'Unit' attribute of the Dimension entity.	
 	Measured part	Observed property link from the measurement event, or observed feature attribute of the 'had dimensions' shortcut..	

Object Association information

 
Object Association Information	 	A history of events associated with the object. This is open to specialisation. (The model shown here illustrates the notion of 'original function').	
 	Associated place	Modelled elsewhere with specific relations.	
 	Associated date	Modelled elsewhere with specific relations.	
 	Associated group/person name	Modelled elsewhere with specific relations.	
 	Association type	 	
 	Original function	Was used for - actual instance of use
Had as general use - activity type
Was made for - event instance (intended use)
Was intended for - activity type.(intended use)
See diagram below... (function use)	

Object collection information
 
No model 

Object Collection Information	 	Could be seen as initial event in ownership history (provenance). (Collecting is a specialisation of an acquisition event.) Or as initial transfer of physical custody, or both. 	
 	Collection place	inherited from Physical Context	
 	Collection date	Time-Span inherited from Period.	
 	Collector 	Actor who acquires the object	
 	Collection method	type of collection method - link to Type hierarchy. (e.g. excavation, trapped, stolen)	

Object Entry Information

Object Entry Information	 	Transfer of physical custody of an object.
Object entry and exit are two relative views of transfer of custody.	
 	Current owner	Interpreted as current owner at moment of transfer. Iff data consistency is guaranteed, current owner may be derived from the ownership history. Otherwise a specific link is needed.	
 	Depositor	Actor who surrenders custody of the object	
 	Entry date	Time-span attribute of Transfer of custody	
 	Entry number	Object identifier assigned as a result of the transfer event. Either multiple instantiation or multiple inheritance (transfer of custody and identifier assignment) depending on the organisation's practice. Another possibility : two events grouped by consists of link.	
 	Entry reason	General and specific reasons for the transfer taking place : an activity type and a specific activity. NB The specific purpose of an activity should not usually be the same instance as the activity itself.	

Object Name Information

Object Name Information	Object name 	CIDOC Type of an object 	
 	Object name type	The Type of the Reference Document used.
 
In order to enable interoperability, it is essential that type systems refer to a specific Reference Document. (This can be stated a) for the entire scope of the database or b) for individual database fields or c) per term, as modelled here.) It is strongly recommended that local, 'ad hoc' systems correlate their terms to a known reference system. (Within the context of the CIDOC reference model, ad hoc systems are considered to be Reference Documents.)	
 	Object name authority	Actor responsible for the Type Assignment	

Object Number Information

Object Number Information	 	Only one identifier should be used. Associating date and type complexifies the identifier which should be separated into other, non preferred, numbers.	
 	Object number	Object number is an instance of the class Object Identifier. An identifier is a token - a number or string, which is arbitrarily assigned to an object for use as an identifier. An object identifier should be uniquely assigned to each object.
 
Each identifier has a certain scope and context - the environment in which it is unique. e.g. The Smithsonian 1956-1996.	
 	Object number type	The object identifier type - inherited from CIDOC-ENTITY	
 	Object number date	Time-span of the identifier assignment.	

Object Production Information

Object Production Information	 	Creation of an object. - an intermediate 'rôle' class could be used between production and actor. This would allow for specialisation of the relation.	
 	Production place	Inherited from activity	
 	Production date	idem	
 	Production group/person name	actor	
 	Production rôle	How someone contributed to the creation. Rôle of the performed relation.	

Object Title information

 
Object Title Information	 	Title is a subclass of linguistic object (itself a subclass of conceptual object) from which it inherits 'linguistic' attributes. Translations are also linguistic objects. Title is also a subclass of Appellation from which it derives its 'naming' aspect.	
 	Title	String attribute of Title entity	
 	Title type	Type of title is an attribute of the 'has title' link.	
 	Title translation	Translation attribute inherited from linguistic object.	

Part and component Information

 
Part and Component Information	 	This information could be treated as a sub field of the physical description.	
 	Number of parts or components	Can be calculated for physical component parts which use the is composed of link. However, for sets of items, like a pack of cards, for which analysis into components would be unnecessary, a formal number of parts field can be used when the inventory count requires.
In either case, the total number of parts must reflect inventory practice.	
 	Description of parts and components	Inherited text attribute.	

Recorder Information
See model for Object name Information Group

Recorder Information	 	Attribute Assignment is a potential hook-in point for information about the recorder of the information. However, using the note field for this purpose is preferred.
 
It is recommended that the system should record the author and date of information entry. However, this information need not be available as an access point
 
For the purposes of external access, 'version' information should be generated dynamically as a database 'signature' 
•	Generate dynamically a 'database' signature : e.g. SIBIL GENEVA 20/4/1997, at moment of retrieval
•	Finer granularity ... text format.
 
Who is the 'author' ? The authority should be distributed, rather than the person responsible for data entry.	
 	Recorder	Optionally per object record
Dynamically per database	
 	Record date	idem	
 	Authority	controller, supervisor, 	

Reference information

 
Reference Information	 	 	
 	Reference	Link from Document to Object. Documents may, of course, refer to things other than objects. However, in the present context, only the documentation of museum objects is of relevance. 	
 	Reference type	Type attribute of Document, inherited from CIDOC entity. 	

Reproduction Rights Information

 
Reproduction Rights Information 	 	This information could be generalised to include all 'rights' granted to an actor concerning an, object or intellectual object, type of right and description. (text)	
 	Reproduction rights note	Inherited text attribute of 'Rights' entity	
 	Reproduction rights owner	Actor	

 

Subject depicted information

 
 
Subject Depicted Information	 	Concerns any man-made object which depicts another object, event, concept or place. E.g. a photograph, painting, engraving, coin, etc.	
 	Subject depicted 	Links depicts concept (Link to Type), depicts event and depicts object. Each of these links has a Mode of depiction attribute, which allows the way in which the iconographic object represents : as main subject, incidental subject, etc.	
 	Subject depicted description	Text attribute of the iconographical object, inherited from CIDOC Entity.	

CRM class hierarchy

Documentation
 
Guidelines for Museum Objects - CIDOC Information Categories (June 1995) 
Notes on the transformation of the CIDOC relational data model (July 1996) 
Introduction to object oriented modelling (September 1996) 
Preliminary Definition of the CIDOC Reference Model (Revised May 1998) 
Electronic Communication on Diverse Data - The Role of the oo CIDOC Reference Model (August 1998)
 
Web site : http://www.ville-ge.ch/musinfo/cidoc/oomodel/