Definition of the
CIDOC
Conceptual Reference Model

 

 

 

 

 

 

Produced by the ICOM/CIDOC

Documentation Standards Group,

Continued by the

CIDOC CRM Special Interest Group

 

 

 

Version 5.0.4

 

November 2011

 

 

 

 

Editors: Nick Crofts, Martin Doerr, Tony Gill, Stephen Stead, Matthew Stiff.

 

 

Copyright © 2003 ICOM/CIDOC CRM Special Interest Group
Table of Contents

 

 

 

Introduction

Objectives of the CIDOC CRM

Scope of the CIDOC CRM

Compatibility with the CRM

Utility of CRM compatibility

The Information Integration Environment

CRM-Compatible Form

CRM Compatibility of Data Structure

CRM Compatibility of Information Systems

Compatibility claim declaration

Applied Form

Terminology

Property Quantifiers

Naming Conventions

Modelling principles

Monotonicity

Minimality

Shortcuts

Disjointness

About Types

Extensions

Coverage

Examples

Class & Property Hierarchies

CIDOC CRM Class Hierarchy

CIDOC CRM Property Hierarchy:

CIDOC CRM Class Declarations

E1 CRM Entity

E2 Temporal Entity

E3 Condition State

E4 Period

E5 Event

E6 Destruction

E7 Activity

E8 Acquisition

E9 Move

E10 Transfer of Custody

E11 Modification

E12 Production

E13 Attribute Assignment

E14 Condition Assessment

E15 Identifier Assignment

E16 Measurement

E17 Type Assignment

E18 Physical Thing

E19 Physical Object

E20 Biological Object

E21 Person

E22 Man-Made Object

E24 Physical Man-Made Thing

E25 Man-Made Feature

E26 Physical Feature

E27 Site

E28 Conceptual Object

E29 Design or Procedure

E30 Right

E31 Document

E32 Authority Document

E33 Linguistic Object

E34 Inscription

E35 Title

E36 Visual Item

E37 Mark

E38 Image

E39 Actor

E40 Legal Body

E41 Appellation

E42 Identifier

E44 Place Appellation

E45 Address

E46 Section Definition

E47 Spatial Coordinates

E48 Place Name

E49 Time Appellation

E50 Date

E51 Contact Point

E52 Time-Span

E53 Place

E54 Dimension

E55 Type

E56 Language

E57 Material

E58 Measurement Unit

E59 Primitive Value

E60 Number

E61 Time Primitive

E62 String

E63 Beginning of Existence

E64 End of Existence

E65 Creation

E66 Formation

E67 Birth

E68 Dissolution

E69 Death

E70 Thing

E71 Man-Made Thing

E72 Legal Object

E73 Information Object

E74 Group

E75 Conceptual Object Appellation

E77 Persistent Item

E78 Collection

E79 Part Addition

E80 Part Removal

E81 Transformation

E82 Actor Appellation

E83 Type Creation

E84 Information Carrier

E85 Joining

E86 Leaving

E87 Curation Activity

E89 Propositional Object

E90 Symbolic Object

CIDOC CRM Property Declarations

P1 is identified by (identifies)

P2 has type (is type of)

P3 has note

P4 has time-span (is time-span of)

P5 consists of (forms part of)

P7 took place at (witnessed)

P8 took place on or within (witnessed)

P9 consists of (forms part of)

P10 falls within (contains)

P11 had participant (participated in)

P12 occurred in the presence of (was present at)

P13 destroyed (was destroyed by)

P14 carried out by (performed)

P15 was influenced by (influenced)

P16 used specific object (was used for)

P17 was motivated by (motivated)

P19 was intended use of (was made for):

P20 had specific purpose (was purpose of)

P21 had general purpose (was purpose of)

P22 transferred title to (acquired title through)

P23 transferred title from (surrendered title through)

P24 transferred title of (changed ownership through)

P25 moved (moved by)

P26 moved to (was destination of)

P27 moved from (was origin of)

P28 custody surrendered by (surrendered custody through)

P29 custody received by (received custody through)

P30 transferred custody of (custody transferred through)

P31 has modified (was modified by)

P32 used general technique (was technique of)

P33 used specific technique (was used by)

P34 concerned (was assessed by)

P35 has identified (was identified by)

P37 assigned (was assigned by)

P38 deassigned (was deassigned by)

P39 measured (was measured by)

P40 observed dimension (was observed in)

P41 classified (was classified by)

P42 assigned (was assigned by)

P43 has dimension (is dimension of)

P44 has condition (is condition of)

P45 consists of (is incorporated in)

P46 is composed of (forms part of)

P48 has preferred identifier (is preferred identifier of)

P49 has former or current keeper (is former or current keeper of)

P50 has current keeper (is current keeper of)

P51 has former or current owner (is former or current owner of)

P52 has current owner (is current owner of)

P53 has former or current location (is former or current location of)

P54 has current permanent location (is current permanent location of)

P55 has current location (currently holds)

P56 bears feature (is found on):

P57 has number of parts

P58 has section definition (defines section)

P59 has section (is located on or within)

P62 depicts (is depicted by)

P65 shows visual item (is shown by)

P67 refers to (is referred to by)

P68 foresees use of (use foreseen by)

P69 is associated with

P70 documents (is documented in)

P71 lists (is listed in)

P72 has language (is language of)

P73 has translation (is translation of)

P74 has current or former residence (is current or former residence of)

P75 possesses (is possessed by)

P76 has contact point (provides access to)

P78 is identified by (identifies)

P79 beginning is qualified by

P80 end is qualified by

P81 ongoing throughout

P82 at some time within

P83 had at least duration (was minimum duration of)

P84 had at most duration (was maximum duration of)

P86 falls within (contains)

P87 is identified by (identifies)

P88 consists of (forms part of)

P89 falls within (contains)

P90 has value

P91 has unit (is unit of)

P92 brought into existence (was brought into existence by)

P93 took out of existence (was taken out of existence by)

P94 has created (was created by)

P95 has formed (was formed by)

P96 by mother (gave birth)

P97 from father (was father for)

P98 brought into life (was born)

P99 dissolved (was dissolved by)

P100 was death of (died in)

P101 had as general use (was use of)

P102 has title (is title of)

P103 was intended for (was intention of)

P104 is subject to (applies to)

P105 right held by (has right on)

P106 is composed of (forms part of)

P107 has current or former member (is current or former member of)

P108 has produced (was produced by)

P109 has current or former curator (is current or former curator of)

P110 augmented (was augmented by)

P111 added (was added by)

P112 diminished (was diminished by)

P113 removed (was removed by)

P114 is equal in time to

P115 finishes (is finished by)

P116 starts (is started by)

P117 occurs during (includes)

P118 overlaps in time with (is overlapped in time by)

P119 meets in time with (is met in time by)

P120 occurs before (occurs after)

P121 overlaps with

P122 borders with

P123 resulted in (resulted from)

P124 transformed (was transformed by)

P125 used object of type (was type of object used in)

P126 employed (was employed in)

P127 has broader term (has narrower term)

P128 carries (is carried by)

P129 is about (is subject of)

P130 shows features of (features are also found on)

P131 is identified by (identifies)

P132 overlaps with

P133 is separated from

P134 continued (was continued by)

P135 created type (was created by)

P136 was based on (supported type creation)

P137 exemplifies ( is exemplified by )

P138 represents (has representation)

P139 has alternative form

P140 assigned attribute to (was attributed by)

P141 assigned (was assigned by)

P142 used constituent (was used in)

P143 joined (was joined by)

P144 joined with (gained member by)

P145 separated (left by)

P146 separated from (lost member by)

P147 curated (was curated by)

P148 has component (is component of)

P149 is identified by (identifies)

References:

APPENDIX

Editorial notes

Amendments to version 3.3

Amendments to version 3.3.1

Amendments to version 3.3.2

Amendments to version 3.4

Amendments to version 3.4.1

Amendments to version 3.4.2

Amendments to version 3.4.9

Amendments to version 4.2

Amendments to version 4.2.1

P16 used specific object (was used for)

P32 used general technique (was technique of)

P33 used specific technique (was used by)

P35 has identified (identified by)

Amendments to version 4.2.2

E1 CRM Entity

E3 Condition State

E4 Period

E15 Identifier Assignment

E29 Design or Procedure

E33 Linguistic Object

E41 Appellation

E42 Identifier

E51 Contact Point

E54 Dimension

E74 Group

E85, E80 have been added

E85 Joining

E80 Leaving

P3 has note

P36

P37 assigned (was assigned by)

P38 deassigned (was deassigned by)

P47 is identified by(identifies)

P48 has preferred identifier (is preferred identifier of

P69 is associated with

P139 has alternative form

P142, P143, P144, P145, P146, P148

P142 used constituent (was used in)

P143 joined (was joined by)

P144 joined with (gained member by)

P145 separated (left by)

P146 separated from (lost member by)

P148 is identified by (identifies)

Amendments to version 4.2.4

Delete the word “domain”

E15

E42

E85 and E86

Amendments to version 4.2.5

Changes in the terminology

E89, E90 have been added:

E89 Propositional Object

E90 Symbolic Object

P148  has been changed

P67, P129 changed domain

P106 changed domain and range

Changes in the scope note of E7 Activity P16

P16 used specific object (was used for)

Changes to E54

Changes to the text of E28

E28 Conceptual Object

E28 Conceptual Object

Changes in the domain, range and superproperty of P137

P137 is exemplified by (exemplifies) (old)

P137 exemplifies (is exemplified by) (NEW)

P39

P39 measured (was measured by):

P39 measured (was measured by):

Amendments to version 4.2.5a

The range and the scope note of P20 has been changed

P20 had specific purpose (was purpose of)

The scope note of P21 has been changed and an example is added

P21 had general purpose (was purpose of)

P105 has been superproperty of P52

The scope note of P105 has been changed

P105 right held by (has right on)

Proofreading:

Amendments to version 4.3

P68 usually employs (is usually employed by)

Compatibility

About Types

E55 Type

E66 Formation

P143 joined was joined by)

P144 joined with (gained member by)

P5 consists of

E78 Collection

E87 Curation Activity

P147 curated (was curated by)

P109 has current or former curator (is current or former curator of)

Amendments to version 5.0

Compatibility claim declaration

E78 Collection

P107 has current or former member (is current or former member of)

P144 joined with (gained member by)

Proofreading:

Amendments to version 5.01

Proofreading:

Amendments to version 5.02

E5 Event, E6 Destruction

E12 Production

E29 Design or Procedure

E35 Title

E70 Thing

E75 Conceptual Object Appellation

E81 Transformation – issue 165

P4 has time-span (is time-span of)

P5 consists of (forms part of)

P14 carried out by (performed) – issue 170

P44 has condition (is condition of) – issue 144

P62 depicts (is depicted by)

P65 shows visual item (is shown by) – issue 169

P107 has current or former member (is current or former member of)

P148 has component (is component of)

Proofreading:

Amendments to version 5.0.3

E11 Modification

E51 Contact Point

E89 Propositional Object

P2 has type (is type of)

P33 used specific technique (was used by)

P68 foresees use of (use foreseen by)

P69 is associated with

P71 lists (is listed in)

P101 had as general use (was use of)

P111 added (was added by)

P113 removed (was removed by)

P128 carries (is carried by)

P149 is identified by (identifies)

Proofreading:

Amendments to version 5.0.4

Change the text in objectives of the CIDOC CRM

P109 is subproperty of P19

P111 is subproperty of P16

Proofreading:


Definition of the CIDOC Conceptual Reference Model

Introduction

 

This document is the formal definition of the CIDOC Conceptual Reference Model (“CRM”), a formal ontology intended to facilitate the integration, mediation and interchange of heterogeneous cultural heritage information. The CRM is the culmination of more than a decade of standards development work by the International Committee for Documentation (CIDOC) of the International Council of Museums (ICOM). Work on the CRM itself began in 1996 under the auspices of the ICOM-CIDOC Documentation Standards Working Group. Since 2000, development of the CRM has been officially delegated by ICOM-CIDOC to the CIDOC CRM Special Interest Group, which collaborates with the ISO working group ISO/TC46/SC4/WG9 to bring the CRM to the form and status of an International Standard.

Objectives of the CIDOC CRM

The primary role of the CRM is to enable information exchange and integration between heterogeneous sources of cultural heritage information. It aims at providing the semantic definitions and clarifications needed to transform disparate, localised information sources into a coherent global resource, be it within a larger institution, in intranets or on the Internet.

Its perspective is supra-institutional and abstracted from any specific local context. This goal determines the constructs and level of detail of the CRM.

 

More specifically, it defines and is restricted to the underlying semantics of database schemata and document structures used in cultural heritage and museum documentation in terms of a formal ontology. It does not define any of the terminology appearing typically as data in the respective data structures; however it foresees the characteristic relationships for its use. It does not aim at proposing what cultural institutions should document. Rather it explains the logic of what they actually currently document, and thereby enables semantic interoperability.

 

It intends to provide a model of the intellectual structure of cultural documentation in logical terms. As such, it is not optimised for implementation-specific storage and processing aspects. Implementations may lead to solutions where elements and links between relevant elements of our conceptualizations are no longer explicit in a database or other structured storage system. For instance the birth event that connects elements such as father, mother, birth date, birth place may not appear in the database, in order to save storage space or response time of the system. The CRM allows us to explain how such apparently disparate entities are intellectually interconnected, and how the ability of the database to answer certain intellectual questions is affected by the omission of such elements and links.

 

The CRM aims to support the following specific functionalities:

 

Users of the CRM should be aware that the definition of data entry systems requires support of community-specific terminology, guidance to what should be documented and in which sequence, and application-specific consistency controls. The CRM does not provide such notions.

 

By its very structure and formalism, the CRM is extensible and users are encouraged to create extensions for the needs of more specialized communities and applications.

Scope of the CIDOC CRM

The overall scope of the CIDOC CRM can be summarised in simple terms as the curated knowledge of museums.

 

However, a more detailed and useful definition can be articulated by defining both the Intended Scope, a broad and maximally-inclusive definition of general application principles, and the Practical Scope, which is expressed by the overall scope of a reference set of specific identifiable museum documentation standards and practices that the CRM aims to encompass, however restricted in its details to the limitations of the Intended Scope.

 

The Intended Scope of the CRM may be defined as all information required for the exchange and integration of heterogeneous scientific documentation of museum collections. This definition requires further elaboration:

 

 

The Practical Scope[2] of the CRM is expressed in terms of the current reference standards for museum documentation that have been used to guide and validate the CRM’s development. The CRM covers the same domain of discourse as the union of these reference standards; this means that data correctly encoded according to these museum documentation standards there can be a CRM-compatible expression that conveys the same meaning.

 

Compatibility with the CRM

Utility of CRM compatibility

 

The goal of the CRM is to enable the integration of the largest number of information resources. Therefore it aims to provide the greatest flexibility of systems to become compatible, rather than imposing one particular solution.

 

Users intending to take advantage of the semantic interoperability offered by the CRM may want to make parts of their data structures compatible with the CRM. Compatibility may pertain either to the associations by which users would like their data to be accessible in an integrated environment, or to the contents intended for transport to other environments, allowing encoded meaning to be preserved in a target system.

 

The CRM does not require complete matching of all user documentation structures with the CRM, nor that systems should always implement all CRM concepts and associations; instead it leaves room both for extensions, needed to capture the full richness of cultural information, and for simplifications, required for reasons of economy.

 

Furthermore, the CRM provides a means of interpreting structured information so that large amounts of data can be transformed or mediated automatically. It does not require unstructured or semi-structured free text information to be analysed into a formal logical representation. In other words, it does not aim to provide more structure than users have previously provided. The interpretation of information in the form of free text falls outside the scope of compatibility considerations. The CRM does, however, allow free text information to be integrated with structured information.

The Information Integration Environment

 

The notion of CRM compatibility is based on interoperability. Interoperability is best defined on the basis of specific communication practices between information systems. Following current practice, we distinguish the following types of information integration environments pertaining to information systems:

 

  1. Local information systems. These are either collection management systems or content management systems that constitute institutional memories and are maintained by an institution. They are used for primary data entry, i.e. a relevant part of the information, be it data or metadata, is primary information in digital form that fulfils institutional needs.

 

  1. Integrated access systems. These provide an homogeneous access layer to multiple local systems.  The information they manage resides primarily on local systems. We distinguish between:
    1. Materialized access systems, which physically import data provided by local systems, using a data warehouse approach. Such systems may employ so-called metadata harvesting techniques or rely on data submission. Data may be transformed to respect the schema of the access system before being merged. 
    2. Mediation systems, [Gio Wiederholt] which send out queries, formulated according to a virtual global schema, to multiple local systems and then collect and integrate the answers. The queries may be transformed to a local schema either by the mediation system or by the receiving local system itself.

