Non-automatically generated text sections of CIDOC-CRM version: 7.1.1

Produced by the CIDOC CRM

Special Interest Group

Version 7.1.1

April 2021

Editors: Chryssoula Bekiari, George Bruseker, Martin Doerr,

Christian-Emil Ore, Stephen Stead, Athanasios Velios

CC BY 4.0 2021 Individual Contributors to CIDOC CRM 7.1.1

https://doi.org/10.26225/FDZH-X261

This page is left blank on purpose

This document is the formal definition of the CIDOC Conceptual Reference Model (“CIDOC CRM”), a formal ontology intended to facilitate the integration, mediation and interchange of heterogeneous cultural heritage information and similar information from other domains, as further detailed below. The CRM is the culmination of more than two decades of standards development work by the International Committee for Documentation (CIDOC) of the International Council of Museums (ICOM). Work on the CRM itself began in 1996 under the auspices of the ICOM-CIDOC Documentation Standards Working Group. Since 2000, development of the CRM has been officially delegated by ICOM-CIDOC to the CIDOC CRM Special Interest Group (SIG). The SIG, in turn, collaborates with the ISO working group ISO/TC46/SC4/WG9 to bring the CRM to the form and status of an International Standard. This set of collaborations has resulted in the production of ISO21127:2004 and ISO21127:2014, the ISO standard editions of the CIDOC CRM. This collaboration will be continued in order to support the next update of the ISO standard edition. The present document belongs to the series of evolving versions of the formal definition of the CRM, which serve the ISO working group as community draft for the standard. Eventual minor differences, in semantics and notation, of the ISO standard text from the present, community CIDOC CRM version, which the ISO working group requires and implements, will be harmonized in the subsequent versions of the present, community CIDOC CRM formal definition document.

The primary role of the CIDOC CRM is to enable the exchange and integration of information from heterogeneous sources for the reconstruction and interpretation of the past at a human scale, based on all kinds of material evidence, including texts, audio-visual material and oral tradition. It starts from, but is not limited to, the needs of museum documentation and research based on museum holdings. It aims at providing the semantic definitions and clarifications needed to transform disparate, localised information sources into a coherent global resource, be it within a larger institution, in intranets or on the Internet, and to make it available for scholarly interpretation and scientific evaluation. These goals determine the constructs and level of detail of the CIDOC CRM.

More specifically, it defines, in terms of a formal ontology, the underlying semantics of database schemata and structured documents used in the documentation of cultural heritage and scientific activities. In particular it defines the semantics related to the study of the past and current state of our world, as it is characteristic for museums, but also or other cultural heritage institutions and disciplines. It does not define any of the terminology appearing typically as data in the respective data structures; it foresees, however, the characteristic relationships for its use. It does not aim at proposing what cultural heritage institutions should document. Rather, it explains the logic of what they actually currently document, and thereby enables semantic interoperability.

The CIDOC CRM intends, moreover, to provide a model of the intellectual structure of the respective kinds of mentioned documentation in logical terms. As such, it has not been optimised for implementation specific storage and processing factors. Actual system implementations may lead to solutions where elements and links between relevant elements of our conceptualizations are no longer explicit in a database or other structured storage system. For instance, the birth event that connects elements such as father, mother, birth date, birth place may not appear in the database, in order to save storage space or response time of the system. The CIDOC CRM provides a conceptual and technical means to explain how such apparently disparate entities are semantically and logically interconnected, and how the ability of the database to answer certain intellectual questions is affected by the omission of such elements and links.

The CIDOC CRM aims to support the following specific functionalities:

Inform developers of information systems as a guide to good practice in conceptual modelling, in order to effectively structure and relate information assets of cultural documentation.

• Serve as a common language for domain experts and IT developers to formulate requirements and to agree on system functionalities with respect to the correct handling of cultural contents.
• To 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. The latter being useful for data exchange, data migration from legacy systems, data information integration and mediation of heterogeneous sources.
• To support associative queries against integrated resources by providing a global model of the basic classes and their associations to formulate such queries.
• It is further believed that advanced natural language algorithms and case-specific heuristics can take significant advantage of the CIDOC CRM to resolve free text information into a formal logical form, if that is regarded beneficial. The CIDOC CRM is not thought, however, to be a means to replace scholarly text, rich in meaning, by logical forms, but only a means to identify related data.

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

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

The overall scope of the CIDOC CRM can be summarised in simple terms as the curated, factual knowledge about the past at a human scale.

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

The reasons for this distinctions between Intended and Practical Scope are twofold. Firstly, the CIDOC CRM is developed in a “bottom-up” manner, starting from well-understood, actually and widely used concepts of domain experts, which are disambiguated and gradually generalized as more forms of encoding are encountered. This aims to avoid the misadaptations and vagueness that can sometimes be found in introspection-driven attempts to find overarching concepts for such a wide scope, and provides stability to the generalizations found. Secondly, it is a means to identify and keep a focus on the concepts most needed by the communities working in the scope of the CIDOC CRM and to maintain a well-defined agenda for its evolution.

The Intended Scope of the CIDOC CRM may, therefore, be defined as all information required for the exchange and integration of heterogeneous scientific and scholarly documentation about the past at a human scale and the available documented and empirical evidence for this. This definition requires further elaboration:

• The term “scientific and scholarly documentation” is intended to convey the requirement that the depth and quality of descriptive information that can be handled by the CIDOC CRM should 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 the CRM is intended to provide the level of detail and precision expected and required by museum professionals and researchers in the field.
• As “available documented and material evidence” are regarded all types of material collected and displayed by museums and related institutions, as defined by ICOM^[1], and other collections, in-situ objects, sites, monuments and intangible heritage relating to fields such as social history, ethnography, archaeology, fine and applied arts, natural history, history of sciences and technology.
• The concept “documentation” includes the detailed description of individual items, in situ or within collections, groups of items and collections as a whole, as well as practices of intangible heritage. It pertains to their current state as well as to information about their past. The CIDOC CRM is specifically intended to cover contextual information: the historical, geographical and theoretical background that gives cultural heritage collections much of their cultural significance and value.
• The documentation of collections includes the detailed description of individual items within collections, groups of items and collections as a whole. The CIDOC CRM is specifically intended to cover contextual information: 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 the harmonisation of the CIDOC CRM with their models, falls within the Intended Scope of the CIDOC CRM.
• 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 the CIDOC CRM.

The Practical Scope^[2] of the CIDOC CRM is expressed in terms of the set of reference standards and de facto standards for documenting factual knowledge that have been used to guide and validate the CIDOC CRM’s development and its further evolution. The CRM covers the same domain of discourse as the union of these reference standards; this means that for data correctly encoded according to these documentation formats there can be a CIDOC CRM-compatible expression that conveys the same meaning.

As part of the on-going work of keep the standard up-to-date, discussions on the types of bias present in the CIDOC CRM are in progress within the CIDOC CRM community.

Users intending to take advantage of the semantic interoperability offered by the CIDOC CRM should ensure conformance with the relevant data structures. Conformance pertains either to data to be made accessible in an integrated environment or 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 the CIDOC CRM 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 documentation, and for simplification, in the interests of economy. A system will be deemed partially conformant if it supports a subset of subclasses and sub properties defined by this International Standard. Designers of the system should publish details of the constructs that are supported.

The focus of the CIDOC CRM is the exchange and mediation of structured information. It does not require the interpretation of unstructured (free text) information into a structured, logical form. Unstructured information is supported, but 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.

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

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

Although the definition of the CIDOC CRM provided here is complete, it is an intentionally compact and concise presentation of the CIDOC CRM’s 81 classes and 160 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 160). However, this definition does contain all of the information necessary to infer and automatically generate a full declaration of all properties, including inherited properties.

The following naming conventions have been applied throughout the CIDOC CRM:

• 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) using 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 related to events are named in past tense, such as “carried out.” For example, P126 employed (was employed in).
• 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. Reading a property in range-to-domain direction is equivalent to the inverse of that property. Following a current notational practice in OWL knowledge representation language, we represent inverse properties in this text by adding a letter “i” following the identification number and the parenthetical form of the full property name, such as P59i is located on or within, which is the inverse of P59 has section (is located on or within).
• Properties with a range that is a subclass of E59 Primitive Value (such as E1 CRM Entity. P3 has note: E62 String, for example) have no parenthetical name form, because 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 same 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 consist of (forms part of): E4 Period, have a parenthetical form that relates to the meaning of the inverse direction.
• The choice of the domain of properties, and hence the order of their names, are established in accordance with the following priority list:
  • Temporal Entity and its subclasses
  • Thing and its subclasses
  • Actor and its subclasses
  • Other

CIDOC CRM is formulated as a class system with inheritance. A property P with domain A and range B will also be a property between any possible subclasses of A and of B. In many cases there will be a common subclass C of both A and B. In these cases, when the property is restricted to C, that is, with C as domain and range, the restricted property could be transitive. For instance, an E73 Information Object can be incorporated into an E90 Symbolic Object and thus an information object can be incorporated in another information object.

In the definition of CIDOC CRM the transitive properties are explicitly marked as such in the scope notes. All unmarked properties should be considered as not transitive.

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

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

The present CIDOC CRM specifications are annotated with logical axioms, providing an additional formal expression of the CIDOC CRM ontology. This section briefly introduces the assumptions that are at the basis of the logical expression of the CIDOC CRM (for a fully detailed account of the logical expression of semantic data modelling, see (Reiter,1984)).

The CIDOC CRM is expressed in terms of the primitives of semantic data modelling. As such, it consists of:

• classes, which represent general notions in the domain of discourse, such as the CIDOC CRM class E21 Person which represents the notion of person;
• properties, which represent the binary relations that link the individuals in the domain of discourse, such as the CIDOC CRM property P152 has parent linking a person to one of the person’s parent.

Classes and properties are used to express ontological knowledge by means of various kinds of constraints, such as sub-class/sub-property links, e.g., E21 Person is a sub-class of E20 Biological Object, or domain/range constraints, e.g., the domain of P152 has parent is class E21 Person.

In contrast, first-order logic-based knowledge representation relies on a language for formally encoding an ontology. This language can be directly put in correspondence with semantic data modelling in a straightforward way:

• classes are named by unary predicate symbols; conventionally, we use E21 as the unary predicate symbol corresponding to class E21 Person;
• properties are named by binary predicate symbols; conventionally, we use P152 as the binary predicate symbol corresponding to property P152 has parent.
• properties of properties, “.1 properties” are named by ternary predicate symbols; conventionally, we use P14.1 as the ternary predicate symbol corresponding to property P14.1 in the role of.

Ontology is expressed in logic by means of logical axioms, which correspond to the constraints of semantic modelling. In the definition of classes and properties of the CIDOC CRM the axioms are placed under the heading ‘In first order logic’. There are several options for writing statements in first order logic. In this document we use a standard compact notation widely used in text books and scientific papers. The definition is given in the table below.

Table 1: Symbolic Operators in First Order Logic Representation

For instance, the above sub-class link between E21 Person and E20 Biological Object can be formulated in first order logic as the axiom:

(∀x) [E21(x) ⇒E20(x)]

(reading: for all individuals x, if x is a E21 then x is an E20).

In the definitions of classes and properties in this document the universal quantifier(s) are omitted for simplicity, so the above axiom is simply written:

E21(x) ⇒E20(x)

Likewise, the above domain constraint on property P152 has parent can be formulated in first order logic as the axiom:

P152(x,y) ⇒E21(x)

(reading: for all individuals x and y, if x is a P152 of y, then x is an E21).

These basic considerations should be used by the reader to understand the logical axioms that are used into the definition of the classes and properties. Further information about the first order formulation of CIDOC CRM can be found in (Meghini & Doerr, 2018)

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

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

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

the property is necessary for the domain

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

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

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

The CIDOC CRM is a formal ontology in the sense introduced by (Guarino, 1998).^[4] The present document is intended to embrace an audience not specialized in computer science and logic; therefore, it focuses on the informal semantics and on the pragmatics of the CIDOC CRM concepts, offering a detailed discussion of the main traits of the conceptualization underlying the CIDOC CRM through basic usage patterns.^[5] The CIDOC CRM aims to assist sharing, connecting and integrating information from research about the past. In order to understand the function of a formal ontology of this kind, one needs to make the following distinctions:

• The material reality. For the purpose of the CIDOC CRM, material reality is regarded as whatever has substance that can be perceived with senses or instruments. Examples are people, a forest or a settlement environment, sea, atmosphere, distant celestial or cellular micro structures, including what we assume could be potentially or theoretically perceived if we could be there, such as the center of Earth or the sun, and all that is past. It is constrained to space and time. What goes on in our minds or is produced by our minds is also regarded as part of the material reality, as it becomes materially evident to other people at least by our utterances, behavior and products.
• The units of description or particulars, i.e., the things and relations which we refer to in order to distinguish parts of reality. Examples are Mount Ida, the Taj Mahal, the formation of China by emperor Qin Shi Huang (秦始皇) in 221BC, Tut-Ankh Amun and his embalming, Prince Shotoku of Japan sending a mission to China in 607AD, the participation of Socrates in the Battle of Potidaea or the radiocarbon dating of the Iceman Ötzi (Kutschera, 2002).

A formal ontology, such as the CIDOC CRM, constitutes a controlled language for talking about particulars. I.e., it provides classes and properties for categorizing particulars as so-called “instances” in a way that their individuation, unity and relevant properties are as unambiguous as possible. For instance, Tut-Ankh Amun as instance of E21 Person is the real pharaoh from his birth to death, and not extending to his mummy, as follows from the specification of the class E21 Person and its properties in the CIDOC CRM.

For clarification, the CIDOC CRM does not take a position against or in favour of the existence of spiritual substance nor of substance not accessible by either senses or instruments, nor does it suggest a materialistic philosophy. However, for practical reasons, it relies on the priority of integrating information based on material evidence available for whatever human experience. The CIDOC CRM only commits to a unique material reality independent from the observer.

When we provide descriptions of particulars, we need to refer to them by unique names, titles or constructed identifiers, all of which are instances of E41 Appellation in the CIDOC CRM, in order the reference to be independent of the context. (In contrast, reference to particulars by pronouns or enumerations of characteristic properties, such as name and birth date, are context dependent). The appellation, and the relation between the appellation and the referred item or relationship, must not be confused with the referred item and its identity. For example, Tut-Ankh Amun the name (instance of E41 Appellation) is different from Tut-Ankh Amun the person (instance of E21 Person) and also different from the relationship between name and person (P1 is identified by). Instances of CIDOC CRM classes are the real particulars, not their names, but in descriptions, names must be used as surrogates for the real things meant. Particulars are approximate individuations, like sections, of parts of reality. In other words, the uniqueness of reality does not depend on where one draws the line between the mountain and the valley.

