ISO 21127:2006
(Main)Information and documentation - A reference ontology for the interchange of cultural heritage information
Information and documentation - A reference ontology for the interchange of cultural heritage information
ISO 21127:2006 establishes guidelines for the exchange of information between cultural heritage institutions. In simple terms this can be defined as the curated knowledge of museums. A more detailed definition can be articulated by defining both the intended scope, a broad and maximally inclusive definition of general principles, and the practical scope, which is defined by reference to a set of specific museum documentation standards and practices. The intended scope of ISO 21127:2006 is defined as the exchange and integration of heterogeneous scientific documentation relating to museum collections. This definition requires further elaboration: The term "scientific documentation" is intended to convey the requirement that the depth and quality of descriptive information that can be handled by ISO 21127:2006 need be sufficient for serious academic research. This does not mean that information intended for presentation to members of the general public is excluded, but rather that ISO 21127:2006 is intended to provide the level of detail and precision expected and required by museum professionals and researchers in the field. The term "museum collections" is intended to cover all types of material collected and displayed by museums and related institutions, as defined by ICOM. This includes collections, sites, and monuments relating to fields such as social history, ethnography, archaeology, fine and applied arts, natural history, history of sciences and technology. The documentation of collections includes the detailed description of individual items within collections, groups of items and collections as a whole. ISO 21127:2006 is specifically intended to cover contextual information (i.e. the historical, geographical, and theoretical background that gives museum collections much of their cultural significance and value). The exchange of relevant information with libraries and archives, and harmonization with their models, falls within the intended scope of ISO 21127:2006. Information required solely for the administration and management of cultural institutions, such as information relating to personnel, accounting, and visitor statistics, falls outside the intended scope of ISO 21127:2006. The practical scope of ISO 21127:2006 is the set of reference standards for museum documentation that have been used to guide and validate its development. ISO 21127:2006 covers the same domain of discourse as the union of these reference documents; this means that data correctly encoded according to any of these reference documents can be expressed in a compatible form, without any loss of meaning.
Information et documentation — Une ontologie de référence pour l'échange d'informations du patrimoine culturel
L'ISO 21127:2006 donne des lignes directrices pour l'échange d'informations entre institutions responsables du patrimoine culturel. Ceci peut être défini en termes plus simples comme la connaissance des conservateurs de musées. Une définition plus détaillée peut être formulée en définissant soit le domaine d'application de principe, une définition large et inclusive basée sur des principes généraux, soit le domaine d'application pratique, qui est défini par référence à une série de normes et de pratiques de documentation utilisées par les musées. Le domaine d'application de principe de l'ISO 21127:2006 peut être défini comme toutes les informations nécessaires pour l'échange et l'intégration de la documentation scientifique des collections de musée. Cette définition peut être développée: Le terme «documentation scientifique» est censé exprimer l'exigence que la profondeur et la qualité d'informations descriptives qui peuvent être traitées par l'ISO 21127:2006 ont besoin d'être suffisantes pour la recherche académique et scientifique. Cette exigence ne signifie pas pour autant que des informations destinées à la présentation au public ne sont pas prises en compte, mais surtout que l'ISO 21127:2006 est destinée à supporter le niveau de détail et de précision exigés par des professionnels des musées et des chercheurs dans le domaine. Le terme «collections de musées» englobe tout type de matériel rassemblé et exposé par des musées et des institutions apparentées, selon la définition de l'ICOM. Ceci inclut des collections, des sites et des monuments en rapport avec des domaines tels que l'histoire sociale, l'ethnographie, l'archéologie, les beaux-arts et les arts appliqués, l'histoire naturelle, l'histoire des sciences et de la technologie. La documentation des collections inclut la description détaillée d'objets individuels qui font partie des collections ainsi que des groupes d'objets et des collections dans leur ensemble. L'ISO 21127:2006 est spécifiquement censée couvrir des informations contextuelles (c'est-à-dire historiques, géographiques et théoriques qui donnent aux collections de musée leur signification culturelle et leur valeur). L'échange des informations avec les bibliothèques et les archives et l'harmonisation avec leurs modèles relève du domaine d'application de l'ISO 21127:2006. Les informations exigées seulement pour l'administration et la gestion des institutions culturelles, telles que les informations concernant la gestion personnelle, la comptabilité et les statistiques des visiteurs, échappent au domaine d'application de principe de l'ISO 21127:2006. Le domaine d'application pratique de l'ISO 21127:2006 est un ensemble de normes de référence pour la documentation des collections des musées, employés lors de son élaboration pour guider et pour valider son développement. L'ISO 21127:2006 couvre le même domaine de discours que l'ensemble de ces documents de référence; cela signifie que les données correctement codées selon n'importe lequel de ces documents de référence peuvent être exprimées dans une forme compatible avec la présente Norme internationale sans aucune perte de signification.
Informatika in dokumentacija - Referenčna ontologija za izmenjavo informacij o kulturni dediščini
General Information
Relations
Frequently Asked Questions
ISO 21127:2006 is a standard published by the International Organization for Standardization (ISO). Its full title is "Information and documentation - A reference ontology for the interchange of cultural heritage information". This standard covers: ISO 21127:2006 establishes guidelines for the exchange of information between cultural heritage institutions. In simple terms this can be defined as the curated knowledge of museums. A more detailed definition can be articulated by defining both the intended scope, a broad and maximally inclusive definition of general principles, and the practical scope, which is defined by reference to a set of specific museum documentation standards and practices. The intended scope of ISO 21127:2006 is defined as the exchange and integration of heterogeneous scientific documentation relating to museum collections. This definition requires further elaboration: The term "scientific documentation" is intended to convey the requirement that the depth and quality of descriptive information that can be handled by ISO 21127:2006 need be sufficient for serious academic research. This does not mean that information intended for presentation to members of the general public is excluded, but rather that ISO 21127:2006 is intended to provide the level of detail and precision expected and required by museum professionals and researchers in the field. The term "museum collections" is intended to cover all types of material collected and displayed by museums and related institutions, as defined by ICOM. This includes collections, sites, and monuments relating to fields such as social history, ethnography, archaeology, fine and applied arts, natural history, history of sciences and technology. The documentation of collections includes the detailed description of individual items within collections, groups of items and collections as a whole. ISO 21127:2006 is specifically intended to cover contextual information (i.e. the historical, geographical, and theoretical background that gives museum collections much of their cultural significance and value). The exchange of relevant information with libraries and archives, and harmonization with their models, falls within the intended scope of ISO 21127:2006. Information required solely for the administration and management of cultural institutions, such as information relating to personnel, accounting, and visitor statistics, falls outside the intended scope of ISO 21127:2006. The practical scope of ISO 21127:2006 is the set of reference standards for museum documentation that have been used to guide and validate its development. ISO 21127:2006 covers the same domain of discourse as the union of these reference documents; this means that data correctly encoded according to any of these reference documents can be expressed in a compatible form, without any loss of meaning.
ISO 21127:2006 establishes guidelines for the exchange of information between cultural heritage institutions. In simple terms this can be defined as the curated knowledge of museums. A more detailed definition can be articulated by defining both the intended scope, a broad and maximally inclusive definition of general principles, and the practical scope, which is defined by reference to a set of specific museum documentation standards and practices. The intended scope of ISO 21127:2006 is defined as the exchange and integration of heterogeneous scientific documentation relating to museum collections. This definition requires further elaboration: The term "scientific documentation" is intended to convey the requirement that the depth and quality of descriptive information that can be handled by ISO 21127:2006 need be sufficient for serious academic research. This does not mean that information intended for presentation to members of the general public is excluded, but rather that ISO 21127:2006 is intended to provide the level of detail and precision expected and required by museum professionals and researchers in the field. The term "museum collections" is intended to cover all types of material collected and displayed by museums and related institutions, as defined by ICOM. This includes collections, sites, and monuments relating to fields such as social history, ethnography, archaeology, fine and applied arts, natural history, history of sciences and technology. The documentation of collections includes the detailed description of individual items within collections, groups of items and collections as a whole. ISO 21127:2006 is specifically intended to cover contextual information (i.e. the historical, geographical, and theoretical background that gives museum collections much of their cultural significance and value). The exchange of relevant information with libraries and archives, and harmonization with their models, falls within the intended scope of ISO 21127:2006. Information required solely for the administration and management of cultural institutions, such as information relating to personnel, accounting, and visitor statistics, falls outside the intended scope of ISO 21127:2006. The practical scope of ISO 21127:2006 is the set of reference standards for museum documentation that have been used to guide and validate its development. ISO 21127:2006 covers the same domain of discourse as the union of these reference documents; this means that data correctly encoded according to any of these reference documents can be expressed in a compatible form, without any loss of meaning.
ISO 21127:2006 is classified under the following ICS (International Classification for Standards) categories: 35.240.30 - IT applications in information, documentation and publishing. The ICS classification helps identify the subject area and facilitates finding related standards.
ISO 21127:2006 has the following relationships with other standards: It is inter standard links to ISO 21127:2014. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.
You can purchase ISO 21127:2006 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of ISO standards.
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 21127
First edition
2006-09-15
Information and documentation —
A reference ontology for the interchange
of cultural heritage information
Information et documentation — Une ontologie de référence pour
l'échange d'informations du patrimoine culturel
Reference number
©
ISO 2006
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO 2006
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2006 – All rights reserved
Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Conformance. 2
3 Terms and definitions. 2
4 Structure and presentation. 6
4.1 Property quantifiers. 6
4.2 Naming conventions. 8
5 Modelling principles . 8
5.1 Monotonicity. 8
5.2 Minimality . 9
5.3 Shortcuts . 9
5.4 Disjointness. 9
5.5 Types. 10
5.6 Extensions. 10
5.7 Coverage of intended scope. 11
6 Class declarations . 11
7 Property declarations. 55
Annex A (informative) Class hierarchy . 101
Annex B (informative) Property hierarchy . 103
Bibliography . 108
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 21127 was prepared by Technical Committee ISO/TC 46, Information and documentation, Subcommittee
SC 4, Technical interoperability, in collaboration with the International Council of Museums Committee for
Documentation (ICOM CIDOC).
iv © ISO 2006 – All rights reserved
Introduction
This International Standard 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 this International Standard began in 1996 under the auspices of the ICOM-CIDOC Documentation
Standards Working Group. Throughout its development, the model has been known as the “CIDOC
Conceptual Reference Model” or CRM. References to the CRM can be considered throughout as synonymous
with ISO 21127.
The primary purpose of this International Standard is to offer a conceptual basis for the mediation of
information between cultural heritage organizations such as museums, libraries and archives. This
International Standard aims to provide a common reference point against which divergent and incompatible
sources of information can be compared and, ultimately, harmonized.
1)
ISO 21127 is a domain ontology for cultural heritage information: a formal representation of the conceptual
scheme, or “world view”, underlying the database applications and documentation systems that are used by
cultural heritage institutions. It is important to note that this International Standard aims to clarify the logic of
what cultural heritage institutions do in fact document; it is not intended as a normative specification of what
they should document. The primary role of this International Standard is to enable information exchange and
integration between heterogeneous sources of cultural heritage information. It aims to provide the semantic
definitions and clarifications needed to transform disparate, localized information sources into a coherent
global resource, be it within an institution, an intranet or on the Internet.
The specific aims of this International Standard are to:
⎯ Serve as a common language for domain experts and IT developers when formulating requirements.
⎯ Serve as a formal language for the identification of common information contents in different data formats;
in particular to support the implementation of automatic data transformation algorithms from local to
global data structures without loss of meaning. These transformation algorithms are useful for data
exchange, data migration from legacy systems, data information integration, and mediation of
heterogeneous sources.
⎯ Support associative queries against integrated resources by providing a global model of the basic classes
and their associations to formulate such queries.
⎯ Provide developers of information systems with a guide to good practice in conceptual modelling.
The CRM ontology is expressed as a series of interrelated concepts with definitions. This presentation is
similar to that used for a thesaurus. However, the ontology is not intended as a terminology standard and
does not set out to define the terms that are typically used as data in cultural heritage documentation.
Although the presentation provided here is complete, it is an intentionally compact and concise presentation of
the ontology's 80 classes and 130 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 130). However, this definition does contain all the information needed to
infer and automatically generate a full declaration of all properties, including inherited properties.
1) In the sense used in computer science, i.e. it describes in a formal language the relevant explicit and implicit concepts
[1]
and the relationships between them .
INTERNATIONAL STANDARD ISO 21127:2006(E)
Information and documentation — A reference ontology for
the interchange of cultural heritage information
1 Scope
This International Standard establishes guidelines for the exchange of information between cultural heritage
institutions. In simple terms this can be defined as the curated knowledge of museums.
A more detailed definition can be articulated by defining both the intended scope, a broad and maximally
inclusive definition of general principles, and the practical scope, which is defined by reference to a set of
specific museum documentation standards and practices.
The intended scope of this International Standard is defined as the exchange and integration of
heterogeneous scientific documentation relating to museum collections. This definition requires further
elaboration:
⎯ The term “scientific documentation” is intended to convey the requirement that the depth and quality of
descriptive information that can be handled by this International Standard need be sufficient for serious
academic research. This does not mean that information intended for presentation to members of the
general public is excluded, but rather that this International Standard is intended to provide the level of
detail and precision expected and required by museum professionals and researchers in the field.
⎯ The term “museum collections” is intended to cover all types of material collected and displayed by
2)
museums and related institutions, as defined by ICOM . This includes collections, sites, and monuments
relating to fields such as social history, ethnography, archaeology, fine and applied arts, natural history,
history of sciences and technology.
⎯ The documentation of collections includes the detailed description of individual items within collections,
groups of items and collections as a whole. This International Standard is specifically intended to cover
contextual information (i.e. the historical, geographical, and theoretical background that gives museum
collections much of their cultural significance and value).
⎯ The exchange of relevant information with libraries and archives, and harmonization with their models,
falls within the intended scope of this International Standard.
⎯ Information required solely for the administration and management of cultural institutions, such as
information relating to personnel, accounting and visitor statistics, falls outside the intended scope of this
International Standard.
3)
The practical scope of this International Standard is the set of reference standards for museum documentation
that have been used to guide and validate its development. This International Standard covers the same
domain of discourse as the union of these reference documents; this means that data correctly encoded
according to any of these reference documents can be expressed in a compatible form, without any loss of
meaning.
2) The ICOM Statutes provide a definition of the term “museum” at .
3) The practical scope of the CIDOC CRM, including a list of the relevant museum documentation standards, is
discussed in more detail on the CIDOC CRM website at .
2 Conformance
Users intending to take advantage of the semantic interoperability offered by this International Standard
should ensure conformance with the relevant data structures. Conformance pertains either to data to be made
accessible in an integrated environment, or to contents intended for transport to other environments. Any
encoding of data in a formal language that preserves the relations of the classes, properties and inheritance
rules defined by this International Standard is regarded as conformant.
Conformance with this International Standard does not require complete matching of all local documentation
structures, nor that all concepts and structures present in this International Standard be implemented. This
International Standard is intended to allow room both for extensions, needed to capture the full richness of
cultural information, and for simplification, in the interests of economy. A system will be deemed partially
conformant if it supports a subset of subclasses and subproperties defined by this International Standard.
Designers of the system should publish details of the constructs that are supported.
The focus of this International Standard is on the transport and mediation of structured information. It does not
provide or require interpretation of unstructured free-text information into a structured, logical form. Free-text
information, while supported, falls outside the scope of conformance considerations.
Any documentation system will be deemed conformant with this International Standard, regardless of the
internal data structures it uses, if a deterministic logical algorithm can be constructed that transforms data
contained in the system into a directly compatible form without loss of meaning. No assumptions are made as
to the nature of this algorithm. “Without loss of meaning” signifies that designers and users of the system are
satisfied that the data representation corresponds to the semantic definitions provided by this International
Standard.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply. We have selected these terms
for ease of understanding by non-computer experts from the various terminologies in use for object-oriented
models.
3.1
class
category of items that share one or more common properties
NOTE Class properties serve as criteria to identify items that belong to the class. These properties need not be
explicitly formulated in logical terms, but can be described in a text (called a scope note) that refers to a common
conceptualisation of domain experts. The sum of these properties is called the intension of the class. A class can 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 can bring new instances into being 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 need to have an unambiguously defined domain
and range). For example, “Person” is a class. A “Person” can have the property of being a member of a “Group”, but this is
not a necessary condition for being a “Person”. We will never know all “Persons” who have lived in the past, and there will
be more “Persons” in the future. Classes are usually organized as a class hierarchy. The relationship between a subclass
and its superclass is known as the IsA relationship (a concatenation of the words “is a”). For example, a ship IsA vehicle.
3.2
complement
〈of a class A〉 set of all instances of its superclass, B, that are not instances of class A
NOTE In terms of set theory, the complement of a class is the extension of the superclass minus the extension of the
class. Compatible extensions of this International Standard need not declare any class as the complement of one or more
other classes. To do so would violate the goal of describing an Open World. For example, for all possible cases of human
gender, “male” need not be declared as the complement of “female” or vice versa.
2 © ISO 2006 – All rights reserved
3.3
disjoint
having no common instances in any possible world
NOTE 1 Classes are disjoint if the intersection of their extensions is necessarily an empty set.
NOTE 2 See also 5.4.
3.4
domain
class for which a property is formally defined
NOTE Instances of a property are applicable to instances of its domain class. A property needs to have exactly one
domain, though the domain class can always contain instances for which the property is not instantiated. The domain
class is analogous to the grammatical subject of a phrase while the property is analogous to the verb. Which class is
selected as the domain and which as the range is arbitrary, as is the choice between active or passive voice. Property
names in the CRM are designed to be semantically meaningful and grammatically correct when read from domain to
range. The inverse property name, given in parentheses, is also designed to be semantically meaningful and
grammatically correct when read from range to domain.
3.5
extension
set of all real life instances belonging to a class that fulfil the criteria of its intension
NOTE 1 The extension of a class is an “open” set in the sense that it is generally beyond our capabilities to know all
instances of a class in the world. The future can bring new instances into being 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.
NOTE 2 See also 5.6.
3.6
inheritance
duplication of properties from a class to its subclasses
NOTE Inheritance of properties from superclasses to subclasses entails that if an item x is an instance of a class A,
then all properties that need hold for the instances of any of the superclasses of A need also hold for item x, and that all
optional properties that can hold for the instances of any of the superclasses of A can also hold for item x.
3.7
instance
item having properties that meet the criteria of the intension of the class
NOTE “The Mona Lisa” is an instance of the class of “physical man-made objects”. 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”. The number of instances of a class declared in an information system is usually less than the total
number of instances in the real world. For example, although you are an instance of “person”, you are not mentioned in all
information systems describing “persons”.
3.8
intension
intended meaning of a class
NOTE The intension of a class consists of one or more common properties, or traits shared by all instances of the
class. These properties need not be explicitly formulated in logical terms, but can simply be described in a text (a scope
note) that refers to a conceptualization shared by domain experts.
3.9
interoperability
capability of different information systems to communicate some of their contents
NOTE Interoperability can imply that
a) two systems can exchange information, and/or
b) multiple systems can be accessed with a single method.
Generally, syntactic interoperability is distinguished from semantic interoperability. Syntactic interoperability means that
the information encoding and the access protocols of the relevant systems are compatible, so that information can be
processed as described above without error. However, syntactic interoperability alone does not ensure that each system
processes the data in a manner consistent with the intended meaning. For example, one system can use a table called
“Actor” and another one called “Agent”. Data from the two tables might remain separated, even though they can 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.
3.10
monotonic
〈of a knowledge base〉 having a set of conclusions derived via inference rules that does not reduce,
irrespective of the whatever additional propositions can be inserted
NOTE 1 Monotonic reasoning is a term derived from knowledge representation. In practical terms, as experts enter
correct statements to an information system, the system need not regard any of the existing statements as invalid. The
CRM ontology is designed for monotonic reasoning and so enables conflict-free merging of huge stores of knowledge.
NOTE 2 See also 5.1.
3.11
multiple inheritance
possibility for a class to have more than one immediate superclass
NOTE 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, then some classes will
inevitably be repeated at different positions in the hierarchy. For example, “person” is both an “actor” and a “biological
object”.
3.12
open world
assumption that the information stored in a knowledge base is incomplete with respect to the universe of
discourse it aims to describe
NOTE A term derived from knowledge representation. The incompleteness of a knowledge base can be due to the
inability of the maintainer to provide sufficient information, or to more fundamental problems of cognition in the system’s
domain. Such problems are characteristic of cultural information systems since our records about the past are necessarily
incomplete. In addition, some items cannot be clearly assigned to a given class. In particular, the absence of a certain
property for an item described in the system does not necessarily entail that the item does not possess the property. For
example, if one item is described as “biological object” and another as “physical object”, this does not imply that the latter
is not also a “biological object”. Therefore, complements of a class with respect to a superclass cannot be derived in
general from an information system based on the open world assumption.
3.13
primitive concept
concept that is declared and for which the meaning is clear, but which cannot be derived from other concepts
NOTE Primitive concept is a term derived from knowledge representation. For example, mother can be described as
a female who has given birth to a child, so mother is not a primitive concept. Event however is a primitive concept. The
CRM is composed primarily of primitive concepts.
3.14
property
defining characteristic that serves to define a relationship of a specific kind between two classes
4 © ISO 2006 – All rights reserved
NOTE A property is characterized by an intension, which is conveyed by a scope note. A property plays a role
analogous to a verb in that it need be defined with reference to both a domain and range, which are analogous to the
subject and object in a phrase (unlike classes, which can be defined independently). Which class is selected as the
domain and which as the range, is arbitrary, as is the choice between active and passive voice. In other words, a property
can be interpreted in both directions, with two distinct but related interpretations. Properties can 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. For example, “physical man-made thing depicts CRM entity” is equivalent to
“CRM entity is depicted by physical man-made thing”.
3.15
query containment
query X contains another query Y if, for each possible population of a database, the answer set to query X also
contains the answer set to query Y
NOTE If query X and Y were classes, then X would be a superclass of Y.
3.16
range
class that comprises all the potential values of a property
NOTE Instances of a property can only link to instances of its range class. A property needs to have exactly one
range, though the range class can also contain instances that are not values of the property. The range class is analogous
to the grammatical object of a phrase, while the property is analogous to the verb. Which class is selected as domain, and
which as range, is arbitrary, as is the choice between active and passive voice. Property names in the CRM are designed
to be semantically meaningful and grammatically correct when read from domain to range. The inverse property name,
given in parentheses, is designed to be semantically meaningful and grammatically correct when read from range to
domain.
3.17
scope note
textual description of the intension of a class or property
NOTE 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 conceptualization shared by domain experts and
disambiguate different possible interpretations. Illustrative examples of classes and properties are also provided with the
scope notes for explanatory purposes.
3.18
shortcut
formally defined single property that represents a deduction or join of a data path in the CRM
NOTE 1 The scope notes of shortcut properties provide a verbal description of the equivalent deduction. Shortcuts are
introduced for those 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
E16 measurement activity that observed it. The CRM allows shortcuts as cases of less detailed knowledge, while
preserving in its schema the relationship to the full information.
NOTE 2 See also 5.3.
3.19
strict inheritance
properties inheritance that allows no exceptions
NOTE Some systems can declare that “elephants are grey”, and regard a white elephant as an exception. Under
strict inheritance rules it would hold that if all elephants were indeed grey, then a white elephant could not be an elephant.
Obviously not all elephants are grey; being grey is not part of the intension of the concept elephant but an optional
property. The CRM applies strict inheritance as a normalization principle.
3.20
subclass
specialization of another class, i.e. the superclass
NOTE A subclass inherits all the properties of its superclass (i.e. strict inheritance), in addition to having none, one,
or more additional properties of its own. A subclass can have more than one immediate superclass, and consequently
inherits the properties of all of its superclasses (i.e. multiple inheritance). A subclass has an IsA relationship to its
superclass(es): every instance of the subclass is also, by definition, an instance of the superclass(es). For example, every
“person” IsA “biological object”.
3.21
subproperty
specialization of another property, i.e. the superproperty
NOTE 1 All instances of a subproperty are also instances of its superproperty. The intension of a subproperty extends
the intension of its superproperty, i.e. its traits are more restrictive than that of its superproperty. The domain of a
subproperty is a subclass of the domain of its superproperty. The range of a subproperty is a subclass of the range of its
superproperty. Instances of a subproperty inherit 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 their own.
NOTE 2 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 can not be cyclic. In some object-
oriented languages, including C++, there is no equivalent to the specialization of properties.
3.22
superclass
generalization of one or more other classes, i.e. the subclasses
NOTE A superclass subsumes all instances of its subclasses, and 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. The
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”. Fewer properties are needed to
identify an item as a “biological object” than to identify it as a “person”.
3.23
superproperty
generalization of one or more other properties, i.e. the subproperties
NOTE A superproperty subsumes all instances of its subproperties, and 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.
4 Structure and presentation
4.1 Property quantifiers
Quantifiers for properties are provided for the purpose of semantic clarification only, and should not be treated
as implementation recommendations. This International Standard has been designed to accommodate
alternative opinions and incomplete information; all properties should therefore be implemented as optional
and repeatable for their domain and range (“many to many (0,n:0,n)”). The term “cardinality constraints” is
avoided here as it typically pertains to implementations.
Table 1 lists all possible property quantifiers occurring in this document according to their notation, together
with a textual explanation. In order to provide optimal clarity, two widely accepted notations are used in this
International Standard, i.e. one verbal, the other numerical. The verbal notation uses phrases such as “one to
many”, and the numerical notation expressions such as “(0,n:0,1)”. The terms “one”, “many” and “necessary”
are fairly intuitive; the term “dependent” is less obvious. It 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.
6 © ISO 2006 – All rights reserved
Table 1 — Property quantifiers
Quantifier Description
many to many Unconstrained: an individual domain instance and range instance of this property can have zero,
one, or more instances of the property. In other words, the property is optional and repeatable
(0,n:0,n)
for its domain and range.
one to many An individual domain instance of this property can have zero, one, or more instances of the
property, but an individual range instance cannot be referenced by more than one instance of
(0,n:0,1)
this property. In other words, the property is optional for its domain and range, but repeatable for
its domain only. This situation is sometimes called a “fan-out”.
many to one An individual domain instance of this property can have zero or one instance of the property, but
an individual range instance can be referenced by zero, one, or more instances of the property.
(0,1:0,n)
In other words, the property is optional for its domain and range, but repeatable for its range
only. This situation is sometimes called a “fan-in”.
many to many, An individual domain instance of this property can have one or more instances of the property,
necessary but an individual range instance can have zero, one, or more instances of the property. In other
words, the property is necessary and repeatable for its domain, and optional and repeatable for
(1,n:0,n)
its range.
one to many, An individual domain instance of this property can have one or more instances of the property,
necessary but an individual range instance cannot be referenced by more than one instance of the
property. In other words, the property is necessary and repeatable for its domain, and optional
(1,n:0,1)
but not repeatable for its range. This situation is sometimes called a “fan-out”.
many to one, An individual domain instance of this property shall have exactly one instance of the property,
necessary but an individual range instance can be referenced by zero, one, or more instances of the
property. In other words, the property is necessary and not repeatable for its domain, and
(1,1:0,n)
optional and repeatable for its range. This situation is sometimes called a “fan-in”.
one to many, An individual domain instance of this property can have zero, one, or more instances of the
dependent property, but an individual range instance shall be referenced by exactly one instance of the
property. In other words, this property is optional and repeatable for its domain, but necessary
(0,n:1,1)
and not repeatable for its range. This situation is sometimes called a “fan-out”.
one to many, An individual domain instance of this property can have one or more instances of the property,
necessary, dependent but an individual range instance shall be referenced by exactly one instance of the property. In
other words, the property is necessary and repeatable for its domain, and necessary but not
(1,n:1,1)
repeatable for its range. This situation is sometimes called a “fan-out”
many to one, An individual domain instance of this property shall have exactly one instance of the property,
necessary, dependent but an individual range instance can be referenced by one or more instances of the property. In
other words, this property is necessary and not repeatable for its domain, and necessary and
(1,1:1,n)
repeatable for its range. This situation is sometimes called a “fan-in”
one to one An individual domain instance and range instance of this property shall have exactly one
instance of the property. In other words, the property is necessary and not repeatable for its
(1,1:1,1)
domain and for its range.
NOTE Some properties are defined as being necessary for their domain or as being dependent on their range. If such properties
are not specified for an instance of the respective domain or range, it means that the property exists, but that the value on one side of
the property is unknown. In the case of optional properties, no distinction is made between a value being unknown or the property not
being applicable at all. For example, one can know that an object has an owner, but not know who the owner is, or know that an object
has no owner. The model makes no distinction between these two cases. A textual note can be used for clarification if needed.
4.2 Naming conventions
The following naming conventions have been applied hereafter:
4)
⎯ Classes are identified by numbers preceded by the letter “E” (historically classes were sometimes
referred to as “Entities”), and are named using noun phrases (nominal groups) in title case (initial capitals).
For example, E63 Beginning of Existence.
⎯ Properties are identified by numbers preceded by the letter “P,” and are named in both directions, using
verbal phrases in lower case. Properties with the character of states are named in the present tense,
such as “has type”, whereas properties relating to events are named in past tense, such as “carried out”.
For example, P126 employed (was employed by).
⎯ Property names should be read in their non-parenthetical form for the domain-to-range direction, and in
parenthetical form for the range-to-domain direction.
⎯ Properties with a range that is a subclass of E59 Primitive Value (such as E1 CRM Entity.P2 has note:
E62 String) have no parenthetical name form as reading the property name in the range-to-domain
direction is not regarded as meaningful.
⎯ Properties that have identical domain and range are either symmetric or transitive. Instantiating a
symmetric property implies that the relation holds for both the domain-to-range and the range-to-domain
directions. An example of this is E53 Place.P122 borders with: E53 Place. The names of symmetric
properties have no parenthetical form, because reading in the range-to-domain direction is the same as
the domain-to-range reading. Transitive asymmetric properties, such as E4 Period. P9 consists of (forms
part of): E4 Period, do have a parenthetical form that relates to the meaning of the inverse direction.
⎯ The choice of property domains, and hence the order of their names, is established in accordance with
the following priority list:
1) Temporal Entity and its subclasses;
2) Thing and its subclasses;
3) Actor and its subclasses;
4) Other.
5 Modelling principles
5.1 Monotonicity
Because this International Standard's primary role is the meaningful integration of information in an Open
World, it aims to be monotonic in the sense of Domain Theory. Existing constructs, and deductions made from
them, shall always remain valid and well-formed, i.e. even if new constructs and extensions are added.
For example, one may add a subclass of E7 Activity to describe the use of a certain name for a place over a
certain time-span by a particular group. By this extension, no existing IsA Relationships or property
inheritances are compromised.
In addition, this International Standard aims to enable the formal preservation of monotonicity when
augmenting a compatible system. Existing instances, their properties, and deductions made from them,
should always remain valid and well-formed even as new instances are added to the system.
4) Some gaps are present in the numbering sequence used for classes are properties. This is intentional: numbers
assigned in previous versions of the CRM to deprecated classes and properties have not been re-used.
8 © ISO 2006 – All rights reserved
For example, if someone describes correctly that an item is an instance of E19 Physical Object and,
subsequently, 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 in cases where opinions diverge, all formally defined properties
should be implemented with unconstrained cardinality (many:many) so that conflicting instances of properties
are merely accumulated. Knowledge stored in a conformant system can thus serve as a research base,
accumulating relevant alternative opinions around well-defined entities. Conclusions about the truth or
falsehood of the instances stored remain the subject of open-ended scientific or scholarly hypothesis building.
For example, “El Greco” and even “King Arthur” should be treated as instances of E21 Person and be dealt
with as existing within the domain of discourse once they are entered into a knowledge base. Alternative
opinions about properties, such as their birthplace and the details of their lives, may be accumulated without
decisions concerning their veracity being required during data compilation.
5.2 Minimality
Although the scope of this International Standard is very broad, the ontology itself is constructed as
economically as possible.
⎯ A class is not declared unless it is required as the domain or range of a property not appropriate to its
superclass, or it is a key concept in the practical scope.
⎯ Classes and properties that share a superclass are non-exclusive by default. For example, an object may
be both an instance of E20 Biological Object and E22 Man-made Object.
⎯ Classes and properties are either primitive, or constitute key concepts in the practical scope.
⎯ Complements of classes are not declared.
5.3 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: 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.
5.4 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 would easily become inconsistent with the goal
of providing a concise definition. However, the two following examples of disjoint class pairs are fundamental
to an effective comprehension of the CRM ontology.
5.4.1 E2 Temporal Entity is disjoint from E77 Persistent Item
Instances of the class E2 Temporal
...
SLOVENSKI STANDARD
01-december-2009
,QIRUPDWLNDLQGRNXPHQWDFLMD5HIHUHQþQDRQWRORJLMD]DL]PHQMDYRLQIRUPDFLMR
NXOWXUQLGHGLãþLQL
Information and documentation - A reference ontology for the interchange of cultural
heritage information
Information et documentation - Une ontologie de référence pour l'échange d'informations
du patrimoine culturel
Ta slovenski standard je istoveten z: ISO 21127:2006
ICS:
35.240.30 Uporabniške rešitve IT v IT applications in information,
informatiki, dokumentiranju in documentation and
založništvu publishing
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
INTERNATIONAL ISO
STANDARD 21127
First edition
2006-09-15
Information and documentation —
A reference ontology for the interchange
of cultural heritage information
Information et documentation — Une ontologie de référence pour
l'échange d'informations du patrimoine culturel
Reference number
©
ISO 2006
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO 2006
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2006 – All rights reserved
Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Conformance. 2
3 Terms and definitions. 2
4 Structure and presentation. 6
4.1 Property quantifiers. 6
4.2 Naming conventions. 8
5 Modelling principles . 8
5.1 Monotonicity. 8
5.2 Minimality . 9
5.3 Shortcuts . 9
5.4 Disjointness. 9
5.5 Types. 10
5.6 Extensions. 10
5.7 Coverage of intended scope. 11
6 Class declarations . 11
7 Property declarations. 55
Annex A (informative) Class hierarchy . 101
Annex B (informative) Property hierarchy . 103
Bibliography . 108
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 21127 was prepared by Technical Committee ISO/TC 46, Information and documentation, Subcommittee
SC 4, Technical interoperability, in collaboration with the International Council of Museums Committee for
Documentation (ICOM CIDOC).
iv © ISO 2006 – All rights reserved
Introduction
This International Standard 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 this International Standard began in 1996 under the auspices of the ICOM-CIDOC Documentation
Standards Working Group. Throughout its development, the model has been known as the “CIDOC
Conceptual Reference Model” or CRM. References to the CRM can be considered throughout as synonymous
with ISO 21127.
The primary purpose of this International Standard is to offer a conceptual basis for the mediation of
information between cultural heritage organizations such as museums, libraries and archives. This
International Standard aims to provide a common reference point against which divergent and incompatible
sources of information can be compared and, ultimately, harmonized.
1)
ISO 21127 is a domain ontology for cultural heritage information: a formal representation of the conceptual
scheme, or “world view”, underlying the database applications and documentation systems that are used by
cultural heritage institutions. It is important to note that this International Standard aims to clarify the logic of
what cultural heritage institutions do in fact document; it is not intended as a normative specification of what
they should document. The primary role of this International Standard is to enable information exchange and
integration between heterogeneous sources of cultural heritage information. It aims to provide the semantic
definitions and clarifications needed to transform disparate, localized information sources into a coherent
global resource, be it within an institution, an intranet or on the Internet.
The specific aims of this International Standard are to:
⎯ Serve as a common language for domain experts and IT developers when formulating requirements.
⎯ Serve as a formal language for the identification of common information contents in different data formats;
in particular to support the implementation of automatic data transformation algorithms from local to
global data structures without loss of meaning. These transformation algorithms are useful for data
exchange, data migration from legacy systems, data information integration, and mediation of
heterogeneous sources.
⎯ Support associative queries against integrated resources by providing a global model of the basic classes
and their associations to formulate such queries.
⎯ Provide developers of information systems with a guide to good practice in conceptual modelling.
The CRM ontology is expressed as a series of interrelated concepts with definitions. This presentation is
similar to that used for a thesaurus. However, the ontology is not intended as a terminology standard and
does not set out to define the terms that are typically used as data in cultural heritage documentation.
Although the presentation provided here is complete, it is an intentionally compact and concise presentation of
the ontology's 80 classes and 130 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 130). However, this definition does contain all the information needed to
infer and automatically generate a full declaration of all properties, including inherited properties.
1) In the sense used in computer science, i.e. it describes in a formal language the relevant explicit and implicit concepts
[1]
and the relationships between them .
INTERNATIONAL STANDARD ISO 21127:2006(E)
Information and documentation — A reference ontology for
the interchange of cultural heritage information
1 Scope
This International Standard establishes guidelines for the exchange of information between cultural heritage
institutions. In simple terms this can be defined as the curated knowledge of museums.
A more detailed definition can be articulated by defining both the intended scope, a broad and maximally
inclusive definition of general principles, and the practical scope, which is defined by reference to a set of
specific museum documentation standards and practices.
The intended scope of this International Standard is defined as the exchange and integration of
heterogeneous scientific documentation relating to museum collections. This definition requires further
elaboration:
⎯ The term “scientific documentation” is intended to convey the requirement that the depth and quality of
descriptive information that can be handled by this International Standard need be sufficient for serious
academic research. This does not mean that information intended for presentation to members of the
general public is excluded, but rather that this International Standard is intended to provide the level of
detail and precision expected and required by museum professionals and researchers in the field.
⎯ The term “museum collections” is intended to cover all types of material collected and displayed by
2)
museums and related institutions, as defined by ICOM . This includes collections, sites, and monuments
relating to fields such as social history, ethnography, archaeology, fine and applied arts, natural history,
history of sciences and technology.
⎯ The documentation of collections includes the detailed description of individual items within collections,
groups of items and collections as a whole. This International Standard is specifically intended to cover
contextual information (i.e. the historical, geographical, and theoretical background that gives museum
collections much of their cultural significance and value).
⎯ The exchange of relevant information with libraries and archives, and harmonization with their models,
falls within the intended scope of this International Standard.
⎯ Information required solely for the administration and management of cultural institutions, such as
information relating to personnel, accounting and visitor statistics, falls outside the intended scope of this
International Standard.
3)
The practical scope of this International Standard is the set of reference standards for museum documentation
that have been used to guide and validate its development. This International Standard covers the same
domain of discourse as the union of these reference documents; this means that data correctly encoded
according to any of these reference documents can be expressed in a compatible form, without any loss of
meaning.
2) The ICOM Statutes provide a definition of the term “museum” at .
3) The practical scope of the CIDOC CRM, including a list of the relevant museum documentation standards, is
discussed in more detail on the CIDOC CRM website at .
2 Conformance
Users intending to take advantage of the semantic interoperability offered by this International Standard
should ensure conformance with the relevant data structures. Conformance pertains either to data to be made
accessible in an integrated environment, or to contents intended for transport to other environments. Any
encoding of data in a formal language that preserves the relations of the classes, properties and inheritance
rules defined by this International Standard is regarded as conformant.
Conformance with this International Standard does not require complete matching of all local documentation
structures, nor that all concepts and structures present in this International Standard be implemented. This
International Standard is intended to allow room both for extensions, needed to capture the full richness of
cultural information, and for simplification, in the interests of economy. A system will be deemed partially
conformant if it supports a subset of subclasses and subproperties defined by this International Standard.
Designers of the system should publish details of the constructs that are supported.
The focus of this International Standard is on the transport and mediation of structured information. It does not
provide or require interpretation of unstructured free-text information into a structured, logical form. Free-text
information, while supported, falls outside the scope of conformance considerations.
Any documentation system will be deemed conformant with this International Standard, regardless of the
internal data structures it uses, if a deterministic logical algorithm can be constructed that transforms data
contained in the system into a directly compatible form without loss of meaning. No assumptions are made as
to the nature of this algorithm. “Without loss of meaning” signifies that designers and users of the system are
satisfied that the data representation corresponds to the semantic definitions provided by this International
Standard.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply. We have selected these terms
for ease of understanding by non-computer experts from the various terminologies in use for object-oriented
models.
3.1
class
category of items that share one or more common properties
NOTE Class properties serve as criteria to identify items that belong to the class. These properties need not be
explicitly formulated in logical terms, but can be described in a text (called a scope note) that refers to a common
conceptualisation of domain experts. The sum of these properties is called the intension of the class. A class can 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 can bring new instances into being 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 need to have an unambiguously defined domain
and range). For example, “Person” is a class. A “Person” can have the property of being a member of a “Group”, but this is
not a necessary condition for being a “Person”. We will never know all “Persons” who have lived in the past, and there will
be more “Persons” in the future. Classes are usually organized as a class hierarchy. The relationship between a subclass
and its superclass is known as the IsA relationship (a concatenation of the words “is a”). For example, a ship IsA vehicle.
3.2
complement
〈of a class A〉 set of all instances of its superclass, B, that are not instances of class A
NOTE In terms of set theory, the complement of a class is the extension of the superclass minus the extension of the
class. Compatible extensions of this International Standard need not declare any class as the complement of one or more
other classes. To do so would violate the goal of describing an Open World. For example, for all possible cases of human
gender, “male” need not be declared as the complement of “female” or vice versa.
2 © ISO 2006 – All rights reserved
3.3
disjoint
having no common instances in any possible world
NOTE 1 Classes are disjoint if the intersection of their extensions is necessarily an empty set.
NOTE 2 See also 5.4.
3.4
domain
class for which a property is formally defined
NOTE Instances of a property are applicable to instances of its domain class. A property needs to have exactly one
domain, though the domain class can always contain instances for which the property is not instantiated. The domain
class is analogous to the grammatical subject of a phrase while the property is analogous to the verb. Which class is
selected as the domain and which as the range is arbitrary, as is the choice between active or passive voice. Property
names in the CRM are designed to be semantically meaningful and grammatically correct when read from domain to
range. The inverse property name, given in parentheses, is also designed to be semantically meaningful and
grammatically correct when read from range to domain.
3.5
extension
set of all real life instances belonging to a class that fulfil the criteria of its intension
NOTE 1 The extension of a class is an “open” set in the sense that it is generally beyond our capabilities to know all
instances of a class in the world. The future can bring new instances into being 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.
NOTE 2 See also 5.6.
3.6
inheritance
duplication of properties from a class to its subclasses
NOTE Inheritance of properties from superclasses to subclasses entails that if an item x is an instance of a class A,
then all properties that need hold for the instances of any of the superclasses of A need also hold for item x, and that all
optional properties that can hold for the instances of any of the superclasses of A can also hold for item x.
3.7
instance
item having properties that meet the criteria of the intension of the class
NOTE “The Mona Lisa” is an instance of the class of “physical man-made objects”. 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”. The number of instances of a class declared in an information system is usually less than the total
number of instances in the real world. For example, although you are an instance of “person”, you are not mentioned in all
information systems describing “persons”.
3.8
intension
intended meaning of a class
NOTE The intension of a class consists of one or more common properties, or traits shared by all instances of the
class. These properties need not be explicitly formulated in logical terms, but can simply be described in a text (a scope
note) that refers to a conceptualization shared by domain experts.
3.9
interoperability
capability of different information systems to communicate some of their contents
NOTE Interoperability can imply that
a) two systems can exchange information, and/or
b) multiple systems can be accessed with a single method.
Generally, syntactic interoperability is distinguished from semantic interoperability. Syntactic interoperability means that
the information encoding and the access protocols of the relevant systems are compatible, so that information can be
processed as described above without error. However, syntactic interoperability alone does not ensure that each system
processes the data in a manner consistent with the intended meaning. For example, one system can use a table called
“Actor” and another one called “Agent”. Data from the two tables might remain separated, even though they can 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.
3.10
monotonic
〈of a knowledge base〉 having a set of conclusions derived via inference rules that does not reduce,
irrespective of the whatever additional propositions can be inserted
NOTE 1 Monotonic reasoning is a term derived from knowledge representation. In practical terms, as experts enter
correct statements to an information system, the system need not regard any of the existing statements as invalid. The
CRM ontology is designed for monotonic reasoning and so enables conflict-free merging of huge stores of knowledge.
NOTE 2 See also 5.1.
3.11
multiple inheritance
possibility for a class to have more than one immediate superclass
NOTE 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, then some classes will
inevitably be repeated at different positions in the hierarchy. For example, “person” is both an “actor” and a “biological
object”.
3.12
open world
assumption that the information stored in a knowledge base is incomplete with respect to the universe of
discourse it aims to describe
NOTE A term derived from knowledge representation. The incompleteness of a knowledge base can be due to the
inability of the maintainer to provide sufficient information, or to more fundamental problems of cognition in the system’s
domain. Such problems are characteristic of cultural information systems since our records about the past are necessarily
incomplete. In addition, some items cannot be clearly assigned to a given class. In particular, the absence of a certain
property for an item described in the system does not necessarily entail that the item does not possess the property. For
example, if one item is described as “biological object” and another as “physical object”, this does not imply that the latter
is not also a “biological object”. Therefore, complements of a class with respect to a superclass cannot be derived in
general from an information system based on the open world assumption.
3.13
primitive concept
concept that is declared and for which the meaning is clear, but which cannot be derived from other concepts
NOTE Primitive concept is a term derived from knowledge representation. For example, mother can be described as
a female who has given birth to a child, so mother is not a primitive concept. Event however is a primitive concept. The
CRM is composed primarily of primitive concepts.
3.14
property
defining characteristic that serves to define a relationship of a specific kind between two classes
4 © ISO 2006 – All rights reserved
NOTE A property is characterized by an intension, which is conveyed by a scope note. A property plays a role
analogous to a verb in that it need be defined with reference to both a domain and range, which are analogous to the
subject and object in a phrase (unlike classes, which can be defined independently). Which class is selected as the
domain and which as the range, is arbitrary, as is the choice between active and passive voice. In other words, a property
can be interpreted in both directions, with two distinct but related interpretations. Properties can 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. For example, “physical man-made thing depicts CRM entity” is equivalent to
“CRM entity is depicted by physical man-made thing”.
3.15
query containment
query X contains another query Y if, for each possible population of a database, the answer set to query X also
contains the answer set to query Y
NOTE If query X and Y were classes, then X would be a superclass of Y.
3.16
range
class that comprises all the potential values of a property
NOTE Instances of a property can only link to instances of its range class. A property needs to have exactly one
range, though the range class can also contain instances that are not values of the property. The range class is analogous
to the grammatical object of a phrase, while the property is analogous to the verb. Which class is selected as domain, and
which as range, is arbitrary, as is the choice between active and passive voice. Property names in the CRM are designed
to be semantically meaningful and grammatically correct when read from domain to range. The inverse property name,
given in parentheses, is designed to be semantically meaningful and grammatically correct when read from range to
domain.
3.17
scope note
textual description of the intension of a class or property
NOTE 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 conceptualization shared by domain experts and
disambiguate different possible interpretations. Illustrative examples of classes and properties are also provided with the
scope notes for explanatory purposes.
3.18
shortcut
formally defined single property that represents a deduction or join of a data path in the CRM
NOTE 1 The scope notes of shortcut properties provide a verbal description of the equivalent deduction. Shortcuts are
introduced for those 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
E16 measurement activity that observed it. The CRM allows shortcuts as cases of less detailed knowledge, while
preserving in its schema the relationship to the full information.
NOTE 2 See also 5.3.
3.19
strict inheritance
properties inheritance that allows no exceptions
NOTE Some systems can declare that “elephants are grey”, and regard a white elephant as an exception. Under
strict inheritance rules it would hold that if all elephants were indeed grey, then a white elephant could not be an elephant.
Obviously not all elephants are grey; being grey is not part of the intension of the concept elephant but an optional
property. The CRM applies strict inheritance as a normalization principle.
3.20
subclass
specialization of another class, i.e. the superclass
NOTE A subclass inherits all the properties of its superclass (i.e. strict inheritance), in addition to having none, one,
or more additional properties of its own. A subclass can have more than one immediate superclass, and consequently
inherits the properties of all of its superclasses (i.e. multiple inheritance). A subclass has an IsA relationship to its
superclass(es): every instance of the subclass is also, by definition, an instance of the superclass(es). For example, every
“person” IsA “biological object”.
3.21
subproperty
specialization of another property, i.e. the superproperty
NOTE 1 All instances of a subproperty are also instances of its superproperty. The intension of a subproperty extends
the intension of its superproperty, i.e. its traits are more restrictive than that of its superproperty. The domain of a
subproperty is a subclass of the domain of its superproperty. The range of a subproperty is a subclass of the range of its
superproperty. Instances of a subproperty inherit 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 their own.
NOTE 2 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 can not be cyclic. In some object-
oriented languages, including C++, there is no equivalent to the specialization of properties.
3.22
superclass
generalization of one or more other classes, i.e. the subclasses
NOTE A superclass subsumes all instances of its subclasses, and 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. The
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”. Fewer properties are needed to
identify an item as a “biological object” than to identify it as a “person”.
3.23
superproperty
generalization of one or more other properties, i.e. the subproperties
NOTE A superproperty subsumes all instances of its subproperties, and 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.
4 Structure and presentation
4.1 Property quantifiers
Quantifiers for properties are provided for the purpose of semantic clarification only, and should not be treated
as implementation recommendations. This International Standard has been designed to accommodate
alternative opinions and incomplete information; all properties should therefore be implemented as optional
and repeatable for their domain and range (“many to many (0,n:0,n)”). The term “cardinality constraints” is
avoided here as it typically pertains to implementations.
Table 1 lists all possible property quantifiers occurring in this document according to their notation, together
with a textual explanation. In order to provide optimal clarity, two widely accepted notations are used in this
International Standard, i.e. one verbal, the other numerical. The verbal notation uses phrases such as “one to
many”, and the numerical notation expressions such as “(0,n:0,1)”. The terms “one”, “many” and “necessary”
are fairly intuitive; the term “dependent” is less obvious. It 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.
6 © ISO 2006 – All rights reserved
Table 1 — Property quantifiers
Quantifier Description
many to many Unconstrained: an individual domain instance and range instance of this property can have zero,
one, or more instances of the property. In other words, the property is optional and repeatable
(0,n:0,n)
for its domain and range.
one to many An individual domain instance of this property can have zero, one, or more instances of the
property, but an individual range instance cannot be referenced by more than one instance of
(0,n:0,1)
this property. In other words, the property is optional for its domain and range, but repeatable for
its domain only. This situation is sometimes called a “fan-out”.
many to one An individual domain instance of this property can have zero or one instance of the property, but
an individual range instance can be referenced by zero, one, or more instances of the property.
(0,1:0,n)
In other words, the property is optional for its domain and range, but repeatable for its range
only. This situation is sometimes called a “fan-in”.
many to many, An individual domain instance of this property can have one or more instances of the property,
necessary but an individual range instance can have zero, one, or more instances of the property. In other
words, the property is necessary and repeatable for its domain, and optional and repeatable for
(1,n:0,n)
its range.
one to many, An individual domain instance of this property can have one or more instances of the property,
necessary but an individual range instance cannot be referenced by more than one instance of the
property. In other words, the property is necessary and repeatable for its domain, and optional
(1,n:0,1)
but not repeatable for its range. This situation is sometimes called a “fan-out”.
many to one, An individual domain instance of this property shall have exactly one instance of the property,
necessary but an individual range instance can be referenced by zero, one, or more instances of the
property. In other words, the property is necessary and not repeatable for its domain, and
(1,1:0,n)
optional and repeatable for its range. This situation is sometimes called a “fan-in”.
one to many, An individual domain instance of this property can have zero, one, or more instances of the
dependent property, but an individual range instance shall be referenced by exactly one instance of the
property. In other words, this property is optional and repeatable for its domain, but necessary
(0,n:1,1)
and not repeatable for its range. This situation is sometimes called a “fan-out”.
one to many, An individual domain instance of this property can have one or more instances of the property,
necessary, dependent but an individual range instance shall be referenced by exactly one instance of the property. In
other words, the property is necessary and repeatable for its domain, and necessary but not
(1,n:1,1)
repeatable for its range. This situation is sometimes called a “fan-out”
many to one, An individual domain instance of this property shall have exactly one instance of the property,
necessary, dependent but an individual range instance can be referenced by one or more instances of the property. In
other words, this property is necessary and not repeatable for its domain, and necessary and
(1,1:1,n)
repeatable for its range. This situation is sometimes called a “fan-in”
one to one An individual domain instance and range instance of this property shall have exactly one
instance of the property. In other words, the property is necessary and not repeatable for its
(1,1:1,1)
domain and for its range.
NOTE Some properties are defined as being necessary for their domain or as being dependent on their range. If such properties
are not specified for an instance of the respective domain or range, it means that the property exists, but that the value on one side of
the property is unknown. In the case of optional properties, no distinction is made between a value being unknown or the property not
being applicable at all. For example, one can know that an object has an owner, but not know who the owner is, or know that an object
has no owner. The model makes no distinction between these two cases. A textual note can be used for clarification if needed.
4.2 Naming conventions
The following naming conventions have been applied hereafter:
4)
⎯ Classes are identified by numbers preceded by the letter “E” (historically classes were sometimes
referred to as “Entities”), and are named using noun phrases (nominal groups) in title case (initial capitals).
For example, E63 Beginning of Existence.
⎯ Properties are identified by numbers preceded by the letter “P,” and are named in both directions, using
verbal phrases in lower case. Properties with the character of states are named in the present tense,
such as “has type”, whereas properties relating to events are named in past tense, such as “carried out”.
For example, P126 employed (was employed by).
⎯ Property names should be read in their non-parenthetical form for the domain-to-range direction, and in
parenthetical form for the range-to-domain direction.
⎯ Properties with a range that is a subclass of E59 Primitive Value (such as E1 CRM Entity.P2 has note:
E62 String) have no parenthetical name form as reading the property name in the range-to-domain
direction is not regarded as meaningful.
⎯ Properties that have identical domain and range are either symmetric or transitive. Instantiating a
symmetric property implies that the relation holds for both the domain-to-range and the range-to-domain
directions. An example of this is E53 Place.P122 borders with: E53 Place. The names of symmetric
properties have no parenthetical form, because reading in the range-to-domain direction is the same as
the domain-to-range reading. Transitive asymmetric properties, such as E4 Period. P9 consists of (forms
part of): E4 Period, do have a parenthetical form that relates to the meaning of the inverse direction.
⎯ The choice of property domains, and hence the order of their names, is established in accordance with
the following priority list:
1) Temporal Entity and its subclasses;
2) Thing and its subclasses;
3) Actor and its subclasses;
4) Other.
5 Modelling principles
5.1 Monotonicity
Because this International Standard's primary role is the meaningful integration of information in an Open
World, it aims to be monotonic in the sense of Domain Theory. Existing constructs, and deductions made from
them, shall always remain valid and well-formed, i.e. even if new constructs and extensions are added.
For example, one may add a subclass of E7 Activity to describe the use of a certain name for a place over a
certain time-span by a particular group. By this extension, no existing IsA Relationships or property
inheritances are compromised.
In addition, this International Standard aims to enable the formal preservation of monotonicity when
augmenting a compatible system. Existing instances, their properties, and deductions made from them,
should always remain valid and well-formed even as new instances are added to the system.
4) Some gaps are present in the numbering sequence used for classes are properties. This is intentional: numbers
assigned in previous versions of the CRM to deprecated classes and properties have not been re-used.
8 © ISO 2006 – All rights reserved
For example, if someone describes correctly that an item is an instance of E19 Physical Object and,
subsequently, 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 in cases where opinions diverge, all formally defined properties
should be implemented with unconstrained cardinality (many:many) so that conflicting instances of properties
are merely accumulated. Knowledge stored in a conformant system can thus serve as a research base,
accumulating relevant alternative opinions around well-defined entities. Conclusions about the truth or
falsehood of the instances stored remain the subject of open-ended scientific or scholarly hypothesis building.
For example, “El Greco” and even “King Arthur” should be treated as instances of E21 Person and be dealt
with as existing within the domain of discourse once they are entered into a knowledge base. Alternative
opinions about properties, such as their birthplace and the details of their lives, may be accumulated without
decisions concerning their veracity being required during data compilation.
5.2 Minimality
Although the scope of this International Standard is very broad, the ontology itself is constructed as
economically as possible.
⎯ A class is not declared unless it is required as the domain or range of a property not appropriate to its
superclass, or it is a key concept in the practical scope.
⎯ Classes and properties that share a superclass are non-exclusive by default. For example, an object may
be both an instance of E20 Biological Object and E22 Man-made Object.
⎯ Classes and properties are either primitive, or constitute key concepts in the practical scope.
⎯ Complements of classes are not declared.
5.3 Shortcuts
Some properties are declared as sho
...
NORME ISO
INTERNATIONALE 21127
Première édition
2006-09-15
Information et documentation —
Une ontologie de référence pour
l'échange d'informations du patrimoine
culturel
Information and documentation — A reference ontology for
the interchange of cultural heritage information
Numéro de référence
©
ISO 2006
PDF – Exonération de responsabilité
Le présent fichier PDF peut contenir des polices de caractères intégrées. Conformément aux conditions de licence d'Adobe, ce fichier
peut être imprimé ou visualisé, mais ne doit pas être modifié à moins que l'ordinateur employé à cet effet ne bénéficie d'une licence
autorisant l'utilisation de ces polices et que celles-ci y soient installées. Lors du téléchargement de ce fichier, les parties concernées
acceptent de fait la responsabilité de ne pas enfreindre les conditions de licence d'Adobe. Le Secrétariat central de l'ISO décline toute
responsabilité en la matière.
Adobe est une marque déposée d'Adobe Systems Incorporated.
Les détails relatifs aux produits logiciels utilisés pour la création du présent fichier PDF sont disponibles dans la rubrique General Info
du fichier; les paramètres de création PDF ont été optimisés pour l'impression. Toutes les mesures ont été prises pour garantir
l'exploitation de ce fichier par les comités membres de l'ISO. Dans le cas peu probable où surviendrait un problème d'utilisation,
veuillez en informer le Secrétariat central à l'adresse donnée ci-dessous.
© ISO 2006
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne peut être reproduite ni utilisée sous
quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie et les microfilms, sans l'accord écrit
de l'ISO à l'adresse ci-après ou du comité membre de l'ISO dans le pays du demandeur.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax. + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Publié en Suisse
ii © ISO 2006 – Tous droits réservés
Sommaire Page
Avant-propos. iv
Introduction . v
1 Domaine d'application. 1
2 Conformité. 2
3 Termes et définitions. 2
4 Structure et présentation . 7
4.1 Quantificateurs de propriété. 7
4.2 Conventions d'appellation. 8
5 Principes de modélisation . 9
5.1 Monotonicité. 9
5.2 Minimalité . 9
5.3 Raccourcis. 9
5.4 Classes disjointes. 10
5.5 Types. 10
5.6 Extensions. 11
5.7 Couverture du domaine d'application théorique. 11
6 Déclaration des classes . 12
7 Déclaration des propriétés . 60
Annexe A (informative) Hiérarchie des classes . 109
Annexe B (informative) Hiérarchie des propriétés. 111
Bibliographie . 116
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux de
normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général confiée
aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire partie du
comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec
la Commission électrotechnique internationale (CEI) en ce qui concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/CEI,
Partie 2.
La tâche principale des comités techniques est d'élaborer les Normes internationales. Les projets de Normes
internationales adoptés par les comités techniques sont soumis aux comités membres pour vote. Leur
publication comme Normes internationales requiert l'approbation de 75 % au moins des comités membres
votants.
L'attention est appelée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable de ne
pas avoir identifié de tels droits de propriété et averti de leur existence.
L'ISO 21127 a été élaborée par le comité technique ISO/TC 46, Information et documentation, sous-comité
SC 4, Interopérabilité technique, en collaboration avec le Comité pour la Documentation du Conseil
International des Musées (ICOM-CIDOC).
iv © ISO 2006 – Tous droits réservés
Introduction
La présente Norme internationale est l'aboutissement de plus d'une décennie de travail de la part du Comité
international pour la Documentation (CIDOC) du Conseil international des musées (ICOM). Le travail sur la
présente Norme internationale a commencé en 1996 sous les auspices du groupe de travail de l'ICOM-
CIDOC sur la normalisation documentaire. Tout au long de son élaboration, le modèle a été connu sous
l'appellation «CIDOC conceptual reference model» (le modèle conceptuel de référence du CIDOC) ou CRM.
Des références au CRM dans le présent document peuvent être considérées comme synonymes de
l'ISO 21127.
Le but primaire de la présente Norme internationale est d'offrir une base conceptuelle pour la médiation
d'informations entre les institutions de patrimoine culturel tels que les musées, les bibliothèques et les
archives. L'intention est de fournir un point de référence commun avec lequel des sources d'information
divergentes et incompatibles peuvent être comparées et, finalement, harmonisées.
1)
L'ISO 21127 est une ontologie formelle de domaine pour les informations concernant le patrimoine culturel:
c'est une représentation formelle du schéma conceptuel, ou «point de vue», qui est sous-jacent aux
applications de base de données et aux systèmes de documentation qui sont employés par les institutions de
patrimoine culturel. Il est important de noter que la présente Norme internationale vise à clarifier la logique de
ce que ces institutions documentent en pratique, et non pas à fournir des spécifications normatives de ce qu'il
convient qu'elles documentent. L'objectif primaire de la présente Norme internationale est de permettre
l'échange d'informations et l'intégration de sources hétérogènes d'informations sur le patrimoine culturel. Elle
établit les définitions et les clarifications sémantiques requises pour transformer les sources d'informations
localisées et disparates en une ressource globale, que ce soit dans le contexte d'une institution, d'un intranet
ou sur Internet.
Les objectifs spécifiques de la présente Norme internationale sont de
⎯ servir de langage commun entre experts du domaine et informaticiens, lors de l'élaboration d'un cahier
des charges,
⎯ servir de langage formel pour l'identification du contenu partagé entre diverses sources de données; en
particulier pour faciliter la conception d'algorithmes automatiques pour la transformation et le transfert de
données entre systèmes sans perte de signification. Ces algorithmes de transformation sont utiles pour
l'échange de données, la récupération de données depuis des systèmes existants, l'intégration des
informations et la médiation de sources de données hétérogènes,
⎯ permettre l'interrogation de ressources intégrées en fournissant un modèle global des classes de base et
de leurs associations pour formuler de telles questions,
⎯ fournir à des réalisateurs de systèmes d'information un guide de bonne pratique dans la modélisation
conceptuelle.
1) Dans le sens utilisé par les sciences de l'information, c'est à dire qu'il décrit dans un langage formel tous les concepts
[1]
explicites et implicites utilisés dans le domaine et les relations entre eux .
L'ontologie du CRM consiste en une série de concepts et de définitions. Cette présentation est semblable à
celle utilisée pour un thesaurus. Cependant, l'ontologie ne doit pas être considérée comme un standard
terminologique et n'offre pas une définition de tous les termes qui sont typiquement employés comme
données dans la documentation des biens culturels. La présentation fournie ici est complète, mais
intentionnellement compacte et concise. Les 80 classes et les 130 propriétés dont l'ontologie se compose
sont définies sans que l'héritage des propriétés par des sous-classes soit explicité. (Au lieu de 130 propriétés,
cela exigerait la déclaration de plusieurs milliers). Cependant, cette définition contient toute l'information
requise pour développer et pour produire une déclaration complète de toutes les propriétés, y compris les
propriétés héritées.
vi © ISO 2006 – Tous droits réservés
NORME INTERNATIONALE ISO 21127:2006(F)
Information et documentation — Une ontologie de référence
pour l'échange d'informations du patrimoine culturel
1 Domaine d'application
La présente Norme internationale donne des lignes directrices pour l'échange d'informations entre institutions
responsables du patrimoine culturel. Ceci peut être défini en termes plus simples comme la connaissance des
conservateurs de musées.
Une définition plus détaillée peut être formulée en définissant le domaine d'application de principe, une
définition large et inclusive basée sur des principes généraux, et le domaine d'application pratique, qui est
défini par référence à une série de normes et de pratiques de documentation utilisées par les musées.
Le domaine d'application de principe de la présente Norme internationale peut être défini comme toutes les
informations nécessaires pour l'échange et l'intégration de la documentation scientifique des collections de
musée. Cette définition peut être développée:
⎯ Le terme «documentation scientifique» est censé exprimer l'exigence que la profondeur et la qualité
d'informations descriptives qui peuvent être traitées par la présente Norme internationale ont besoin
d'être suffisantes pour la recherche académique et scientifique. Cette exigence ne signifie pas pour
autant que des informations destinées à la présentation au public ne sont pas prises en compte, mais
surtout que la présente Norme internationale est destinée à supporter le niveau de détail et de précision
exigés par des professionnels des musées et des chercheurs dans le domaine.
⎯ Le terme «collections de musées» englobe tout type de matériel rassemblé et exposé par des musées et
2)
des institutions apparentées, selon la définition de l'ICOM . Ceci inclut des collections, des sites et des
monuments en rapport avec des domaines tels que l'histoire sociale, l'ethnographie, l'archéologie, les
beaux-arts et les arts appliqués, l'histoire naturelle, l'histoire des sciences et de la technologie.
⎯ La documentation des collections inclut la description détaillée d'objets individuels qui font partie des
collections ainsi que des groupes d'objets et des collections dans leur ensemble. La présente Norme
internationale est spécifiquement censée couvrir des informations contextuelles (c'est-à-dire historiques,
géographiques et théoriques qui donnent aux collections de musée leur signification culturelle et leur
valeur).
⎯ L'échange des informations avec les bibliothèques et les archives et l'harmonisation avec leurs modèles
relève du domaine d'application de la présente Norme internationale.
⎯ Les informations exigées seulement pour l'administration et la gestion des institutions culturelles, telles
que les informations concernant la gestion personnelle, la comptabilité et les statistiques des visiteurs,
échappent au domaine d'application de principe de la présente Norme internationale.
3)
Le domaine d'application pratique de la présente Norme internationale est un ensemble de normes de
référence pour la documentation des collections des musées, employées lors de son élaboration pour guider
2) Les statuts de l'ICOM offrent une définition du terme «musée» à .
3) Le domaine d'application pratique du CIDOC CRM, y compris une liste des normes de documentation pour les
musées, est présenté plus en détail sur le site Web du CIDOC CRM à .
et pour valider son développement. La présente Norme internationale couvre le même domaine de discours
que l'ensemble de ces documents de référence; cela signifie que les données correctement codées selon
n'importe lequel de ces documents de référence peuvent être exprimées dans une forme compatible avec la
présente Norme internationale sans aucune perte de signification.
2 Conformité
Il convient que les utilisateurs censés profiter de l'interopérabilité sémantique offerte par la présente Norme
internationale assurent la conformité des structures de données appropriées. La conformité concerne soit les
données qu'il convient de rendre accessibles dans un environnement intégré, soit le contenu destiné à être
transporté vers d'autres environnements. N'importe quel codage de données dans un langage formel qui
préserve les relations entre les classes, les propriétés et les règles d'héritage définies par la présente Norme
internationale est considéré comme conforme.
La conformité avec la présente Norme internationale n'exige ni une correspondance complète de toutes les
structures de documentation locales, ni que tous les concepts et les structures définis par la présente Norme
internationale soient mis en œuvre. La conception de la Norme est telle que les extensions sont possibles,
souvent nécessaires pour englober toute la richesse des informations culturelles, ainsi que des simplifications,
pour des raisons d'économie. Un système sera considéré comme partiellement conforme s'il supporte un
sous-ensemble de classes et de propriétés définies par la présente Norme internationale. Il convient que les
concepteurs du système publient les détails des éléments qui sont supportés.
L'intérêt primaire de la présente Norme internationale est le transport et la médiation d'informations
structurées. Il ne permet ni ne requiert l'interprétation d'informations sous forme de texte libre vers une forme
structurée et logique. Les informations sous forme de texte libre, bien que rendues possibles, ne sont pas
visées par ces considérations sur la conformité.
On considérera n'importe quel système de documentation conforme avec la présente Norme internationale,
indépendamment de la structure interne de données qu'il emploie, si un algorithme logique qui transforme les
données enregistrées par le système dans une forme directement compatible avec la norme, sans perte de
signification, peut être construit. Aucune supposition n'est faite quant à la nature de cet algorithme. «Sans
perte de signification» indique que les concepteurs et les utilisateurs du système sont satisfaits de la
correspondance de la représentation des données avec les définitions sémantiques fournies par la présente
Norme internationale.
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s'appliquent. Nous avons choisi ces
termes à partir des diverses terminologies utilisées pour la description des modèles orientés objet dans le but
de faciliter la compréhension par des non-informaticiens.
3.1
classe
catégorie d’items qui partagent un ou plusieurs attributs
NOTE Les attributs d'une classe servent de critères pour l'identification des membres de la classe. Ces attributs n'ont
pas besoin d'être explicitement formulés en termes logiques, mais peuvent être décrits dans un texte (appelé ici une note
d'application) qui fait référence à une conceptualisation commune aux experts du domaine. La somme de ces attributs est
appelée l'intension de la classe. Une classe peut être le domaine ou la cible de zéro, une seule ou plusieurs propriétés
formellement définies dans un modèle. Les propriétés formellement définies n'ont pas besoin de faire partie de l'intension
de leurs domaines ou de leurs cibles: de telles propriétés sont facultatives. Un article qui appartient à une classe est
appelé une instance de cette classe. Une classe est associée à un ensemble ouvert d'instances réelles, qui constituent
l'extension de la classe. Ici le terme «ouvert» signifie qu'il est en général au-delà de nos capacités de connaître tous les
cas d'une classe dans le monde. L'avenir peut, d'ailleurs, révéler de nouveaux cas à tout moment (Monde Ouvert). Une
classe ne peut être définie par l'énumération de ses instances. Une classe joue un rôle analogue à un groupe nominal et
peut être complètement définie indépendamment de tout autre élément (à la différence des propriétés, qui doivent être
définies par rapport à un domaine et une cible). Par exemple «Personne» est une classe. Une «Personne» peut être
membre d'un «Groupe», mais il n'est pas nécessaire d'appartenir à un «Groupe» pour être une Personne. Nous n'aurons
2 © ISO 2006 – Tous droits réservés
jamais les connaissances complètes concernant toutes les «Personnes» qui ont vécu et il y aura plus de «Personnes» à
l'avenir. Les classes sont normalement organisées dans une hiérarchie de classes. La relation entre une sous-classe et sa
super-classe est appelée EstUn (la concaténation des mots «est un»). Par exemple un bateau EstUn véhicule.
3.2
complément
〈d'une classe A〉 ensemble de toutes les instances de sa super-classe, B, qui ne sont pas des instances de A
NOTE En termes de la théorie des ensembles, le complément d'une classe est l'extension de sa super-classe moins
l'extension de la classe. Les extensions compatibles avec la présente Norme internationale ne doivent pas déclarer une
classe dans le but de former le complément d'une ou de plusieurs autres classes. Ceci est en contradiction avec l'objectif
de décrire un Monde Ouvert. Par exemple pour tous les cas possibles de genre humain, on ne doit pas déclarer «mâle»
comme étant le complément de «femelle» ou vice versa.
3.3
classes disjointes
n'ayant pas d'instances communes dans n'importe quel monde envisageable
NOTE 1 Deux classes sont disjointes si l'intersection de leurs extensions est nécessairement un ensemble vide.
NOTE 2 Voir aussi 5.4.
3.4
domaine
classe pour laquelle une propriété est formellement définie
NOTE Les instances d'une propriété sont applicables aux instances de sa classe de domaine. Une propriété doit
avoir exactement un domaine, bien que la classe de domaine puisse toujours contenir des instances pour lesquelles la
propriété n'est pas instanciée. La classe de domaine est analogue au sujet grammatical d'une phrase; la propriété est
analogue au verbe. Le choix de sens d'une propriété entre son domaine et sa cible est essentiellement arbitraire, de
même que pour une phrase le choix entre la voix active et la voix passive est arbitraire. Les noms de propriété dans le
CRM sont conçus pour être sémantiquement significatifs et grammaticalement corrects quand ils sont lus du domaine vers
la cible. De plus, le nom de propriété inverse, normalement donné entre parenthèses, est aussi conçu pour être
sémantiquement significatif et grammaticalement correct quand il est lu de la cible vers le domaine.
3.5
extension
l'ensemble de toutes les instances réelles d'une classe qui respectent les critères de son intension
NOTE 1 L'extension d'une classe est un ensemble «ouvert» dans le sens qu'il est, en général, impossible de connaître
toutes les instances d'une classe dans le monde; l'avenir peut créer de nouveaux cas à tout moment (dans un Monde
Ouvert). Un système d'information ne peut, à un moment donné, se référer qu'à certaines instances d'une classe, qui
forment un sous-ensemble de son extension.
NOTE 2 Voir aussi 5.6.
3.6
héritage
duplication des attributs d'une classe vers ses sous-classes
NOTE L'héritage de propriétés de super-classes vers les sous-classes signifie que si un terme x est une instance
d'une classe A, toutes les propriétés qui s'appliquent aux instances des super-classes de A s'appliquent également au
terme x et que toutes les propriétés facultatives qui s'appliquent aux super-classes de A s'appliquent également au terme x.
3.7
instance
terme dont les attributs correspondent aux critères de l'intension de la classe
NOTE «La Joconde» est une instance de la classe des «objets physiques fabriqués par l'homme». Une instance
d'une propriété est une relation factuelle entre une instance du domaine et une instance de la cible de la propriété qui
correspond aux critères de l'intension de la propriété. Par exemple, «le Louvre est le propriétaire actuel de La Joconde»
est une instance de la propriété «est le propriétaire actuel de». Le nombre d'instances d'une classe déclarées dans un
système d'information est normalement inférieur au total des instances réelles. Par exemple, vous êtes une instance de
«Personne», mais vous ne figurez pas dans tous les systèmes d'information qui décrivent des «Personnes».
3.8
intension
signification d'une classe
NOTE L'intension d'une classe consiste en un ou en plusieurs attributs communs partagés par toutes les instances
de la classe. Ces attributs n'ont pas besoin d'être explicitement formulés en termes logiques, mais peuvent simplement
être décrits dans un texte (une note d'application) qui se réfère à une conceptualisation commune aux experts de domaine.
3.9
interopérabilité
capacité des systèmes d'information à communiquer une partie de leur contenu
NOTE L'interopérabilité peut signifier que
a) deux systèmes peuvent échanger des informations, et/ou
b) des systèmes multiples peuvent être exploités par le biais d'une méthode unique.
En général, une distinction peut être faite entre l'interopérabilité syntactique et l'interopérabilité sémantique.
L'interopérabilité syntactique signifie que le codage de l'information des systèmes et les protocoles d'accès sont
compatibles; ainsi les informations peuvent être traitées comme décrit ci-dessus et sans erreurs. Cependant, ceci ne
garantit pas que chaque système traite les données de façon compatible avec la signification voulue. Par exemple un
système peut utiliser une table appelée «Acteur» et une autre appelée «Agent». À un niveau d'interopérabilité syntactique,
les deux tables sont traitées comme des entités distinctes, bien qu'au niveau sémantique elles puissent avoir exactement
la même signification. L'interopérabilité sémantique est également nécessaire pour surmonter le problème. Le CRM part
du principe que l'interopérabilité syntactique est assurée et s'occupe seulement de l'addition de l'interopérabilité
sémantique.
3.10
monotonique
〈d'une base de connaissances〉 ayant un ensemble de conclusions tirées par des règles d'inférence qui ne
diminue jamais, malgré l'addition de propositions supplémentaires
NOTE 1 Le raisonnement monotonique est un terme dérivé de la représentation des connaissances. En termes
pratiques, si des experts entrent des déclarations dans un système d'information, le système ne doit jamais considérer les
résultats de ces déclarations comme invalides lorsqu'une nouvelle déclaration est entrée. L'ontologie CRM est conçue
pour le raisonnement monotonique et permet la fusion sans conflits de grands fonds de connaissance.
NOTE 2 Voir aussi 5.1.
3.11
héritage multiple
possibilité pour une classe d'avoir plus d'une super-classe directe
NOTE L'extension d'une classe avec plusieurs super-classes directes est un sous-ensemble de l'intersection de
toutes les extensions de ses super-classes. L'intension d'une classe avec plusieurs super-classes directes multiples étend
l'intension de toutes ses super-classes, c'est-à-dire que ses attributs sont plus restrictifs que ceux de ses super-classes.
Si l'héritage multiple est utilisé, la «hiérarchie de classes» qui en résulte est un graphe dirigé et non pas une arborescence.
Si elle est représentée comme une liste indentée, il y a nécessairement des répétitions de la même classe à des positions
différentes dans la hiérarchie. Par exemple, «Personne» est à la fois un «Acteur» et un «Objet biologique».
3.12
monde ouvert
supposition que les informations stockées dans une base de connaissances sont incomplètes par rapport à
l'univers de discours qu'elle tente de décrire
NOTE Un terme dérivé de la représentation des connaissances. L'incomplétude d'une base peut être due à
l'incapacité du gestionnaire à fournir des informations suffisantes, ou à des problèmes plus fondamentaux de
connaissances dans le domaine du système. De tels problèmes sont caractéristiques de systèmes d'information culturels.
Nos archives relatives au passé sont nécessairement incomplètes. De plus, il peut exister des items qui ne peuvent pas
être assignés sans équivoque à une classe donnée. Plus spécifiquement, l'absence d'une certaine propriété pour un item
décrit par le système ne signifie pas forcément que l'item en question ne possède pas cette propriété. Par exemple, si un
article est décrit comme un Objet biologique et un autre comme un Objet matériel, ceci n'implique pas que ce dernier ne
soit pas également un Objet biologique. De façon générale, on ne peut donc pas déduire les compléments d'une classe
par rapport à une super-classe dans un système d'information basé sur la Supposition du Monde Ouvert.
4 © ISO 2006 – Tous droits réservés
3.13
concept primitif
concept qui peut être déclaré et dont la signification est connue, mais qui ne peut pas être dérivé à partir
d'autres concepts
NOTE Concept primitif est un terme dérivé de la représentation des connaissances. Par exemple mère peut se
décrire comme un être féminin ayant un enfant. Alors mère n'est pas un concept primitif. En revanche, Événement est un
concept primitif. Le CRM est composé, en majeure partie, de concepts primitifs.
3.14
propriété
caractéristique qui définit une relation de nature très spécifique entre deux classes
NOTE Une propriété est caractérisée par une intension, qui est présentée par une note d'application. Une propriété
joue un rôle analogue au verbe dans une phrase: elle est définie par référence à son domaine et à sa cible, qui sont
comparables au sujet et à l'objet d'une phrase (une classe, par distinction, peut être définie indépendamment). Le choix
de sens d'une propriété entre son domaine et sa cible est essentiellement arbitraire, de même que pour une phrase le
choix entre la voix active et la voix passive est arbitraire. Autrement dit, une propriété peut être interprétée dans les deux
sens, avec deux interprétations qui sont distinctes mais liées. Les propriétés peuvent elles-mêmes posséder des
propriétés en rapport avec d'autres classes. (Cette caractéristique est utilisée dans le modèle uniquement pour décrire les
sous-types dynamiques de propriétés.) Les propriétés peuvent aussi être spécialisées de la même manière que les
classes, créant ainsi des rapports EstUn entre les sous-propriétés et leurs super-propriétés. Par exemple «Chose
matérielle fabriquée figure Entité CRM» est équivalent à «Entité CRM est figurée sur Chose matérielle fabriquée».
3.15
englobement des requêtes
une requête X englobe une autre requête Y, si pour chaque population possible d'une base de données
l'ensemble de réponses à la requête X contient aussi l'ensemble de réponses à la requête Y
NOTE Si les requêtes X et Y étaient des classes, X serait la super-classe d'Y.
3.16
cible
classe qui comprend toutes les valeurs potentielles d'une propriété
NOTE Les instances d'une propriété peuvent se lier seulement avec les instances de la classe de cible. Une
propriété doit avoir exactement une cible, bien que la classe de cible puisse toujours contenir des instances qui ne sont
pas des valeurs de la propriété. La classe de cible est analogue à l'objet grammatical d'une expression où la propriété est
le verbe. Le choix d'une classe dans le rôle du domaine ou dans celui de la cible est arbitraire, de même que le choix
entre la voix active et la voix passive pour une phrase est arbitraire. Dans le CRM, les noms des propriétés sont censés
être sémantiquement significatifs et grammaticalement corrects quand ils sont lus dans le sens du domaine à la cible. De
plus, le nom de propriété inverse, normalement donné entre parenthèses, est aussi censé être sémantiquement significatif
et grammaticalement correct lu de la cible au domaine.
3.17
note d'application
description textuelle de l'intension d'une classe ou d'une propriété
NOTE Les notes d'application ne sont pas des éléments de modélisation formels, mais sont fournies dans le but de
clarifier la signification et l'application des classes et des propriétés de modèle. Elles font référence à une
conceptualisation commune aux experts de domaine et éliminent des équivoques entre différentes interprétations
possibles. À titre d'illustration et d'explication, des exemples d'instances de classes et de propriétés sont fournis avec les
notes d'application.
3.18
raccourci
une simple propriété, formellement définie, qui représente une déduction ou une jointure d'un chemin de
données dans le CRM
NOTE 1 Les notes d'application de toutes les propriétés définies en tant que raccourcis donnent une description
verbale de cette déduction. Les raccourcis sont présentés dans les cas où la pratique de documentation habituelle
emploie seulement la déduction plutôt que le chemin développé. Par exemple les musées enregistrent souvent les
«dimensions» d'un objet sans documenter les détails de l'activité de E16 Mesurage. Le CRM permet des raccourcis dans
les cas ou les connaissances sont moins détaillées, tout en préservant dans le schéma les liens avec les informations
complètes.
NOTE 2 Voir aussi 5.3.
3.19
héritage strict
forme d'héritage de propriétés qui ne permet aucune exception
NOTE Cetains systèmes peuvent déclarer que les «éléphants sont gris» et considérer qu'un éléphant blanc est une
exception. D'après l'héritage strict si tous les éléphants sont gris, un éléphant blanc n'est pas un éléphant. Évidemment,
en réalité tous les éléphants ne sont pas gris. Être gris ne fait pas partie de l'intension du concept d'un éléphant, c'est
plutôt une propriété facultative. Le CRM applique l'héritage strict comme un principe de normalisation.
3.20
sous-classe
spécialisation d'une autre classe, c'est-à-dire la super-classe
NOTE Une sous-classe hérite toutes les propriétés de sa super-classe (c'est-à-dire l'héritage strict) et peut, en plus,
posséder ses propres propriétés. Une sous-classe peut avoir plus d'une super-classe directe et hérite par conséquent les
propriétés de toutes ses super-classes (c'est-à-dire l'héritage multiple). Une sous-classe a une relation EstUn avec ses
super-classes: chaque instance de la sous-classe est aussi, par définition, une instance d'une ou de plusieurs super-
classes. Par exemple chaque «Personne» EstUn «Objet biologique».
3.21
sous-propriété
spécialisation d'une autre propriété, c'est-à-dire la super-propriété
NOTE 1 Toutes les instances de la sous-propriété sont aussi des instances de sa super-propriété. L'intension de la
sous-propriété étend l'intension de la super-propriété, c'est-à-dire que ses attributs sont plus restrictifs que ceux de sa
super-propriété. Le domaine de la sous-propriété est une sous-classe du domaine de sa super-propriété. La cible de la
sous-propriété est une sous-classe de la cible de sa super-propriété. Les instances d'une sous-propriété héritent, sans
exception, la définition de toutes les propriétés déclarées pour la super-propriété (héritage strict), et peuvent aussi avoir
leurs propres propriétés.
NOTE 2 Une sous-propriété peut avoir plus d'une super-propriété directe et peut donc hériter les propriétés de toutes
ses super-propriétés (héritage multiple). La relation EstUn, c'est à dire la spécialisation, de deux ou de plusieurs
propriétés engendre la structure que nous appelons une hiérarchie de propriétés. La relation EstUn est transitive et n'est
pas cyclique. Dans certains langages de programmation orientés objet, dont C++, il n'y a aucun équivalent de la
spécialisation de propriétés.
3.22
super-classe
généralisation d'une ou de plusieurs autres classes, c'est-à-dire les sous-classes
NOTE Une super-classe englobe toutes les instances de ses sous-classes et peut aussi avoir ses propres instances
qui n'appartiennent à aucune de ses sous-classes. L'intension de la super-classe est moins restrictive que celles de ses
sous-classes. Le fait d'englober ou de généraliser est l'inverse de la relation EstUn, autrement dit, la spécialisation. Dans
certains contextes (par exemple le langage de programmation C++), le terme classe parente est employé comme
synonyme de super-classe. Par exemple «Objet biologique est la classe parente de Personne» est synonyme de «Objet
biologique est une super-classe de Personne». Il faut moins de propriétés pour classifier quelque chose comme «Objet
biologique» que comme «Personne».
3.23
super-propriété
généralisation d'une ou de plusieurs autres propriétés, c'est-à-dire les sous-propriétés
NOTE Une super-propriété englobe toutes les instances de ses sous-propriétés et peut aussi avoir ses propres
instances qui n'appartiennent à aucune de ses sous-propriétés. L'intension de la super-propriété est moins restrictive que
celles de ses sous-propriétés. La généralisation est l'inverse de la relation EstUn, autrement dit la spécialisation.
6 © ISO 2006 – Tous droits réservés
4 Structure et présentation
4.1 Quantificateurs de propriété
Les quantificateurs des propriétés sont uniquement donnés dans un but de clarification sémantique et il
convient qu'ils ne soient pas traités comme des recommandations d'implémentation. Un aspect fondamental
de la présente Norme internationale est la capacité de pouvoir accepter des avis divergents et des
informations incomplètes. Il convient donc que toutes les propriétés soient traitées comme facultatives et
répétables pour leur domaine et leur cible («plusieurs à plusieurs (0,n:0,n)»). Nous évitons le terme
«contraintes de cardinalité», puisqu'il est surtout pertinent dans un contexte d'implémentation.
Le Tableau 1 énumère tous les quantificateurs possibles utilisés dans ce document selon leur notation, avec
une explication en termes clairs. Afin d'arriver à une clarté optimale, deux notations couramment utilisées sont
utilisées de façon redondante dans ce document, l'une verbale, l'autre numérique. La notation verbale utilise
des expressions comme «un à plusieurs» et la notation numérique, des expressions comme «(0,n:0,1)». Les
termes «un» «plusieurs» et «nécessaire» sont tout à fait intuitifs; le terme «dépendant» dénote une situation
où une instance de cible ne peut pas exister sans une instance de la propriété pertinente. Autrement dit, la
propriété est «nécessaire» pour sa cible.
Tableau 1 — Quantificateurs de propriété
Quantificateur Description
Plusieurs à plusieurs Sans contraintes: une instance du domaine de la propriété ainsi qu'une instance de sa cible
peuvent avoir zéro, une ou plusieurs instances de cette propriété. Autrement dit, la propriété est
(0,n:0,n)
facultative et répétable pour son domaine ainsi que pour sa cible.
un à plusieurs Une instance du domaine de la propriété peut avoir zéro, une ou plusieurs instances de la
propriété, mais une instance de la cible ne peut être référencée que par une instance de cette
(0,n:0,1)
propriété. Autrement dit, cette propriété est facultative pour son domaine et pour sa cible, mais
répétable pour son domaine seulement. Cette situation est parfois appelée «en éventail».
plusieurs à un Une instance du domaine de la propriété peut avoir zéro ou une instance de la propriété, mais
une instance de la cible peut être référencée par zéro, une ou plusieurs instances de cette
(0,1:0,n)
propriété. Autrement dit, cette propriété est facultative pour son domaine et pour sa cible, mais
répétable uniquement pour sa cible. Cette situation est parfois appelée «convergence».
plusieurs à plusieurs, Une instance du domaine de la propriété peut avoir une ou plusieurs instances de la propriété,
nécessaire mais une instance de sa cible peut avoir zéro, une ou plusieurs instances. Autrement dit, cette
propriété est nécessaire et répétable pour son domaine mais facultative et répétable pour sa
(1,n:0,n)
cible.
un à plusieurs, Une instance du domaine de la propriété peut avoir une ou plusieurs instances de la propriété,
nécessaire mais une instance de la cible ne peut être référencée par plus d'une instance de cette propriété.
Autrement dit, cette propriété est nécessaire et répétable pour son domaine mais facultative et
(1,n:0,1)
unique pour sa cible. Cette situation est parfois appelée «en éventail».
plusieurs à un, Une instance du domaine de la propriété doit avoir exactement une instance de la propriété,
nécessaire mais une instance de la cible peut être référencée que par zéro, une ou plusieurs instances de
cette propriété. Autrement dit, cette propriété est nécessaire et unique pour son domaine et
(1,1:0,n)
facultative et répétable pour sa cible. Cette situation est parfois appelée «convergence».
un à plusieurs, Une instance du domaine de la propriété peut avoir zéro, une ou plusieurs instances de la
dépendant propriété, mais une instance de la cible doit être référencée par exactement une instance de
cette propriété. Autrement dit, cette propriété est facultative et répétable pour son domaine mais
(0,n:1,1)
nécessaire et unique pour sa cible. Cette situation est parfois appelée «en éventail».
un à plusieurs, Une instance du domaine de la propriété peut avoir une ou plusieurs instances de la propriété,
nécessaire, dépendant mais une instance de la cible doit être référencée par exactement une instance de cette
propriété. Autrement dit, cette propriété est nécessaire et répétable pour son domaine mais
(1,n:1,1)
nécessaire et unique pour sa cible. Cette situation est parfois appelée «en éventail».
Tableau 1 — Quantificateurs de propriété (suite)
plusieurs à un, Une instance du domaine de la propriété doit avoir exactement une instance de la propriété,
nécessaire, dépendant mais une instance de la cible peut être référencée par une ou plusieurs instances de cette
propriété. Autrement dit, cette propriété est nécessaire et unique pour son domaine et
(1,1:1,n)
nécessaire et répétable pour sa cible. Cette situation est parfois appelée «convergence».
un à un Une instance du domaine de la propriété ainsi qu'une instance de la cible doivent avoir
exactement une instance de la propriété. Autrement dit, cette propriété est nécessaire et unique
(1,1:1,1)
pour son domaine et pour sa cible.
NOTE Certaines propriétés sont définies comme nécessaires pour leur domaine ou comme dépendantes de leur cible. Si de
telles propriétés ne sont pas spécifiées pour une instance du domaine ou de la cible, cela signifie que la propriété existe, mais que la
valeur d'un côté de la propriété est inconnue. Dans le cas de propriétés facultatives, aucune distinction n'est faite entre les cas où une
valeur est inconnue et les cas où la propriété n'est pas applicable. Par exemple on peut savoir qu'un objet a un propriétaire, sans
connaître l'identité du propriétaire, ou bien on peut savoir qu'un objet n'a pas de propriétaire. Le modèle ne fait pas de distinction entre
les deux cas de figure. Une note textuelle peut être utilisée pour clarification si nécessaire.
4.2 Conventions d'appellation
Les conventions d'appellation suivantes ont été appliquées:
4)
⎯ Chaque classe est identifiée par un numéro précédé de la lettre «E» (historiquement les classes étaient
connues sous le terme «Entités»). Les noms des classes sont des phrases composées (groupes
nominaux) qui sont présentées en casse de titre (lettre capitale initiale). Par exemple E63 Début
d'existence.
⎯ Chaque propriété est identifiée par un numéro précédé par la lettre «P». Elles sont nommées dans les
deux directions en utilisant des expressions verbales en minuscules. Les propriétés qui représentent des
états sont exprimées au présent, comme «est de type», tandis que les propriétés liées aux événements
sont exprimées au passé, comme «a effectué». Par exemple P126 a employé (a été employé dans).
⎯ Il convient de lire les noms des propriétés dans leur forme normale pour la direction domaine-à-cible et
dans la forme entre parenthèses pour la direction cible-à-domaine.
⎯ Les propriétés dont la cible est une sous-classe de E59 Valeur primitive (comme E1 Entité CRM. P2 a
pour note: E62 Chaîne de caractères) n'ont aucune forme de nom entre parenthèses puisque la lecture
dans la direction cible-à-domaine n'a pas de sens.
⎯ Les propriétés dont le domaine et la cible sont identiques sont soit symétriques soit transitives.
L'instanciation d'une propriété symétrique implique que la relation est valide tant dans le sens domaine-à-
cible que dans le sens cible-à-domaine. Par exemple E53 Lieu.P122 jouxte: E53 Lieu. Les noms des
propriétés symétriques n'ont pas de forme entre parenthèses, puisque la lecture dans la direction cible-à-
domaine est identique à la lecture domaine-à-cible. Les propriétés asymétriques et transitives, comme E4
Période. P9 consiste en (fait partie
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...