`             

Local systems may also import data from other systems, in order to complement collections, or to merge information from other systems. An information system may export information for migration and preservation.

 

Compatibility with the CRM pertains to one or more of the following data communication capabilities or use cases:

  1. data falling within the scope of the CRM can be exported from an information system into an encoded form without loss of meaning with respect to CRM concepts;
  2. data falling within the scope of the CRM can be transformed into another encoded form without loss of meaning with respect to CRM concepts;
  3. data falling within the scope of the CRM can be imported from an encoded form into an information system without loss of meaning with respect to CRM concepts;
  4. data falling within the scope of the CRM that is contained in an information system can be queried and retrieved exhaustively in terms of CRM concepts, subject to the expressive power of a particular query language.

 

Any declaration of CRM compatibility must specify one or more of the above use cases. System and data structure providers shall not declare their products as “CRM compatible” without specifying the appropriate use cases as detailed below.

 

In the context of this chapter, the expression “without loss of meaning with respect to the CRM concepts” means the following: The CRM concepts are used to classify items of discourse and their relationships. By virtue of this classification, data can be understood as propositions of a kind declared by the CRM about real world facts, such as “Object x. forms part of: Object y”. In case the encoding, i.e. the language used to describe a fact, is changed, only an expert conversant with both languages can assess if the two propositions do indeed describe the same fact. If this is the case, then there is no loss of meaning with respect to CRM concepts. Communities of practice requiring fewer concepts than the CRM declares may restrict CRM compatibility with respect to an explicitly declared subset of the CRM.

 

Users of this standard may communicate CRM compatible data, as detailed below, with data structures and systems that are either more detailed and specialized than the CRM or whose scope extends beyond  that of the CRM. In such cases, the standard guarantees only the preservation of meaning with respect to CRM concepts. However, additional information that can be regarded as extending CRM concepts may be communicated and preserved in CRM compatible systems through the appropriate use of controlled terminology. The specification of the latter techniques does not fall under the scope of this standard. Communities of practice requiring extensions to the CRM are encouraged to declare their extensions as CRM-compatible standards.

CRM-Compatible Form

The CRM is a formal ontology which can be expressed in terms of logic or a suitable knowledge representation language. Its concepts can be instantiated as sets of statements that provide a model of reality. We call any encoding of such CRM instances in a formal language that preserves the relations between the CRM classes, properties and inheritance rules  a “CRM-compatible form”. Hence data expressed in any CRM-compatible form can be automatically transformed into any other CRM-compatible form without loss of meaning. Classes and properties of the CRM are identified by their initial codes, such as “E55” or “P12”. The names of classes and properties of a CRM-compatible form may be translated into any local language, but the identifying codes must be preserved. A CRM-compatible form should not implement the quantifiers of CRM properties as cardinality constraints for the encoded instances. Quantifiers may be implemented in an informative way, or not at all. Statements that violate quantifiers should be treated as alternative knowledge.

 

Any encoding of CRM instances in a formal language that preserves the relations within a consistent subset of CRM classes, properties and inheritance rules is regarded a “reduced CRM-compatible form”, if:

 

E1

CRM Entity

E2

-

Temporal Entity

E4

-

-

Period

E5

-

-

-

Event

E7

-

-

-

-

Activity

E11

-

-

-

-

-

Modification

E12

-

-

-

-

-

-

Production

E13

-

-

-

-

-

Attribute Assignment

E65

-

-

-

-

-

Creation

E63

-

-

-

-

Beginning of Existence

E12

-

-

-

-

-

Production

E65

-

-

-

-

-

Creation

E64

-

-

-

-

End of Existence

E77

-

Persistent Item

E70

-

-

Thing

E72

-

-

-

Legal Object

E18

-

-

-

-

Physical Thing

E24

-

-

-

-

-

Physical Man-Made Thing

E90

-

-

-

-

Symbolic Object

E71

-

-

-

Man-Made Thing

E24

-

-

-

-

Physical Man-Made Thing

E28

-

-

-

-

Conceptual Object

E89

-

-

-

-

-

Propositional Object

E30

-

-

-

-

-

-

Right

E73

-

-

-

-

-

-

Information Object

E90

-

-

-

-

-

Symbolic Object

E41

-

-

-

-

-

-

Appellation

E73

-

-

-

-

-

-

Information Object

E55

-

-

-

-

-

Type

E39

-

-

Actor

E74

-

-

-

Group

E52

-

Time-Span

E53

-

Place

E54

-

Dimension

E59

Primitive Value

E61

-

Time Primitive

E62

-

String

 

Property id
Property Name

Entity – Domain

Entity - Range

P1

is identified by (identifies)

E1 CRM Entity

E41 Appellation

P2

has type (is type of)

E1 CRM Entity

E55 Type

P3

has note

E1 CRM Entity

E62 String

P4

has time-span (is time-span of)

E2 Temporal Entity

E52 Time-Span

P7

took place at (witnessed)

E4 Period

E53 Place 

P10

falls within (contains)

E4 Period

E4 Period

P12

occurred in the presence of (was present at)

E5 Event

E77 Persistent Item

P11

   -   had participant (participated in)

E5 Event

E39 Actor

P14

   -   -   carried out by (performed)

E7 Activity

E39 Actor

P16

   -   used specific object (was used for)

E7 Activity

E70 Thing

P31

   -   has modified (was modified by)

E11 Modification

E24 Physical Man-Made Thing

P108

   -  -    has produced (was produced by)

E12 Production

E24 Physical Man-Made Thing

P92

   -   brought into existence (was brought into existence by)

E63 Beginning of Existence

E77 Persistent Item

P108

   -  -    has produced (was produced by)

E12 Production

E24 Physical Man-Made Thing

P94

   -   -   has created (was created by)

E65 Creation

E28 Conceptual Object

P93

   -   took out of existence (was taken out of existence by)

E64 End of Existence

E77 Persistent Item

P15

was influenced by (influenced)

E7 Activity

E1 CRM Entity

P16

   -   used specific object (was used for)

E7 Activity

E70 Thing

P20

had specific purpose (was purpose of)

E7 Activity

E5 Event

P43

has dimension (is dimension of)

E70 Thing

E54 Dimension

P46

is composed of (forms part of)

E18 Physical Thing

E18 Physical Thing

P59

has section (is located on or within)

E18 Physical Thing

E53 Place 

P67

refers to ( is referred to by)

E89 Propositional Object

E1 CRM Entity

P75

possesses (is possessed by)

E39 Actor

E30 Right

P81

ongoing throughout

E52 Time-Span

E61 Time Primitive

P82

at some time within

E52 Time-Span

E61 Time Primitive

P89

falls within (contains)

E53 Place 

E53 Place 

P104

is subject to (applies to)

E72 Legal Object

E30 Right

P106

is composed of (forms part of)

E90 Symbolic Object

E90 Symbolic Object

P107

has current or former member (is current or former member of)

E74 Group

E39 Actor

P127

has broader term (has narrower term)

E55 Type

E55 Type

P128

carries (is carried by)

E24 Physical Man-Made Thing

E90 Symbolic Object

P130

shows features of (features are also found on)

E70 Thing

E70 Thing

P140

assigned attribute to (was attributed by)

E13 Attribute Assignment

E1 CRM Entity

P141

assigned (was assigned by)

E13 Attribute Assignement

E1 CRM Entity

P148

has component (is component of)

E89 Propositional Object

E89 Propositional Object

 

CRM Compatibility of Data Structure

 

A data structure is export-compatible with the CRM if it is possible to transform any data from this data structure into a CRM-compatible form without loss of meaning. Implicit concepts may be present in elements of the data structure that are not supported by the CRM. As long as these concepts can be encoded as instances of E55 Type (i.e. as terminology) and attached unambiguously to their respective data items with suitable properties, the data structure is still regarded as export compatible.

 

Note that not all CRM concepts may be represented by elements of an export-compatible data structure. All data from export-compatible data structures can be transported in a CRM-compatible form. In particular any CRM compatible form or reduced CRM-compatible form is export-compatible with the CRM.

 

A data structure is import-compatible with the CRM if it is possible to automatically transform any data from a CRM-compatible form into this data structure without loss of meaning, simply on the basis of knowledge about the data structure elements being used. This implies that a data record transformed into this data structure from a CRM-compatible form can be transformed back into the CRM-compatible form without loss of meaning. Note that the back-transformation into a CRM-compatible form may result in a data record that is semantically equivalent but not identical with the original.

 

Any CRM-compatible form is automatically import-compatible with the CRM. Note that an import-compatible data structure may be semantically richer than the CRM. It may contain elements that, through the use of a transformation algorithm, can be made to correspond to CRM concepts or specializations thereof or that contain elements with meanings that fall outside the scope of the CRM. However, it must not contain elements that overlap in meaning with CRM concepts and which cannot be subsumed via transformation by a CRM concept other than E1 CRM Entity and E77 Persistent Item. 

 

Import-compatible data structures may be used to transport data for applications that require concepts that lie beyond the scope of the CRM, as well as data from any export-compatible data structure. Note that, in general, applications may make use of data from a CRM import-compatible data structure that has been exported into a CRM compatible form by semantic reduction to CRM concepts, i.e. by generalizing all subsumed concepts to the most specific CRM concept applicable, and by discarding elements that fall outside the scope of the CRM.

 

A data structure is partially import-compatible with the CRM if the above holds for a reduced CRM-compatible form.

 

CRM Compatibility of Information Systems

 

An information system is export-compatible with the CRM if it is possible to export all user data from this information system into an import-compatible data structure. This capability is the recommended kind of CRM-compatibility for local information systems.

 

An information system is partially export compatible if it is possible to export all user data from this information system into a partially import-compatible data structure. This is not the recommended kind of CRM-compatibility, but it may not be feasible for legacy systems to acquire a higher level of CRM compatibility without unreasonable effort. This reduced level of CRM compatibility is nonetheless highly useful.

 

Note that there is no minimum requirement for the classes and properties that must be present in the exported user data. Therefore it is possible that the data may pertain to instances of just a single property, such as E21 Person. P131 is identified by: E82 Actor Appellation.

 

An information system is import-compatible with the CRM if it is possible to import data encoded in a CRM-compatible form and to access the data in a manner equivalent to and homogeneous with all generic data of this system that fall under the same concepts. This capability is considered as the normal kind of CRM compatibility for integrated access systems that physically copy source data in a data warehouse style (materialized access systems).

 

An information system is partially import-compatible with the CRM if it is possible to import data encoded in a reduced CRM-compatible form and to access the data in a manner equivalent to and homogeneous with all generic data of this system that fall under the same concepts. Depending on the functional requirements, it makes sense for integrated access systems to offer access services of reduced complexity by being only partially import-compatible with the CRM.

 

Note that it makes sense for integrated access systems to import data from extended data structures by semantic reduction to CRM defined concepts.

 

Note that local information system providers may choose to make their systems import-compatible with the CRM in order to exchange data, for example in the case of museum object loans or for system migration purposes. Communities of practice may choose to agree on import compatibility for extended data structures.

 

Some local information systems are likely to focus on specialized subject areas, such as inscriptions. For these specialized systems, the ability to import a specific data structure is recommended. This should be export-compatible with the CRM, and encompass the concepts that are required by the subject matter (“dedicated import compatibility”).

 

An information system is access-compatible with the CRM if it is possible to access the user data in the information system by querying with CRM classes and properties so that the meaning of the answers to the queries corresponds to the query terms used. It is not regarded as a reduction of compatibility if access is limited to data deemed to be exchanged.

 

An information system is partially access-compatible with the CRM if it is possible to access the user data in the information system by querying with a consistent subset of CRM classes and properties, corresponding to a reduced CRM-compatible form, so that the meaning of the answers to the queries corresponds to the query terms used.

 

An access-compatible system may be export-compatible with respect to the query answers. Note that it may make sense for an access-compatible content management system to return only content items in response to queries rather than being export compatible.

 

 

fig. 1: Possible data flow between different kinds of CRM-compatible systems and data structures

 

Fig. 1 shows a symbolic representation of some of the data flow patterns defined above between different kinds of CRM-compatible systems and data structures. In this figure it is assumed that the Local System B exports data into a CRM export-compatible data structure, which implies that it can be exported into a CRM-compatible form or any other CRM import-compatible data structure. Therefore Local System B is export-compatible with the CRM. For Local System A, the figure symbolizes the case where the exported data contain elements that correspond to specializations of the CRM or fall out of its scope.

Compatibility claim declaration

 

A provider of a data structure or information system claiming compatibility with the CRM has to provide a declaration that describes the kind of compatibility and, depending on the kind, the following additional information: 

The subset of CRM concepts directly instantiated by any possible data in this data structure after transformation into a CRM-compatible form.

The subset of CRM concepts under which data can be imported into the system.

  1. The query language by which the system can be queried.
  2. The subset of CRM concepts directly instantiated by any possible query answers exported from the system after transformation into a CRM-compatible form.
  3. For partially access-compatible systems, the subset of CRM concepts by which the system can be queried.

 

The provider should be able to demonstrate the claim with suitable test data. The provider should be able to demonstrate its claim according to certain procedures included in any applicable certificate practice related statement.

The provider should either make evidence of these procedures publicly available on the Internet on a site nominated by the ISO community of use, so that any third party is able to verify the claim with suitable test data, or acquire a certificate by a certification authority (CA).

A trusted third party recognised and authorised by a competent regulatory authority to act as a CA in this practice area, should be able to verify the credentials of the provider applying for such certificate and thus, of its claim with suitable test data, before issuing the certificate so that the users can trust the information in the CA certificates.

The CA will grant the provider of the certified system the right to use the “CRM compatible” logo..

 

Applied Form

The CRM is an ontology in the sense used in computer science. It has been expressed as an object-oriented semantic model, in the hope that this formulation will be comprehensible to both documentation experts and information scientists alike, while at the same time being readily converted to machine-readable formats such as RDF Schema, KIF, DAML+OIL, OWL, STEP, etc. It can be implemented in any Relational or object-oriented schema. CRM instances can also be encoded in RDF, XML, DAML+OIL, OWL and others.

 

Although the definition of the CRM provided here is complete, it is an intentionally compact and concise presentation of the CRM’s 86 classes and 137 unique properties. It does not attempt to articulate the inheritance of properties by subclasses throughout the class hierarchy (this would require the declaration of several thousand properties, as opposed to 137). However, this definition does contain all of the information necessary to infer and automatically generate a full declaration of all properties, including inherited properties.

Terminology

The following definitions of key terminology used in this document are provided both as an aid to readers unfamiliar with object-oriented modelling terminology, and to specify the precise usage of terms that are sometimes applied inconsistently across the object oriented modelling community for the purpose of this document. Where applicable, the editors have tried to consistently use terminology that is compatible with that of the Resource Description Framework (RDF)[3], a recommendation of the World Wide Web Consortium. The editors have tried to find a language which is comprehensible to the non-computer expert and precise enough for the computer expert so that both understand the intended meaning.

 

Class

A class is a category of items that share one or more common traits serving as criteria to identify the items belonging to the class. These properties need not be explicitly formulated in logical terms, but may be described in a text (here called a scope note) that refers to a common conceptualisation of domain experts. The sum of these traits is called the intension of the class. A class may be the domain or range of none, one or more properties formally defined in a model. The formally defined properties need not be part of the intension of their domains or ranges: such properties are optional. An item that belongs to a class is called an instance of this class. A class is associated with an open set of real life instances, known as the extension of the class. Here “open” is used in the sense that it is generally beyond our capabilities to know all instances of a class in the world and indeed that the future may bring new instances about at any time (Open World). Therefore a class cannot be defined by enumerating its instances. A class plays a role analogous to a grammatical noun, and can be completely defined without reference to any other construct (unlike properties, which must have an unambiguously defined domain and range). In some contexts, the terms individual class, entity or node are used synonymously with class.

For example:

Person is a class. To be a Person may actually be determined by DNA characteristics, but we all know what a Person is. A Person may have the property of being a member of a Group, but it is not necessary to be member of a Group in order to be a Person. We shall never know all Persons of the past. There will be more Persons in the future.

 

subclass

A subclass is a class that is a specialization of another class (its superclass). Specialization or the IsA relationship means that:

  1. all instances of the subclass are also instances of its superclass,
  2. the intension of the subclass extends the intension of its superclass, i.e. its traits are more restrictive than that of its superclass and
  3. the subclass inherits the definition of all of the properties declared for its superclass without exceptions (strict inheritance), in addition to having none, one or more properties of its own.

 

A subclass can have more than one immediate superclass and consequently inherits the properties of all of its superclasses (multiple inheritance). The IsA relationship or specialization between two or more classes gives rise to a structure known as a class hierarchy. The IsA relationship is transitive and may not be cyclic. In some contexts (e.g. the programming language C++) the term derived class is used synonymously with subclass.

 

For example:

Every Person IsA Biological Object, or Person is a subclass of Biological Object.

Also, every Person IsA Actor. A Person may die. However other kinds of Actors, such as companies, don’t die (c.f. 2).

Every Biological Object IsA Physical Object. A Physical Object can be moved. Hence a Person can be moved also (c.f. 3).

 

superclass

A superclass is a class that is a generalization of one or more other classes (its subclasses), which means that it subsumes all instances of its subclasses, and that it can also have additional instances that do not belong to any of its subclasses. The intension of the superclass is less restrictive than any of its subclasses. This subsumption relationship or generalization is the inverse of the IsA relationship or specialization.

In some contexts (e.g. the programming language C++) the term parent class is used synonymously with superclass.

 

For example:

“Biological Object subsumes Person” is synonymous with “Biological Object is a superclass of Person”. It needs fewer traits to identify an item as a Biological Object than to identify it as a Person.

 

intension

The intension of a class or property is its intended meaning. It consists of one or more common traits shared by all instances of the class or property. These traits need not be explicitly formulated in logical terms, but may just be described in a text (here called a scope note) that refers to a conceptualisation common to domain experts. In particular the so-called primitive concepts, which make up most of the CRM, cannot be further reduced to other concepts by logical terms.

 

extension

The extension of a class is the set of all real life instances belonging to the class that fulfil the criteria of its intension. This set is “open” in the sense that it is generally beyond our capabilities to know all instances of a class in the world and indeed that the future may bring new instances about at any time (Open World). An information system may at any point in time refer to some instances of a class, which form a subset of its extension.

 

scope note

A scope note is a textual description of the intension of a class or property.

Scope notes are not formal modelling constructs, but are provided to help explain the intended meaning and application of the CRM’s classes and properties. Basically, they refer to a conceptualisation common to domain experts and disambiguate between different possible interpretations. Illustrative example instances of classes and properties are also regularly provided in the scope notes for explanatory purposes.

 

instance

An instance of a class is a real world item that fulfils the criteria of the intension of the class. Note, that the number of instances declared for a class in an information system is typically less than the total in the real world. For example, you are an instance of Person, but you are not mentioned in all information systems describing Persons.

For example:

The painting known as the “The Mona Lisa” is an instance of the class Man Made Object.

 

An instance of a property is a factual relation between an instance of the domain and an instance of the range of the property that matches the criteria of the intension of the property.

 

For example:

“The Louvre is current owner of The Mona Lisa” is an instance of the property “is current owner of”.

 

property

A property serves to define a relationship of a specific kind between two classes. The property is characterized by an intension, which is conveyed by a scope note. A property plays a role analogous to a grammatical verb, in that it must be defined with reference to both its domain and range, which are analogous to the subject and object in grammar (unlike classes, which can be defined independently). It is arbitrary, which class is selected as the domain, just as the choice between active and passive voice in grammar is arbitrary. In other words, a property can be interpreted in both directions, with two distinct, but related interpretations. Properties may themselves have properties that relate to other classes (This feature is used in this model only in order to describe dynamic subtyping of properties). Properties can also be specialized in the same manner as classes, resulting in IsA relationships between subproperties and their superproperties.

In some contexts, the terms attribute, reference, link, role or slot are used synonymously with property.

 

For example:

“Physical Man-Made Thing depicts CRM Entity” is equivalent to “CRM Entity is depicted by Physical Man-Made Thing”.

 

subproperty

 

A subproperty is a property that is a specialization of another property (its superproperty). Specialization or IsA relationship means that:

  1. all instances of the subproperty are also instances of its superproperty,
  2. the intension of the subproperty extends the intension of the superproperty, i.e. its traits are more restrictive than that of its superproperty,
  3. the domain of the subproperty is the same as the domain of its superproperty or a subclass of that domain,
  4. the range of the subproperty is the same as the range of its superproperty or a subclass of that range,
  5. the subproperty inherits the definition of all of the properties declared for its superproperty without exceptions (strict inheritance), in addition to having none, one or more properties of its own.

 

A subproperty can have more than one immediate superproperty and consequently inherits the properties of all of its superproperties (multiple inheritance). The IsA relationship or specialization between two or more properties gives rise to the structure we call a property hierarchy. The IsA relationship is transitive and may not be cyclic.

Some object-oriented programming languages, such as C++, do not contain constructs that allow for the expression of the specialization of properties as sub-properties

 

superproperty

 

A superproperty is a property that is a generalization of one or more other properties (its subproperties), which means that it subsumes all instances of its subproperties, and that it can also have additional instances that do not belong to any of its subproperties. The intension of the superproperty is less restrictive than any of its subproperties. The subsumption relationship or generalization is the inverse of the IsA relationship or specialization.

 

domain

The domain is the class for which a property is formally defined. This means that instances of the property are applicable to instances of its domain class. A property must have exactly one domain, although the domain class may always contain instances for which the property is not instantiated. The domain class is analogous to the grammatical subject of the phrase for which the property is analogous to the verb. It is arbitrary, which class is selected as the domain and which as the range, just as the choice between active and passive voice in grammar is arbitrary. Property names in the CRM are designed to be semantically meaningful and grammatically correct when read from domain to range. In addition, the inverse property name, normally given in parentheses, is also designed to be semantically meaningful and grammatically correct when read from range to domain.

range

The range is the class that comprises all potential values of a property. That means that instances of the property can link only to instances of its range class. A property must have exactly one range, although the range class may always contain instances that are not the value of the property. The range class is analogous to the grammatical object of a phrase for which the property is analogous to the verb. It is arbitrary, which class is selected as domain and which as range, just as the choice between active and passive voice in grammar is arbitrary. Property names in the CRM are designed to be semantically meaningful and grammatically correct when read from domain to range. In addition the inverse property name, normally given in parentheses, is also designed to be semantically meaningful and grammatically correct when read from range to domain.

 

inheritance

Inheritance of properties from superclasses to subclasses means that if an item x is an instance of a class A, then

  1. all properties that must hold for the instances of any of the superclasses of A must also hold for item x, and

all optional properties that may hold for the instances of any of the superclasses of A may also hold for item x.

 

strict

inheritance

Strict inheritance means that there are no exceptions to the inheritance of properties from superclasses to subclasses. For instance, some systems may declare that elephants are grey, and regard a white elephant as an exception. Under strict inheritance it would hold that: if all elephants were grey, then a white elephant could not be an elephant. Obviously not all elephants are grey. To be grey is not part of the intension of the concept elephant but an optional property. The CRM applies strict inheritance as a normalization principle.

 

multiple

inheritance

Multiple inheritance means that a class A may have more than one immediate superclass. The extension of a class with multiple immediate superclasses is a subset of the intersection of all extensions of its superclasses. The intension of a class with multiple immediate superclasses extends the intensions of all its superclasses, i.e. its traits are more restrictive than any of its superclasses. If multiple inheritance is used, the resulting “class hierarchy” is a directed graph and not a tree structure. If it is represented as an indented list, there are necessarily repetitions of the same class at different positions in the list.

For example, Person is both, an Actor and a Biological Object.

 

endurant, perdurant

“The difference between enduring and perduring entities (which we shall also call endurants and perdurants) is related to their behaviour in time. Endurants are wholly present (i.e., all their proper parts are present) at any time they are present. Perdurants, on the other hand, just extend in time by accumulating different temporal parts, so that, at any time they are present, they are only partially present, in the sense that some of their proper temporal parts (e.g., their previous or future phases) may be not present. E.g., the piece of paper you are reading now is wholly present, while some temporal parts of your reading are not present any more. Philosophers say that endurants are entities that are in time, while lacking however temporal parts (so to speak, all their parts flow with them in time). Perdurants, on the other hand, are entities that happen in time, and can have temporal parts (all their parts are fixed in time).” (Gangemi et al. 2002, pp. 166-181).

 

shortcut

A shortcut is a formally defined single property that represents a deduction or join of a data path in the CRM. The scope notes of all properties characterized as shortcuts describe in words the equivalent deduction. Shortcuts are introduced for the cases where common documentation practice refers only to the deduction rather than to the fully developed path. For example, museums often only record the dimension of an object without documenting the Measurement that observed it. The CRM declares shortcuts explicitly as single properties in order to allow the user to describe cases in which he has less detailed knowledge than the full data path would need to be described. For each shortcut, the CRM contains in its schema the properties of the full data path explaining the shortcut.

monotonic

reasoning

Monotonic reasoning is a term from knowledge representation. A reasoning form is monotonic if an addition to the set of propositions making up the knowledge base never determines a decrement in the set of conclusions that may be derived from the knowledge base via inference rules. In practical terms, if experts enter subsequently correct statements to an information system, the system should not regard any results from those statements as invalid, when a new one is entered. The CRM is designed for monotonic reasoning and so enables conflict-free merging of huge stores of knowledge.

 

disjoint

Classes are disjoint if the intersection of their extensions is an empty set. In other words, they have no common instances in any possible world.

 

primitive

The term primitive as used in knowledge representation characterizes a concept that is declared and its meaning is agreed upon, but that is not defined by a logical deduction from other concepts. For example, mother may be described as a female human with child. Then mother is not a primitive concept. Event however is a primitive concept.

Most of the CRM is made up of primitive concepts.

 

Open World

The “Open World Assumption” is a term from knowledge base systems. It characterizes knowledge base systems that assume the information stored is incomplete relative to the universe of discourse they intend to describe. This incompleteness may be due to the inability of the maintainer to provide sufficient information or due to more fundamental problems of cognition in the system’s domain. Such problems are characteristic of cultural information systems. Our records about the past are necessarily incomplete. In addition, there may be items that cannot be clearly assigned to a given class.

In particular, absence of a certain property for an item described in the system does not mean that this item does not have this property. For example, if one item is described as Biological Object and another as Physical Object, this does not imply that the latter may not be a Biological Object as well. Therefore complements of a class with respect to a superclass cannot be concluded in general from an information system using the Open World Assumption. For example, one cannot list “all Physical Objects known to the system that are not Biological Objects in the real world”, but one may of course list “all items known to the system as Physical Objects but that are not known to the system as Biological Objects”.

 

complement

The complement of a class A with respect to one of its superclasses B is the set of all instances of B that are not instances of A. Formally, it is the set-theoretic difference of the extension of B minus the extension of A. Compatible extensions of the CRM should not declare any class with the intension of them being the complement of one or more other classes. To do so will normally violate the desire to describe an Open World. For example, for all possible cases of human gender, male should not be declared as the complement of female or vice versa. What if someone is both or even of another kind?

 

query containment

Query containment is a problem from database theory: A query X contains another query Y, if for each possible population of a database the answer set to query X contains also the answer set to query Y. If query X and Y were classes, then X would be superclass of Y.

 

interoperability

Interoperability means the capability of different information systems to communicate some of their contents. In particular, it may mean that

  1. two systems can exchange information, and/or
  2. multiple systems can be accessed with a single method.

 

Generally, syntactic interoperability is distinguished from semantic interoperability. Syntactic interoperability means that the information encoding of the involved systems and the access protocols are compatible, so that information can be processed as described above without error. However, this does not mean that each system processes the data in a manner consistent with the intended meaning. For example, one system may use a table called “Actor” and another one called “Agent”. With syntactic interoperability, data from both tables may only be retrieved as distinct, even though they may have exactly the same meaning. To overcome this situation, semantic interoperability has to be added. The CRM relies on existing syntactic interoperability and is concerned only with adding semantic interoperability.

 

semantic interoperability

Semantic interoperability means the capability of different information systems to communicate information consistent with the intended meaning. In more detail, the intended meaning encompasses

  1. the data structure elements involved,
  2. the terminology appearing as data and
  3. the identifiers used in the data for factual items such as places, people, objects etc.

 

Obviously communication about data structure must be resolved first. In this case consistent communication means that data can be transferred between data structure elements with the same intended meaning or that data from elements with the same intended meaning can be merged. In practice, the different levels of generalization in different systems do not allow the achievement of this ideal. Therefore semantic interoperability is regarded as achieved if elements can be found that provide a reasonably close generalization for the transfer or merge. This problem is being studied theoretically as the query containment problem. The CRM is only concerned with semantic interoperability on the level of data structure elements.

 

property quantifiers

We use the term "property quantifiers" for the declaration of the allowed number of instances of a certain property that can refer to a particular instance of the range class or the domain class of that property. These declarations are ontological, i.e. they refer to the nature of the real world described and not to our current knowledge. For example, each person has exactly one father, but collected knowledge may refer to none, one or many.

universal

The fundamental ontological distinction between universals and particulars can be informally understood by considering their relationship with instantiation: particulars are entities that have no instances in any possible world; universals are entities that do have instances. Classes and properties (corresponding to predicates in a logical language) are usually considered to be universals. (after Gangemi et al. 2002, pp. 166-181).

 

Property Quantifiers

Quantifiers for properties are provided for the purpose of semantic clarification only, and should not be treated as implementation recommendations. The CRM has been designed to accommodate alternative opinions and incomplete information, and therefore all properties should be implemented as optional and repeatable for their domain and range (“many to many (0,n:0,n)”). Therefore the term “cardinality constraints” is avoided here, as it typically pertains to implementations.

 

The following table lists all possible property quantifiers occurring in this document by their notation, together with an explanation in plain words. In order to provide optimal clarity, two widely accepted notations are used redundantly in this document, a verbal and a numeric one. The verbal notation uses phrases such as “one to many”, and the numeric one, expressions such as “(0,n:0,1)”. While the terms “one”, “many” and “necessary” are quite intuitive, the term “dependent” denotes a situation where a range instance cannot exist without an instance of the respective property. In other words, the property is “necessary” for its range.

 

many to many (0,n:0,n)

Unconstrained: An individual domain instance and range instance of this property can have zero, one or more instances of this property. In other words, this property is optional and repeatable for its domain and range.

 

one to many

(0,n:0,1)

An individual domain instance of this property can have zero, one or more instances of this property, but an individual range instance cannot be referenced by more than one instance of this property. In other words, this property is optional for its domain and range, but repeatable for its domain only. In some contexts this situation is called a “fan-out”.

 

many to one

(0,1:0,n)

An individual domain instance of this property can have zero or one instance of this property, but an individual range instance can be referenced by zero, one or more instances of this property. In other words, this property is optional for its domain and range, but repeatable for its range only. In some contexts this situation is called a “fan-in”.

 

many to many, necessary (1,n:0,n)

An individual domain instance of this property can have one or more instances of this property, but an individual range instance can have zero, one or more instances of this property. In other words, this property is necessary and repeatable for its domain, and optional and repeatable for its range.

 

one to many, necessary

(1,n:0,1)

 

An individual domain instance of this property can have one or more instances of this property, but an individual range instance cannot be referenced by more than one instance of this property. In other words, this property is necessary and repeatable for its domain, and optional but not repeatable for its range. In some contexts this situation is called a “fan-out”.

 

many to one, necessary

(1,1:0,n)

An individual domain instance of this property must have exactly one instance of this property, but an individual range instance can be referenced by zero, one or more instances of this property. In other words, this property is necessary and not repeatable for its domain, and optional and repeatable for its range. In some contexts this situation is called a “fan-in”.

 

one to many, dependent

(0,n:1,1)

 

An individual domain instance of this property can have zero, one or more instances of this property, but an individual range instance must be referenced by exactly one instance of this property. In other words, this property is optional and repeatable for its domain, but necessary and not repeatable for its range. In some contexts this situation is called a “fan-out”.

 

one to many, necessary, dependent

(1,n:1,1)

An individual domain instance of this property can have one or more instances of this property, but an individual range instance must be referenced by exactly one instance of this property. In other words, this property is necessary and repeatable for its domain, and necessary but not repeatable for its range. In some contexts this situation is called a “fan-out”.

 

many to one, necessary, dependent

(1,1:1,n)

An individual domain instance of this property must have exactly one instance of this property, but an individual range instance can be referenced by one or more instances of this property. In other words, this property is necessary and not repeatable for its domain, and necessary and repeatable for its range. In some contexts this situation is called a “fan-in”.

 

one to one

(1,1:1,1)

An individual domain instance and range instance of this property must have exactly one instance of this property. In other words, this property is necessary and not repeatable for its domain and for its range.

 

The CRM defines some dependencies between properties and the classes that are their domains or ranges. These can be one or both of the following:

A) the property is necessary for the domain

B) the property is necessary for the range, or, in other words, the range is dependent on the property.

The possible kinds of dependencies are defined in the table above. Note that if a dependent property is not specified for an instance of the respective domain or range, it means that the property exists, but the value on one side of the property is unknown. In the case of optional properties, the methodology proposed by the CRM does not distinguish between a value being unknown or the property not being applicable at all. For example, one may know that an object has an owner, but the owner is unknown. In a CRM instance this case cannot be distinguished from the fact that the object has no owner at all. Of course, such details can always be specified by a textual note.

Naming Conventions

The following naming conventions have been applied throughout the CRM:

 

 

Modelling principles

 

The following modelling principles have guided and informed the development of the CIDOC CRM.

Monotonicity

Because the CRM’s primary role is the meaningful integration of information in an Open World, it aims to be monotonic in the sense of Domain Theory. That is, the existing CRM constructs and the deductions made from them must always remain valid and well-formed, even as new constructs are added by extensions to the CRM.

 

For example:

One may add a subclass of E7 Activity to describe the practice of an instance of group to use a certain name for a place over a certain time-span. By this extension, no existing IsA Relationships or property inheritances are compromised.

 

In addition, the CRM aims to enable the formal preservation of monotonicity when augmenting a particular CRM compatible system. That is, existing CRM instances, their properties and deductions made from them, should always remain valid and well-formed, even as new instances, regarded as consistent by the domain expert, are added to the system.

 

For example:

If someone describes correctly that an item is an instance of E19 Physical Object, and later it is correctly characterized as an instance of E20 Biological Object, the system should not stop treating it as an instance of E19 Physical Object.

 

In order to formally preserve monotonicity for the frequent cases of alternative opinions, all formally defined properties should be implemented as unconstrained (many: many) so that conflicting instances of properties are merely accumulated. Thus knowledge integrated following the CRM serves as a research base, accumulating relevant alternative opinions around well-defined entities, whereas conclusions about the truth are the task of open-ended scientific or scholarly hypothesis building.

 

For example:

El Greco and even King Arthur should always remain an instance of E21 Person and be dealt with as existing within the sense of our discourse, once they are entered into our knowledge base. Alternative opinions about properties, such as their birthplaces and their living places, should be accumulated without validity decisions being made during data compilation.

Minimality

Although the scope of the CRM is very broad, the model itself is constructed as economically as possible.

 

Shortcuts

Some properties are declared as shortcuts of longer, more comprehensively articulated paths that connect the same domain and range classes as the shortcut property via one or more intermediate classes. For example, the property E18 Physical Thing. P52 has current owner (is current owner of): E39 Actor, is a shortcut for a fully articulated path from E18 Physical Thing through E8 Acquisition to E39 Actor. An instance of the fully-articulated path always implies an instance of the shortcut property. However, the inverse may not be true; an instance of the fully-articulated path cannot always be inferred from an instance of the shortcut property.

 

The class E13 Attribute Assignment allows for the documentation of how the assignment of any property came about, and whose opinion it was, even in cases of properties not explicitly characterized as “shortcuts”.

Disjointness

Classes are disjoint if they share no common instances in any possible world. There are many examples of disjoint classes in the CRM.

A comprehensive declaration of all possible disjoint class combinations afforded by the CRM has not been provided here; it would be of questionable practical utility, and may easily become inconsistent with the goal of providing a concise definition. However, there are two key examples of disjoint class pairs that are fundamental to effective comprehension of the CRM:

 

About Types

Virtually all structured descriptions of museum objects begin with a unique object identifier and information about the "type" of the object, often in a set of fields with names like "Classification", "Category", "Object Type", "Object Name", etc. All these fields are used for terms that declare that the object belongs to a particular category of items. In the CRM the class E55 Type comprises such terms from thesauri and controlled vocabularies used to characterize and classify instances of CRM classes.  Instances of E55 Type represent concepts (universals) in contrast to instances of E41 Appellation which are used to name instances of CRM classes.

 

E55 Type is the CRM’s interface to domain specific ontologies and thesauri. These can be represented in the CRM as subclasses of E55 Type, forming hierarchies of terms, i.e. instances of E55 Type linked via P127 has broader term (has narrower term). Such hierarchies may be extended with additional properties.

 

For this purpose the CRM provides two basic properties that describe classification with terminology, corresponding to what is the current practice in the majority of information systems. The class E1 CRM Entity is the domain of the property P2 has type (is type of), which has the range E55 Type. Consequently, every class in the CRM, with the exception of E59 Primitive Value, inherits the property P2 has type (is type of).  This provides a general mechanism for simulating a specialization of the classification of CRM instances to any level of detail, by linking to external vocabulary sources, thesauri, classification schema or ontologies.

 

Analogous to the function of the P2 has type (is type of) property, some properties in the CRM are associated with an additional property. These are numbered in the CRM documentation with a ‘.1’ extension. The range of these properties of properties always falls under E55 Type. Their purpose is to simulate a specialization of their parent property through the use of property subtypes declared as instances of E55 Type. They do not appear in the property hierarchy list but are included as part of the property declarations and referred to in the class declarations. For example, P62.1 mode of depiction: E55 Type is associated with E24 Physical Man-made Thing. P62 depicts (is depicted by): E1 CRM Entity.

 

The class E55 Type also serves as the range of properties that relate to categorical knowledge commonly found in cultural documentation. For example, the property P125 used object of type (was type of object used in) enables the CRM to express statements such as “this casting was produced using a mould”, meaning that there has been an unknown or unmentioned object, a mould, that was actually used. This enables the specific instance of the casting to be associated with the entire type of manufacturing devices known as moulds. Further, the objects of type “mould” would be related via P2 has type (is type of) to this term. This indirect relationship may actually help in detecting the unknown object in an integrated environment. On the other side, some casting may refer directly to a known mould via P16 used specific object (was used for).  So a statistical question to how many objects in a certain collection are made with moulds could be answered correctly (following both paths through P16 used specific object (was used for) - P2 has type (is type of) and P125 used object of type (was type of object used in). This consistent treatment of categorical knowledge enhances the CRM’s ability to integrate cultural knowledge.

 

In addition to being an interface to external thesauri and classification systems E55 Type is an ordinary class in the CRM and a subclass of E28 Conceptual Object. E55 Type and its subclasses inherit all properties from this superclass.  Thus together with the CRM class E83 Type Creation the rigorous scholarly or scientific process that ensures a type is exhaustively described and appropriately named can be modelled inside the CRM. In some cases, particularly in archaeology and the life sciences, E83 Type Creation requires the identification of an exemplary specimen and the publication of the type definition in an appropriate scholarly forum. This is very central to research in the life sciences, where a type would be referred to as a “taxon,” the type description as a “protologue,” and the exemplary specimens as “original element” or “holotype”.

 

Finally, types, that is, instances of E55 Type and its subclasses, are used to characterize the instances of a CRM class and hence refine the meaning of the class.  A type ‘artist’ can be used to characterize persons through P2 has type (is type of). On the other hand, in an art history application of the CRM it can be adequate to extend the CRM class E21 Person with a subclass E21.xx Artist. What is the difference of the type ‘artist’ and the class Artist? From an everyday conceptual point of view there is no difference. Both denote the concept ‘artist’ and identify the same set of persons. Thus in this setting a type could be seen as a class and the class of types may be seen as a metaclass.  Since current systems do not provide an adequate control of user defined metaclasses, the CRM prefers to model instances of E55 Type as if they were particulars, with the relationships described in the previous paragraphs.

 

Users may decide to implement a concept either as a subclass extending the CRM class system or as an instance of E55 Type. A new subclass should only be created in case the concept is sufficiently stable and associated with additional explicitly modelled properties specific to it. Otherwise, an instance of E55 Type provides more flexibility of use. Users that may want to describe a discourse not only using a concept extending the CRM but also describing the history of this concept itself, may chose to model the same concept both as subclass and as an instance of E55 Type with the same name. Similarly it should be regarded as good practice to foresee for each term hierarchy refining a CRM class a term equivalent of this class as top term. For instance, a term hierarchy for instances of E21 Person may begin with “Person”.

 

Extensions

Since the intended scope of the CRM is a subset of the “real” world and is therefore potentially infinite, the model has been designed to be extensible through the linkage of compatible external type hierarchies.

Compatibility of extensions with the CRM means that data structured according to an extension must also remain valid as a CRM instance. In practical terms, this implies query containment: any queries based on CRM concepts should retrieve a result set that is correct according to the CRM’s semantics, regardless of whether the knowledge base is structured according to the CRM’s semantics alone, or according to the CRM plus compatible extensions. For example, a query such as “list all events” should recall 100% of the instances deemed to be events by the CRM, regardless of how they are classified by the extension.

 

A sufficient condition for the compatibility of an extension with the CRM is that CRM classes subsume all classes of the extension, and all properties of the extension are either subsumed by CRM properties, or are part of a path for which a CRM property is a shortcut. Obviously, such a condition can only be tested intellectually.

Coverage

Of necessity, some concepts covered by the CRM are less thoroughly elaborated than others: E39 Actor and E30 Right, for example. This is a natural consequence of staying within the CRM’s clearly articulated practical scope in an intrinsically unlimited domain of discourse. These ‘underdeveloped’ concepts can be considered as hooks for compatible extensions.

 

The CRM provides a number of mechanisms to ensure that coverage of the intended scope is complete:

  1. Existing high level classes can be extended, either structurally as subclasses or dynamically using the type hierarchy.
  2. Existing high level properties can be extended, either structurally as subproperties, or in some cases, dynamically, using properties of properties which allow subtyping.
  3. Additional information that falls outside the semantics formally defined by the CRM can be recorded as unstructured data using E1 CRM Entity. P3 has note: E62 String.

 

In mechanisms 1 and 2 the CRM concepts subsume and thereby cover the extensions.

 

In mechanism 3, the information is accessible at the appropriate point in the respective knowledge base. This approach is preferable when detailed, targeted queries are not expected; in general, only those concepts used for formal querying need to be explicitly modelled.

 

Examples

fig. 2 reasoning about spatial information

 

The diagram above shows a partial view of the CRM, representing reasoning about spatial information. Five of the main hierarchy branches are included in this view: E39 Actor, E51 Contact Point, E41 Appellation, E53 Place and E70 Thing. All classes are shown as blue-white rectangles. Properties are shown as single arrows. In some cases the order of priority for property names has been reversed in order to facilitate reading the diagram from left to right. Double arrows indicate IsA relations between classes and their subclasses or between properties and their subproperties. 'Shortcuts' are indicated with light grey rectangles and their names are written in italics, such as the P59 has section (is located on or within) between E53 Place and E18 Physical Thing, which is a shortcut of the path through E46 Section Definition. .

 

As can be seen, an instance of E53 Place is identified by an instance of E44 Place Appellation, which may be an instance of E45 Address, E47 Spatial Coordinates, E48 Place Name, or E46 Section Definition such as ‘basement’, ‘prow’, or ‘lower left-hand corner.’ An instance of E53 Place may consist of or form part of another instance of E53 Place, thereby allowing a hierarchy of geometric ‘containers’ to be constructed.

 

An instance of E45 Address can be considered both as an E44 Place Appellation–a way of referring to an E53 Place–and as an E51 Contact Point for an E39 Actor. An E39 Actor may have any number of instances of E51 Contact Point. E18 Physical Thing is found on locations as a consequence of being created there or being moved there. Therefore the properties P53 has former or current location (is former or current location of) (and P55 has current location (currently holds) are regarded as shortcuts of the fully articulated paths through the respective events. P55 has current location (currently holds) is a subproperty of P53 has former or current location (is former or current location of). The latter is a container for location information in the absence of knowledge about time of validity and related events.

 

An interesting aspect of the model is the P58 has section definition (defines section) property between E46 Section Definition and E18 Physical Thing (and the corresponding shortcut from E53 Place to E19 Physical Object). This allows an instance of E53 Place to be defined as a section of an instance of E19 Physical Object. For example, we may know that Nelson fell at a particular spot on the deck of H.M.S. Victory, without knowing the exact position of the vessel in geospatial terms at the time of the fatal shooting of Nelson. Similarly, a signature or inscription can be located “in the lower right corner of” a painting, regardless of where the painting is hanging.

 

fig. 3 reasoning about temporal information

 

This second example shows how the CRM handles reasoning about temporal information. Four of the main hierarchy branches are included in this view: E2 Temporal Entity, E52 Time-Span, E77 Persistent Item and E53 Place.

 

The E2 Temporal Entity class is an abstract class (i.e. it has no direct instances) that serves to group together all classes with a temporal component, such as instances of E4 Period, E5 Event and E3 Condition State.

 

An instance of E52 Time-Span is simply a temporal interval that does not make any reference to cultural or geographical contexts (unlike instances of E4 Period, which took place at a particular instance of E53 Place). Instances of E52 Time-Span are sometimes identified by instances of E49 Time Appellation, often in the form of E50 Date.

 

Both E52 Time-Span and E4 Period have transitive properties. E52 Time-Span has the transitive property P86 falls within (contains), denoting a purely incidental inclusion; whereas E4 Period has the transitive property P9 consists of (forms part of) that supports the decomposition of instances of E4 Period into their constituent parts. For example, the E52 Time-Span during which a building is constructed might falls within the E52 Time-Span of a particular government, although there is no causal or contextual connection between the two instances of E52 Time-Span; conversely, the E4 Period of the Chinese Song Dynasty consists of the Northern Song Period and the Southern Song Period.

 

Instances of E52 Time-Span are related to their outer bounds (i.e. their indeterminacy interval) by the property P82 at some time within, and to their inner bounds via the property P81 ongoing throughout. The range of these properties is the E61 Time Primitive class, instances of which are treated by the CRM as application or system specific date intervals that are not further analysed.

Class & Property Hierarchies

Although they do not provide comprehensive definitions, compact monohierarchical presentations of the class and property IsA hierarchies have been found to significantly aid comprehension and navigation of the CRM, and are therefore provided below.

 

The class hierarchy presented below has the following format:

 

The property hierarchy presented below has the following format:

 


CIDOC CRM Class Hierarchy

 

E1

CRM Entity

E2

-

Temporal Entity

E3

-

-

Condition State 

E4

-

-

Period

E5

-

-

-

Event

E7

-

-

-

-

Activity

E8

-

-

-

-

-

Acquisition Event

E9

-

-

-

-

-

Move

E10

-

-

-

-

-

Transfer of Custody

E11

-

-

-

-

-

Modification

E12

-

-

-

-

-

-

Production

E79

-

-

-

-

-

-

Part Addition

E80

-

-

-

-

-

-

Part Removal

E13

-

-

-

-

-

Attribute Assignment

E14

-

-

-

-

-

-

Condition Assessment

E15

-

-

-

-

-

-

Identifier Assignment

E16

-

-

-

-

-

-

Measurement

E17

-

-

-

-

-

-

Type Assignment

E65

-

-

-

-

-

Creation

E83

-

-

-

-

-

-

Type Creation

E66

-

-

-

-

-

Formation

E85

-

-

-

-

-

Joining

E86

-

-

-

-

-

Leaving

E87

-

-

-

-

-

Curation Activity

E63

-

-

-

-

Beginning of Existence

E67

-

-

-

-

-

Birth

E81

-

-

-

-

-

Transformation

E12

-

-

-

-

-

Production

E65

-

-

-

-

-

Creation

E83

-

-

-

-

-

-

Type Creation

E66

-

-

-

-

-

Formation

E64

-

-

-

-

End of Existence

E6

-

-

-

-

-

Destruction

E68

-

-

-

-

-

Dissolution

E69

-

-

-

-

-

Death

E81

-

-

-

-

-

Transformation

E77

-

Persistent Item

E70

-

-

Thing

E72

-

-

-

Legal Object

E18

-

-

-

-

Physical Thing

E19

-

-

-

-

-

Physical Object

E20

-

-

-

-

-

-

Biological Object

E21

-

-

-

-

-

-

-

Person

E22

-

-

-

-

-

-

Man-Made Object

E84

-

-

-

-

-

-

-

Information Carrier

E24

-

-

-

-

-

Physical Man-Made Thing

E22

-

-

-

-

-

-

Man-Made Object

E84

-

-

-

-

-

-

-

Information Carrier

E25

-

-

-

-

-

-

Man-Made Feature

E78

-

-

-

-

-

-

Collection

E26

-

-

-

-

-

Physical Feature

E27

-

-

-

-

-

-

Site

E25

-

-

-

-

-

-

Man-Made Feature

E90

-

-

-

-

Symbolic Object

E73

-

-

-

-

-

Information Object

E29

-

-

-

-

-

 

Design or Procedure

E31

-

-

-

-

-

 

Document

E32

-

-

-

-

-

-

-

Authority Document

E33

-

-

-

-

-

-

Linguistic Object

E34

-

-

-

-

-

-

-

Inscription

E35

-

-

-

-

-

-

-

Title

E36

-

-

-

-

-

 

Visual Item

E37

-

-

-

-

-

-

-

Mark

E34

-

-

-

-

-

-

-

-

Inscription

E38

-

-

-

-

-

-

-

Image

E41

-

-

-

-

-

Appellation

E42

-

-

-

-

-

-

Identifier

E44

-

-

-

-

-

-

Place Appellation

E45

-

-

-

-

-

-

-

Address

E46

-

-

-

-

-

-

-

Section Definition

E47

-

-

-

-

-

-

-

Spatial Coordinates

E48

-

-

-

-

-

-

-

Place Name

E49

-

-

-

-

-

-

Time Appellation

E50

-

-

-

-

-

-

-

Date

E75

-

-

-

-

-

-

Conceptual Object Appellation

E82

-

-

-

-

-

-

Actor Appellation

E51

-

-

-

-

-

-

Contact Point

E45

-

-

-

-

-

-

-

Address

E35

-

-

-

-

-

-

Title

E71

-

-

-

Man-Made Thing

E24

-

-

-

-

Physical Man-Made Thing

E22

-

-

-

-

-

Man-Made Object

E84

-

-

-

-

-

-

Information Carrier

E25

-

-

-

-

-

Man-Made Feature

E78

-

-

-

-

-

Collection

E28

-

-

-

-

Conceptual Object

E90

-

-

-

-

-

Symbolic Object

E73

-

-

-

-

-

-

Information Object

E29

-

-

-

-

-

-

-

Design or Procedure

E31

-

-

-

-

-

-

-

Document

E32

-

-

-

-

-

-

-

-

Authority Document

E33

-

-

-

-

-

-

 

Linguistic Object

E34

-

-

-

-

-

-

-

-

Inscription

E35

-

-

-

-

-

-

 

-

Title

E36

-

-

-

-

-

-

-

-

Visual Item

E37

-

-

-

-

-

-

-

-

Mark

E34

-

-

-

-

-

-

-

-

-

Inscription

E38

-

-

-

-

-

-

-

-

Image

E41

-

-

-

-

-

-

Appellation

E42

-

-

-

-

-

-

-

Identifier

E44

-

-

-

-

-

-

-

Place Appellation

E45

-

-

-

-

-

-

-

-

Address

E46

-

-

-

-

-

-

-

-

Section Definition

E47

-

-

-

-

-

-

-

-

Spatial Coordinates

E48

-

-

-

-

-

-

-

-

Place Name

E49

-

-

-

-

-

 

-

Time Appellation

E50

-

-

-

-

-

-

-

-

Date

E75

-

-

-

-

-

-

-

Conceptual Object Appellation

E82

-

-

-

-

-

-

-

Actor Appellation

E51

-

-

-

-

-

-

-

Contact Point

E45

-

-

-

-

-

-

-

-

Address

E35

-

-

-

-

 

 

-

Title

E89

-

-

-

-

-

Propositional Object

E73

-

-

-

-

-

-

Information Object

E29

-

-

-

-

-

-

-

Design or Procedure

E31

-

-

-

-

-

-

-

Document

E32

-

-

-

-

-

-

-

-

Authority Document

E33

-

-

-

-

-

-

-

Linguistic Object

E34

-

-

-

-

-

-

-

-

Inscription

E35

-

-

-

-

-

-

-

-

Title

E36

-

-

-

-

-

-

-

Visual Item

E37

-

-

-

-

-

-

-

-

Mark

E34

-

-

-

-

-

-

-

-

 

Inscription

E38

-

-

-

-

-

-

-

-

Image

E30

-

-

-

-

-

-

Right

E55

-

-

-

-

-

Type

E56

-

-

-

-

-

-

Language

E57

-

-

-

-

-

-

Material

E58

-

-

-

-

-

-

Measurement Unit

E39

-

-

Actor

E74

-

-

-

Group

E40

-

-

-

-

Legal Body

E21

-

-

-

Person

E52

-

Time-Span

E53

-

Place

E54

-

Dimension

E59

Primitive Value

E60

-

Number

E61

-

Time Primitive

E62

-

String


CIDOC CRM Property Hierarchy:

 

Property id
Property Name

Entity – Domain

Entity - Range

P1

is identified by (identifies)

E1 CRM Entity

E41 Appellation

P48

   -   has preferred identifier (is preferred identifier of)

E1 CRM Entity

E42 Identifier

P78

   -   is identified by (identifies)

E52 Time-Span

E49 Time Appellation

P87

   -   is identified by (identifies)

E53 Place

E44 Place Appellation

P102

   -   has title (is title of)

E71 Man-Made Thing

E35 Title

P131

   -   is identified by (identifies)

E39 Actor

E82 Actor Appellation

P149

   -   is identified by (identifies)

E28 Conceptual Object

E75 Conceptual Object Appellation

P2

has type (is type of)

E1 CRM Entity

E55 Type

P137

   -   exemplifies (is exemplified by)

E1 CRM Entity

E55 Type

P3

has note

E1 CRM Entity

E62 String

P79

   -   beginning is qualified by

E52 Time-Span

E62 String

P80

   -   end is qualified by

E52 Time-Span

E62 String

P4

has time-span (is time-span of)

E2 Temporal Entity

E52 Time-Span

P5

consists of (forms part of)

E3 Condition State

E3 Condition State

P7

took place at (witnessed)

E4 Period

E53 Place

P26

   -   moved to (was destination of)

E9 Move

E53 Place

P27

   -   moved from (was origin of)

E9 Move

E53 Place

P8

took place on or within (witnessed)

E4 Period

E19 Physical Object

P9

consists of (forms part of)

E4 Period

E4 Period

P10

falls within (contains)

E4 Period

E4 Period

P12

occurred in the presence of (was present at)

E5 Event

E77 Persistent Item

P111

   -   added (was added by)

E79 Part Addition

E18 Physical Thing

P113

   -   removed (was removed by)

E80 Part Removal

E18 Physical Thing

P11

   -   had participant (participated in)

E5 Event

E39 Actor

P14

   -   -   carried out by (performed)

E7 Activity

E39 Actor

P22

   -   -   -   transferred title to (acquired title through)

E8 Acquisition

E39 Actor

P23

   -   -   -   transferred title from (surrendered title through)

E8 Acquisition

E39 Actor

P28

   -   -   -   custody surrendered by (surrendered custody through)

E10 Transfer of Custody

E39 Actor

P29

   -   -   -   custody received by (received custody through)

E10 Transfer of Custody

E39 Actor

P96

   -   -   by mother (gave birth)

E67 Birth

E21 Person

P99

   -   -   dissolved (was dissolved by)

E68 Dissolution

E74 Group

P143

   -   -   joined (was joined by)

E85 Joining

E39 Actor

P144

   -   -   joined with (gained member by)

E85 Joining

E74 Group

P145

   -   -   separated (left by)

E86 Leaving

E39 Actor

P146

   -   -   separated from (lost member by)

E86 Leaving

E74 Group

P16

   -   used specific object (was used for)

E7 Activity

E70 Thing

P33

   -   -   used specific technique (was used by)

E7 Activity

E29 Design or Procedure

P111

   -   -   added (was added by)

E79 Part Addition

E18 Physical Thing

P142

   -   -   used constituent (was used in)

E15 Identifier Assignment

E41 Appellation

P25

   -   moved (moved by)

E9 Move

E19 Physical Object

P31

   -   has modified (was modified by)

E11 Modification

E24 Physical Man-Made Thing

P108

   -  -    has produced (was produced by)

E12 Production

E24 Physical Man-Made Thing

P110

   -   -   augmented (was augmented by)

E79 Part Addition

E24 Physical Man-Made Thing

P112

   -   -   diminished (was diminished by)

E80 Part Removal

E24 Physical Man-Made Thing

P92

   -   brought into existence (was brought into existence by)

E63 Beginning of Existence

E77 Persistent Item

P94

   -   -   has created (was created by)

E65 Creation

E28 Conceptual Object

P135

   -   -   -   created type (was created by)

E83 Type Creation

E55 Type

P95

   -   -   has formed (was formed by)

E66 Formation

E74 Group

P98

   -   -   brought into life (was born)

E67 Birth

E21 Person

P108

   -  -    has produced (was produced by)

E12 Production

E24 Physical Man-Made Thing

P123

   -   -   resulted in (resulted from)

E81 Transformation

E77 Persistent Item

P93

   -   took out of existence (was taken out of existence by)

E64 End of Existence

E77 Persistent Item

P13

   -   -   destroyed (was destroyed by)

E6 Destruction

E18 Physical Thing

P99

   -   -   dissolved (was dissolved by)

E68 Dissolution

E74 Group

P100

   -   -   was death of (died in)

E69 Death

E21 Person

P124

   -   -   transformed (was transformed by)

E81 Transformation

E77 Persistent Item

P142

   -   -   used constituent (was used in)

E15 Identifier Assignment

E41 Appellation

P15

was influenced by (influenced)

E7 Activity

E1 CRM Entity

P16

   -   used specific object (was used for)

E7 Activity

E70 Thing

P33

   -   -   used specific technique (was used by)

E11 Modification

E29 Design or Procedure

P111

   -   -   added (was added by)

E79 Part Addition

E18 Physical Thing

P142

   -   -   used constituent (was used in)

E15 Identifier Assignment

E41 Appellation

P17

   -   was  motivated by (motivated)

E7 Activity

E1 CRM Entity

P134

   -   continued (was continued by)

E7 Activity

E7 Activity

P136

   -   was based on (supported type creation)

E83 Type Creation

E1 CRM Entity

P19

was intended use of (was made for)

E7 Activity

E71 Man-Made Thing

P20

had specific purpose (was purpose of)

E7 Activity

E5 Event

P21

had general purpose (was purpose of)

E7 Activity

E55 Type

P24

transferred title of (changed ownership through)

E8 Acquisition

E18 Physical Thing

P30

transferred custody of (custody transferred through)

E10 Transfer of Custody

E18 Physical Thing

P43

has dimension (is dimension of)

E70 Thing

E54 Dimension

P44

has condition (is condition of)

E18 Physical Thing

E3 Condition State

P45

consists of (is incorporated in)

E18 Physical Thing

E57 Material

P46

is composed of (forms part of)

E18 Physical Thing

E18 Physical Thing

P56

   -   bears feature (is found on)

E19 Physical Object

E26 Physical Feature

P49

has former or current keeper (is former or current keeper of)

E18 Physical Thing

E39 Actor

P50

   -   has current keeper (is current keeper of)

E18 Physical Thing

E39 Actor

P109

   -   has current or former curator (is current or former curator of)

E78 Collection

E39 Actor

P51

has former or current owner (is former or current owner of)

E18 Physical Thing

E39 Actor

P52

   -   has current owner (is current owner of)

E18 Physical Thing

E39 Actor

P53

has former or current location (is former or current location of)

E18 Physical Thing

E53 Place

P55

   -   has current location (currently holds)

E19 Physical Object

E53 Place

P54

has current permanent location (is current permanent location of)

E19 Physical Object

E53 Place

P57

has number of parts

E19 Physical Object

E60 Number

P58

has section definition (defines section)

E18 Physical Thing

E46 Section Definition

P59

has section (is located on or within)

E18 Physical Thing

E53 Place

P62

depicts  (is depicted by)

E24 Physical Man-Made Thing

E1 CRM Entity

P67

refers to ( is referred to by)

E89 Propositional Object

E1 CRM Entity

P68

   -   foresees use of (use foreseen by)

E29 Design or Procedure

E57 Material

P70

   -   documents (is documented in)

E31 Document

E1 CRM Entity

P71

   -   lists (is listed in)

E32 Authority Document

E1 CRM Entity

P129

   -   is about (is subject of)

E89 Propositional Object

E1 CRM Entity

P138

   -   represents (has representation)

E36 Visual Item

E1 CRM Entity

P69

is associated with

E29 Design or Procedure

E29 Design or Procedure

P72

has language (is language of)

E33 Linguistic Object

E56 Language

P74

has current or former residence (is current or former residence of)

E39 Actor

E53 Place

P75

possesses (is possessed by)

E39 Actor

E30 Right

P76

has contact point (provides access to)

E39 Actor

E51 Contact Point

P81

ongoing throughout

E52 Time-Span

E61 Time Primitive

P82

at some time within

E52 Time-Span

E61 Time Primitive

P83

had at least duration (was minimum duration of)

E52 Time-Span

E54 Dimension

P84

had at most duration (was maximum duration of)

E52 Time-Span

E54 Dimension

P86

falls within (contains)

E52 Time-Span

E52 Time-Span

P88

consists of (forms part of)

E53 Place

E53 Place

P89

falls within (contains)

E53 Place

E53 Place

P90

has value

E54 Dimension

E60 Number

P91

has unit (is unit of)

E54 Dimension

E58 Measurement Unit

P97

from father (was father for)

E67 Birth

E21 Person

P101

had as general use (was use of)

E70 Thing

E55 Type

P103

was intended for (was intention of)

E71 Man-Made Thing

E55 Type

P104

is subject to (applies to)

E72 Legal Object

E30 Right

P105

right held by (has right on)

E72 Legal Object

E39 Actor

P52

   -   has current owner (is current owner of)

E18 Physical Thing

E39 Actor

P106

is composed of (forms part of)

E90 Symbolic Object

E90 Symbolic Object

P107

has current or former member (is current or former member of)

E74 Group

E39 Actor

P114

is equal in time to

E2 Temporal Entity

E2 Temporal Entity

P115

finishes (is finished by)

E2 Temporal Entity

E2 Temporal Entity

P116

starts (is started by)

E2 Temporal Entity

E2 Temporal Entity

P117

occurs during (includes)

E2 Temporal Entity

E2 Temporal Entity

P118

overlaps in time with (is overlapped in time by)

E2 Temporal Entity

E2 Temporal Entity

P119

meets in time with (is met in time by)

E2 Temporal Entity

E2 Temporal Entity

P120

occurs  before (occurs  after)

E2 Temporal Entity

E2 Temporal Entity

P121

overlaps with

E53 Place

E53 Place

P122

borders with

E53 Place

E53 Place

P125

used object of type (was type of object used in)

E7 Activity

E55 Type

P32

   -   used general technique (was technique of)

E7 Activity

E55 Type

P126

employed (was employed in)

E11 Modification

E57 Material

P127

has broader term (has narrower term)

E55 Type

E55 Type

P65

   -   shows visual item (is shown by)

E24 Physical Man-Made Thing

E36 Visual Item

P130

shows features of (features are also found on)

E70 Thing

E70 Thing

P128

   -   carries (is carried by)

E24 Physical Man-Made Thing

E90 Symbolic Object

P65

   -   -   shows visual item (is shown by)

E24 Physical Man-Made Thing

E36 Visual Item

P73

   -   has translation (is translation of)

E33 Linguistic Object

E33 Linguistic Object

P132

overlaps with

E4 Period

E4 Period

P133

is separated from

E4 Period

E4 Period

P139

has alternative form

E41 Appellation

E41 Appellation

P140

assigned attribute to (was attributed by)

E13 Attribute Assignment

E1 CRM Entity

P34

   -   concerned (was assessed by)

E14 Condition Assessment

E18 Physical Thing

P39

   -   measured (was measured by)

E16 Measurement

E1 CRM Entity

P41

   -   classified (was classified by)

E17 Type Assignement

E1 CRM Entity

P141

assigned (was assigned by)

E13 Attribute Assignement

E1 CRM Entity

P35

   -   has identified (identified by)

E14 Condition Assessment

E3 Condition State

P37

   -   assigned (was assigned by)

E15 Identifier Assignement

E42 Identifier

P38

   -   deassigned (was deassigned by)

E15 Identifier Assignement

E42 Identifier

P40

   -   observed dimension (was observed in)

E16 Measurement

E54 Dimension

P42

   -   assigned (was assigned by)

E17 Type Assignment

E55 Type

P147

curated (was curated by)

E87 Curation Activity

E78 Collection

P148

has component (is component of)

E89 Propositional Object

E89 Propositional Object


CIDOC CRM Class Declarations

The classes of the CRM are comprehensively declared in this section using the following format:

 

 


E1 CRM Entity

Superclass of:              E2 Temporal Entity

E52 Time-Span

E53 Place

E54 Dimension

E77 Persistent Item

 

Scope note:              This class comprises all things in the universe of discourse of the CIDOC Conceptual Reference Model.

 

It is an abstract concept providing for three general properties:

  1. Identification by name or appellation, and in particular by a preferred identifier
  2. Classification by type, allowing further refinement of the specific subclass an instance belongs to
  3. Attachment of free text for the expression of anything not captured by formal properties

 

With the exception of E59 Primitive Value, all other classes within the CRM are directly or indirectly specialisations of E1 CRM Entity.

 

Examples:

 

Properties:

P1 is identified by (identifies): E41 Appellation

P2 has type (is type of): E55 Type

P3 has note: E62 String

              (P3.1 has type: E55 Type)

P48 has preferred identifier (is preferred identifier of): E42 Identifier

P137 exemplifies (is exemplified by): E55 Type

              (P137.1 in the taxonomic role: E55 Type)

E2 Temporal Entity

Subclass of:                 Ε1 CRM Entity

Superclass of:               Ε3 Condition State

                                    E4 Period

Scope note:              This class comprises all phenomena, such as the instances of E4 Periods, E5 Events and states, which happen over a limited extent in time.

 

              In some contexts, these are also called perdurants. This class is disjoint from E77 Persistent Item. This is an abstract class and has no direct instances. E2 Temporal Entity is specialized into E4 Period, which applies to a particular geographic area (defined with a greater or lesser degree of precision), and E3 Condition State, which applies to instances of E18 Physical Thing.

Examples:

Properties:

P4 has time-span (is time-span of): E52 Time-Span

P114 is equal in time to: E2 Temporal Entity

P115 finishes (is finished by): E2 Temporal Entity

P116 starts (is started by): E2 Temporal Entity

P117 occurs during (includes): E2 Temporal Entity

P118 overlaps in time with (is overlapped in time by): E2 Temporal Entity

P119 meets in time with (is met in time by): E2 Temporal Entity

P120 occurs before (occurs after): E2 Temporal Entity

E3 Condition State

 

Scope note:              This class comprises the states of objects characterised by a certain condition over a time-span.

 

An instance of this class describes the prevailing physical condition of any material object or feature during a specific E52 Time Span. In general, the time-span for which a certain condition can be asserted may be shorter than the real time-span, for which this condition held.

The nature of that condition can be described using P2 has type. For example, the E3 Condition State “condition of the SS Great Britain between 22 September 1846 and 27 August 1847” can be characterized as E55 Type “wrecked”.

 

Examples:

Properties:

P5 consists of (forms part of): E3 Condition State

E4 Period

Subclass of:                 E2 Temporal Entity

Superclass of:               E5 Event

 

Scope note:                            This class comprises sets of coherent phenomena or cultural manifestations bounded in time and space.

 

It is the social or physical coherence of these phenomena that identify an E4 Period and not the associated spatio-temporal bounds. These bounds are a mere approximation of the actual process of growth, spread and retreat. Consequently, different periods can overlap and coexist in time and space, such as when a nomadic culture exists in the same area as a sedentary culture.

 

Typically this class is used to describe prehistoric or historic periods such as the “Neolithic Period”, the “Ming Dynasty” or the “McCarthy Era”. There are however no assumptions about the scale of the associated phenomena. In particular all events are seen as synthetic processes consisting of coherent phenomena. Therefore E4 Period is a superclass of E5 Event. For example, a modern clinical E67 Birth can be seen as both an atomic E5 Event and as an E4 Period that consists of multiple activities performed by multiple instances of E39 Actor.

 

There are two different conceptualisations of ‘artistic style’, defined either by physical features or by historical context. For example, “Impressionism” can be viewed as a period lasting from approximately 1870 to 1905 during which paintings with particular characteristics were produced by a group of artists that included (among others) Monet, Renoir, Pissarro, Sisley and Degas. Alternatively, it can be regarded as a style applicable to all paintings sharing the characteristics of the works produced by the Impressionist painters, regardless of historical context. The first interpretation is an E4 Period, and the second defines morphological object types that fall under E55 Type.

 

Another specific case of an E4 Period is the set of activities and phenomena associated with a settlement, such as the populated period of Nineveh.

 

Examples:

Properties:

P7 took place at (witnessed): E53 Place

P8 took place on or within (witnessed): E19 Physical Object

P9 consists of (forms part of): E4 Period

P10 falls within (contains): E4 Period

P132 overlaps with: E4 Period

P133 is separated from: E4 Period

E5 Event

Subclass of:                 E4 Period

Superclass of:               E7 Activity

E63 Beginning of Existence

E64 End of Existence

 

Scope note:              This class comprises changes of states in cultural, social or physical systems, regardless of scale, brought about by a series or group of coherent physical, cultural, technological or legal phenomena. Such changes of state will affect instances of E77 Persistent Item or its subclasses.

 

The distinction between an E5 Event and an E4 Period is partly a question of the scale of observation. Viewed at a coarse level of detail, an E5 Event is an ‘instantaneous’ change of state. At a fine level, the E5 Event can be analysed into its component phenomena within a space and time frame, and as such can be seen as an E4 Period. The reverse is not necessarily the case: not all instances of E4 Period give rise to a noteworthy change of state.

Examples:

Properties:

P11 had participant (participated in): E39 Actor

P12 occurred in the presence of (was present at): E77 Persistent Item

E6 Destruction

Subclass of:                 E64 End of Existence

 

Scope note:              This class comprises events that destroy one or more instances of E18 Physical Thing such that they lose their identity as the subjects of documentation. 

 

Some destruction events are intentional, while others are independent of human activity. Intentional destruction may be documented by classifying the event as both an E6 Destruction and E7 Activity.

 

The decision to document an object as destroyed, transformed or modified is context sensitive:

1.  If the matter remaining from the destruction is not documented, the event is modelled solely as E6 Destruction.

2. An event should also be documented using E81 Transformation if it results in the destruction of one or more objects and the simultaneous production of others using parts or material from the original. In this case, the new items have separate identities. Matter is preserved, but identity is not.

3. When the initial identity of the changed instance of E18 Physical Thing is preserved, the event should be documented as E11 Modification.

Examples:

Properties:

P13 destroyed (was destroyed by): E18 Physical Thing

E7 Activity

Subclass of:                 E5 Event

Superclass of:               E8 Acquisition

E9 Move

E10 Transfer of Custody

E11 Modification

E13 Attribute Assignment

E65 Creation

E66 Formation

E85 Joining

E86 Leaving

E87 Curation Activity

 

Scope note:              This class comprises actions intentionally carried out by instances of E39 Actor that result in changes of state in the cultural, social, or physical systems documented.

 

This notion includes complex, composite and long-lasting actions such as the building of a settlement or a war, as well as simple, short-lived actions such as the opening of a door.

Examples:

Properties:

P14 carried out by (performed): E39 Actor

(P14.1 in the role of: E55 Type)

P15 was influenced by (influenced): E1 CRM Entity

P16 used specific object (was used for): E70 Thing

(P16.1 mode of use: E55 Type)

P17 was motivated by (motivated): E1 CRM Entity

P19 was intended use of (was made for): E71 Man-Made Thing

(P19.1 mode of use: E55 Type)

P20 had specific purpose (was purpose of): E5 Event

P21 had general purpose (was purpose of): E55 Type

P32 used general technique (was technique of): E55 Type

P33 used specific technique (was used by): E29 Design or Procedure

P125 used object of type (was type of object used in): E55 Type

P134 continued (was continued by): E7 Activity

 

E8 Acquisition

Subclass of:                 E7 Activity

 

Scope note:              This class comprises transfers of legal ownership from one or more instances of E39 Actor to one or more other instances of E39 Actor.

 

The class also applies to the establishment or loss of ownership of instances of E18 Physical Thing. It does not, however, imply changes of any other kinds of right. The recording of the donor and/or recipient is optional. It is possible that in an instance of E8 Acquisition there is either no donor or no recipient. Depending on the circumstances, it may describe:

 

  1. the beginning of ownership
  2. the end of ownership
  3. the transfer of ownership
  4. the acquisition from an unknown source
  5. the loss of title due to destruction of the item

 

It may also describe events where a collector appropriates legal title, for example by annexation or field collection. The interpretation of the museum notion of "accession" differs between institutions. The CRM therefore models legal ownership (E8 Acquisition) and physical custody (E10 Transfer of Custody) separately. Institutions will then model their specific notions of accession and deaccession as combinations of these.

Examples

Properties:

P22 transferred title to (acquired title through): E39 Actor

P23 transferred title from (surrendered title through): E39 Actor

P24 transferred title of (changed ownership through): E18 Physical Thing

E9 Move

Subclass of:                 E7 Activity

 

Scope note:              This class comprises changes of the physical location of the instances of E19 Physical Object.

 

Note, that the class E9 Move inherits the property P7 took place at (witnessed): E53 Place. This property should be used to describe the trajectory or a larger area within which a move takes place, whereas the properties P26 moved to (was destination of), P27 moved from (was origin of) describe the start and end points only. Moves may also be documented to consist of other moves (via P9 consists of (forms part of)), in order to describe intermediate stages on a trajectory. In that case, start and end points of the partial moves should match appropriately between each other and with the overall event.

Examples

Properties:

P25 moved (moved by): E19 Physical Object

P26 moved to (was destination of): E53 Place

P27 moved from (was origin of): E53 Place

E10 Transfer of Custody

Subclass of:                 E7 Activity

 

Scope note:              This class comprises transfers of physical custody of objects between instances of E39 Actor.

 

The recording of the donor and/or recipient is optional. It is possible that in an instance of E10 Transfer of Custody there is either no donor or no recipient. Depending on the circumstances it may describe:

  1. the beginning of custody
  2. the end of custody
  3. the transfer of custody
  4. the receipt of custody from an unknown source
  5. the declared loss of an object

 

The distinction between the legal responsibility for custody and the actual physical possession of the object should be expressed using the property P2 has type (is type of). A specific case of transfer of custody is theft.

 

The interpretation of the museum notion of "accession" differs between institutions. The CRM therefore models legal ownership and physical custody separately. Institutions will then model their specific notions of accession and deaccession as combinations of these.

Examples:

Properties:

P28 custody surrendered by (surrendered custody through): E39 Actor

P29 custody received by (received custody through): E39 Actor

P30 transferred custody of (custody transferred through): E18 Physical Thing

E11 Modification

Subclass of:                 E7 Activity

Superclass of:               E12 Production

                            E79 Part Addition

                            E80 Part Removal

 

Scope note:              This class comprises all instances of E7 Activity that create, alter or change E24 Physical Man-Made Thing.

 

This class includes the production of an item from raw materials, and other so far undocumented objects, and the preventive treatment or restoration of an object for conservation.

 

Since the distinction between modification and production is not always clear, modification is regarded as the more generally applicable concept. This implies that some items may be consumed or destroyed in a Modification, and that others may be produced as a result of it. An event should also be documented using E81 Transformation if it results in the destruction of one or more objects and the simultaneous production of others using parts or material from the originals. In this case, the new items have separate identities.

 

If the instance of the E29 Design or Procedure utilized for the modification prescribes the use of specific materials, they should be documented using property P68 foresees use of (use foreseen by): E57 Material of E29 Design or Procedure, rather than via P126 employed (was employed in): E57 Material.

Examples:

Properties:

P31 has modified (was modified by): E24 Physical Man-Made Thing

P126 employed (was employed in): E57 Material

E12 Production

Subclass of:                 E11 Modification

                            E63 Beginning of Existence

 

Scope note:              This class comprises activities that are designed to, and succeed in, creating one or more new items.

 

It specializes the notion of modification into production. The decision as to whether or not an object is regarded as new is context sensitive. Normally, items are considered “new” if there is no obvious overall similarity between them and the consumed items and material used in their production. In other cases, an item is considered “new” because it becomes relevant to documentation by a modification. For example, the scribbling of a name on a potsherd may make it a voting token. The original potsherd may not be worth documenting, in contrast to the inscribed one.

 

This entity can be collective: the printing of a thousand books, for example, would normally be considered a single event.

 

An event should also be documented using E81 Transformation if it results in the destruction of one or more objects and the simultaneous production of others using parts or material from the originals. In this case, the new items have separate identities and matter is preserved, but identity is not.

Examples:

Properties:

P108 has produced (was produced by): E24 Physical Man-Made Thing

E13 Attribute Assignment

Subclass of:                 E7 Activity

Superclass of:               E14 Condition Assessment

E15 Identifier Assignment

E16 Measurement

E17 Type Assignment

 

Scope note:              This class comprises the actions of making assertions about properties of an object or any relation between two items or concepts.

 

This class allows the documentation of how the respective assignment came about, and whose opinion it was. All the attributes or properties assigned in such an action can also be seen as directly attached to the respective item or concept, possibly as a collection of contradictory values. All cases of properties in this model that are also described indirectly through an action are characterised as "short cuts" of this action. This redundant modelling of two alternative views is preferred because many implementations may have good reasons to model either the action or the short cut, and the relation between both alternatives can be captured by simple rules.

 

In particular, the class describes the actions of people making propositions and statements during certain museum procedures, e.g. the person and date when a condition statement was made, an identifier was assigned, the museum object was measured, etc. Which kinds of such assignments and statements need to be documented explicitly in structures of a schema rather than free text, depends on if this information should be accessible by structured queries.

Examples:

Properties:

P140 assigned attribute to (was attributed by): E1 CRM Entity

P141 assigned (was assigned by): E1 CRM Entity

E14 Condition Assessment

Subclass of:                 E13 Attribute Assignment

 

Scope note:              This class describes the act of assessing the state of preservation of an object during a particular period.

 

The condition assessment may be carried out by inspection, measurement or through historical research. This class is used to document circumstances of the respective assessment that may be relevant to interpret its quality at a later stage, or to continue research on related documents.

 

Examples:

Properties:

P34 concerned (was assessed by): E18 Physical Thing

P35 has identified (identified by): E3 Condition State

E15 Identifier Assignment

Subclass of:                 E13 Attribute Assignment

 

Scope note:              This class comprises activities that result in the allocation of an identifier to an instance of E1 CRM Entity. An E15 Identifier Assignment may include the creation of the identifier from multiple constituents, which themselves may be instances of E41 Appellation. The syntax and kinds of constituents to be used may be declared in a rule constituting an instance of E29 Design or Procedure.

 

Examples of such identifiers include Find Numbers, Inventory Numbers, uniform titles in the sense of librarianship and Digital Object Identifiers (DOI). Documenting the act of identifier assignment and deassignment is especially useful when objects change custody or the identification system of an organization is changed. In order to keep track of the identity of things in such cases, it is important to document by whom, when and for what purpose an identifier is assigned to an item.

 

The fact that an identifier is a preferred one for an organisation can be expressed by using the property E1 CRM Entity. P48 has preferred identifier (is preferred identifier of): E42 Identifier. It can better be expressed in a context independent form by assigning a suitable E55 Type, such as “preferred identifier assignment”, to the respective instance of E15 Identifier Assignment via the P2 has type property.

Examples:

Properties:

P37 assigned (was assigned by): E42 Identifier

P38 deassigned (was deassigned by): E42 Identifier

P142 used constituent (was used in): E41 Appellation

E16 Measurement

Subclass of:                 E13 Attribute Assignment

 

Scope note:               This class comprises actions measuring physical properties and other values that can be determined by a systematic procedure.

 

Examples include measuring the monetary value of a collection of coins or the running time of a specific video cassette.

 

The E16 Measurement may use simple counting or tools, such as yardsticks or radiation detection devices. The interest is in the method and care applied, so that the reliability of the result may be judged at a later stage, or research continued on the associated documents. The date of the event is important for dimensions, which may change value over time, such as the length of an object subject to shrinkage. Details of methods and devices are best handled as free text, whereas basic techniques such as "carbon 14 dating" should be encoded using P2 has type (is type of:) E55 Type.

Examples:

Properties:

P39 measured (was measured by): E70 Thing

P40 observed dimension (was observed in): E54 Dimension

E17 Type Assignment

Subclass of:                 E13 Attribute Assignment

 

Scope note:              This class comprises the actions of classifying items of whatever kind. Such items include objects, specimens, people, actions and concepts.

 

This class allows for the documentation of the context of classification acts in cases where the value of the classification depends on the personal opinion of the classifier, and the date that the classification was made. This class also encompasses the notion of "determination," i.e. the systematic and molecular identification of a specimen in biology.

Examples:

Properties:

P41 classified (was classified by): E1 CRM Entity

P42 assigned (was assigned by): E55 Type

E18 Physical Thing

Subclass of:                 E72 Legal Object

Superclass of:               E19 Physical Object

E24 Physical Man-Made Thing

E26 Physical Feature

 

Scope Note:              This class comprises all persistent physical items with a relatively stable form, man-made or natural.

 

Depending on the existence of natural boundaries of such things, the CRM distinguishes the instances of E19 Physical Object from instances of E26 Physical Feature, such as holes, rivers, pieces of land etc. Most instances of E19 Physical Object can be moved (if not too heavy), whereas features are integral to the surrounding matter.

 

The CRM is generally not concerned with amounts of matter in fluid or gaseous states.

Examples:

Properties:

P44 has condition (is condition of): E3 Condition State

P45 consists of (is incorporated in): E57 Material

P46 is composed of (forms part of): E18 Physical Thing

P49 has former or current keeper (is former or current keeper of): E39 Actor

P50 has current keeper (is current keeper of): E39 Actor

P51 has former or current owner (is former or current owner of): E39 Actor

P52 has current owner (is current owner of): E39 Actor

P53 has former or current location (is former or current location of): E53 Place

P58 has section definition (defines section): E46 Section Definition

P59 has section (is located on or within): E53 Place

E19 Physical Object

Subclass of:                 E18 Physical Thing

Superclass of:               E20 Biological Object

E22 Man-Made Object

 

Scope note:              This class comprises items of a material nature that are units for documentation and have physical boundaries that separate them completely in an objective way from other objects.

 

The class also includes all aggregates of objects made for functional purposes of whatever kind, independent of physical coherence, such as a set of chessmen. Typically, instances of E19 Physical Object can be moved (if not too heavy).

 

In some contexts, such objects, except for aggregates, are also called “bona fide objects” (Smith & Varzi, 2000, pp.401-420), i.e. naturally defined objects.

 

The decision as to what is documented as a complete item, rather than by its parts or components, may be a purely administrative decision or may be a result of the order in which the item was acquired.

Examples:

Properties:

P54 has current permanent location (is current permanent location of): E53 Place

P55 has current location (currently holds): E53 Place

P56 bears feature (is found on): E26 Physical Feature

P57 has number of parts: E60 Number

E20 Biological Object

Subclass of:                 E19 Physical Object

Superclass of:               E21 Person

 

Scope note:              This class comprises individual items of a material nature, which live, have lived or are natural products of or from living organisms.

 

Artificial objects that incorporate biological elements, such as Victorian butterfly frames, can be documented as both instances of E20 Biological Object and E22 Man-Made Object.

 

Examples:              

E21 Person

Subclass of:                 E20 Biological Object

E39 Actor

 

Scope note:              This class comprises real persons who live or are assumed to have lived.

 

Legendary figures that may have existed, such as Ulysses and King Arthur, fall into this class if the documentation refers to them as historical figures. In cases where doubt exists as to whether several persons are in fact identical, multiple instances can be created and linked to indicate their relationship. The CRM does not propose a specific form to support reasoning about possible identity.

Examples:              

E22 Man-Made Object

Subclass of:                 E19 Physical Object

                            E24 Physical Man-Made Thing

Superclass of:               E84 Information Carrier

 

Scope note:              This class comprises physical objects purposely created by human activity.

 

No assumptions are made as to the extent of modification required to justify regarding an object as man-made. For example, an inscribed piece of rock or a preserved butterfly are both regarded as instances of E22 Man-Made Object.

Examples:             

E24 Physical Man-Made Thing

Subclass of:                 E18 Physical Thing

Superclass of:               E22 Man-Made Object

E25 Man-Made Feature

E78 Collection

 

Scope Note:              This class comprises all persistent physical items that are purposely created by human activity.

 

This class comprises man-made objects, such as a swords, and man-made features, such as rock art. No assumptions are made as to the extent of modification required to justify regarding an object as man-made. For example, a “cup and ring” carving on bedrock is regarded as instance of E24 Physical Man-Made Thing.

Examples:             

Properties:

P62 depicts (is depicted by): E1 CRM Entity

(P62.1 mode of depiction: E55 Type)

P65 shows visual item (is shown by): E36 Visual Item

P128 carries (is carried by): E90 Symbolic Object

E25 Man-Made Feature

Subclass of:                 E24 Physical Man-Made Thing

E26 Physical Feature

 

Scope Note:              This class comprises physical features that are purposely created by human activity, such as scratches, artificial caves, artificial water channels, etc.

 

No assumptions are made as to the extent of modification required to justify regarding a feature as man-made. For example, rock art or even “cup and ring” carvings on bedrock a regarded as types of E25 Man-Made Feature.

Examples:              

E26 Physical Feature

Subclass of:                 E18 Physical Thing

Superclass of:               E25 Man-Made Feature

E27 Site

 

Scope Note:              This class comprises identifiable features that are physically attached in an integral way to particular physical objects.

 

Instances of E26 Physical Feature share many of the attributes of instances of E19 Physical Object. They may have a one-, two- or three-dimensional geometric extent, but there are no natural borders that separate them completely in an objective way from the carrier objects. For example, a doorway is a feature but the door itself, being attached by hinges, is not.

 

Instances of E26 Physical Feature can be features in a narrower sense, such as scratches, holes, reliefs, surface colours, reflection zones in an opal crystal or a density change in a piece of wood. In the wider sense, they are portions of particular objects with partially imaginary borders, such as the core of the Earth, an area of property on the surface of the Earth, a landscape or the head of a contiguous marble statue. They can be measured and dated, and it is sometimes possible to state who or what is or was responsible for them. They cannot be separated from the carrier object, but a segment of the carrier object may be identified (or sometimes removed) carrying the complete feature.

 

This definition coincides with the definition of "fiat objects" (Smith & Varzi, 2000, pp.401-420), with the exception of aggregates of “bona fide objects”.

Examples:              

E27 Site

Subclass of:                 E26 Physical Feature

 

Scope Note:              This class comprises pieces of land or sea floor.

 

In contrast to the purely geometric notion of E53 Place, this class describes constellations of matter on the surface of the Earth or other celestial body, which can be represented by photographs, paintings and maps.

 

Instances of E27 Site are composed of relatively immobile material items and features in a particular configuration at a particular location.

 

Examples:             

E28 Conceptual Object

Subclass of:                 E71 Man-Made Thing

Superclass of:               E55 Type

E89 Propositional Object

E90 Symbolic Object

 

Scope note:              This class comprises non-material products of our minds and other human produced data that                             have become objects of a discourse about their identity, circumstances of creation or historical                             implication. The production of such information may have been supported by the use of                                technical devices such as cameras or computers.

 

Characteristically, instances of this class are created, invented or thought by someone, and then may be documented or communicated between persons. Instances of E28 Conceptual Object have the ability to exist on more than one particular carrier at the same time, such as paper, electronic signals, marks, audio media, paintings, photos, human memories, etc.

 

They cannot be destroyed. They exist as long as they can be found on at least one carrier or in at least one human memory. Their existence ends when the last carrier and the last memory are lost.

Examples:              

 

Properties:               P149 is identified by (identifies): E75 Conceptual Object Appellation

E29 Design or Procedure

Subclass of:                 E73 Information Object

 

Scope note:              This class comprises documented plans for the execution of actions in order to achieve a result of a specific quality, form or contents. In particular it comprises plans for deliberate human activities that may result in the modification or production of instances of E24 Physical Thing.

 

Instances of E29 Design or Procedure can be structured in parts and sequences or depend on others. This is modelled using P69 is associated with.

 

Designs or procedures can be seen as one of the following:

 

  1. A schema for the activities it describes
  2. A schema of the products that result from their application.
  3. An independent intellectual product that may have never been applied, such as Leonardo da Vinci’s famous plans for flying machines.

 

Because designs or procedures may never be applied or only partially executed, the CRM models a loose relationship between the plan and the respective product.

Examples:              

Properties:

P68 foresees use of (use foreseen by): E57 Material

P69 is associated with: E29 Design or Procedure

              (P69.1 has type: E55 Type)

E30 Right

Subclass of:              E89 Propositional Object

 

Scope Note:              This class comprises legal privileges concerning material and immaterial things or their derivatives.

 

These include reproduction and property rights.

 

Examples:               

E31 Document

Subclass of:                 E73 Information Object

Superclass of:               E32 Authority Document

 

Scope note:              This class comprises identifiable immaterial items that make propositions about reality.

 

These propositions may be expressed in text, graphics, images, audiograms, videograms or by other similar means. Documentation databases are regarded as a special case of E31 Document. This class should not be confused with the term “document” in Information Technology, which is compatible with E73 Information Object.

 

Examples:              

Properties:

P70 documents (is documented in): E1 CRM Entity

E32 Authority Document

Subclass of:                 E31 Document

 

Scope note:              This class comprises encyclopaedia, thesauri, authority lists and other documents that define terminology or conceptual systems for consistent use.

 

Examples:              

Properties:

P71 lists (is listed in): E1 CRM Entity

E33 Linguistic Object

Subclass of:                 E73 Information Object

Superclass of:               E34 Inscription

E35 Title

 

Scope note:              This class comprises identifiable expressions in natural language or languages.

 

Instances of E33 Linguistic Object can be expressed in many ways: e.g. as written texts, recorded speech or sign language. However, the CRM treats instances of E33 Linguistic Object independently from the medium or method by which they are expressed. Expressions in formal languages, such as computer code or mathematical formulae, are not treated as instances of E33 Linguistic Object by the CRM. These should be modelled as instances of E73 Information Object.

The text of an instance of E33 Linguistic Object can be documented in a note by P3 has note: E62 String

Examples:              

Properties:

P72 has language (is language of): E56 Language

P73 has translation (is translation of): E33 Linguistic Object

E34 Inscription

Subclass of:               E33 Linguistic Object

E37 Mark

 

Scope note:              This class comprises recognisable, short texts attached to instances of E24 Physical Man-Made Thing.

 

The transcription of the text can be documented in a note by P3 has note: E62 String. The alphabet used can be documented by P2 has type: E55 Type. This class does not intend to describe the idiosyncratic characteristics of an individual physical embodiment of an inscription, but the underlying prototype. The physical embodiment is modelled in the CRM as E24 Physical Man-Made Thing.

 

The relationship of a physical copy of a book to the text it contains is modelled using E84 Information Carrier. P128 carries (is carried by): E33 Linguistic Object.

 

Examples:              

E35 Title

Subclass of:                 E33 Linguistic Object

E41 Appellation

 

Scope note:              This class comprises the names assigned to works, such as texts, artworks or pieces of music.

 

Titles are proper noun phrases or verbal phrases, and should not be confused with generic object names such as “chair”, “painting” or “book” (the latter are common nouns that stand for instances of E55 Type). Titles may be assigned by the creator of the work itself, or by a social group.

 

This class also comprises the translations of titles that are used as surrogates for the original titles in different social contexts.

 

Examples:              

E36 Visual Item

Subclass of:                 E73 Information Object

Superclass of:               E37 Mark

E38 Image

 

Scope Note:              This class comprises the intellectual or conceptual aspects of recognisable marks and images.

 

This class does not intend to describe the idiosyncratic characteristics of an individual physical embodiment of a visual item, but the underlying prototype. For example, a mark such as the ICOM logo is generally considered to be the same logo when used on any number of publications. The size, orientation and colour may change, but the logo remains uniquely identifiable. The same is true of images that are reproduced many times. This means that visual items are independent of their physical support.

 

The class E36 Visual Item provides a means of identifying and linking together instances of E24 Physical Man-Made Thing that carry the same visual symbols, marks or images etc. The property P62 depicts (is depicted by) between E24 Physical Man-Made Thing and depicted subjects (E1 CRM Entity) can be regarded as a short-cut of the more fully developed path from E24 Physical Man-Made Thing through P65 shows visual item (is shown by), E36 Visual Item, P138 represents (has representation) to E1CRM Entity, which in addition captures the optical features of the depiction. 

 

Examples:              

 

Properties:

P138 represents (has representation): E1 CRM Entity

(P138.1 mode of representation: E55 Type)

E37 Mark

Subclass of:                 E36 Visual Item

Superclass of:               E34 Inscription

 

Scope note:              This class comprises symbols, signs, signatures or short texts applied to instances of E24 Physical Man-Made Thing by arbitrary techniques in order to indicate the creator, owner, dedications, purpose, etc.

 

This class specifically excludes features that have no semantic significance, such as scratches or tool marks. These should be documented as instances of E25 Man-Made Feature.

 

Examples:              

E38 Image

Subclass of:                 E36 Visual Item

 

Scope note:              This class comprises distributions of form, tone and colour that may be found on surfaces such as photos, paintings, prints and sculptures or directly on electronic media.

 

The degree to which variations in the distribution of form and colour affect the identity of an instance of E38 Image depends on a given purpose. The original painting of the Mona Lisa in the Louvre may be said to bear the same instance of E38 Image as reproductions in the form of transparencies, postcards, posters or T-shirts, even though they may differ in size and carrier and may vary in tone and colour. The images in a “spot the difference” competition are not the same with respect to their context, however similar they may at first appear.

 

Examples:              

E39 Actor

Subclass of:                 E77 Persistent Item

Superclass of:               E21 Person

 

Scope note:              This class comprises people, either individually or in groups, who have the potential to perform intentional actions for which they can be held responsible.

 

The CRM does not attempt to model the inadvertent actions of such actors. Individual people should be documented as instances of E21 Person, whereas groups should be documented as instances of either E74 Group or its subclass E40 Legal Body.

 

Examples:             

Properties:

P74 has current or former residence (is current or former residence of): E53 Place

P75 possesses (is possessed by): E30 Right

P76 has contact point (provides access to): E51 Contact Point

P131 is identified by (identifies): E82 Actor Appellation

E40 Legal Body

Subcass of:              E74 Group

 

Scope Note:              This class comprises institutions or groups of people that have obtained a legal recognition as a group and can act collectively as agents. 

 

This means that they can perform actions, own property, create or destroy things and can be held collectively responsible for their actions like individual people. The term 'personne morale' is often used for this in French.

 

Examples             

E41 Appellation

Subclass of:                 E90 Symbolic Object

Superclass of:               E35 Title

E42 Identifier

E44 Place Appellation

E49 Time Appellation

E51 Contact Point

E75 Conceptual Object Appellation

E82 Actor Appellation

 

Scope note:              This class comprises all sequences of signs of any nature, either meaningful or not, that are used or can be used to refer to and identify a specific instance of some class within a certain context.

 

Instances of E41 Appellation do not identify things by their meaning, even if they happen to have one, but by convention, tradition, or agreement. Instances of E41 Appellation are cultural constructs; as such, they have a context, a history, and a use in time and space by some group of users. A given instance of E41 Appellation can have alternative forms, i.e., other instances of E41 Appellation that are always regarded as equivalent independent from the thing it denotes.

 

Specific subclasses of E41 Appellation should be used when instances of E41 Appellation of a characteristic form are used for particular objects. Instances of E49 Time Appellation, for example, which take the form of instances of E50 Date, can be easily recognised.

 

E41 Appellation should not be confused with the act of naming something. Cf. E15 Identifier Assignment

Examples:             

Properties:

P139 has alternative form: E41 Appellation

              (P139.1 has type: E55 Type)

E42 Identifier

Subclass of:                 E41 Appellation

Scope note:              This class comprises strings or codes assigned to instances of E1 CRM Entity in order to identify them uniquely and permanently within the context of one or more organisations. Such codes are often known as inventory numbers, registration codes, etc. and are typically composed of alphanumeric sequences. The class E42 Identifier is not normally used for machine-generated identifiers used for automated processing unless these are also used by human agents.

Examples:              

E44 Place Appellation

Subclass of:                 E41 Appellation

Superclass of              E45 Address

E46 Section Definition

E47 Spatial Coordinates

E48 Place Name

Scope Note:              This class comprises any sort of identifier characteristically used to refer to an E53 Place.

 

Instances of E44 Place Appellation may vary in their degree of precision and their meaning may vary over time - the same instance of E44 Place Appellation may be used to refer to several places, either because of cultural shifts, or because objects used as reference points have moved around. Instances of E44 Place Appellation can be extremely varied in form: postal addresses, instances of E47 Spatial Coordinate, and parts of buildings can all be considered as instances of E44 Place Appellation.

Examples:             

E45 Address

Subclass of:                 E44 Place Appellation

                            E51 Contact Point

 

Scope Note:              This class comprises identifiers expressed in coding systems for places, such as postal addresses used for mailing.

 

An E45 Address can be considered both as the name of an E53 Place and as an E51 Contact Point for an E39 Actor. This dual aspect is reflected in the multiple inheritance. However, some forms of mailing addresses, such as a postal box, are only instances of E51 Contact Point, since they do not identify any particular Place. These should not be documented as instances of E45 Address.

 

Examples:              

E46 Section Definition

Subclass of:                 E44 Place Appellation

 

Scope Note:              This class comprises areas of objects referred to in terms specific to the general geometry or structure of its kind.

 

The 'prow' of the boat, the 'frame' of the picture, the 'front' of the building are all instances of E46 Section Definition. The class highlights the fact that parts of objects can be treated as locations. This holds in particular for features without natural boundaries, such as the “head” of a marble statue made out of one block (cf. E53 Place). In answer to the question 'where is the signature?' one might reply 'on the lower left corner'. (Section Definition is closely related to the term “segment” in Gerstl, P.& Pribbenow, S, 1996 “ A conceptual theory of part – whole relations and its applications”, Data & Knowledge               Engineering 20 305-322, North Holland- Elsevier ).

Examples:              

E47 Spatial Coordinates

Subclass of:                 E44 Place Appellation

 

Scope Note:              This class comprises the textual or numeric information required to locate specific instances of E53 Place within schemes of spatial identification.

 

Coordinates are a specific form of E44 Place Appellation, that is, a means of referring to a particular E53 Place. Coordinates are not restricted to longitude, latitude and altitude. Any regular system of reference that maps onto an E19 Physical Object can be used to generate coordinates.

Examples:              

E48 Place Name

Subclass of:                 E44 Place Appellation

 

Scope Note:              This class comprises particular and common forms of E44 Place Appellation.

 

Place Names may change their application over time: the name of an E53 Place may change, and a name may be reused for a different E53 Place. Instances of E48 Place Name are typically subject to place name gazetteers.

Examples:             

E49 Time Appellation

Subclass of:                 E41 Appellation

Superclass of              E50 Date

                           

Scope Note:              This class comprises all forms of names or codes, such as historical periods, and dates, which are characteristically used to refer to a specific E52 Time-Span.

 

The instances of E49 Time Appellation may vary in their degree of precision, and they may be relative to other time frames, “Before Christ” for example. Instances of E52 Time-Span are often defined by reference to a cultural period or an event e.g. ‘the duration of the Ming Dynasty’.

Examples:              

E50 Date

Subclass of:                 E49 Time Appellation

 

Scope Note:              This class comprises specific forms of E49 Time Appellation.

                           

Dates may vary in their degree of precision.

Examples:             

E51 Contact Point

Subcass of:              E41 Appellation

Superclass of:              E45 Address

 

Scope Note:              This class comprises identifiers employed, or understood, by communication services to direct communications to an instance of E39 Actor. These include E-mail addresses, telephone numbers, post office boxes, Fax numbers, URLs etc. Most postal addresses can be considered both as instances of E44 Place Appellation and E51 Contact Point. In such cases the subclass E45 Address should be used.

              URLs are addresses used by machines to access another machine through an http request. Since the accessed machine acts on behalf of the E39 Actor providing the machine, URLs are considered as instances of E51 Contact Point to that E39 Actor.

Examples:             

E52 Time-Span

Subclass of:                 E1 CRM Entity

 

Scope note:              This class comprises abstract temporal extents, in the sense of Galilean physics, having a beginning, an end and a duration.

 

Time Span has no other semantic connotations. Time-Spans are used to define the temporal extent of instances of E4 Period, E5 Event and any other phenomena valid for a certain time. An E52 Time-Span may be identified by one or more instances of E49 Time Appellation.

 

Since our knowledge of history is imperfect, instances of E52 Time-Span can best be considered as approximations of the actual Time-Spans of temporal entities. The properties of E52 Time-Span are intended to allow these approximations to be expressed precisely.  An extreme case of approximation, might, for example, define an E52 Time-Span having unknown beginning, end and duration. Used as a common E52 Time-Span for two events, it would nevertheless define them as being simultaneous, even if nothing else was known.

 

              Automatic processing and querying of instances of E52 Time-Span is facilitated if data can be parsed into an E61 Time Primitive.

Examples:              

Properties:

P78 is identified by (identifies): E49 Time Appellation

P79 beginning is qualified by: E62 String

P80 end is qualified by: E62 String

P81 ongoing throughout: E61 Time Primitive

P82 at some time within: E61 Time Primitive

P83 had at least duration (was minimum duration of): E54 Dimension

P84 had at most duration (was maximum duration of): E54 Dimension

P86 falls within (contains): E52 Time-Span

 

E53 Place 

Subclass of:                 E1 CRM Entity

 

Scope note:              This class comprises extents in space, in particular on the surface of the earth, in the pure sense of physics: independent from temporal phenomena and matter.

 

The instances of E53 Place are usually determined by reference to the position of “immobile” objects such as buildings, cities, mountains, rivers, or dedicated geodetic marks. A Place can be determined by combining a frame of reference and a location with respect to this frame. It may be identified by one or more instances of E44 Place Appellation.

 

It is sometimes argued that instances of E53 Place are best identified by global coordinates or absolute reference systems. However, relative references are often more relevant in the context of cultural documentation and tend to be more precise. In particular, we are often interested in position in relation to large, mobile objects, such as ships. For example, the Place at which Nelson died is known with reference to a large mobile object – H.M.S Victory. A resolution of this Place in terms of absolute coordinates would require knowledge of the movements of the vessel and the precise time of death, either of which may be revised, and the result would lack historical and cultural relevance.

 

Any object can serve as a frame of reference for E53 Place determination. The model foresees the notion of a "section" of an E19 Physical Object as a valid E53 Place determination.

Examples:              

Properties:

P87 is identified by (identifies): E44 Place Appellation

P88 consists of (forms part of): E53 Place

P89 falls within (contains): E53 Place

P121 overlaps with: E53 Place

P122 borders with: E53 Place

E54 Dimension

Subclass of:                 E1 CRM Entity

 

Scope note:              This class comprises quantifiable properties that can be measured by some calibrated means and can be approximated by values, i.e. points or regions in a mathematical or conceptual space, such as natural or real numbers, RGB values etc.

 

An instance of E54 Dimension represents the true quantity, independent from its numerical approximation, e.g. in inches or in cm. The properties of the class E54 Dimension allow for expressing the numerical approximation of the values of an instance of E54 Dimension. If the true values belong to a non-discrete space, such as spatial distances, it is recommended to record them as approximations by intervals or regions of indeterminacy enclosing the assumed true values. For instance, a length of 5 cm may be recorded as 4.5-5.5 cm, according to the precision of the respective observation. Note, that interoperability of values described in different units depends critically on the representation as value regions.

 

Numerical approximations in archaic instances of E58 Measurement Unit used in historical records should be preserved. Equivalents corresponding to current knowledge should be recorded as additional instances of E54 Dimension as appropriate.

Examples:              

Properties:

P90 has value: E60 Number

P91 has unit (is unit of): E58 Measurement Unit

E55 Type

Subclass of:               E28 Conceptual Object

Superclass of:               E56 Language

E57 Material

E58 Measurement Unit

 

Scope note:              This class comprises concepts denoted by terms from thesauri and controlled vocabularies used to characterize and classify instances of CRM classes. Instances of E55 Type represent concepts  in contrast to instances of E41 Appellation which are used to name instances of CRM classes.

 

E55 Type is the CRM’s interface to domain specific ontologies and thesauri. These can be represented in the CRM as subclasses of E55 Type, forming hierarchies of terms, i.e. instances of E55 Type linked via P127 has broader  term (has narrower term). Such hierarchies may be extended with additional properties.

Examples:              

Properties:

                            P127 has broader term (has narrower term): E55 Type

E56 Language

Subclass of:                 E55 Type

 

Scope note:              This class is a specialization of E55 Type and comprises the natural languages in the sense of concepts.

 

This type is used categorically in the model without reference to instances of it, i.e. the Model does not foresee the description of instances of instances of E56 Language, e.g.: “instances of  Mandarin Chinese”.

 

It is recommended that internationally or nationally agreed codes and terminology are used to denote instances of E56 Language, such as those defined in ISO 639:1988.

Examples:              

E57 Material

Subclass of:                 E55 Type

 

Scope note:              This class is a specialization of E55 Type and comprises the concepts of materials.

 

Instances of E57 Material may denote properties of matter before its use, during its use, and as incorporated in an object, such as ultramarine powder, tempera paste, reinforced concrete. Discrete pieces of raw-materials kept in museums, such as bricks, sheets of fabric, pieces of metal, should be modelled individually in the same way as other objects. Discrete used or processed pieces, such as the stones from Nefer Titi's temple, should be modelled as parts (cf. P46 is composed of).

 

This type is used categorically in the model without reference to instances of it, i.e. the Model does not foresee the description of instances of instances of E57 Material, e.g.: “instances of  gold”.

 

It is recommended that internationally or nationally agreed codes and terminology are used.

Examples:             

E58 Measurement Unit

Subclass of:                 E55 Type

 

Scope Note:              This class is a specialization of E55 Type and comprises the types of measurement units: feet, inches, centimetres, litres, lumens, etc.

 

This type is used categorically in the model without reference to instances of it, i.e. the Model does not foresee the description of instances of instances of E58 Measurement Unit, e.g.: “instances of cm”.

 

Système International (SI) units or internationally recognized non-SI terms should be used whenever possible. (ISO 1000:1992). Archaic Measurement Units used in historical records should be preserved.

Examples:             

E59 Primitive Value

Superclass of:                 E60 Number

                            E61 Time Primitive

                            E62 String

 

Scope Note:              This class comprises primitive values used as documentation elements, which are not further elaborated upon within the model.

 

As such they are not considered as elements within our universe of discourse. No specific implementation recommendations are made. It is recommended that the primitive value system from the implementation platform be used to substitute for this class and its subclasses.

Examples:             

E60 Number

Subclass of:              E59 Primitive Value

 

Scope Note:              This class comprises any encoding of computable (algebraic) values such as integers, real numbers, complex numbers, vectors, tensors etc., including intervals of these values to express limited precision.

 

Numbers are fundamentally distinct from identifiers in continua, such as instances of E50 Date and E47 Spatial Coordinate, even though their encoding may be similar. Instances of E60 Number can be combined with each other in algebraic operations to yield other instances of E60 Number, e.g., 1+1=2. Identifiers in continua may be combined with numbers expressing distances to yield new identifiers, e.g., 1924-01-31 + 2 days = 1924-02-02. Cf. E54 Dimension

Examples:              

E61 Time Primitive

Subclass of:                 E59 Primitive Value

 

Scope Note:              This class comprises instances of E59 Primitive Value for time that should be implemented with appropriate validation, precision and interval logic to express date ranges relevant to cultural documentation.

 

E61 Time Primitive is not further elaborated upon within the model.

 

Examples:             

E62 String

Subclass of:                 E59 Primitive Value

 

Scope Note:              This class comprises the instances of E59 Primitive Values used for documentation such as free text strings, bitmaps, vector graphics, etc.

 

E62 String is not further elaborated upon within the model

Examples:             

E63 Beginning of Existence

Subclass of:               E5 Event

Superclass of:               E12 Production

E65 Creation

                            E66 Formation

                            E67 Birth

                            E81 Transformation

 

Scope note:               This class comprises events that bring into existence any E77 Persistent Item.

 

It may be used for temporal reasoning about things (intellectual products, physical items, groups of people, living beings) beginning to exist; it serves as a hook for determination of a terminus post quem and ante quem.

Examples:             

Properties:

P92 brought into existence (was brought into existence by): E77 Persistent Item

E64 End of Existence

Subclass of:               E5 Event

Superclass of:               E6 Destruction

                            E68 Dissolution

                            E69 Death

                            E81 Transformation

 

Scope note:               This class comprises events that end the existence of any E77 Persistent Item.

 

It may be used for temporal reasoning about things (physical items, groups of people, living beings) ceasing to exist; it serves as a hook for determination of a terminus postquem and antequem. In cases where substance from a Persistent Item continues to exist in a new form, the process would be documented by E81 Transformation.

Examples:             

Properties:

P93 took out of existence (was taken out of existence by): E77 Persistent Item

E65 Creation

 

Subclass of:               E7 Activity

E63 Beginning of Existence

Superclass of:               E83 Type Creation

 

Scope note:               This class comprises events that result in the creation of conceptual items or immaterial products, such as legends, poems, texts, music, images, movies, laws, types etc.

Examples:             

Properties:

P94 has created (was created by): E28 Conceptual Object

E66 Formation

Subclass of:               E7 Activity

E63 Beginning of Existence

 

Scope note:               This class comprises events that result in the formation of a formal or informal E74 Group of people, such as a club, society, association, corporation or nation.

 

E66 Formation does not include the arbitrary aggregation of people who do not act as a collective.

The formation of an instance of E74 Group does not mean that the group is populated with members at the time of formation. In order to express the joining of members at the time of formation, the respective activity should be simultaneously an instance of both E66 Formation and E85 Joining.

Examples:             

Properties:

P95 has formed (was formed by): E74 Group

E67 Birth

Subclass of:               E63 Beginning of Existence

 

Scope note:               This class comprises the births of human beings. E67 Birth is a biological event focussing on the context of people coming into life. (E63 Beginning of Existence comprises the coming into life of any living beings).

 

Twins, triplets etc. are brought into life by the same E67 Birth event. The introduction of the E67 Birth event as a documentation element allows the description of a range of family relationships in a simple model. Suitable extensions may describe more details and the complexity of motherhood with the intervention of modern medicine. In this model, the biological father is not seen as a necessary participant in the E67 Birth event.

Examples:              

Properties:

P96 by mother (gave birth): E21 Person

P97 from father (was father for): E21 Person

P98 brought into life (was born): E21 Person

E68 Dissolution

Subclass of:               E64 End of Existence

 

Scope note:               This class comprises the events that result in the formal or informal termination of an E74 Group of people.

 

If the dissolution was deliberate, the Dissolution event should also be instantiated as an E7 Activity.

Examples:              

Properties:

P99 dissolved (was dissolved by): E74 Group

E69 Death

Subclass of:               E64 End of Existence

 

Scope note:               This class comprises the deaths of human beings.

If a person is killed, their death should be instantiated as E69 Death and as E7 Activity. The death or perishing of other living beings should be documented using E64 End of Existence.

Examples:             

Properties:

P100 was death of (died in): E21 Person

E70 Thing

Subclass of:               E77 Persistent Item

Superclass of:               E71 Man-Made Thing

              E72 Legal Object

 

Scope note:                This general class comprises usable discrete, identifiable, instances of E77 Persistent Item that are documented as single units.

 

They can be either intellectual products or physical things, and are characterized by relative stability. They may for instance either have a solid physical form, an electronic encoding, or they may be logical concept or structure.

Examples:              

Properties

P43 has dimension (is dimension of): E54 Dimension

P101 had as general use (was use of): E55 Type

P130 shows features of (features are also found on): E70 Thing

(P130.1 kind of similarity: E55 Type)

E71 Man-Made Thing

Subclass of:               E70 Thing

Superclass of:               E24 Physical Man-Made Thing

              E28 Conceptual Object

 

Scope note:               This class comprises discrete, identifiable man-made items that are documented as single units.

 

These items are either intellectual products or man-made physical things, and are characterized by relative stability. They may for instance have a solid physical form, an electronic encoding, or they may be logical concepts or structures.

Examples:              

Properties

P102 has title (is title of): E35 Title

(P102.1 has type: E55 Type)

P103 was intended for (was intention of): E55 Type

E72 Legal Object

Subclass of:               E70 Thing

Superclass of:               E18 Physical Thing

E90 Symbolic Object

 

Scope note:              This class comprises those material or immaterial items to which instances of E30 Right, such as the right of ownership or use, can be applied.

 

This is true for all E18 Physical Thing. In the case of instances of E28 Conceptual Object, however, the identity of the E28 Conceptual Object or the method of its use may be too ambiguous to reliably establish instances of E30 Right, as in the case of taxa and inspirations. Ownership of corporations is currently regarded as out of scope of the CRM.

Examples:              

Properties:

P104 is subject to (applies to): E30 Right

P105 right held by (has right on): E39 Actor

E73 Information Object

Subclass of:               E89 Propositional Object

E90 Symbolic Object

Superclass of:               E29 Design or Procedure

E31 Document

E33 Linguistic Object

E36 Visual Item

 

Scope note:               This class comprises identifiable immaterial items, such as a poems, jokes, data sets, images, texts, multimedia objects, procedural prescriptions, computer program code, algorithm or mathematical formulae, that have an objectively recognizable structure and are documented as single units.

 

An E73 Information Object does not depend on a specific physical carrier, which can include human memory, and it can exist on one or more carriers simultaneously.

Instances of E73 Information Object of a linguistic nature should be declared as instances of the E33 Linguistic Object subclass. Instances of E73 Information Object of a documentary nature should be declared as instances of the E31 Document subclass. Conceptual items such as types and classes are not instances of E73 Information Object, nor are ideas without a reproducible expression.

Examples:             

Properties:

E74 Group

Subclass of:               E39 Actor

Superclass of:               E40 Legal Body

 

Scope note:              This class comprises any gatherings or organizations of two or more people that act collectively or in a similar way due to any form of unifying relationship. In the wider sense this class also comprises official positions which used to be regarded in certain contexts as one actor, independent of the current holder of the office, such as the president of a country.

 

A gathering of people becomes an E74 Group when it exhibits organizational characteristics usually typified by a set of ideas or beliefs held in common, or actions performed together. These might be communication, creating some common artifact, a common purpose such as study, worship, business, sports, etc. Nationality can be modeled as membership in an E74 Group (cf. HumanML markup). Married couples and other concepts of family are regarded as particular examples of E74 Group.

Examples:              

Properties:

P107 has current or former member (is current or former member of): E39 Actor

                            (P107.1 kind of member: E55 Type)

 

E75 Conceptual Object Appellation

 

Subclass of:               E41 Appellation

 

Scope note:              This class comprises all appellations specific to intellectual products or standardized patterns.

Examples:              

E77 Persistent Item

 

Subclass of:               E1 CRM Entity

Superclass of:              E39 Actor

E70 Thing

 

Scope note:              This class comprises items that have a persistent identity, sometimes known as “endurants” in philosophy.

 

They can be repeatedly recognized within the duration of their existence by identity criteria rather than by continuity or observation. Persistent Items can be either physical entities, such as people, animals or things, or conceptual entities such as ideas, concepts, products of the imagination or common names.

 

The criteria that determine the identity of an item are often difficult to establish -; the decision depends largely on the judgement of the observer. For example, a building is regarded as no longer existing if it is dismantled and the materials reused in a different configuration. On the other hand, human beings go through radical and profound changes during their life-span, affecting both material composition and form, yet preserve their identity by other criteria. Similarly, inanimate objects may be subject to exchange of parts and matter. The class E77 Persistent Item does not take any position about the nature of the applicable identity criteria and if actual knowledge about identity of an instance of this class exists. There may be cases, where the identity of an E77 Persistent Item is not decidable by a certain state of knowledge.

The main classes of objects that fall outside the scope the E77 Persistent Item class are temporal objects such as periods, events and acts, and descriptive properties.

Examples:

E78 Collection

Subclass of:               E24 Physical Man-Made Thing

 

Scope note:              This class comprises aggregations of instances of E18 Physical Thing that are assembled and maintained (“curated” and “preserved,” in museological terminology) by one or more instances of E39 Actor over time for a specific purpose and audience, and according to a particular collection development plan. 

 

Items may be added or removed from an E78 Collection in pursuit of this plan. This class should not be confused with the E39 Actor maintaining the E78 Collection often referred to with the name of the E78 Collection (e.g. “The Wallace Collection decided…”).

 

Collective objects in the general sense, like a tomb full of gifts, a folder with stamps or a set of chessmen, should be documented as instances of E19 Physical Object, and not as instances of E78 Collection. This is because they form wholes either because they are physically bound together or because they are kept together for their functionality.

Examples:              

Properties:

P109 has current or former curator (is current or former curator of): E39 Actor

E79 Part Addition

Subclass of:               E11 Modification

 

Scope note:               This class comprises activities that result in an instance of E24 Physical Man-Made Thing being increased, enlarged or augmented by the addition of a part.

 

Typical scenarios include the attachment of an accessory, the integration of a component, the addition of an element to an aggregate object, or the accessioning of an object into a curated E78 Collection. Objects to which parts are added are, by definition, man-made, since the addition of a part implies a human activity. Following the addition of parts, the resulting man-made assemblages are treated objectively as single identifiable wholes, made up of constituent or component parts bound together either physically (for example the engine becoming a part of the car), or by sharing a common purpose (such as the 32 chess pieces that make up a chess set). This class of activities forms a basis for reasoning about the history and continuity of identity of objects that are integrated into other objects over time, such as precious gemstones being repeatedly incorporated into different items of jewellery, or cultural artifacts being added to different museum instances of E78 Collection over their lifespan.

Examples:             

Properties:

P110 augmented (was augmented by): E24 Physical Man-Made Thing

P111 added (was added by): E18 Physical Thing

E80 Part Removal

Subclass of:               E11 Modification

 

Scope note:              This class comprises the activities that result in an instance of E18 Physical Thing being decreased by the removal of a part.

 

Typical scenarios include the detachment of an accessory, the removal of a component or part of a composite object, or the deaccessioning of an object from a curated E78 Collection. If the E80 Part Removal results in the total decomposition of the original object into pieces, such that the whole ceases to exist, the activity should instead be modelled as an E81 Transformation, i.e. a simultaneous destruction and production. In cases where the part removed has no discernible identity prior to its removal but does have an identity subsequent to its removal, the activity should be regarded as both E80 Part Removal and E12 Production. This class of activities forms a basis for reasoning about the history, and continuity of identity over time, of objects that are removed from other objects, such as precious gemstones being extracted from different items of jewelry, or cultural artifacts being deaccessioned from different museum collections over their lifespan.

Examples:              

Properties:

P112 diminished (was diminished by): E24 Physical Man-Made Thing

P113 removed (was removed by): E18 Physical Thing

E81 Transformation

Subclass of:               E63 Beginning of Existence

E64 End of Existence

 

Scope note:              This class comprises the events that result in the simultaneous destruction of one or more than one E77 Persistent Item and the creation of one or more than one E77 Persistent Item that preserves recognizable substance from the first one(s) but has fundamentally different nature and identity.

 

Although the old and the new instances of E77 Persistent Item are treated as discrete entities having separate, unique identities, they are causally connected through the E81 Transformation; the destruction of the old E77 Persistent Item(s) directly causes the creation of the new one(s) using or preserving some relevant substance. Instances of E81 Transformation are therefore distinct from re-classifications (documented using E17 Type Assignment) or modifications (documented using E11 Modification) of objects that do not fundamentally change their nature or identity. Characteristic cases are reconstructions and repurposing of historical buildings or ruins, fires leaving buildings in ruins, taxidermy of specimen in natural history and the reorganization of a corporate body into a new one.

Examples:              

Properties:

P123 resulted in (resulted from): E77 Persistent Item

P124 transformed (was transformed by): E77 Persistent Item

E82 Actor Appellation

Subclass of:               E41 Appellation

 

Scope note:              This class comprises any sort of name, number, code or symbol characteristically used to identify an E39 Actor.

 

An E39 Actor will typically have more than one E82 Actor Appellation, and instances of E82 Actor Appellation in turn may have alternative representations. The distinction between corporate and personal names, which is particularly important in library applications, should be made by explicitly linking the E82 Actor Appellation to an instance of either E21 Person or E74 Group/E40 Legal Body. If this is not possible, the distinction can be made through the use of the P2 has type mechanism.

Examples:              

E83 Type Creation

Subclass of:               E65 Creation

 

Scope note:              This class comprises activities formally defining new types of items.

 

It is typically a rigorous scholarly or scientific process that ensures a type is exhaustively described and appropriately named. In some cases, particularly in archaeology and the life sciences, E83 Type Creation requires the identification of an exemplary specimen and the publication of the type definition in an appropriate scholarly forum. The activity of E83 Type Creation is central to research in the life sciences, where a type would be referred to as a “taxon,” the type description as a “protologue,” and the exemplary specimens as “orgininal element” or “holotype”.

Examples:             

Properties:

P135 created type (was created by): E55 Type

P136 was based on (supported type creation): E1 CRM Entity

(P136.1 in the taxonomic role: E55 Type)

E84 Information Carrier

Subclass of:                 E22 Man-Made Object

 

Scope note:              This class comprises all instances of E22 Man-Made Object that are explicitly designed to act as persistent physical carriers for instances of E73 Information Object.

 

This allows a relationship to be asserted between an E19 Physical Object and its immaterial information contents. An E84 Information Carrier may or may not contain information, e.g., a diskette. Note that any E18 Physical Thing may carry information, such as an E34 Inscription. However, unless it was specifically designed for this purpose, it is not an Information Carrier. Therefore the property P128 carries (is carried by) applies to E18 Physical Thing in general.

 

Examples:             

E85 Joining

 

Subclass of:               E7 Activity

 

Scope note:               This class comprises the activities that result in an instance of E39 Actor becoming a member of an instance of E74 Group. This class does not imply initiative by either party.

 

Typical scenarios include becoming a member of a social organisation, becoming employee of a company, marriage, the adoption of a child by a family and the inauguration of somebody into an official position.

Examples:             

Properties:

P143 joined (was joined by): E39 Actor

P144 joined with (gained member by) E74 Group

              (P144.1 kind of member: E55 Type)

E86 Leaving

Subclass of:               E7 Activity

 

Scope note:              This class comprises the activities that result in an instance of E39 Actor to be disassociated from an instance of E74 Group. This class does not imply initiative by either party.

Typical scenarios include the termination of membership in a social organisation, ending the employment at a company, divorce, and the end of tenure of somebody in an official position.

Examples:              

Properties:

P145 separated (left by) E39 Actor

P146 separated from (lost member by) E74 Group

E87 Curation Activity

Subclass of:     E7 Activity

                           

Scope note:              This class comprises the activities that result in the continuity of management and the preservation and evolution of instances of E78 Collection, following an implicit or explicit curation plan.

 

It specializes the notion of activity into the curation of a collection and allows the history of curation to be recorded.

 

Items are accumulated and organized following criteria like subject, chronological period, material type, style of art etc. and can be added or removed from an E78 Collection for a specific purpose and/or audience. The initial aggregation of items of a collection is regarded as an instance of E12 Production Event while the activity of evolving, preserving and promoting a collection is regarded as an instance of E87 Curation Activity.

Examples:              

Properties:

P147 curated (was curated by): E78 Collection

E89 Propositional Object

Subclass of:               E28 Conceptual Object

Superclass of:                E73 Information Object

                            E30 Right

 

Scope note:               This class comprises immaterial items, including but not limited to stories, plots, procedural prescriptions, algorithms, laws of physics or images that are, or represent in some sense, sets of propositions about real or imaginary things and that are documented as single units or serve as topic of discourse.

             

This class also comprises items that are “about” something in the sense of a subject. In the wider sense, this class includes expressions of psychological value such as non-figural art and musical themes. However, conceptual items such as types and classes are not instances of E89 Propositional Object. This should not be confused with the definition of a type, which is indeed an instance of E89 Propositional Object.

Examples:              

Properties:

P148 has component (is component of): E89 Propositional Object

P67 refers to (is referred to by): E1 CRM Entity

(P67.1 has type: E55 Type)

P129 is about (is subject of): E1 CRM Entity

E90 Symbolic Object

Subclass of:               E28 Conceptual Object

                            E72 Legal Object

Superclass of:                E73 Information Object

                            E41 Appellation

Scope note:              

This class comprises identifiable symbols and any aggregation of symbols, such as characters, identifiers, traffic signs, emblems, texts, data sets, images, musical scores, multimedia objects, computer program code or mathematical formulae that have an objectively recognizable structure and that are documented as single units.

 

It includes sets of signs of any nature, which may serve to designate something, or to communicate some propositional content.

 

An instance of E90 Symbolic Object does not depend on a specific physical carrier, which can include human memory, and it can exist on one or more carriers simultaneously. An instance of E90 Symbolic Object may or may not have a specific meaning, for example an arbitrary character string.

Examples:              

Properties:

P106 is composed of (forms part of): E90 Symbolic Object


CIDOC CRM Property Declarations

The properties of the CRM are comprehensively declared in this section using the following format:

 

The line “Examples:” provides illustrative examples showing how the property should be used.

 

 

 


P1 is identified by (identifies)

Domain:                            E1 CRM Entity

Range:                            E41 Appellation

Superproperty of:              E1 CRM Entity. P48 has preferred identifier (is preferred identifier of): E42 Identifier

              E52 Time-Span. P78 is identified by (identifies): E49 Time Appellation

              E53 Place. P87 is identified by (identifies): E44 Place Appellation

              E71 Man-Made Thing. P102 has title (is title of): E35 Title

              E39 Actor. P131 is identified by (identifies): E82 Actor Appellation

              E28 Conceptual Object.P149 is identified by (identifies): E75 Conceptual Object Appellation

Quantification:              many to many (0,n:0,n)

 

Scope note:              This property describes the naming or identification of any real world item by a name or any other identifier.

 

This property is intended for identifiers in general use, which form part of the world the model intends to describe, and not merely for internal database identifiers which are specific to a technical system, unless these latter also have a more general use outside the technical context. This property includes in particular identification by mathematical expressions such as coordinate systems used for the identification of instances of E53 Place. The property does not reveal anything about when, where and by whom this identifier was used. A more detailed representation can be made using the fully developed (i.e. indirect) path through E15 Identifier Assignment.

Examples:              

P2 has type (is type of)

Domain:               E1 CRM Entity

Range:                             E55 Type

Superproperty of. E1 CRM Entity.P137 exemplifies (is exemplified by):E55 Type

Quantification:              many to many (0,n:0,n)

 

Scope note:              This property allows sub typing of CRM entities - a form of specialisation – through the use of a terminological hierarchy, or thesaurus.

 

The CRM is intended to focus on the high-level entities and relationships needed to describe data structures. Consequently, it does not specialise entities any further than is required for this immediate purpose. However, entities in the isA hierarchy of the CRM may by specialised into any number of sub entities, which can be defined in the E55 Type hierarchy. E51 Contact Point, for example, may be specialised into “e-mail address”, “telephone number”, “post office box”, “URL” etc. none of which figures explicitly in the CRM hierarchy. Sub typing obviously requires consistency between the meaning of the terms assigned and the more general intent of the CRM entity in question.

Examples:              

              “enquiries@cidoc-crm.org” (E51) has type e-mail address (E55)

P3 has note

Domain:                            E1 CRM Entity

Range:                            E62 String

Superproperty of:              E52 Time-Span. P79 beginning is qualified by: E62 String

                            E52 Time-Span. P80 end is qualified by: E62 String

Quantification:              one to many (0,n:0,1)

 

Scope note:              This property is a container for all informal descriptions about an object that have not been expressed in terms of CRM constructs.

 

In particular it captures the characterisation of the item itself, its internal structures, appearance etc.

Like property P2 has type (is type of), this property is a consequence of the restricted focus of the CRM. The aim is not to capture, in a structured form, everything that can be said about an item; indeed, the CRM formalism is not regarded as sufficient to express everything that can be said. Good practice requires use of distinct note fields for different aspects of a characterisation. The P3.1 has type property of P3 has note allows differentiation of specific notes, e.g. “construction”, “decoration” etc.

An item may have many notes, but a note is attached to a specific item.

Examples:              

Properties:              P3.1 has type: E55 Type

P4 has time-span (is time-span of)

Domain:                            E2 Temporal Entity

Range:                            E52 Time-Span

Quantification:              many to one, necessary, dependent (1,1:1,n)

 

Scope note:              This property describes the temporal confinement of an instance of an E2 Temporal Entity.

 

The related E52 Time-Span is understood as the real Time-Span during which the phenomena were active, which make up the temporal entity instance. It does not convey any other meaning than a positioning on the “time-line” of chronology. The Time-Span in turn is approximated by a set of dates (E61 Time Primitive). A temporal entity can have in reality only one Time-Span, but there may exist alternative opinions about it, which we would express by assigning multiple Time-Spans. Related temporal entities may share a Time-Span. Time-Spans may have completely unknown dates but other descriptions by which we can infer knowledge.

Examples:              

P5 consists of (forms part of)

Domain:                            E3 Condition State

Range:                            E3 Condition State

Quantification:              one to many (0,n:0,1)

 

Scope note:              This property describes the decomposition of an E3 Condition State into discrete, subsidiary states.

 

It is assumed that the sub-states into which the condition state is analysed form a logical whole - although the entire story may not be completely known – and that the sub-states are in fact constitutive of the general condition state. For example, a general condition state of “in ruins” may be decomposed into the individual stages of decay.

Examples:              

The Condition State of the ruined Parthenon (E3) consists of the bombarded state after the explosion of a Venetian shell in 1687 (E3)[4]

P7 took place at (witnessed)

Domain:                            E4 Period

Range:                            E53 Place

Superproperty of:              E9 Move. P26 moved to (was destination of): E53 Place

              E9 Move. P27 moved from (was origin of): E53 Place

Quantification:              many to many, necessary (1,n:0,n)

 

Scope note:              This property describes the spatial location of an instance of E4 Period.

 

The related E53 Place should be seen as an approximation of the geographical area within which the phenomena that characterise the period in question occurred. P7took place at (witnessed) does not convey any meaning other than spatial positioning (generally on the surface of the earth).  For example, the period “Révolution française” can be said to have taken place in “France”, the “Victorian” period, may be said to have taken place in “Britain” and its colonies, as well as other parts of Europe and north America.

A period can take place at multiple locations.

Examples:              

P8 took place on or within (witnessed)

Domain:                            E4 Period

Range:                            E19 Physical Object

Quantification:              many to many (0,n:0,n)

 

Scope note:              This property describes the location of an instance of E4 Period with respect to an E19 Physical Object.

P8 took place on or within (witnessed) is a short-cut of a path defining a E53 Place with respect to the geometry of an object. cf. E46 Section Definition.

 

This property is in effect a special case of P7 took place at. It describes a period that can be located with respect to the space defined by an E19 Physical Object such as a ship or a building. The precise geographical location of the object during the period in question may be unknown or unimportant.

For example, the French and German armistice of 22 June 1940 was signed in the same railway carriage as the armistice of 11 November 1918.

 

Examples:              

P9 consists of (forms part of)

Domain:                            E4 Period

Range:                            E4 Period

Quantification:              one to many, (0,n:0,1)

 

Scope note:              This property describes the decomposition of an instance of E4 Period into discrete, subsidiary periods.

 

The sub-periods into which the period is decomposed form a logical whole - although the entire picture may not be completely known - and the sub-periods are constitutive of the general period.

 

Examples:             

P10 falls within (contains)

Domain:                            E4 Period

Range:                            E4 Period

Quantification:              many to many (0,n:0,n)

 

Scope note:              This property describes an instance of E4 Period, which falls within the E53 Place and E52 Time-Span of another.

 

The difference with P9 consists of (forms part of) is subtle. Unlike P9 consists of (forms part of), P10 falls within (contains) does not imply any logical connection between the two periods and it may refer to a period of a completely different type.

 

Examples:             

P11 had participant (participated in)

Domain:                            E5 Event

Range:                            E39 Actor

Subproperty of:               E5 Event. P12 occurred in the presence of (was present at): E77 Persistent Item

Superproperty of:              E7 Activity. P14 carried out by (performed): E39 Actor

                            E67 Birth. P96 by mother (gave birth): E21 Person

                            E68 Dissolution. P99 dissolved (was dissolved by): E74 Group

E85 Joining.P143 joined (was joined by): E39 Actor

E85 Joining.P144 joined with (gained member by): E74 Group

E86 Leaving.P145 separated (left by):E39 Actor

E86 Leaving.P146 separated from (lost member by):E74 Group

Quantification:              many to many (0,n:0,n)

 

Scope note:              This property describes the active or passive participation of instances of E39 Actors in an E5 Event.

 

It connects the life-line of the related E39 Actor with the E53 Place and E50 Date of the event. The property implies that the Actor was involved in the event but does not imply any causal relationship. The subject of a portrait can be said to have participated in the creation of the portrait.

Examples:             

P12 occurred in the presence of (was present at)

Domain:                            E5 Event

Range:                            E77 Persistent Item

Superproperty of:              E5 Event. P11 had participant (participated in): E39 Actor

E7 Activity. P16 used specific object (was used for): E70 Thing

              E9 Move. P25 moved (moved by): E19 Physical Object

                            E11 Modification. P31 has modified (was modified by): E24 Physical Man-Made Thing

                            E63 Beginning of Existence. P92 brought into existence (was brought into existence by): E77 Persistent Item

E64 End of Existence. P93 took out of existence (was taken out of existence by): E77 Persistent Item

E79 Part Addition.P111 added (was added by): E18 Physical Thing

E80 Part Removal.P113 removed (was removed by): E18 Physical Thing

Quantification:              many to many, necessary (1,n:0,n)

 

Scope note:              This property describes the active or passive presence of an E77 Persistent Item in an E5 Event without implying any specific role.

 

It connects the history of a thing with the E53 Place and E50 Date of an event. For example, an object may be the desk, now in a museum on which a treaty was signed. The presence of an immaterial thing implies the presence of at least one of its carriers.

Examples:              

P13 destroyed (was destroyed by)

Domain:                            E6 Destruction

Range:                            E18 Physical Thing

Subproperty of:               E64 End of Existence. P93 took out of existence (was taken out of existence by): E77 Persistent Item

Quantification:              one to many, necessary (1,n:0,1)

 

Scope note:              This property allows specific instances of E18 Physical Thing that have been destroyed to be related to a destruction event.

Destruction implies the end of an item’s life as a subject of cultural documentation – the physical matter of which the item was composed may in fact continue to exist. A destruction event may be contiguous with a Production that brings into existence a derived object composed partly of matter from the destroyed object.

Examples:             

P14 carried out by (performed)

 

Domain:                            E7 Activity

Range:                            E39 Actor

Subproperty of:               E5 Event. P11 had participant (participated in): E39 Actor

Superproperty of:              E8 Acquisition. P22 transferred title to (acquired title through): E39 Actor

              E8 Acquisition. P23 transferred title from (surrendered title through): E39 Actor

E10 Transfer of Custody. P28 custody surrendered by (surrendered custody through): E39 Actor

E10 Transfer of Custody. P29 custody received by (received custody through): E39 Actor

Quantification:              many to many, necessary (1,n:0,n)

 

Scope note:              This property describes the active participation of an E39 Actor in an E7 Activity.

 

It implies causal or legal responsibility. The P14.1 in the role of property of the property allows the nature of an Actor’s participation to be specified.

Examples:             

Properties:              P14.1 in the role of: E55 Type

P15 was influenced by (influenced)

Domain:                            E7 Activity

Range:                            E1 CRM Entity

Superproperty of:              E7 Activity. P16 used specific object (was used for): E70 Thing

E7 Activity. P17 was motivated by (motivated): E1 CRM Entity

E7 Activity. P134 continued (was continued by): E7 Activity

E83 Type Creation. P136 was based on (supported type creation): E1 CRM Entity

Quantification:               many to many (0,n:0,n)

 

Scope note:              This is a high level property, which captures the relationship between an E7 Activity and anything that may have had some bearing upon it.

 

The property has more specific sub properties.

Examples:              

P16 used specific object (was used for)

Domain:                            E7 Activity

Range:                            E70 Thing

Subproperty of:               E5 Event. P12 occurred in the presence of (was present at): E77 Persistent Item

E7 Activity. P15 was influenced by (influenced): E1 CRM Entity

Superproperty of:E7 Activity.P33 used specific technique (was used by):E29 Design or Procedure

E15 Identifier Assignment. P142 used constituent (was used in):E41 Appellation

E79 Part Addition. P111 added (was added by):E18 Physical Thing

Quantification:              many to many (0,n:0,n)

 

Scope note:              This property describes the use of material or immaterial things in a way essential to the performance or the outcome of an E7 Activity.

 

This property typically applies to tools, instruments, moulds, raw materials and items embedded in a product. It implies that the presence of the object in question was a necessary condition for the action. For example, the activity of writing this text required the use of a computer. An immaterial thing can be used if at least one of its carriers is present. For example, the software tools on a computer.

 

Another example is the use of a particular name by a particular group of people over some span to identify a thing, such as a settlement. In this case, the physical carriers of this name are at least the people understanding its use.

Examples:              

Properties:              P16.1 mode of use: E55 Type

P17 was motivated by (motivated)

Domain:                            E7 Activity

Range:                            E1 CRM Entity

Subproperty of:               E7 Activity. P15 was influenced by (influenced): E1 CRM Entity

Quantification:              many to many (0,n:0,n)

 

Scope note:              This property describes an item or items that are regarded as a reason for carrying out the E7 Activity.

 

For example, the discovery of a large hoard of treasure may call for a celebration, an order from head quarters can start a military manoeuvre.

Examples:             

P19 was intended use of (was made for):

Domain:                            E7 Activity

Range:                            E71 Man-Made Thing

Quantification:              many to many (0,n:0,n)

 

Scope note:              This property relates an E7 Activity with objects created specifically for use in the activity.

 

This is distinct from the intended use of an item in some general type of activity such as the book of common prayer which was intended for use in Church of England services (see P101 had as general use (was use of)).

Examples:             

 

Properties:              P19.1 mode of use: E55 Type

P20 had specific purpose (was purpose of)

Domain:                            E7 Activity

Range:                            E5 Event

Quantification:              many to many (0,n:0,n)

 

Scope note: This property identifies the relationship between a preparatory activity and the event it is intended to be preparation for.

                           

This includes activities, orders and other organisational actions, taken in preparation for other activities or events.


P20 had specific purpose (was purpose of) implies that an activity succeeded in achieving its aim. If it does not succeed, such as the setting of a trap that did not catch anything, one may document the unrealized intention using P21 had general purpose (was purpose of):E55 Type and/or  P33 used specific technique (was used by): E29 Design or Procedure.

Examples:             

P21 had general purpose (was purpose of)

Domain:                            E7 Activity

Range:                            E55 Type

Quantification:              many to many (0,n:0,n)

 

Scope note:              This property describes an intentional relationship between an E7 Activity and some general goal or purpose.

 

This may involve activities intended as preparation for some type of activity or event. P21had general purpose (was purpose of) differs from P20 had specific purpose (was purpose of) in that no occurrence of an event is implied as the purpose.

Examples:             

P22 transferred title to (acquired title through)

Domain:                            E8 Acquisition

Range:                            E39 Actor

Subproperty of:               E7 Activity. P14 carried out by (performed): E39 Actor

Quantification:              many to many (0,n:0,n)

 

Scope note:              This property identifies the E39 Actor that acquires the legal ownership of an object as a result of an E8 Acquisition.

 

The property will typically describe an Actor purchasing or otherwise acquiring an object from another Actor. However, title may also be acquired, without any corresponding loss of title by another Actor, through legal fieldwork such as hunting, shooting or fishing.

                           

In reality the title is either transferred to or from someone, or both.

Examples:              

P23 transferred title from (surrendered title through)

Domain:                            E8 Acquisition

Range:                            E39 Actor

Subproperty of:               E7 Activity. P14 carried out by (performed): E39 Actor

Quantification:              many to many (0,n:0,n)

 

Scope note:              This property identifies the E39 Actor or Actors who relinquish legal ownership as the result of an E8 Acquisition.

 

The property will typically be used to describe a person donating or selling an object to a museum. In reality title is either transferred to or from someone, or both.

 

Examples:              

P24 transferred title of (changed ownership through)

Domain:                            E8 Acquisition

Range:                            E18 Physical Thing

Quantification:              many to many, necessary (1,n:0,n)

 

Scope note:              This property identifies the E18 Physical Thing or things involved in an E8 Acquisition.

 

In reality, an acquisition must refer to at least one transferred item.

 

Examples:             

P25 moved (moved by)

Domain:                            E9 Move

Range:                            E19 Physical Object

Subproperty of:               E5 Event. P12 occurred in the presence of (was present at): E77 Persistent Item

Quantification:              many to many, necessary (1,n:0,n)

 

Scope note:              This property identifies the E19 Physical Object that is moved during a move event.

 

The property implies the object’s passive participation. For example, Monet’s painting “Impression sunrise” was moved for the first Impressionist exhibition in 1874.

In reality, a move must concern at least one object.

 

Examples:             

P26 moved to (was destination of)

Domain:                            E9 Move

Range:                            E53 Place

Subproperty of:               E4 Period. P7 took place at (witnessed): E53 Place

Quantification:              many to many, necessary (1,n:0,n)

 

Scope note:              This property identifies the destination of a E9 Move.

 

A move will be linked to a destination, such as the move of an artefact from storage to display. A move may be linked to many terminal instances of E53 Places. In this case the move describes a distribution of a set of objects. The area of the move includes the origin, route and destination.

Examples:             

P27 moved from (was origin of)

 

Domain:                            E9 Move

Range:                            E53 Place

Subproperty of:               E4 Period. P7 took place at (witnessed): E53 Place

Quantification:              many to many, necessary (1,n:0,n)

 

Scope note:              This property identifies the starting E53 Place of an E9 Move.

 

A move will be linked to an origin, such as the move of an artefact from storage to display. A move may be linked to many origins. In this case the move describes the picking up of a set of objects. The area of the move includes the origin, route and destination.

Examples:             

P28 custody surrendered by (surrendered custody through)

Domain:                            E10 Transfer of Custody

Range:                            E39 Actor

Subproperty of:               E7 Activity. P14 carried out by (performed): E39 Actor

Quantification:              many to many (0,n:0,n)

 

Scope note:              This property identifies the E39 Actor or Actors who surrender custody of an instance of E18 Physical Thing in an E10 Transfer of Custody activity.

 

The property will typically describe an Actor surrendering custody of an object when it is handed over to someone else’s care. On occasion, physical custody may be surrendered involuntarily – through accident, loss or theft.

In reality, custody is either transferred to someone or from someone, or both.

Examples:             

P29 custody received by (received custody through)

 

Domain:                            E10 Transfer of Custody

Range:                            E39 Actor

Subproperty of:               E7 Activity. P14 carried out by (performed): E39 Actor

Quantification:              many to many (0,n:0,n)

 

Scope note:              This property identifies the E39 Actor or Actors who receive custody of an instance of E18 Physical Thing in an E10 Transfer of Custody activity.

 

The property will typically describe Actors receiving custody of an object when it is handed over from another Actor’s care. On occasion, physical custody may be received involuntarily or illegally – through accident, unsolicited donation, or theft.

In reality, custody is either transferred to someone or from someone, or both.

Examples:             

P30 transferred custody of (custody transferred through)

 

Domain:                            E10 Transfer of Custody

Range:                            E18 Physical Thing

Quantification:              many to many, necessary (1,n:0,n)

 

Scope note:              This property identifies an item or items of E18 Physical Thing concerned in an E10 Transfer of Custody activity.

 

The property will typically describe the object that is handed over by an E39 Actor to another Actor’s custody. On occasion, physical custody may be transferred involuntarily or illegally – through accident, unsolicited donation, or theft.

Examples:             

the delivery of the paintings by Secure Deliveries Inc. to the National Gallery (E10) transferred custody of paintings from The Iveagh Bequest (E19)

P31 has modified (was modified by)

Domain:                            E11 Modification

Range:                            E24 Physical Man-Made Thing

Subproperty of:               E5 Event. P12 occurred in the presence of (was present at): E77 Persistent Item

Superproperty of:              E12 Production. P108 has produced (was produced by): E24 Physical Man-Made Thing

              E79 Part Addition. P110 augmented (was augmented by): E24 Physical Man-Made Thing

              E80 Part Removal. P112 diminished (was diminished by): E24 Physical Man-Made Thing

Quantification:              many to many, necessary (1,n:0,n)

 

Scope note:              This property identifies the E24 Physical Man-Made Thing modified in an E11 Modification.

 

If a modification is applied to a non-man-made object, it is regarded as an E22 Man-Made Object from that time onwards.

Examples:             

P32 used general technique (was technique of)

 

Domain:                            E7 Activity

Range:                            E55 Type

Subproperty of:               E7 Activity. P125 used object of type (was type of object used in): E55 Type

Superproperty of:             

Quantification:              many to many (0,n:0,n)

 

Scope note:              This property identifies the technique that was employed in an act of modification.

 

These techniques should be drawn from an external E55 Type hierarchy of consistent terminology of general techniques such as embroidery, oil-painting, etc. Specific techniques may be further described as instances of E29 Design or Procedure.

Examples:             

P33 used specific technique (was used by)

Domain:                            E7 Activity

Range:                            E29 Design or Procedure

Subproperty of:               E7 Activity. P16 used specific object (was used for): E70 Thing

Quantification:              many to many (0,n:0,n)

 

Scope note:              This property identifies a specific instance of E29 Design or Procedure in order to carry out an                             instance of E7 Activity or parts of it.

 

The property differs from P32 used general technique (was technique of) in that P33 refers to an instance of E29 Design or Procedure, which is a concrete information object in its own right rather than simply being a term or a method known by tradition.

 

Typical examples would include intervention plans for conservation or the construction plans of a building

Examples:             

P34 concerned (was assessed by)

Domain:                            E14 Condition Assessment

Range:                            E18 Physical Thing

Subproperty of:               E13 Attribute Assignment. P140 assigned attribute to (was attributed by): E1 CRM Entity

Quantification:              many to many, necessary (1,n:0,n)

 

Scope note:              This property identifies the E18 Physical Thing that was assessed during an E14 Condition Assessment activity.

Conditions may be assessed either by direct observation or using recorded evidence. In the latter case the E18 Physical Thing does not need to be present or extant.

Examples:             

P35 has identified (was identified by)

Domain:                            E14 Condition Assessment

Range:                            E3 Condition State

Subproperty of:               E13 Attribute Assignment. P141 assigned (was assigned by): E1 CRM Entity

Quantification:              many to many, necessary (1,n:0,n)

 

Scope note:              This property identifies the E3 Condition State that was observed in an E14 Condition Assessment activity.

Examples:             

P37 assigned (was assigned by)

Domain:                            E15 Identifier Assignment

Range:                            E42 Identifier

Subproperty of:               E13 Attribute Assignment. P141 assigned (was assigned by): E1 CRM Entity

Quantification:                            many to many (0,n:0,n)

 

Scope note:              This property records the identifier that was assigned to an item in an Identifier Assignment activity.

The same identifier may be assigned on more than one occasion.

An Identifier might be created prior to an assignment.

Examples:             

P38 deassigned (was deassigned by)

Domain:                            E15 Identifier Assignment

Range:                            E42 Identifier

Subproperty of:               E13 Attribute Assignment. P141 assigned (was assigned by): E1 CRM Entity

Quantification:                            many to many (0,n:0,n)

 

Scope note:              This property records the identifier that was deassigned from an instance of E1 CRM Entity.

Deassignment of an identifier may be necessary when an item is taken out of an inventory, a new numbering system is introduced or items are merged or split up.

The same identifier may be deassigned on more than one occasion.

Examples:             

P39 measured (was measured by)

Domain:                            E16 Measurement

Range:                            E1 CRM Entity

Subproperty of:               E13 Attribute Assignment. P140 assigned attribute to (was attributed by): E1 CRM Entity

Quantification:              many to one, necessary (1,1:0,n)

 

Scope note:              This property associates an instance of E16 Measurement with the instance of E1 CRM Entity to which it applied. An instance of E1 CRM Entity may be measured more than once. Material and immaterial things and processes may be measured, e.g. the number of words in a text, or the duration of an event.

Examples:             

P40 observed dimension (was observed in)

Domain:                            E16 Measurement

Range:                            E54 Dimension

Subproperty of:               E13 Attribute Assignment. P141 assigned (was assigned by): E1 CRM Entity

Quantification:              many to many, necessary (1,n:0,n)

 

Scope note:              This property records the dimension that was observed in an E16 Measurement Event.

E54 Dimension can be any quantifiable aspect of E70 Thing. Weight, image colour depth and monetary value are dimensions in this sense. One measurement activity may determine more than one dimension of one object.

Dimensions may be determined either by direct observation or using recorded evidence. In the latter case the measured Thing does not need to be present or extant.

Even though knowledge of the value of a dimension requires measurement, the dimension may be an object of discourse prior to, or even without, any measurement being made.

Examples:             

P41 classified (was classified by)

Domain:                            E17 Type Assignment

Range:                            E1 CRM Entity

Subproperty of:               E13 Attribute Assignment. P140 assigned attribute to (was attributed by): E1 CRM Entity

Quantification:                            many to one, necessary (1,1:0,n)

 

Scope note:              This property records the item to which a type was assigned in an E17 Type Assignment activity.

Any instance of a CRM entity may be assigned a type through type assignment. Type assignment events allow a more detailed path from E1 CRM Entity through P41 classified (was classified), E17 Type Assignment, P42 assigned (was assigned by) to E55 Type for assigning types to objects compared to the shortcut offered by P2 has type (is type of).

Examples:             

P42 assigned (was assigned by)

Domain:                            E17 Type Assignment

Range:                            E55 Type

Subproperty of:               E13 Attribute Assignment. P141 assigned (was assigned by): E1 CRM Entity

Quantification:                            many to many, necessary (1,n:0,n)

 

Scope note:              This property records the type that was assigned to an entity by an E17 Type Assignment activity.

Type assignment events allow a more detailed path from E1 CRM Entity through P41 classified (was classified by), E17 Type Assignment, P42 assigned (was assigned by) to E55 Type for assigning types to objects compared to the shortcut offered by P2 has type (is type of).

For example, a fragment of an antique vessel could be assigned the type “attic red figured belly handled amphora” by expert A. The same fragment could be assigned the type “shoulder handled amphora” by expert B.

A Type may be intellectually constructed independent from assigning an instance of it.

Examples:             

P43 has dimension (is dimension of)

Domain:                            E70 Thing

Range:                            E54 Dimension

Quantification:              one to many, dependent (0,n:1.1)

 

Scope note:              This property records a E54 Dimension of some E70 Thing.

It is a shortcut of the more fully developed path from E70 Thing through P39 measured (was measured by), E16 Measurement P40 observed dimension (was observed in) to E54 Dimension. It offers no information about how and when an E54 Dimension was established, nor by whom.

 

An instance of E54 Dimension is specific to an instance of E70 Thing.

Examples:             

P44 has condition (is condition of)

Domain:                            E18 Physical Thing

Range:                            E3 Condition State

Quantification:                            one to many, dependent (0,n:1,1)

 

Scope note:              This property records an E3 Condition State for some E18 Physical Thing.

 

It is a shortcut of the more fully developed path from E18 Physical Thing through P34 concerned (was assessed by), E14 Condition Assessment P35 has identified (was identified by) to E3 Condition State. It offers no information about how and when the E3 Condition State was established, nor by whom.

 

An instance of Condition State is specific to an instance of Physical Thing.

Examples:              

P45 consists of (is incorporated in)

Domain:                            E18 Physical Thing

Range:                            E57 Material

Quantification:                            many to many, necessary (1,n:0,n)

 

Scope note:              This property identifies the instances of E57 Materials of which an instance of E18 Physical Thing is composed.

 

All physical things consist of physical materials. P45 consists of (is incorporated in) allows the different Materials to be recorded. P45 consists of (is incorporated in) refers here to observed Material as opposed to the consumed raw material.

 

A Material, such as a theoretical alloy, may not have any physical instances.

Examples:             

P46 is composed of (forms part of)

 

Domain:                            E18 Physical Thing

Range:                            E18 Physical Thing

Superproperty of:E19 Physical Object. P56 bears feature (is found on): E26 Physical Feature

Quantification:              many to many (0,n:0,n)

 

Scope note:              This property allows instances of E18 Physical Thing to be analysed into component elements.

 

Component elements, since they are themselves instances of E18 Physical Thing, may be further analysed into sub-components, thereby creating a hierarchy of part decomposition. An instance of E18 Physical Thing may be shared between multiple wholes, for example two buildings may share a common wall.

 

This property is intended to describe specific components that are individually documented, rather than general aspects. Overall descriptions of the structure of an instance of E18 Physical Thing are captured by the P3 has note property.

 

The instances of E57 Materials of which an item of E18 Physical Thing is composed should be documented using P45 consists of (is incorporated in).

Examples: