Principes de modélisation

Date de création : 2023-11-08

Dernière mise à jour : 2023-12-22

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

Les principes de modélisation suivants ont guidé le développement du CIDOC CRM.

Note de traduction
Références

Reality, Knowledge Bases and CIDOC CRM - De la réalité, des bases de connaissance et du 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 centre 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, behaviour 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 Potidæa 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 for 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/n790660056) 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.) 4 Nicola Guarino defines a formal ontology as a specification of a set of named concepts used to describe and approximate a part of reality, plus a first-order logical theory narrowing down the intended meaning of the named concepts. 5 For the readers interested in computer science and logic, the syntax and formal semantics employed by the CIDOC CRM are given in (Meghini & Doerr 2018), where the computational aspects are also discussed. 6 The URI (instance of E41 Appellation) of the Library of Congress for Tut-Ankh-Amun, the pharaoh.

Le CIDOC CRM est une ontologie formelle dans le sens que l’a introduit (Guarino, 1998)4. Ce document est destiné à une audience qui n’est spécialiste ni de la logique ni des sciences informatiques, de sorte qu’il se concentre sur la sémantique informelle et sur les aspects pragmatiques des concepts du CIDOC CRM. Il s’agit d’une discussion détaillée, à travers des patrons conceptuels fondamentaux5, des principes qui sous-tendent le CIDOC CRM, une ontologie qui a pour objectif de partager, de connecter et d’intégrer de l’information issue de recherches sur le passé. Afin de comprendre la fonction d’une telle ontologie formelle, les distinctions suivantes sont nécessaires : La réalité matérielle est entendue comme étant tout ce qui a une substance qui peut être perçue par le biais des sens ou d’instruments; cela est limité par l’espace et le temps. Cela inclut, par exemple, des peuples, une forêt, un environnement où s’établissent des personnes, la mer, l'atmosphère, des micro structures célestes ou cellulaires, notamment ce qui pourrait être potentiellement ou théoriquement perçu en présence, par exemple le centre de la terre ou du soleil et tout ce qui est passé. Ce qui se produit dans l’esprit ou est le produit de l’esprit est aussi reconnu comme faisant partie de la réalité matérielle dans la mesure où ce produit devient matériellement évident pour les autres par le biais d’énonciations, de comportements et de produits. Les unités de description, ou éléments particuliers sont les choses et relations auxquelles il est fait référence afin de distinguer des éléments de la réalité. Cela inclut le Mont Ida, le Taj Mahal, la formation de la Chine par l’empereur Qin Shi Huang (秦始皇) en 221 AEC, Toutânkhamon et son embaumement, le prince Shōtoku du Japon envoyant une délégation en Chine en 607 EC, la participation de Socrate à la bataille de Potidæa ou encore la datation radiocarbone d’Ötzi (Kutschera, 2002). Une ontologie formelle telle que le CIDOC CRM constitue en fait un langage contrôlé pour parler d’éléments particuliers, c.-à-d. qu’elle offre des classes et propriétés permettant de catégoriser ces éléments particuliers comme des « instances », de sorte que leur individuation, leur unité et les propriétés pouvant leur être associées de manière pertinente soient aussi claires que possible. Par exemple, Toutânkhamon comme instance de E21_Personne est ce pharaon depuis sa naissance jusqu’à sa mort, mais n’est pas sa momie conformément à la définition de la classe E21_Personne et de ses propriétés. Le CIDOC CRM ne statue pas sur l’existence ou l’inexistence d’une substance spirituelle, ni sur l’existence ou l’inexistence d’une substance qui ne soit pas accessible par les sens ou par des instruments, et ne statue pas non plus en faveur d’une philosophie matérialiste. Cependant, pour des raisons pratiques, le CIDOC CRM repose sur la nécessité d’intégrer de l’information issue d’éléments matériels qui peuvent être appréhendés du fait de l’expérience humaine. Le CIDOC CRM renvoie en ce sens à une réalité matérielle indépendante de l’observateur. Lorsque des descriptions d’éléments particuliers sont disponibles, leurs identifiants, noms ou titres uniques (toutes des instances de E41_Appellation dans CIDOC CRM) sont utilisés [n.d.t afin qu’ils soient conceptualisés de manière générique (le concept) plutôt que spécifique (le concept tel qu’il se déploie dans un contexte particulier)]. Au contraire, les éléments particuliers évoqués à l’aide de pronoms ou d’énumération de leurs propriétés caractéristiques (comme le nom et la date de naissance) sont spécifiques (ils s’appuient sur le contexte particulier de leur mention). L’appellation ainsi que la relation [n.d.t (ou le lien)] entre l’appellation et l’entité à laquelle elle réfère diffèrent en effet de l’entité elle-même et de son identité. Par exemple, le nom Toutânkhamon (instance de E41_Appellation) diffère de la personne Toutânkhamon (instance de E21_Personne) qui diffère aussi du lien qui unit la personne à son nom (P1_est_identifié_par). Les instances de CIDOC CRM sont donc les réels éléments particuliers (plutôt que leurs noms), bien que dans les descriptions les noms doivent être utilisés à titre d’auxiliaires. Les éléments particuliers sont ainsi des différenciations approximatives de parts de la réalité (comme des sections de celle-ci). En d’autres termes, la réalité a un caractère unique qui est indépendant de toute conceptualisation (p. ex. le fait qu’il y ait une montagne adjacente à une vallée ne dépend pas de la frontière arbitraire qui les distingue). Une base de connaissances (BC) compatible avec CIDOC CRM (Meghini & Doerr 2018) est une instance de E73_Objet_informationnel qui contient des énoncés formels (structures d’encodage de données) représentant des affirmations considérées vraies dans le contexte d’une réalité par un observateur. Ces énoncés utilisent les appellations (p. ex. http://id.loc.gov/authorities/names/n790660056) de concepts ontologiques spécifiques ou de concepts de CIDOC CRM (p. ex. P100i_est_mort_par). Les utilisateurs, de par leur connaissance du monde réel et leur cognition, peuvent établir des liens entre ces énoncés formels et les affirmations auxquelles ils réfèrent pour les examiner de plus près et évaluer leur validité. Le contenu numérique fait cependant classe à part, car une BC peut contenir des énoncés au sujet d’instances de E90_Objet_symbolique dont la réelle incarnation existe dans la BC elle-même. L’instance de E90_Objet_symbolique et sa représentation textuelle sont cependant des entités distinctes qui peuvent néanmoins être liées par la propriété P190_a_pour_contenu_symbolique. Une base de connaissances ne contient donc pas les connaissances elles-mêmes, mais bien les énoncés qui représentent ces connaissances tant et aussi longtemps que des personnes en mesure de résoudre les identifiants à leurs référents sont présentes. Les appellations décrites dans une base de connaissances et qui ne sont pas utilisées comme auxiliaires principaux d’autres entités sont néanmoins toujours déclarées comme des instances de E41_Appellation dans la base de connaissances. 4 Nicola Guarino définit une ontologie formelle comme la spécification d’un ensemble de concepts nommés et utilisés pour déterminer par approximation et pour décrire une part de la réalité, spécification à laquelle s’ajoute une théorie logique du premier ordre précisant la signification prévue de ces mêmes concepts nommés. 5 Les lecteurs intéressés par les sciences informatiques, la logique, la syntaxe et la sémantique formelles utilisées par le CIDOC CRM peuvent consulter (Meghini & Doerr 2018) qui examine les aspects computationnels de l’ontologie. 6 L’URI (instance de E41_Appellation) de la Library of Congress pour le pharaon Toutânkhamon.

Note de traduction
Références	Office québécois de la langue française. « base de connaissances ». Dans Grand dictionnaire terminologique. Québec, CA-QC: Office québécois de la langue française, 2017. http://gdt.oqlf.gouv.qc.ca/ficheOqlf.aspx?Id_Fiche=8366746.

Authorship of Knowledge Base Contents - De l’auctorialité des contenus d’une base de connaissances

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 through 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. 7 Statements in a KB may be in contradiction to the ontologically defined quantification of properties without the KB being broken or invalid in any sense, either because necessary properties are unknown or there exist good reasons to assume alternative values for properties with limited cardinality, be it by the same or by different maintainers.

Cette section présente les pratiques exemplaires qui s'appliquent lors de la liaison de contenu d’autorité aux contenus d’une base de connaissances (BC). Les énoncés d’une BC doivent avoir été introduits par un agent humain de manière directe ou indirecte, mais ils ne font souvent pas explicitement référence à cet agent, de sorte que l’autorité sous laquelle une information a été émise n’est pas établie (c’est le cas, par exemple, lors de l’utilisation de raccourcis tels que P2_a_pour_type). Dans le domaine patrimonial, la responsabilité du maintien des informations dans la base de connaissances repose la plupart du temps sur des politiques institutionnelles ou des protocoles documentaires. Il est donc raisonnable de conclure que des affirmations dénuées d’une référence explicite à leur auteur constituent néanmoins le point de vue officiel de l’institution administrant le système (c.-à-d. le responsable de la BC). Cela n’implique pas pour autant que les savoirs représentés dans la BC sont complets ou exhaustifs, de sorte que, tant que l’information fait l’objet d’un maintien actif, elle est sujette à des révisions et à des améliorations au gré de l’avancement de la recherche et de la compréhension qui en est faite7. Une BC ne représente en effet pas une part de la réalité, mais bien la conception que s’en font raisonnablement ces responsables même si, aux fins de simplicité, il est souvent indiqué qu’une BC représente une réalité. Les énoncés d’une BC peuvent toutefois avoir des références explicites aux agents qui les ont produits (c.-à-d. des énoncés de responsabilité supplémentaires [n.d.t. qui s’ajoutent à l’énoncé institutionnel implicite]). Dans CIDOC CRM, de tels énoncés de responsabilité prennent la forme d’évènements de création de connaissances par le biais de E13_Assignation_d'attribut ou de l’une de ses sous-classes pertinentes. Lorsqu’un évènement de création de connaissances comporte un énoncé indiquant explicitement qui est son auteur, l’autorité de cet évènement est attribuée à l’institution responsable du maintien de la BC alors que le contenu résultant de cet évènement est attribué à l’agent l’ayant initié. Lorsqu’une institution prend à sa charge une base de données dans le cadre d’un transfert de sa garde d’une autorité administrative à une autre, deux relations de responsabilité sur les connaissances de cette BC sont possibles. Si l’institution hôte accepte la responsabilité du maintien des informations, elle devient l’autorité associée par défaut aux énoncés qui s’y trouvent. Si, par contre, l’institution hôte traite l’ensemble des données comme une ressource « fermée » [n.d.t. donc traité à la manière d’un artéfact], l’autorité associée par défaut aux énoncés qui s’y trouvent sera celle de l’institution initiale (comme c’est le cas de tout autre document de recherche se trouvant dans la collection de l’institution hôte). [n.d.t. voir « Processus de création de connaissances » dans la section Terminologie.] 7 Les énoncés se trouvant dans une BC peuvent entrer en contradiction avec la quantification ontologique des propriétés sans que cette BC ne soit pour autant dysfonctionnelle ou invalidée. Une telle situation pourrait survenir soit parce que des propriétés sont inconnues, soit parce qu’il est raisonnable pour l’institution ou personne responsable du maintien de penser que des valeurs alternatives sont possibles pour des propriétés dotées d’une cardinalité limitée.

Note de traduction
Références

Extensions of CIDOC CRM - Des extensions de CIDOC CRM

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 losing compatibility: Existing classes can be extended, either structurally as subclasses or dynamically using the type hierarchy (see section About Types below). 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). 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. 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.

Puisque le domaine d’application du CIDOC CRM est en fait un sous-ensemble du monde « réel » qui lui est infini, le modèle a été conçu pour être extensible [n.d.t. afin de répondre aux différents besoins de documentation qui pourraient en émerger]. Cette extensibilité repose en grande partie sur la possibilité d’établir des liens avec des systèmes externes compatibles hiérarchisés par types. Certains concepts du CIDOC CRM sont nécessairement définis plus précisément que d’autres du fait de son application pratique dans un domaine discursif qui est, lui, illimité (p. ex. les classes E39_Actant et E30_Droit sont brièvement définies alors que d’autres sont plus précises). Ces concepts « sous-développés » peuvent être utilisés comme super-classes possibles d’extensions compatibles (en particulier dans le cas de disciplines qui auraient une orientation spécifique et limitée); de telles additions au modèle principal (auquel on réfère parfois comme le CRMbase) sont généralement qualifiées d’« extensions ». La compatibilité des extensions repose sur le fait que les données structurées selon celles-ci demeurent des instances valides des classes de CRMbase. Cela exige, d’un point de vue pratique, un encadrement des requêtes, de sorte que toute requête d’une base de connaissances (BC) basée sur des concepts du CRMbase doit générer des résultats qui s’alignent avec la sémantique du modèle, et ce peu importe si la représentation de ces connaissances (RC) est structurée uniquement selon CRMbase ou si elle repose aussi en partie sur ses extensions. Par exemple, une requête telle que « énumérer tous les évènements » devrait générer 100 % des instances considérées comme des évènements par le CRMbase peu importe la manière dont elles sont classifiées par les extensions du modèle. Un seuil acceptable de compatibilité d’une extension avec le CIDOC CRM est notamment établi par les conditions suivantes (qui doivent toutes être remplies) : les classes de CRMbase à l’exception de E1_Entité_CRM subsument toutes les classes de cette extension; les propriétés de CRMbase subsument les propriétés de cette extension ou ces dernières font partie d’un chemin sémantique pour lequel une propriété du CRMbase fait office de raccourci; les classes et les propriétés de l'extension peuvent être aisément distinguées de celle du CRMbase (p. ex. une classe « objet tangible » pourrait entrer en conflit avec des classes du CRMbase [n.d.t. comme E19_Objet_Matériel] et cette évaluation ne pourrait être faite qu’intellectuellement). Le CRMbase fournit un certain nombre de mécanismes d’extensibilité afin que son domaine d’application initial puisse être élargi sans pour autant compromettre sa compatibilité : Les classes existantes peuvent faire l’objet d’une extension structurellement par des sous-classes – ou dynamiquement – par une hiérarchie de types [n.d.t. comme un vocabulaire contrôlé] (à ce sujet, consulter la section intitulée Des types). Les propriétés existantes peuvent faire l’objet d’une extension structurellement – par des sous-propriétés – ou dynamiquement – par l’utilisation de propriétés de propriétés permettant le sous-typage (à ce sujet, consulter la section intitulée Des types). Les informations pertinentes pour lesquelles la sémantique formelle du CIDOC CRM serait inadéquate ou insuffisante peuvent être enregistrées à titre de données non structurées en utilisant la forme suivante : p. ex. E1_Entité_CRM . P3_a_pour_note : E62_Chaîne_de_caractères. Le CRMbase lui-même peut être élargi par le biais de super-classes et de propriétés s’appliquant à un domaine plus large (des « extensions conservatrices ») qui maintiennent néanmoins une compatibilité rétroactive avec les instances décrites dans le CRMbase. L’utilisation des stratégies [n.d.t. aussi nommées « mécanismes »] 1, 2 et 3 entraîne une subsomption des extensions par le CRMbase et, de fait, leur couverture complète par ce dernier, de sorte qu’une requête n’utilisant que des concepts du CRMbase dans une base de connaissances extensionnée [n.d.t. mobilisant des extensions] aura pour résultat une extraction de tous les éléments décrits par le biais de ces extensions. Dans le cas du troisième mécanisme [n.d.t. l’utilisation de notes pour représenter des données non structurées], l’information contenues dans les notes est accessible depuis la base de connaissances en extrayant les instances de E1_Entité_CRM qui sont le domaine de P3_a_pour_note ou en effectuant une recherche par mot-clé. La note devrait être appliquée à l’élément qui porte le plus spécifiquement sur le contenu de la note et des règles d’application devraient à cet égard être mises en place [n.d.t. par les responsables de la base de connaissances]. Par exemple, des détails quant au rôle que joue un acteur dans le contexte spécifique d’une activité devraient être associés à l’instance de E7_Activité plutôt que de E39_Actant [n.d.t. puisque ce rôle n’est pas généralement endossé par l’acteur et qu’il ne s’applique qu’au contexte particulier de l’activité décrite). Cette approche est la plus appropriée tant et aussi longtemps qu’il n’est pas nécessaire de faire des requêtes reliant les contenus de plusieurs notes de cette nature dans une même base de connaissances. De manière générale, seuls les concepts soumis à des requêtes formelles sélectionnant des instances multiples de la base de connaissances nécessitent une modélisation explicite; cela repose cependant sur les applications anticipée et pratique de la base de connaissances. Le CIDOC CRM accorde en effet une importance particulière à la modélisation des éléments qu’un utilisateur aimerait extraire et lier depuis des sources hétérogènes (voire inter-institutionnelles) de contenus. Il ne priorise donc pas la modélisation d’éléments dont l’application est localisée et spécifique telles que les pratiques administratives internes d’une institution. Le quatrième mécanisme (l’extension conservatrice) est plus complexe : [n.d.t. L’utilisation des extension conservatrices découle d’un] usage accru du CIDOC CRM dont émane le besoin de modéliser des phénomènes issus d’un domaine d’application plus large que celui qu’avait initialement anticipé le modèle bien que ceux-ci s’inscrivent néanmoins dans le domaine d’application des concepts de CRMbase. Dans de tels cas, les propriétés de CRMbase s’avèrent souvent applicables aux super-classes des extensions de manière plus générale qu’elles ne s’appliquent à leur domaine et/ou à leur portée dans CRMbase. Cela résulte de l’approche « ascendante » [n.d.t. élaboration d’un tout depuis ses parties nécessaires, appelée en anglais « bottom-up »] privilégiée par le CIDOC CRM et selon laquelle les domaines et portées des propriétés sont aussi étroitement définis que possible dans le cadre du domaine d’application concerné (et ce afin d’éviter des généralisations qui exigeraient des corrections non monotones ou induiraient des mécompréhensions). Ce quatrième mécanisme d’extension de CIDOC CRM peut être divisé en deux scénarios : Une classe – qui n’est pas couverte par les super-classes de CRMbase à l’exception de E1_Entité_CRM – ou une propriété – qui n’est pas couverte par les super-propriétés du CRMbase – est ajoutée à une extension de CIDOC CRM, de sorte que les éléments qui ne sont décrits que par ces concepts ne sont pas extraits par une requête faite par des concepts de CRMbase uniquement. Dans un tel cas, l’extension devrait publier un énoncé de compatibilité précisant les classes et propriétés de haut niveau nécessaires à l’extraction de ce qui est documenté par le modèle extensionné (une extension monotone). Le domaine ou la portée d’une propriété du CRMbase est modifié en faveur de la super-classe de l’un [n.d.t. (domaine)], l’autre [n.d.t. (portée)] ou encore des deux en raison du fait que cette propriété couvre un domaine d’application plus large qu’il n’était initialement prévu. Dans un tel cas, tous les éléments décrits par l’extension sont accessibles par le biais d’une requête ne mobilisant que des concepts de CRMbase, bien que l’extension soit en mesure de décrire des éléments additionnels. Il s’agit d’une extension monotone, une pratique généralement recommandée, car elle permet une évolution ascendante du modèle [n.d.t. élaboration d’un tout depuis ses parties nécessaires, appelée en anglais « bottom-up »]. Si un tel changement s’inscrit dans une publication du CIDOC CRM lui-même, il est rétro-compatible (une pratique courante dans l’évolution du modèle). La documentation et l’implémentation de ce second scénario dans le cadre d’un module distinct du CRMbase peut mener à des conflits lors du traitement par des langages de représentation des connaissances tels que RDF/OWL. Cela est dû au fait que, du point de vue de la logique formelle, la modification du domaine ou de la portée d’une propriété constitue un changement de signification ontologique complet : il n’y a pas de distinction, dans ce contexte, entre la signification de la propriété (indépendamment de son domaine et de sa portée) et la spécialisation de son domaine et de sa portée. Cela est comparable à l’extension conservatrice d’une théorie dans un contexte logique, une pratique nécessaire à la gestion modulaire d’ontologies de manière efficace. Un tel cas décrit en logique du premier ordre illustre comment atteindre la modularité formellement dans ce contexte : Assumant qu’une propriété P est définie avec pour domaine une classe A et pour portée une classe C, mais qu’elle porte aussi pour domaine une classe B (une super-classe de A) et pour portée une classe D (une super-classe de C). Cette situation peut être décrite plus aisément par l’introduction d’une propriété P’ dont le domaine est la classe B et la portée la classe D. La logique suivante s’applique donc : 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) Ainsi, P’ est une extension conservatrice de P si A(x) ∧ C(y) ∧ P’(x,y) ⇔ P(x,y) En d’autres termes, un module d’extension distinct peut re-déclarer une propriété avec un autre identifiant (préférablement en utilisant une même étiquette) et implémenter la règle ci-haut.

Note de traduction	Certains paragraphes ont été édités dans la version francophone aux fins de compréhension. Les sections concernées sont indiquées de [n.d.t. texte concerné]. Le terme « fact » pour référer à un élément se trouvant dans une base de connaissances a été traduit par « élément » puisqu’il ne semble pas y avoir de référence à la nature attestée de l’élément en question.
Références	Wikipédia. « Extension conservatrice ». Dans Wikipédia. San Francisco, US-CA: Wikipédia, 17 décembre 2017. https://fr.wikipedia.org/w/index.php?title=Extension_conservatrice&oldid=143598511. ———. « Monotonie ». Dans Wikipédia. San Francisco, US-CA: Wikipédia, 19 février 2017. https://fr.wikipedia.org/w/index.php?title=Monotonie&oldid=134697868.

Minimality - De la minimalité

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).

Bien que le domaine d’application du CIDOC CRM soit très large, le modèle lui-même promeut une économie de moyens, de sorte que : Les classes et propriétés de CIDOC CRM sont soit primitives, soit d’une utilité avérée dans le cadre d’une application pratique; En raison de l’hypothèse du monde ouvert qui statue qu’il n’y a pas de propriétés associées aux compléments d’une classe (voir Terminologie et la première conséquence de la Monotonicité), de tels compléments ne sont pas déclarés dans le cadre du CIDOC CRM. Une classe CIDOC CRM est déclarée lorsque : le domaine ou la portée d’une propriété ne sont pas compatibles avec une super-classe [n.d.t. de sorte que son utilisation exige la création d’une nouvelle classe]; cette nouvelle classe fonctionne comme point de convergence de deux branches de classes CIDOC CRM par le biais de multiples liens estUn (p. ex. E25_Caractéristique_élaborée_par_l'humain). Lorsque les super-classes de ces branches sont utilisées afin d’instancier à plusieurs reprises une entité, cette entité se trouve à l’intersection des domaines d’application de chacune, de sorte qu’une classe résultant de multiples estUn devrait avoir un domaine d’application plus restreint que ceux de ses super-classes; les praticiens du CIDOC CRM qui élaborent des extensions de celui-ci ou s'affairent à établir des équivalences avec des classes essentielles d’autres modèles en identifiant le besoin; dans de tels cas, il est important que la classe soit située à la fin de la branche et qu’elle ne contienne pas de sous-classes (p. ex. E34_Inscription).

Note de traduction	Certains paragraphes ont été édités dans la version francophone aux fins de compréhension. Les sections concernées sont indiquées de [n.d.t. texte concerné].
Références

Monotonicity - De la monotonicité

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”.

La fonction primaire du CIDOC CRM est de soutenir l’intégration d’information sur la base de l’hypothèse du monde ouvert [n.d.t. selon laquelle la véracité d'une affirmation ne repose pas sur le fait qu’un agent ou un observateur sache qu’elle est vraie]. Cela implique que le CIDOC CRM lui-même doit être ouvert et que les bases de connaissances implémentées avec celui-ci doivent être suffisamment flexibles pour accueillir de nouvelles idées. Au niveau du modèle, cela implique que de nouvelles classes et/ou propriétés puissent être créées lors de l’intégration de nouveaux enregistrements documentaires ou lorsque [n.d.t. la nécessité de représenter] des éléments inédits est portée à l’attention des responsables du CIDOC CRM. Au niveau des bases de connaissances, la nécessité d’ajouter ou de réviser de l’information en raison de facteurs externes doit être prise en compte (de tels facteurs incluent, par exemple, l’avancement du milieu de la recherche qui soulève de nouvelles questions, la documentation de nouveaux phénomènes, ou encore l’évolution sociale ou naturelle qui révèle de nouveaux objets d’étude). Les responsables du CIDOC CRM ont pour objectif de respecter les tenants de l’hypothèse du monde ouvert, en particulier le principe de la monotonicité qui exige que l’ajout de nouvelles classes et/ou propriétés (au modèle) ou de nouveaux énoncés (à la base de connaissances) n’invalident pas les structures et énoncés préexistants [n.d.t. voir Raisonnement monotone dans la section Terminologie]. La première conséquence de ce choix est que le CIDOC CRM tente d’être monotone au sens de la théorie des domaines : les construits du CIDOC CRM et les déductions qui peuvent en découler doivent donc demeurer formellement et conceptuellement valides malgré l’ajout de construits issus d’extensions du CIDOC CRM, de sorte que toute extension doit être rétro-compatible avec les modèles qui la précèdent. La seule exception à cette règle serait une situation où un construit est considéré objectivement incorrect par les experts du domaine dont ce construit émane et qu’il soit en conséquence soumis à une révision corrective. L’adoption du principe de monotonicité a des conséquences notables sur la manière dont les classes et propriétés sont conceptualisées et déclarées dans le CIDOC CRM, car cela interdit la déclaration de classes complémentaires (c.-à-d. des classes définies uniquement par l’exclusion d’instances d’autres classes). Par exemple : FRBRoo (Bekiari & al (eds). 2015), qui extensionne le CIDOC CRM, a dans sa version 2.4 une classe F51_Activité_d’utilisation_de_nom déclarée sous-classe de E7_Activité. F51_Activité_d’utilisation_de_nom a pour fonction de décrire un phénomène bibliothéconomique spécifique qui n’est pas couvert par le CIDOC CRM, mais qui recense le fait qu’un E74_Groupe adopte et fasse l’usage d’un nom particulier dans le contexte d’un intervalle temporel. La création de cette extension est monotone dans la mesure où (1) aucune relation estUn ou règle d’héritage s’appliquant aux propriétés du CRMbase n’est compromise et où (2) la création de futures extensions n’est pas inhibée par cette création. Au contraire, si pour gérer cette situation une sous-classe « Autre Activité » avait été déclarée, un changement non monotone aurait été introduit dans le CRMbase, car la note d’application d’une telle classe complémentaire aurait proscrit la déclaration d’autres spécialisations de E7_Activité comme « Activité d’utilisation de nom ». Dans l’éventualité où il serait nécessaire de déclarer des sous-classes spécialisées, une révision non monotone devrait être effectuée, car il ne serait pas possible de déterminer quelles instances relèvent de la nouvelle classe spécialisée et lesquelles n’en relèvent pas (un changement et une révision qui sont extrêmement exigeants du point de vue des utilisateurs et qui compromettent sérieusement la rétro-compatibilité et l’intégration du système à long-terme). La seconde conséquence de ce choix [n.d.t.méthodologique d’adopter l’hypothèse du monde ouvert] est qu’il est nécessaire de maintenir la monotonicité même lors de la révision ou de l’ajout de données dans des systèmes compatibles avec le CIDOC CRM. En d’autres termes, les instances des classes du CIDOC CRM, leurs propriétés et les déductions qui en découlent doivent demeurer formellement et conceptuellement valides, et ce même lorsque de nouvelles instances considérées par les experts d’un domaine précis considèrent qu’elles s’insèrent de manière cohérente dans l’ensemble du système. Par exemple : Si quelqu’un indique correctement qu’un élément est une instance de E19_Objet_matériel et que ce même élément est subséquemment qualifié de E20_Objet_biologique, le système ne devrait pas cesser de traiter cet élément comme une instance de E19_Objet_matériel, car E20_Objet_biologique est une sous-classe de E19_Objet_matériel. Cet exemple démontre en outre que la hiérarchie estUn de classes et de propriétés peut rendre compte des étapes caractéristiques de précision des connaissances au sujet d’un élément tel qu’il se décline au fur et à mesure des processus d’investigation et de cueillette d’information et de contenus. Les classes de plus haut niveau peuvent ainsi être utilisées afin de classifier des objets dont les caractéristiques particulières ne sont pas initialement toutes connues ou recensées. Par exemple, un objet biologique dont la nature est incertaine peut d’abord être classifié comme E19_Objet_matériel, mais des investigations subséquentes peuvent établir qu’il s’agit en fait d’un E20_Objet_biologique. Une base de connaissances construite avec des classes CIDOC CRM conçues de manière à permettre une révision monotone rendra possible, dans un tel cas, une recherche des objets physiques qui [n.d.t. à un certain point de leur historique de documentation] n’étaient pas encore reconnus comme des objets biologiques. Cette capacité d’intégrer de l’information dont les niveaux de spécificité descriptive diffèrent est particulièrement importante dans le contexte d’une agrégation à large échelle. C’est aussi une pratique qui permet aux chercheurs d'intégrer dans un même système de l’information au sujet de divers phénomènes sans nécessiter une connaissance exhaustive ou minimale de l’objet [n.d.t. pour se concentrer sur celui-ci plutôt que sur l’acquisition de connaissances qui l’entourent]. Puisque l’intégration d’information à large échelle implique de facto des connaissances dont le niveau de précision varie, cette caractéristique est essentielle pour une intégration cohérente des données. La troisième conséquence de ce choix [n.d.t. d’une méthodologie monotone] est la nécessité d’une implémentation formelle illimitée (plusieurs à plusieurs) des propriétés recensant des enregistrements ou opinions alternatifs au sujet de phénomènes dans une base de connaissances, de telle sorte que des instances qui pourraient s’avérer conflictuelles s’accumulent [n.d.t. plutôt que d’établir des contradictions]. Ainsi, les bases de connaissances [n.d.t. où se retrouvent les informations et savoirs intégrés] peuvent être utilisées afin d’accumuler ou de recenser des opinions alternatives pertinentes au sujet d’un phénomène par l’utilisation d’entités sémantiques clairement définies alors que les constats experts ou conclusions sur ce même sujet [n.d.t. qui peuvent s’appuyer sur l’information trouvée dans ces bases de connaissances] relèvent de l’analyse scientifique ou experte. Par exemple : Les évènements rythmant la vie du Roi Arthur font l’objet de beaucoup de spéculations et de désaccords [n.d.t. qui doivent néanmoins être recensés dans les bases de connaissances traitant de lui]. Le CIDOC CRM préconise un recensement selon la formule suivante : Une fois recensé dans une base de connaissances, le Roi Arthur [n.d.t. en tant qu’individu] devrait être défini comme une instance de E21_Personne et traité comme une figure historique ayant « réellement » existé (au regard de la discipline qu’est l’histoire et des discours qui la construisent). Cette instance de E21_Personne devrait ainsi être utilisée afin de fédérer les possibles propriétés de l’existence de l’individu sachant que les opinions alternatives au sujet de ces propriétés (par exemple le lieu de naissance ou les endroits où il a résidé) devraient être recensés sans qu’un constat sur leur validité ne soit fait à l’étape de la compilation des données. Le recensement du Roi Arthur à titre de figure mythologique [n.d.t. plutôt que comme individu historique] requiert pour sa part une instance de E28_Objet_conceptuel qui permettra de recueillir les informations qui s’y rapportent. La quatrième conséquence de ce choix d’une méthodologie monotone [n.d.t. reposant sur l’hypothèse du monde ouvert] est la possibilité pour certaines propriétés de nature temporelle (telles que celles qui se rapportent au fait d’avoir des composantes, des propriétaires ou des localisations) de changer plusieurs fois en référence à un même élément au cours de son existence. Dans ce contexte, affirmer qu’une propriété est valide pour un élément implique qu’elle soit aussi valide pour un intervalle temporel particulier, mais indéterminé et situé dans le cours de l'existence de ce même élément. Il en résulte qu’un même élément puisse faire l’objet de nombreux énoncés affirmant l’instanciation d’une propriété sans que cela ne soit conflictuel ou ne nécessite de révision. La collecte de tels énoncés résulterait ainsi en une agrégation des instances de cette propriété en tant qu’elle s’applique à l’entièreté de l’existence de l’élément. Si des informations temporelles plus spécifiques sont nécessaires ou disponibles, il est recommandé de décrire explicitement les évènements qui sous-tendent l’application d’une propriété à un élément. Par exemple : Si un élément fait l’objet d’une acquisition ou d’une perte, une instance de E9_Déplacement devrait être liée et déclarée. Une telle approche permet de maintenir la monotonicité du CIDOC CRM malgré un accroissement des connaissances au sujet de l’état d’un élément à différents moments, et ce indépendamment de leur chronologie. Des propriétés temporellement neutres peuvent faire l’objet d’une spécialisation par des propriétés temporellement spécifiques dans le cadre d’extensions monotones futures, mais le contraire n’est pas possible. En outre, plusieurs propriétés du CIDOC CRM n’ont pas de composante temporelle ou sont déjà définies par rapport à des évènements précis [n.d.t. et celles-ci devraient être envisagées avant la création de nouvelles propriétés]. Le CIDOC CRM privilégie la modélisation de propriétés qui sont temporellement neutres et l’utilisation d’évènements pour représenter le changement. Toutefois, dans le cas de certaines de ces propriétés, de nombreuses bases de données indiqueront parfois un statut « actuel » relatif à une autre propriété (p. ex. « localisation actuelle » ou « propriétaire actuel »). L’utilisation d’un tel état « actuel » implique que le responsable de la base de données en question soit garant de l’information en date de la dernière date statuant la validité des contenus. Cette information, évidemment, est de nature non monotone (c.-à-d. qu’elle doit être supprimée lorsque l’état de l’élément change). Afin de préserver malgré cela une forme (réduite) de monotonicité, de telles propriétés s’inscrivent dans les super-propriétés temporellement neutres qui permettent de reclassifier leurs instances dans l’éventualité où la validité de cette information échoit ou devient inconnue. Ainsi, l’usage de telles propriétés dans le cadre du CIDOC CRM n’est recommandé que lorsque leur maintien régulier et rigoureux peut être assuré, sans quoi ces propriétés devraient être reclassifiées en faveur de leur super-propriétés temporellement neutres; cette pratique s’applique notamment lors de l’exportation de données vers des répertoires autres (voir De l’auctorialité des contenus d’une base de connaissances).

Note de traduction	Certains paragraphes ont été édités dans la version francophone aux fins de compréhension. Les sections concernées sont indiquées de [n.d.t. texte concerné].
Références	Wikipédia. « Monotonie ». Dans Wikipédia. San Francisco, US-CA: Wikipédia, 19 février 2017. https://fr.wikipedia.org/w/index.php?title=Monotonie&oldid=134697868.

Disjointness - De la disjonction

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.

Des classes qui ne peuvent pas partager d’instances à quelque moment que ce soit (par le passé, dans le présent ou dans le futur) sont qualifiées de disjointes. Un élément ne peut pas être instancié avec une combinaison de classes qui sont mutuellement disjointes ou qui sont des sous-classes de super-classes mutuellement disjointes (voir « Instanciation multiple » dans la section Terminologie). Il y a de nombreuses paires de classes disjointes dans le CIDOC CRM et une déclaration exhaustive de toutes les combinaisons possibles de celles-ci n’aurait qu’une utilité pratique limitée, en plus d’entrer en conflit avec l’objectif du CIDOC CRM d’offrir des définitions concises, de sorte qu’une telle liste n’est pas recensée ici. Deux exemples emblématiques de disjonction de classes sont néanmoins essentiels à une bonne compréhension du CIDOC CRM : E2_Entité_temporelle est disjoint de E77_Entité_persistante : les instances de la classe E2_Entité_temporelle sont perdurantes alors que les instances de E77_Entité_persistante sont endurantes. Même si les instances de E77_Entité_persistante ont une existence temporellement limitée, elles sont d’une nature fondamentalement différente des instances de E2_Entité_temporelle, car elles préservent leur identité d’un évènement à un autre. La disjonction de classes endurantes et perdurantes s’aligne à cet égard avec les distinctions structurelles des ensembles de données du domaine d’application du CIDOC CRM. E18_Chose_matérielle est disjoint de E28_Objet_conceptuel : les instances de la classe E18_Chose_matérielle sont de nature physique alors que les instances de la classe E28_Objet_conceptuel sont de nature immatérielle et sont exclusivement élaborées par l’humain. Elles diffèrent fondamentalement, notamment en raison du fait que la production d’instances de E18_Chose_matérielle implique des matériaux physiques alors que ce n’est pas le cas de la production d’instances de E28_Objet_conceptuel. De la même manière, les instances de E18_Chose_matérielle cessent d’exister lorsqu’elles sont détruites alors que les instances de E28_Objet_conceptuel s’éteignent lorsqu’elles sont oubliées ou que leur support physique est détruit.

Note de traduction
Références