A CIDOC CRM-compatible knowledge base (KB) (Meghini & Doerr 2018) is an instance of E73 Information Object in the CIDOC CRM. It contains (data structures that encode) formal statements representing propositions believed to be true in a reality by an observer. These statements use appellations (e.g., http://id.loc.gov/authorities/names/n79066005^[6]) of ontological particulars and of CRM concepts (e.g., P100i died in). Thereby users, in their capacity of having real-world knowledge and cognition, may be able to relate these statements to the propositions they are meant to characterize, and be able to reason and research about their validity. In other words, the formal instances in a knowledge base are the identifiers, not the real things or phenomena. A special case is digital content: a KB in a computer system may contain statements about instances of E90 Symbolic Object and the real thing may be text residing within the same KB. The instance of E90 Symbolic Object and its textual representation are separate entities and they can be connected with the property P190 has symbolic content.

Therefore, a knowledge base does not contain knowledge, but statements that represent knowledge, as long as there exist people that can resolve the identifiers used to their referents. (Appellations described in a knowledge base, and not used as primary substitutes of other items, are of course explicitly declared as instances of E41 Appellation in the knowledge base.)

This section describes a recommended good practice how to relate authority to knowledge base contents.

Statements in a KB must have been inserted by some human agent, either directly or indirectly. However, these statements often make no reference to that agent, lacking attribution of authority. An example of such statements in the CIDOC CRM is information expressed through shortcuts such as P2 has type. In the domain of cultural heritage, it is common practice that the responsibility for maintaining knowledge in the KB is elaborated in institutional policy or protocol documents. Thus, it is reasonable to hold that statements which lack explicit authority attribution can be read as the official view of the administrating institution of that system, i.e., the maintainers of the KB. This does not imply that the knowledge described in the KB is complete. So long as the information is under active management, it remains continuously open to revision and improvement as further research reveals further understandings.^[7] A KB does not represent a slice of reality, but the justified beliefs of its maintainers about that reality. For simplicity, we speak about a KB as representing some reality.

Statements in a KB may also carry explicit references to agents that produced them, i.e., further statements of responsibility. In CIDOC CRM such statements of responsibility are expressed though knowledge creation events such as E13 Attribute Assignment and its relevant subclasses. Any knowledge that is about an explicit knowledge creation event, where the creator’s identity has been given, is implicitly attributed to be correctly referred to in the KB by the maintaining authority, whereas the responsibility for the content created by that event is assigned to the agent identified as causal to that event.

In the special case of an institution taking over stewardship of a database transferred into their custody, two relations of responsibility for the knowledge therein can be envisioned. If the institution accepts the dataset and undertakes to maintain and update it, then they take on responsibility for that information and become the default authority behind its statements as described above. If, on the other hand, the institution accepts the data set and stores it without change as a closed resource, then it can be considered that the default authority remains the original steward like for any other scholarly document kept by the institution.

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

Of necessity, some concepts covered by the CIDOC CRM are defined in less details than others: E39 Actor and E30 Right, for example. This is a natural consequence of staying within the model’s clearly articulated practical scope in an intrinsically unlimited domain of discourse. These ‘underdeveloped’ concepts can be considered as candidate superclasses for compatible extensions, in particular for disciplines with a respective focus. Additions to the model are known as extensions while the main model is known as CRMbase.

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

A sufficient condition for the compatibility of an extension with the CIDOC CRM is that its classes, other than E1 CRM Entity, subsume all classes of the extension, and all properties of the extension are either subsumed by CRM properties, or are part of a path for which a CIDOC CRM property is a shortcut, and that classes and properties of the extension can be well distinguished from those in the CIDOC CRM. For instance, a class “tangible object” may be in conflict with existing classes of the CIDOC CRM. Obviously, such a condition can only be tested intellectually.

The CRM provides a number of mechanisms to ensure that coverage of the intended scope can be increased on demand without loosing compatibility:

1. Existing classes can be extended, either structurally as subclasses or dynamically using the type hierarchy (see section About Types below).
2. Existing properties can be extended, either structurally as subproperties, or in some cases, dynamically, using properties of properties which allow subtyping (see section About Types below).
3. Additional information that falls outside the semantics formally defined by the CIDOC CRM can be recorded as unstructured data using E1 CRM Entity. P3 has note: E62 String.
4. Extending the CIDOC CRM by superclasses and properties that pertain to a wider scope. They are called conservative extensions, if they preserve backwards compatibility with instances described with the CIDOC CRM.

Following strategies 1, 2 and 3 will have the result that the CIDOC CRM concepts subsume and thereby cover the extensions. This means that querying an extended knowledge base only with concepts of the CIDOC CRM will nevertheless retrieve all facts described via the extensions.

In mechanism 3, the information in the notes is accessible in the respective knowledge base by retrieving the instances of E1 CRM Entity that are domain of P3 has note. Keyword search will also work for the content of the note. Rules should be applied to attach a note to the item most specific for the content. For instance, details about the role of an actor in an activity should be associated with the instance of E7 Activity, and not with the instance of E39 Actor. This approach is preferable when queries relating elements from the content of such notes across the knowledge base are not expected.

In general, only concepts to be used for selecting multiple instances from the knowledge base by formal querying need to be explicitly modelled. This criterion depends on the expected scope and use of the particular knowledge base. The CIDOC CRM prioritizes modelling the kinds of facts one would like to retrieve and relate from heterogeneous content sources, potentially from different institutions. It does not, by way of contrast, focus on the modelling of facts with a more local scope such as the administrative practices internal to an institution.

Mechanism 4, conservative extension, is more complex:

With increasing use of the CIDOC CRM, there is also a need for extensions that model phenomena from a scope wider than the original one of the CIDOC CRM, but which are also applicable to the concepts that do fall within the CIDOC CRM’s scope. When this occurs, properties of the CIDOC CRM may be found to be applicable more generally to superclasses of the extension than to those of their current domain or range in the CIDOC CRM. This is a consequence of the key principle of the CIDOC CRM to model “bottom up”, i.e., selecting the domains and ranges for properties to be as narrow as they would apply in a well understood fashion in the current scope, thus avoiding making poorly understood generalizations at risk of requiring non-monotonic correction.

The fourth mechanism for extending the CIDOC CRM by conservation extension can be seen to be split into two cases:

1. A new class or property is added to an extension of the CIDOC CRM, which is not covered by superclasses other than E1 CRM Entity or a superproperty in the CIDOC CRM respectively. In this case, all facts described only by such concepts are not accessible by queries with CIDOC CRM concepts. Therefore, the extension should publish in a compatibility statement the additional relevant high-level classes and properties needed to retrieve all facts documented with the extended model. This case is a monotonic extension.
2. The domain or range of an existing property in the CIDOC CRM is changed to a superclass of the one or the other or both, because the property is understood to be applicable beyond its originally anticipated scope. In this case, all facts described by the extension are still accessible by querying with the concepts of the CIDOC CRM, but the extension can describe additional facts that the CIDOC CRM could not. This case is a monotonic extension and generally recommended, because it enables bottom-up evolution of the model. If this change is part of a new release of the CIDOC CRM itself, it is simply backwards compatible, and this has been done frequently in the evolution of this model.

If case (2) should be documented and implemented in an extension module separate from the CIDOC CRM, it may come in conflict with the current way knowledge representation languages, such as RDF/OWL, treat it, because in formal logic changing the range or domain of a property is regarded as changing the ontological meaning completely; there is no distinction between the meaning of the property independent of domain and range and the specification of the domain and range. It is, however, similar to what in logic is called a conservative extension of a theory, and necessary for an effective modular management of ontologies.

Therefore, for the interested reader, we describe here a definition of this case in terms of first order logic, which shows how modularity can formally be achieved:

Let us assume a property P defined with domain class A and range class C also holds for a domain class B, superclass of A, and a range class D, superclass of C, in the sense of its ontological meaning in the real world. We describe this situation by introducing an auxiliary formal property P’, defined with domain class B and range class D, and apply the following logic:

A(x) ⇒ B(x)

C(x) ⇒ D(x)

P(x,y) ⇒ A(x)

P(x,y) ⇒ C(y)

P’(x,y) ⇒ B(x)

P’(x,y) ⇒ D(y)

Then, P’ is a conservative extension of P if: A(x) ∧ C(y) ∧ P’(x,y) ⇔ P(x,y)

In other words, a separate extension module may re-declare the respective property with another identifier, preferably using the same label, and implement the above rule.

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

• CIDOC CRM classes and properties are either primitive, or they are key concepts in the practical scope.
• Complements of CIDOC CRM classes are not declared, because, considering the Open World principle, there are no properties for complements of a class (see Terminology and first consequence of Monotonicity).

A CIDOC CRM class is declared when:

• It is required as the domain or range of a property not appropriate to its superclass.
• It serves as a merging point of two CIDOC CRM class branches via multiple IsA (e.g., E25 Human-Made Feature). When the branch superclasses are used for multiple instantiation of an item, this item is in the intersection of the scopes. The class resulting from multiple IsA should be narrower in scope than the intersection of the scopes of the branch superclasses.
• It is useful as a leaf class (i.e., at the end of a CIDOC CRM branch) to domain communities building CIDOC CRM extensions or matching key domain classes from other models to the CIDOC CRM (e.g., E34 Inscription).

The CIDOC CRM’s primary function is to support the meaningful integration of information in an Open World. The adoption of the Open World principle means that the CIDOC CRM itself must remain fundamentally open and knowledge bases implemented using it should be flexible enough to receive new insights. At the model level, new classes and properties within the CIDOC CRM’s scope may be found in the course of integrating more documentation records or when new kinds of relevant facts come to the attention of its maintainers. At the level of the KBs, the need to add or revise information may arise due to numerous external factors. Research may open new questions; documentation may be directed to new or different phenomena; natural or social evolution may reveal new objects of study.

It is the aim of the maintainers of the CIDOC CRM to respect the Open World principle and to follow the principle of monotonicity. Monotonicity requires that adding new classes and properties to the model or adding new statements to a knowledge base does not invalidate already modelled structures and existing statements.

A first consequence of this commitment, at the level of the model, is that the CIDOC CRM aims to be monotonic in the sense of Domain Theory. That is to say, the existing CIDOC CRM constructs and the deductions made from them should remain valid and well-formed, even as new constructs are added by extensions to the CIDOC CRM. Any extensions should be, under this method, backwards compatible with previous models. The only exception to this rule arises when a previous construct is considered objectively incorrect by the domain experts and thus subjected to corrective revision. Adopting the principle of monotonicity has active consequences for the basic manner in which classes and properties are designed and declared in the CIDOC CRM. In particular, it forbids the declaration of complement classes, i.e., classes solely defined by excluding instances of some other classes.

For example:

FRBRoo (Bekiari et al (eds). 2015) extends the CIDOC CRM. In version 2.4 of FRBRoo, F51 Name Use Activity was declared as a subclass to the CIDOC CRM class E7 Activity. This class was added in order to describe a phenomenon specific to library practice and not considered within CRM base. F51 Name Use Activity describes the practice of an instance of E74 Group adopting and deploying a name within a context for a time-span. The creation of this extension is monotonic because no existing IsA relationship or inheritance of properties in CRM base are compromised and no future extension is ruled out. By way of contrast, if, to handle this situation, a subclass “Other Activity” had been declared, a non-monotonic change would have been introduced. This would be the case because the scope note of a complement class like “Other Activities” would forbid any future declaration of specializations of E7 Activity such as ‘Name Use Activity’. In the case the need arose to declare a particular specialized subclass, a non-monotonic revision would have to be made, since there would be no principled way to decide which instances of ‘Other Activity’ were instances of the new, specialized class and which were not. Such non-monotonic changes are extremely costly to end users, compromising backwards compatibility and long-term integration.

As a second consequence, maintaining monotonicity is also required during revising or augmenting data within a CIDOC CRM compatible system. That is, existing CIDOC CRM instances, their properties and the deductions made from them, should always remain valid and well-formed, even as new instances, regarded as consistent by the domain expert, are added to the system.

For example:

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

This example further demonstrates that the IsA hierarchy of classes and properties can represent characteristic stages of increasing knowledge about some item during the processes of investigation and collection of evidence. Higher level classes can be used to safely classify objects whose precise characteristics are not known in the first instance. An ambiguous biological object may, for example, be classified as only a physical object. Subsequent investigation can reveal its nature as a biological object. A knowledge base constructed with CIDOC CRM classes designed to support monotonic revision allows for seeking physical objects that were not yet recognized as biological ones. This ability to integrate information with different specificity of description in a well-defined way is particularly important for large-scale information integration. Such a system supports scholars being able to integrate all information about potentially relevant phenomena into the information system without forcing an over or under commitment to knowledge about the object. Since large scale information integration always deals with different levels of knowledge of its relevant objects, this feature enables a consistent approach to data integration.

A third consequence, applied at the level of the knowledge base, is that in order to formally preserve monotonicity, when it is required to record and store alternative opinions regarding phenomena all formally defined properties should be implemented as unconstrained (many: many) so that conflicting instances of properties are merely accumulated. Thus, integrated knowledge can serve as a research tool for accumulating relevant alternative opinions around well-defined entities, whereas conclusions about the truth are the task of open-ended scientific or scholarly hypothesis building.

For example:

King Arthur’s basic life events are highly contested. Once entered in a knowledge base, he should be defined as an instance of E21 Person and treated as having existed as such within the sense of our historical discourse. The instance of E21 Person is used as the collection point for describing possible properties and existence of this individual. Alternative opinions about properties, such as the birthplace and his living places, should be accumulated without validity decisions being made during data compilation. King Arthur may be entered as a different instance, of E28 Conceptual Object, for describing him as mythological character and accumulating possibly mythological facts.

The fourth consequence of monotonicity relates to the use of time dependent properties in a knowledge base. Certain properties declared in the CIDOC CRM, such as having a part, an owner or a location, may change many times for a single item during the course of its existence. Asserting that such a property holds for some item means that that property held for some particular, undetermined time-span within the course of its existence. Consequently, one item may be the subject of multiple statements asserting the instantiation of that property without conflict or need for revision. The collection of such statements would reflect an aggregation of these instances of this property holding over the time-span of the item’s existence. If a more specific temporal knowledge is required/available, it is recommended to explicitly describe the events leading to the assertion of that property for that item. For example, in the case of acquiring or losing an item, it would be appropriate to declare the related event class such as E9 Move. By virtue of this principle, the CRM achieves monotonicity with respect to an increase of knowledge about the states of an item at different times, regardless of their temporal order.

Time-neutral properties may be specialized in a future monotonic extension by time-specific properties, but not vice-versa. Also, many properties registered do not change over time or are relative to events in the model already. Therefore, the CIDOC CRM always gives priority to modelling properties as time-neutral, and rather representing changes by events.

However, for some of these properties many databases may describe a “current” state relative to some property, such as “current location” or “current owner”. Using such a “current” state means that the database manager is able to verify the respective reality at the latest date of validity of the database. Obviously, this information is non-monotonic, i.e., it requires deletion when the state changes. In order to preserve a reduced monotonicity, these properties have time-neutral superproperties by which respective instances can be reclassified if the validity becomes unknown or no longer holds. Therefore, the use of such properties in the CRM is only recommended if they can be maintained consistently. Otherwise, they should be reclassified by their time-neutral superproperties. This holds in particular if data is exported to another repository, see also the paragraph “Authorship of Knowledge Base Contents”

Classes are disjoint if they cannot share any common instances at any time, past, present or future. That implies that it is not possible to instantiate an item using a combination of classes that are mutually disjoint or with subclasses of them (see “multiple instantiation” in section “Terminology”). There are many examples of disjoint classes in the CIDOC CRM.

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

• E2 Temporal Entity is disjoint from E77 Persistent Item. Instances of the class E2 Temporal Entity are perdurants, whereas instances of the class E77 Persistent Item are endurants. Even though instances of E77 Persistent Item have a limited existence in time, they are fundamentally different in nature from instances of E2 Temporal Entity, because they preserve their identity between events. Declaring endurants and perdurants as disjoint classes is consistent with the distinctions made in data structures that fall within the CIDOC CRM’s practical scope.
• E18 Physical Thing is disjoint from E28 Conceptual Object. The distinction is between material and immaterial items, the latter being exclusively human-made. Instances of E18 Physical Thing and E28 Conceptual Object differ in many fundamental ways; for example, the production of instances of E18 Physical Thing implies the incorporation of physical material, whereas the production of instances of E28 Conceptual Object does not. Similarly, instances of E18 Physical Thing cease to exist when destroyed, whereas an instance of E28 Conceptual Object perishes when it is forgotten or its last physical carrier is destroyed.

This page is left blank on purpose

The following paragraphs explain the most general logic of the CIDOC CRM. The CIDOC CRM is a formalized representation of historical discourse, a formal ontology. In this capacity, it is meant to support the (re)presentation of fact based, analytic discourse about what has happened in the past in a human understandable and machine-processable manner. It achieves this function by proposing a series of formalized properties (relations) and classes. The formalized properties support the making of semantically explicit statements relating classes of things. Their formal definition logically explicates the classes of things to which they may pertain. The CIDOC CRM properties thus enable a formal, logically explicit description of relations between individual, real world items, classified under distinct ontological classes. Encoding analytic data pertaining to the past under such a system of statements provides a standard representation for data and allows the uniform application of reasoning to large sets of data.

Grounding this high-level logic is a hierarchical system of classes and relations, that provide basic ontological distinctions by which to represent historical discourse. Familiarity with the basic ontological distinctions made in the top level of the class hierarchy provides the basic entry point to understanding how to apply the CIDOC CRM for knowledge representation.

The highest-level distinction in the CIDOC CRM is represented by the top-level concepts of E77 Persistent Item, equivalent to the philosophical notion of endurant; E2 Temporal Entity, equivalent to the philosophical notion of perdurant and, further, the concept of E92 Spacetime Volume.

As an event-centric model, supporting historical discourse, the CIDOC CRM firstly enables the description of entities that are themselves time-limited processes or evolutions within the passing of time using E2 Temporal Entity and its subclasses. Their basic function is to capture the fact of something having happened over time. In addition to allowing the description of a temporal duration, the subclasses of E2 Temporal Entity are used to document the historical relations between objects, similar to the role of action verbs in a natural language phrase. The more specific subclasses of E2 Temporal Entity enable the documentation of events pertaining to individually related/affected material, social or mental objects that have been described using subclasses of E77 Persistent Item. This precise documentation is enabled through the use of specialized properties formalizing the manner of the relation or affect. Examples of specific subclasses of E2 Temporal Entity include E12 Production, which allows the representation of events of making things by humans, and E5 Event which allows the documentation, among other things, of geological events and large-scale social events such as a war. Each of these subclasses have specific properties associated to them which allow them to function to represent the specific, real world connection between instances of E77 Persistent Item, such as the relation of an object to its time of production through P108 was produced by (E12) or the relation of a place to a geological phenomenon through P7 was place of (E5). The entities that E2 Temporal Entity documents, being time limited processes / occurrences, are such that their existence can be declared only on the basis of direct observation or recording of the event, or indirect observation of its material outcomes. Evidence of such entities may be preserved on material objects that are permanently changed because of them. Likewise, events may have been recorded in text or remembered through oral history. E2 Temporal Entity and its subclasses are central to the CRM and essential for almost all modelling tasks (e.g., in a museum catalogue one cannot consider an object outside its production event).

The real-world entities, which the event centric modelling of the CIDOC CRM aims to enable the accurate historical description of, are captured through E77 Persistent Item and its subclasses. E77 Persistent Item is used to describe entities that are relatively stable in form through the passage of time, maintaining a recognizable identity because their significant properties do not change. Specific subclasses of E77 Persistent Item can illustrate this point. E22 Human Made Object is used for the description of discrete, physical objects having been produced by human action, such as an artwork or monument. An artwork or monument is persistent with regards to its physical constitution. So long as it retains its general physical form, it is said to exist and to participate in the flow of historical events. E28 Conceptual Object is also used to describe persistent items, but of a mental character. It is used to describe identifiable ideas that are named and form an object of historical discourse. Its identity conditions rely in having a carrier by which it can be recalled. The entities described by E77 Persistent Item are prone to change through human activity, biological, geological or environmental processes, but are regarded to continue to exist and be the same just as long as such changes do not alter their basic identity (essence) as defined in the scope note of the relevant class.

The notion of identity is key in the application of CIDOC CRM. The properties and relations it provides are designed to allow the accurate historical description of the evolution of real-world items through time. This being the case, classes and properties are created in order to provide a definition, which will allow the accurate application of the classes or properties to the same real-world items by diverse users. Identity, in the sense of the CIDOC CRM, therefore, means that informed people are able to agree that they refer to the same, single thing in its distinction from others, both in its extent and over its time of existence. The criteria for such a determination should come from understanding the scope note of the respective CIDOC CRM class this thing is regarded to be an instance of, because communication via information systems may not leave space for respective clarifying dialogues between users. For example, the Great Sphinx of Giza may have lost part of its nose, but there is no question that we are still referring to the same monument as that before the damage occurred, since it continues to represent significant characteristics and distinctness from an overall shaping in the past, which is of archaeological relevance. Things lacking sufficient stability or differentiation, such as atmosphere, soil, clouds, waves, are not instances of E77 Persistent Item, and not suited for information integration. Discourse about such items may be documented with concepts of the CIDOC CRM as observations in relation to things of persistent identity, such as places.

Learning to distinguish and then interrelate instances of E77 Persistent Item (endurants) and instances of E2 Temporal Entity (perdurants) using the appropriate properties is key to the proper understanding and application of CIDOC CRM in order to formally represent analytic historical data. In the large majority of cases, the distinction this provides, and the subsequent elaboration of subclasses and properties is adequate to describe the content of database records in the cultural and scientific heritage domain. In exceptional cases, where we need to consider complex combinations of changes of spatial extent over time, the concept of spacetime (E92 Spacetime Volume) also needs to be considered. E92 Spacetime Volume describes the entities whose substance has or is an identifiable, confined geometrical extent in the material world that may vary over time, fuzzy boundaries notwithstanding. For example, the built settlement structure of the city of Athens is confined both from the point of view of time-span (from its founding until now) and from its changing geographical extent over the centuries, which may become more or less evident from current observation, historical documents and excavations. Even though E92 Spacetime Volume is an important theoretical part of the model, it can be ignored for most practical documentation and modelling tasks.

The key to the proper understanding of CIDOC CRM comes through the appropriation of its basic divisions and the logic these represent. It is important to underline that the CIDOC CRM is not intended to function as a classification system or vocabulary tool. The basic class divisions in CIDOC CRM are declared in order to be able to apply distinct properties to these classes and, in so doing, formulate precise, analytic propositions that represent historical realities. The expressive power of CIDOC CRM comes not from the application of classes to classify entities but in the documenting the interrelation of individual historical items through well-defined properties. These properties characteristically cover subjects such as relations of identifying items by names and identifiers; participation of persistent items in temporal entities; location of temporal entities and physical things in space and time; relations of observation and assessment; part-decomposition and structural properties of anything; influence of things and experiences on the activities of people and their products; reference of information objects to anything.

We explain these concepts with the help of graphical representations in the next sections.

Figure 1 illustrates the minimal properties in the CIDOC CRM for documenting “what has happened”, the central pattern of the Model. Let us first consider the class E1 CRM Entity, the formal top class of the model. It primarily serves a technical purpose to aggregate the ontologically meaningful concepts of the model. It declares however two important properties of general validity and distinct features of the Model: P1 is identified by, with range E41 Appellation, makes the fundamental ontological distinction between the identity of a particular and an identifier (see section “Reality, Knowledge Bases and CIDOC CRM” above), and in practice allows for describing a discourse about resolving historical ambiguities of names and reconciliation of multiple identifiers. The property P2 has type, with range E55 Type, constitutes a practical interface for refining classes by terminologies, being often volatile, as detailed in the section “About Types” below.

Figure 1: High Level Properties and Classes of CIDOC CRM

All classes in figure 1 are direct or indirect subclasses of E1 CRM Entity, but for better readability, only the “subclass of” -link from E2 Temporal Entity is shown. The latter comprises phenomena that continuously occur over some time-span (E52 Time-Span) in the natural time dimension, but some of them may not be confined to specific area, such as a marriage status. Further specializing, E4 Period comprises phenomena occurring in addition within a specific area in the physical space, which can be specified by P7 took place at, with range E53 Place. Instances of E4 Period can be of any size, such as the Warring States Period, the Roman Period, a siege or just the process of making a signature. Further specializing, E5 Event comprises phenomena involving and affecting certain instances of E77 Persistent Item in a way characteristic of the kind of process, which can be specified by the property P12 occurred in the presence of. This concept of presence is very powerful: It constrains the existence of the involved things to the respective places within the specified time and implies the potential of passive or active involvement and mutual impact. Via presence, events represent nodes in a network of things meeting in various combinations in the course of time at different places.

The most important specializations of E77 Persistent Item in this context are: E39 Actor, those capable of intentional actions, E18 Physical Thing, having an identity bound to a relative stability of material form, and E28 Conceptual Object, the idealized things that can be recognized but have an identity independent from the materialization on a specific carrier. The property P12 occurred in the presence of has 36 direct and indirect subproperties, relating these and many more subclasses of E5 Event and E77 Persistent Item. Regardless whether a CRM-compatible knowledge base is created with these properties only or with their much more expressive specializations, querying for the above presented five properties will provide answer to all “Who-When-Where-What-How” questions, and allow for retrieving potentially richly elaborated stories of people, places, times and things.

This pattern of “meeting” is complemented by two more subclasses of E5 Event: E63 Beginning of Existence and E64 End of Existence, which imply not only presence, but constitute the endpoints of existence of things and people in space and time, often in explicit presence and interaction with others, be they causal by producing or consuming or just witnessing. Note that the Model supports multiple instantiation. As a consequence, particular events can be instances of combinations of these and others classes, describing tightly integrated processes of multiple nature. The representation of things connected in events by presence, beginning and end of existence is sufficient to describe the logic of termini postquos and antequos, a major form of reasoning about chronology in historical studies.

Example:

As a simple, real example of applying the above concepts we present a historical event, relevant for the history of art: Johann-Joachim Winkelmann (a German Scholar) has seen the so-called Laocoön Group in 1755 in the Vatican in Rome (at display in the Cortile del Belvedere). He described his impressions in 1764 in his “History of the Art of Antiquity”, (being the first to articulate the difference between Greek, Greco-Roman and Roman art, characterizing Greek art with the famous words “…noble simplicity, silent grandeur”). The sculpture, in Hellenistic "Pergamene baroque" style (Bieber 1961, Brilliant 2000) is widely assumed to be a copy, made between 27 BC and 68 AD (following a Roman commission) from a Greek (no more extent) original. Johann-Joachim Winkelmann was born 1717 as child of Martin Winkelmann and Anna-Maria Meyer and died in 1768 in Trieste.

Figure 2 presents a semantic graph of this event, as described above, using CIDOC CRM concepts. The facts in parentheses above are omitted for better clarity. Instances of classes are represented by informative labels instead of identifiers, in boxes showing the class label above the instance label. Properties are represented as arrows with the property label attached. After class labels and property labels, we show in parenthesis the identifiers of the respective superclasses and superproperties from figure 1, in order to demonstrate that the story can be represented and queried with these concepts only. It also shows how concept specialization increases expressiveness without losing genericity. It is noteworthy that the transfer of information from the Greek original, to the copy, to the mind of Winkelmann and into his writings can be solely understood by this chain of things being present in different meetings. Note also that the degree to which a fact is believed to be real does not affect the choice of CIDOC CRM concepts for description of the fact, nor the reality concept underlying the Model.

Figure 2: CIDOC CRM Encoding Example (Winkelmann seeing Laocoön)

Figure 2 represents in addition one more top-level property of the CIDOC CRM: P67 refers to, which describe an evidence-based fact that an information object makes reference to an identifiable item.

As mentioned above, the central concept of the CIDOC CRM is the representation of a part of reality that can be approximated as a network of things meeting in various combinations in spacetime. Using the same example from above, figure 3 illustrates this concept via an alternative symbolic representation. It aims at rendering the idea that people and things in the past have performed mostly unknown trajectories in spacetime and the historical facts known to us constrain their possible whereabouts for some limited time-spans to having been together at some known or unknown place.

We use a one-dimensional representation of space, as used in archaeology to describe the spatial evolution of periods or cultures over time, and a vertical time axis. We symbolize the trajectories of things and people as fuzzy lines between events in order to render their relative indeterminacy between known events. Non-animate things use to be stationary if not transferred, whereas people may move around on their own. We symbolize events as fuzzy ovals to render the fuzzy boundaries of events in space and time. Note that in this representation, as a general pattern, things may “survive” events, emerge from events or end in events. Beginning and ending of existence impose an additional temporal order on events of causal nature, which can be stronger than explicit dates. We symbolize the unreported ends of existence of people and things, which are also events, by a dot at the end of the trajectory.