CIDOC CRM Version 7.1.2
Date de création : 2023-11-08
Dernière mise à jour : 2023-12-22
|
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. |
Ce document constitue la définition du Modèle conceptuel de référence du Comité international pour la documentation du Conseil international des musées (« CIDOC CRM »), une ontologie formelle qui a pour objectif de faciliter l’intégration, la médiation et l’échange d’informations patrimoniales hétérogènes (ainsi que d'information comparable issue d'autres domaines pertinents détaillés plus bas). Le CIDOC CRM est le résultat du développement de standards par le Comité pour la documentation (CIDOC) du Conseil international des musées (ICOM), un travail qui a commencé en 1996 sous les auspices du Groupe de travail pour les standards en documentation. En 2000, ICOM-CIDOC a officiellement délégué les tâches de développement du CIDOC CRM au Groupe de travail spécial pour CIDOC CRM (CRM SIG), lequel travaille en collaboration avec le Groupe de travail ISO/TC46/SC4/WG9 afin de veiller à ce que le CIDOC CRM respecte les normes internationales en matière de standards. Ces collaborations ont mené à la publication des documents ISO21127:2004 et ISO21127:2014, les normes ISO (Organisation internationale de normalisation) du CIDOC CRM qui continueront d'être mises à jour. Ce document s'inscrit dans une série de versions évolutives de la définition formelle du CIDOC CRM qui servent de fondements au groupe de travail ISO. Des différences mineures de sémantique et de notation entre les formes ISO et communautaire de cette définition formelle seront harmonisées dans ses versions futures. |
Note de traduction |
L’abréviation la plus utilisée dans le monde francophone pour le modèle demeure son acronyme anglophone (CIDOC CRM) et c’est celle qui est utilisée dans ce document. Les titres francophones des groupes de travail sont tirés des appellations trouvées sur le site francophone de CIDOC. |
|---|---|
Références |
Comité International pour la Documentation de l’ICOM. 2021. « CIDOC ». ICOM CIDOC. 24 février 2021. http://cidoc.mini.icom.museum/fr/. |
Objectives of the CIDOC CRM - Objectifs du CIDOC CRM
|
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:
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. |
CIDOC CRM a pour principale fonction de favoriser l’échange d’informations et leur intégration parmi des sources hétérogènes d’informations dédiées à la reconstruction et l'interprétation du passé à échelle humaine sur la base de preuves matérielles incluant des textes, du matériel audio-visuel et des traditions orales. Il émane des besoins de documentation et de recherche des musées sur les objets de leurs collections sans pour autant s'y limiter. Il fournit les définitions sémantiques et clarifications nécessaires à la transformation d’informations localisées et disparates grâce à une ressource globale et cohérente [n.d.t. prenant la forme d’une norme de documentation], que ce soit au sein d’une institution de plus grande envergure, d’intranets ou sur Internet pour les rendre utilisables à des fins d'interprétation experte et d'évaluation scientifique. Ces objectifs déterminent le niveau de détail et les construits du CIDOC CRM. Plus spécifiquement, ce modèle définit par une ontologie formelle la sémantique qui sous-tend les schèmes de base de données et les documents structurés utilisés dans le cadre de la documentation en milieu patrimonial ou scientifique. Il définit particulièrement la sémantique portant sur l'étude du passé et sur l'état actuel du monde, une approche caractéristique des musées et d'autres institutions et disciplines culturelles. Le CIDOC CRM ne définit pas la terminologie qui se trouve typiquement dans les structures de données sous forme de valeurs, bien qu’il entrevoie les relations caractéristiques nécessaires à son usage [n.d.t. de sorte que le CIDOC CRM précise comment utiliser une classe, mais pas les valeurs qu’elle comprend lorsqu’elle est implémentée]. Il n’a pas pour objectif d’indiquer ce que les institutions culturelles patrimoniales devraient documenter, mais bien d’expliquer la logique de ce qu’elles documentent afin de favoriser l’interopérabilité sémantique. Le CIDOC CRM propose un modèle des structures intellectuelles de la documentation susmentionnée en termes logiques et n’est donc pas optimisé pour une implémentation spécifique, en particulier en ce qui a trait au stockage et au traitement des données. L’implémentation peut en outre mener à ce que certains éléments des conceptualisations du CIDOC CRM ne soient plus explicites dans le contexte d'une base de données ou d'un système de stockage structuré. Par exemple, un évènement de naissance reliant des éléments tels que le père, la mère, la date et le lieu de naissance peut ne pas être apparent dans une base de données afin de préserver l’espace de stockage et le temps de réponse d’un système. Le CIDOC CRM offre les moyens conceptuels et techniques pour expliquer en quoi ces entités à première vue disparates sont sémantiquement et logiquement interconnectées et comment la capacité d’une base de données à fournir des réponses à des questions de nature intellectuelle est limitée par l’omission de tels liens et éléments. Le CIDOC CRM a pour objectif de soutenir les fonctionnalités spécifiques suivantes :
Les utilisateurs du CIDOC CRM auront besoin de l’intégration d’une terminologie particulière à leur domaine ainsi que de l’apport de leur communauté de pratique dans la sélection de ce qui doit être documenté, de la séquence dans laquelle ce doit être documenté ainsi que dans l’application de protocoles de contrôle et de validation. Le CIDOC CRM ne documente pas ces aspects. Par sa structure et son formalisme, le CIDOC CRM est extensible et ses utilisateurs sont encouragés à créer des extensions dédiées à des communautés de pratique et des applications spécialisées. |
Note de traduction |
Le terme « construct » n’a pas d’équivalent français parfait, mais une recherche sommaire révèle que le terme « construit » (n.m.) semble répandu dans les domaines de la philosophie et de la sociologie et est celui dont le sens se rapproche le plus de la forme originale. Le terme « use » (« foresees use of ») a été traduit par « usage » en adéquation avec la traduction de |
|---|---|
Références |
Termium. « construct ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=construct&index=ent&codom2nd_wet=1#resultrecs. |
Scope of the CIDOC CRM - Portée du CIDOC CRM
|
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 these distinctions between Intended and Practical Scope are twofold. Firstly, the CIDOC CRM is developed in a “bottom-up” manner, starting from well-understood, actual, 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 Practical Scope2 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. 1 The ICOM Statutes provide a definition of the term “museum” at http://icom.museum/statutes.html#2 2 The Practical Scope of the CIDOC CRM, including a list of the relevant museum documentation standards, is discussed in more detail on the CIDOC CRM website at http://cidoc.ics.forth.gr/scope.html |
Le domaine d’application global du CIDOC CRM peut être résumé, en termes simples, aux connaissances factuelles au sujet du passé à échelle humaine [n.d.t. c.-à-d. les informations recensées dans les bases de données d’institutions patrimoniales]. Cependant, une définition plus détaillée et utile peut être articulée en définissant à la fois :
La distinction entre les domaines d'application prévu et pratique est attribuable à deux éléments. En premier lieu, le CIDOC CRM est développé avec une approche ascendante (« bottom up ») fondée sur des concepts établis, réels et bien compris des expert·e·s, lesquels sont ensuite désambiguïsés et généralisés de manière graduelle au fur et à mesure que de nouvelles formes d'encodage émergent. Cette distinction confère à ces concepts une certaine stabilité et a pour objectif d'éviter le flou et les erreurs qui peuvent s'immiscer avec des approches plus introspectives visant à trouver des concepts englobant un domaine aussi large. En second lieu, cette distinction permet de désigner les concepts essentiels aux communautés du domaine du CIDOC CRM, d'y accorder une attention particulière et soutenue, et de planifier leur évolution de manière ordonnée. Le Domaine d’application prévu du CIDOC CRM peut être défini comme l’ensemble des informations nécessaires à l'échange et à l'intégration de la documentation hétérogène scientifique et experte au sujet du passé à l'échelle humaine ainsi que des preuves empiriques et documentées disponibles la soutenant. Cette définition requiert une élaboration plus approfondie :
Le Domaine d’application pratique2 du CIDOC CRM est exprimé en termes d'ensembles de normes de références et d'usage pour documenter les connaissances factuelles qui ont été utilisées pour guider et valider le développement du CIDOC CRM ainsi que son évolution. Le CIDOC CRM couvre le même domaine de discours que l'union de ces référentiels; cela signifie que pour les données correctement encodées conformément à ces formats de documentation, il peut y avoir une expression CIDOC CRM compatible qui transmet la même signification. Dans le cadre du travail continu visant à maintenir la norme à jour, des discussions sur les types de biais présents dans le CIDOC CRM sont en cours au sein de la communauté CIDOC CRM. 1 Les statuts de l'ICOM fournissent une définition du terme « musée » à l'adresse http://icom.museum/statutes.html#2(page non accessible). 2 Le Domaine d'application pratique du CIDOC CRM, y compris une liste des normes de documentation muséales pertinentes, est discuté plus en détail sur le site Web du CIDOC CRM à l'adresse http://cidoc.ics.forth.gr/scope.html(page non accessible). |
Note de traduction |
|
|---|---|
Références |
|
Compatibility with the CIDOC CRM - Compatibilité avec le CIDOC CRM
|
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. |
Les utilisateurs voulant tirer avantage de l’interopérabilité sémantique du CIDOC CRM devraient s’assurer de la conformité de leurs structures de données avec celui-ci. La conformité des données réfère à leur accessibilité dans le contexte d’un environnement [n.d.t. d’utilisateur] intégré ou de leur transfert vers d’autres environnements. Tout encodage de données dans un langage formel qui maintient les relations des classes, des propriétés, ainsi que des règles d’héritage définies par le CIDOC CRM est considéré y être conforme. Cela dit, cette conformité ne requiert pas une équivalence complète de toutes les structures de documentation locales, ni que tous les concepts et structures du CIDOC CRM ne soient implémentés. Ce standard international a pour objectif de permettre la mise en place d’extensions nécessaires pour saisir la richesse des phénomènes culturels et de leur documentation, et ce, tout en prônant la parcimonie. Un système est considéré partiellement conforme s’il soutient un sous-ensemble des sous-classes et sous-propriétés définies par ce standard. Les concepteurs de systèmes devraient publier le détail des construits qui sont supportés par leur système. Le CIDOC CRM porte principalement sur l’échange et la médiation d’information structurée et n’exige pas l’interprétation d’information non structurée dans une forme logique. L’information non structurée peut être traitée par le CIDOC CRM, mais les résultats qui en découlent ne sont pas pris en compte dans l’évaluation de la conformité d’un système. Tout système documentaire sera considéré conforme [n.d.t. avec les règles du CIDOC CRM], peu importe les structures de données internes qu’il utilise, si des algorithmes peuvent transformer les données non structurées du système en une forme compatible avec le CIDOC CRM sans que la signification n’en soit affectée. « Sans que la signification n’en soit affectée » signifie que les concepteurs et les utilisateurs du système considèrent que la représentation résultant de l’utilisation de cet algorithme correspond aux définitions sémantiques fournies dans ce standard. |
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 « construct » n’a pas d’équivalent français parfait, mais une recherche sommaire révèle que le terme « construit » (n.m.) semble répandu dans les domaines de la philosophie et de la sociologie et est celui dont le sens se rapproche le plus de la forme originale. |
|---|---|
Références |
Termium. « construct ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=construct&index=ent&codom2nd_wet=1#resultrecs. |
Terminology - Terminologie
|
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. 3 Information about the Resource Description Framework (RDF) can be found at http://www.w3.org/RDF/ |
Les définitions suivantes ont pour objectif d’aider le lecteur qui ne serait pas familier avec la terminologie de la modélisation orientée-objet ainsi que de préciser l’usage de termes qui ne sont parfois pas utilisés de manière uniforme par cette communauté de modélisation. Les éditeurs ont tenté d’utiliser une terminologie compatible avec les recommandations du World Wide Web Consortium quant au Resource Description Framework (RDF)3. Les éditeurs ont utilisé un langage compréhensible pour le lecteur qui ne serait pas un expert informatique tout en préconisant une précision suffisante pour servir les besoins d’un tel expert de manière à ce que l’un comme l’autre comprenne le sens du CIDOC CRM. 3 Plus d'informations au sujet du Resource Description Framework (RDF) sont disponibles au http://www.w3.org/RDF/. |
Note de traduction |
Une recherche sommaire de la documentation technique traduite sur le site du World Wide Web Consortium ne révèle pas de traduction francophone de « Resource Description Framework (RDF) », de sorte que l’appellation anglophone est préconisée dans la présente traduction. |
|---|---|
Références |
Berners-Lee, Tim, Tim Bray, Dan Connolly, Paul Cotton, Roy Fielding, Mario Jeckle, Chris Lilley, et al. « Architecture du World Wide Web: Volume Un ». Recommandation. 2005. Réimpression, Cambridge, USA-MA: World Wide Web Consortium (W3C), 2006. http://www.opikanoba.org/tr/w3c/webarch/. Berrueta, Diego, et Jon Phipps. « Méthodes exemplaires pour la publication des vocabulaires RDF ». Meilleures pratiques. Cambridge, USA-MA: World Wide Web Consortium (W3C), 28 août 2008. http://www.yoyodesign.org/doc/w3c/swbp-vocab-pub/. World Wide Web Consortium (W3C). « Translations of W3C Technical Reports ». World Wide Web Consortium (W3C), 8 mars 2021. https://www.w3.org/Translations/. |
|
class
|
A class is a category of items that share one or more common traits serving as criteria to identify the items belonging to the class. These properties need not be explicitly formulated in logical terms, but may be described in a text (here called a scope note) that refers to a common conceptualisation of domain experts. The sum of these traits is called the intension of the class. A class may be the domain or range of none, one or more properties formally defined in a model. The formally defined properties need not be part of the intension of their domains or ranges: such properties are optional. An item that belongs to a class is called an instance of this class. A class is associated with an open set of real-life instances, known as the extension of the class. Here “open” is used in the sense that it is generally beyond our capabilities to know all instances of a class in the world and indeed that the future may bring new instances about at any time (Open World). Therefore, a class cannot be defined by enumerating its instances. A class plays a role analogous to a grammatical noun, and can be completely defined without reference to any other construct (unlike properties, which must have an unambiguously defined domain and range). In some contexts, the terms individual class, entity or node are used synonymously with class. For example: Person is a class. To be a Person may actually be determined by DNA characteristics, but we all know what a Person is. A Person may have the property of being a member of a Group, but it is not necessary to be member of a Group in order to be a Person. We shall never know all Persons of the past. There will be more Persons in the future. |
Classe |
Une classe est une catégorie d'éléments qui partagent un ou plusieurs traits communs servant de critères pour désigner les éléments appartenant à cette classe. Ces traits communs n'ont pas besoin d'être explicitement formulés en termes logiques (appelés ici propriétés), mais peuvent être décrits dans un texte faisant référence à une conceptualisation commune des experts du domaine (texte appelé ici note d'application). La somme de ces traits s'appelle l'intension de la classe. Une classe peut être le domaine ou la portée d’aucune, d’une ou de plusieurs propriétés formellement définies dans un modèle. Les propriétés formellement définies n'ont pas besoin de faire partie de l'intension de leurs domaines ou portées : ces propriétés sont facultatives. Un élément qui appartient à une classe est appelé une instance de cette classe. Une classe est associée à un ensemble ouvert d'instances réelles (l'extension de la classe), ce qui veut dire qu’une capacité humaine normale ne permet pas de connaître toutes les instances d’une classe existant dans le « monde » à un moment donné, ni de prendre en compte les instances qui pourraient émerger dans le futur (voir Monde Ouvert). Par conséquent, une classe ne peut pas être définie en énumérant ses instances. Une classe joue un rôle analogue à un nom grammatical [n.d.t. dans le contexte d’une langue SVO, c.-à-d. une langue comme le français dont les phrases suivent généralement l’ordre sujet-verbe-objet] et peut être complètement définie sans référence à aucun autre construit (contrairement aux propriétés, qui doivent avoir un domaine et une portée définis sans ambiguïté). Dans certains contextes, les termes classe individuelle, entité ou nœud sont utilisés comme synonymes de classe. Par exemple :
|
Note de traduction |
|||
|---|---|---|---|
Références |
Wikipédia. « Langue SVO ». Dans Wikipédia. San Francisco, US-CA: Wikipédia, 31 octobre 2020. https://fr.wikipedia.org/w/index.php?title=Langue_SVO&oldid=176099662. |
||
|
subclass
|
A subclass is a class that is a specialization of another class (its superclass). Specialization or the IsA relationship means that:
A subclass can have more than one immediate superclass and consequently inherits the properties of all of its superclasses (multiple inheritance). The IsA relationship or specialization between two or more classes gives rise to a structure known as a class hierarchy. The IsA relationship is transitive and may not be cyclic. In some contexts (e.g., the programming language C++) the term derived class is used synonymously with subclass. For example: Every Person IsA Biological Object, or Person is a subclass of Biological Object. Also, every Person IsA Actor. A Person may die. However, other kinds of Actors, such as companies, don’t die (c.f. 2). Every Biological Object IsA Physical Object. A Physical Object can be moved. Hence, a Person can be moved also (c.f. 3). |
Sous-classe |
Une sous-classe est une classe qui est une spécialisation d'une autre classe (sa super-classe). La spécialisation ou la relation
Une sous-classe peut relever directement de plus d'une super-classe et hériter par conséquent des propriétés de toutes ses super-classes (héritage multiple). La relation Par exemple : Chaque De plus, chaque Chaque |
Note de traduction |
|||
Références |
|
||
|
superclass
|
A superclass is a class that is a generalization of one or more other classes (its subclasses), which means that it subsumes all instances of its subclasses, and that it can also have additional instances that do not belong to any of its subclasses. The intension of the superclass is less restrictive than any of its subclasses. This subsumption relationship or generalization is the inverse of the IsA relationship or specialization. For example: “Biological Object subsumes Person” is synonymous with “Biological Object is a superclass of Person”. It needs fewer traits to identify an item as a Biological Object than to identify it as a Person. |
Super-classe |
Une super-classe est une classe qui est une généralisation d'une ou de plusieurs autres classes (ses sous-classes), ce qui signifie qu'elle englobe toutes les instances de ses sous-classes et qu'elle peut également avoir des instances supplémentaires qui n'appartiennent à aucune de ses sous-classes. L'intension de la super-classe est moins restrictive que n'importe laquelle de ses sous-classes. Cette relation de subsomption ou de généralisation est l’inverse de la relation ou de la spécialisation Par exemple : « |
Note de traduction |
|||
Références |
|
||
|
intension
|
The intension of a class or property is its intended meaning. It consists of one or more common traits shared by all instances of the class or property. These traits need not be explicitly formulated in logical terms, but may just be described in a text (here called a scope note) that refers to a conceptualisation common to domain experts. In particular, the so-called primitive concepts, which make up most of the CIDOC CRM, cannot be further reduced to other concepts by logical terms. |
Intension |
L'intension d'une classe ou d'une propriété est sa signification prévue. Elle est composée d'un ou de plusieurs traits communs partagés par toutes les instances de la classe ou de la propriété. Ces traits n'ont pas besoin d'être explicitement formulés en termes logiques, mais peuvent simplement être décrits dans un texte (appelé ici note d'application) qui réfère à une conceptualisation commune aux experts du domaine. En particulier, les concepts dits primitifs, qui constituent l'essentiel du CIDOC CRM, ne peuvent être davantage réduits à d'autres concepts par des termes logiques. |
Note de traduction |
|||
Références |
|
||
|
extension
|
The extension of a class is the set of all real-life instances belonging to the class that fulfil the criteria of its intension. This set is “open” in the sense that it is generally beyond our capabilities to know all instances of a class in the world and indeed that the future may bring new instances about at any time (Open World). An information system may at any point in time refer to some instances of a class, which form a subset of its extension. |
Extension |
L'extension d'une classe est l'ensemble de toutes les instances « réelles » appartenant à la classe [n.d.t. du fait qu’elles] remplissent les critères de son intension. Cet ensemble est « ouvert », ce qui veut dire qu’une capacité humaine normale ne permet pas de connaître toutes les instances d’une classe existant dans le « monde » à un moment donné, ni de prendre en compte les instances qui pourraient émerger dans le futur (voir Monde Ouvert). Un système d'information peut à n’importe quel moment faire référence à certaines instances d'une classe, lesquelles forment un sous-ensemble de son extension. |
Note de traduction |
|||
Références |
|
||
|
scope note
|
A scope note is a textual description of the intension of a class or property. Scope notes are not formal modelling constructs, but are provided to help explain the intended meaning and application of the CIDOC CRM’s classes and properties. Basically, they refer to a conceptualisation common to domain experts and disambiguate between different possible interpretations. Illustrative example instances of classes and properties are also regularly provided in the scope notes for explanatory purposes. |
Note d’application |
Une note d'application est une description textuelle de l'intension d'une classe ou d'une propriété. Les notes d’application ne sont pas des construits de modélisation formels, elles sont plutôt fournies pour expliquer la signification et l’application prévues des classes et des propriétés du CIDOC CRM. Fondamentalement, elles renvoient à une conceptualisation commune aux experts du domaine [n.d.t. qu’elles concernent] et clarifient les différentes interprétations possibles. Des exemples d’instances de classes et de propriétés sont régulièrement fournis dans les notes d'application à des fins d'explication. |
Note de traduction |
|||
Références |
|
||
|
instance
|
An instance of a class is a real-world item that fulfils the criteria of the intension of the class. Note, that the number of instances declared for a class in an information system is typically less than the total in the real world. For example, you are an instance of Person, but you are not mentioned in all information systems describing Persons. For example: The painting known as the “The Mona Lisa” is an instance of the class E22 Human-Made Object. An instance of a property is a factual relation between an instance of the domain and an instance of the range of the property that matches the criteria of the intension of the property. For example: The Mona Lisa has former or current owner. The Louvre is an instance of the property P51 has former or current owner (is former or current owner of). |
Instance |
L’instance d’une classe est un élément du monde réel [n.d.t. voir De la réalité, des bases de connaissance et du CIDOC CRM] qui correspond à l’intension d’une classe [n.d.t. telle qu’elle est exprimée dans sa note d’application]. Le nombre d’instances déclarées pour une classe dans un système d’information est typiquement moins que la totalité [n.d.t. qui existe] dans le monde réel. Par exemple, un individu est une instance de Par exemple : La peinture connue sous le nom de « Mona Lisa » est une instance de la classe L’instance d’une propriété est une relation factuelle entre une instance de son domaine et une instance de sa portée, relation qui correspond à l’intension de cette propriété [n.d.t. telle qu’elle est exprimée dans sa note d’application]. Par exemple : [n.d.t. Dans l’affirmation] « La Mona Lisa a pour propriétaire actuel ou antérieur le Louvre » « a pour propriétaire actuel ou antérieur » est une instance de la propriété |
Note de traduction |
|||
Références |
|
||
|
property
|
A property serves to define a relationship of a specific kind between two classes. The property is characterized by an intension, which is conveyed by a scope note. A property plays a role analogous to a grammatical verb, in that it must be defined with reference to both its domain and range, which are analogous to the subject and object in grammar (unlike classes, which can be defined independently). It is arbitrary, which class is selected as the domain, just as the choice between active and passive voice in grammar is arbitrary. In other words, a property can be interpreted in both directions, with two distinct, but related interpretations. Properties may themselves have properties that relate to other classes (This feature is used in this model only in order to describe dynamic subtyping of properties). Properties can also be specialized in the same manner as classes, resulting in IsA relationships between subproperties and their superproperties. In some contexts, the terms attribute, reference, link, role or slot are used synonymously with property. For example: “Physical Human-Made Thing depicts CRM Entity” is equivalent to “CRM Entity is depicted by Physical Human-Made Thing”. |
Propriété |
Une propriété définit une relation spécifique entre deux classes et est caractérisée par son intension (laquelle est exprimée par la note d’application de la propriété). Une propriété est l’équivalent grammatical d’un verbe dans la mesure où elle est définie par son renvoi à son domaine et à sa portée, lesquels sont comparables au sujet et à l’objet d’une phrase [n.d.t. dans le contexte d’une langue SVO, c.-à-d. une langue comme le français dont les phrases suivent généralement l’ordre sujet-verbe-objet], et ce contrairement aux classes qui peuvent être définies de manière indépendante. De même que le choix qu’une forme grammaticale active ou passive est arbitraire, le choix de la classe sélectionnée pour le domaine et pour la portée l’est aussi. En d’autres termes, l’interprétation d’une propriété serait distincte selon le sens dans lequel elle est lue [n.d.t. c.-à-d. depuis le domaine vers la portée ou depuis la portée vers le domaine]. Certaines propriétés s’appliquent sur d’autres propriétés [n.d.t. et peuvent donc avoir comme portée des instances] d’autres classes, une fonctionnalité qui est mobilisée par le CIDOC CRM afin de décrire le sous-typage dynamique de propriétés [n.d.t. voir Des types; ces propriétés sont signalées par l’usage d’un Les propriétés peuvent aussi être spécialisées (comme c’est le cas des classes) par des relations Dans certains contextes, les termes attribut, référence, lien, rôle ou créneau peuvent être synonymes de propriété. Par exemple :
|
Note de traduction |
|||
Références |
Wikipédia. « Langue SVO ». Dans Wikipédia. San Francisco, US-CA: Wikipédia, 31 octobre 2020. https://fr.wikipedia.org/w/index.php?title=Langue_SVO&oldid=176099662. |
||
|
inverse of
|
The inverse of a property is the reinterpretation of a property from range to domain without more general or more specific meaning, similar to the choice between active and passive voice in some languages. In contrast to some knowledge representation languages, such as RDF and OWL, we regard that the inverse of a property is not a property in its own right that needs an explicit declaration of being inverse of another, but an interpretation implicitly existing for any property. The inverse of the inverse of a property is identical to the property itself, i.e., its primary sense of direction. For example: “CRM Entity is depicted by Physical Human-Made Thing” is the inverse of “Physical Human-Made Thing depicts CRM Entity” |
Inverse de |
L’inverse d’une propriété est la réinterprétation de cette propriété depuis sa portée vers son domaine sans généralisation ou spécialisation de sa signification supplémentaire. De même que le choix d’une forme grammaticale active ou passive est arbitraire [n.d.t. le choix de la classe sélectionnée pour le domaine et pour la portée l’est aussi]. Contrairement à certains langages de représentation tels que RDF et OWL, le CIDOC CRM considère que l’inverse d’une propriété n’est pas une propriété en soi qui nécessiterait la déclaration explicite du fait qu’elle en inverse une autre; il s’agit plutôt d’une interprétation implicite à chaque propriété. L’inverse de l’inverse d’une propriété est identique à la propriété elle-même, à savoir identique à sa direction primaire. Par exemple :
|
Note de traduction |
|||
Références |
|
||
|
subproperty
|
A subproperty is a property that is a specialization of another property (its superproperty). Specialization or IsA relationship means that:
A subproperty can have more than one immediate superproperty and consequently inherits the properties of all of its superproperties (multiple inheritance). The IsA relationship or specialization between two or more properties gives rise to the structure we call a property hierarchy. The IsA relationship is transitive and may not be cyclic. Some object-oriented programming languages, such as C++, do not contain constructs that allow for the expression of the specialization of properties as sub-properties. Alternatively, a property may be subproperty of the inverse of another property, i.e., reading the property from range to domain. In that case:
|
Sous-propriété |
Une sous-propriété est une propriété spécialisant une autre propriété (sa super-propriété); une spécialisation (ou relation
Une sous-propriété peut relever directement de plus d’une super-propriété et ainsi hériter les propriétés de toutes ces super-propriétés (héritage multiple). La relation Une propriété peut aussi être une sous-propriété de l’inverse d’une autre propriété [n.d.t. (la propriété initiale non inversée)], c.-à-d. que lire la propriété depuis la portée vers le domaine implique que :
[n.d.t. voir Déclaration des propriétés du CIDOC CRM]. |
Note de traduction |
Le terme « construct » n’a pas d’équivalent français parfait, mais une recherche sommaire révèle que le terme « construit » (n.m.) semble répandu dans les domaines de la philosophie et de la sociologie et est celui dont le sens se rapproche le plus de la forme originale. |
||
Références |
Termium. « construct ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=construct&index=ent&codom2nd_wet=1#resultrecs. |
||
|
superproperty
|
A superproperty is a property that is a generalization of one or more other properties (its subproperties), which means that it subsumes all instances of its subproperties, and that it can also have additional instances that do not belong to any of its subproperties. The intension of the superproperty is less restrictive than any of its subproperties. The subsumption relationship or generalization is the inverse of the IsA relationship or specialization. A superproperty may be a generalization of the inverse of another property. |
Super-propriété |
Une super-propriété est une propriété qui est une généralisation de l’une ou plusieurs autres propriétés (ses sous-propriétés) : elle subsume toutes les instances de toutes ses sous-propriétés et peut de surcroît avoir des instances qui ne relèvent d'aucune de ces sous-propriétés. L’intension d’une super-propriété est moins restrictive que celle de n’importe laquelle de ses sous-propriétés. La relation de subsomption (généralisation) est l’inverse d’une relation [n.d.t. voir Déclaration des propriétés du CIDOC CRM]. |
Note de traduction |
|||
Références |
|
||
|
domain
|
The domain is the class for which a property is formally defined. This means that instances of the property are applicable to instances of its domain class. A property must have exactly one domain, although the domain class may always contain instances for which the property is not instantiated. The domain class is analogous to the grammatical subject of the phrase for which the property is analogous to the verb. It is arbitrary which class is selected as the domain and which as the range, just as the choice between active and passive voice in grammar is arbitrary. Property names in the CIDOC CRM are designed to be semantically meaningful and grammatically correct when read from domain to range. In addition, the inverse property name, normally given in parentheses, is also designed to be semantically meaningful and grammatically correct when read from range to domain. |
Domaine |
Le domaine est la classe pour laquelle une propriété est formellement définie, de sorte que les instances d’une propriété ne peuvent s’appliquer qu’aux instances de sa classe de domaine. Une propriété doit avoir exactement un domaine, bien que la classe de domaine puisse contenir des instances pour lesquelles la propriété n’est pas instanciée. La classe de domaine est l’équivalent du sujet grammatical d’une phrase dont la propriété serait le verbe [n.d.t. dans le contexte d’une langue SVO, c.-à-d. une langue comme le français dont les phrases suivent généralement l’ordre sujet-verbe-objet]. Le choix de la classe sélectionnée pour le domaine et pour la portée est aussi arbitraire que celui d’une forme grammaticale active ou passive. Les propriétés du CIDOC CRM sont ainsi nommées de manière à être grammaticalement correctes [n.d.t. en anglais] lors d’une lecture depuis le domaine vers la portée [n.d.t. dans le cadre de cette traduction, les propriétés sont grammaticalement correctes, mais toujours accordées au féminin dans le cadre de la phrase où elles sont citées puisqu’il est fait référence à la propriété elle-même (terme féminin) plutôt qu’à sa dénomination, le sujet grammatical des propriétés est pour sa part masculin]. De plus, les propriétés inverses, dont le nom se trouve normalement entre parenthèses, sont elles aussi nommées de manière à être grammaticalement correctes [n.d.t. en anglais] lors d’une lecture depuis la portée vers le domaine. |
Note de traduction |
|||
Références |
Wikipédia. « Langue SVO ». Dans Wikipédia. San Francisco, US-CA: Wikipédia, 31 octobre 2020. https://fr.wikipedia.org/w/index.php?title=Langue_SVO&oldid=176099662. |
||
|
range
|
The range is the class that comprises all potential values of a property. That means that instances of the property can link only to instances of its range class. A property must have exactly one range, although the range class may always contain instances that are not the value of the property. The range class is analogous to the grammatical object of a phrase for which the property is analogous to the verb. It is arbitrary which class is selected as domain and which as range, just as the choice between active and passive voice in grammar is arbitrary. Property names in the CIDOC CRM are designed to be semantically meaningful and grammatically correct when read from domain to range. In addition, the inverse property name, normally given in parentheses, is also designed to be semantically meaningful and grammatically correct when read from range to domain. |
Portée |
La portée est la classe qui englobe toutes les valeurs potentielles d’une propriété, de sorte que les instances d’une propriété peuvent se lier uniquement aux instances de sa classe de portée. Une propriété doit avoir exactement une portée, bien que la classe de portée puisse contenir des instances qui ne sont pas des valeurs de la propriété. La classe de portée est l’équivalent de l’objet grammatical d’une phrase dont la propriété serait le verbe [n.d.t. dans le contexte d’une langue SVO, c.-à-d. une langue comme le français dont les phrases suivent généralement l’ordre sujet-verbe-objet]. Le choix de la classe sélectionnée pour le domaine et pour la portée est aussi arbitraire que celui d’une forme grammaticale active ou passive. Les propriétés du CIDOC CRM sont ainsi nommées de manière à être grammaticalement correctes [n.d.t. en anglais] lors d’une lecture depuis le domaine vers la portée [n.d.t. dans le cadre de cette traduction, les propriétés sont grammaticalement correctes, mais toujours accordées au féminin dans le cadre de la phrase où elles sont citées, le sujet grammatical des propriétés est pour sa part masculin]. De plus, les propriétés inverses, dont le nom se trouve normalement entre parenthèses, sont elles aussi nommées de manière à être grammaticalement correcte [n.d.t. en anglais] lors d’une lecture depuis la portée vers le domaine. |
Note de traduction |
|||
Références |
Wikipédia. « Langue SVO ». Dans Wikipédia. San Francisco, US-CA: Wikipédia, 31 octobre 2020. https://fr.wikipedia.org/w/index.php?title=Langue_SVO&oldid=176099662. |
||
|
inheritance
|
Inheritance of properties from superclasses to subclasses means that if an item x is an instance of a class A, then:
|
Héritage |
L’héritage des propriétés de super-classes vers leurs sous-classes implique que pour tout élément
[n.d.t. voir De l’héritage et de la transitivité dans la section Principes de modélisation]. |
Note de traduction |
|||
Références |
|
||
|
strict inheritance |
Strict inheritance means that there are no exceptions to the inheritance of properties from superclasses to subclasses. For instance, some systems may declare that elephants are grey, and regard a white elephant as an exception. Under strict inheritance it would hold that: if all elephants were grey, then a white elephant could not be an elephant. Obviously not all elephants are grey. To be grey is not part of the intension of the concept elephant but an optional property. The CIDOC CRM applies strict inheritance as a normalization principle. |
Héritage strict |
L’héritage strict désigne le fait qu’il n’y a pas d’exception à l’héritage de propriétés depuis des super-classes vers leurs sous-classes. Par exemple, un système [n.d.t. d’information] peut déclarer que les éléphants sont gris et considérer qu’un éléphant blanc est une exception [n.d.t. à la classe éléphant]. Des règles d’héritage strict imposeraient que si tous les éléphants sont gris, un éléphant blanc ne peut être un éléphant. Évidemment, tous les éléphants ne sont pas gris et le fait d’être gris ne fait pas partie de l’intension du concept « éléphant » (il s’agit plutôt d’une propriété optionnelle). Le CIDOC CRM applique des règles d’héritage strict aux fins de normalisation. |
Note de traduction |
Le terme « normalization » aurait aussi pu être traduit par « standardisation”, mais puisqu’il s’agit du principe et non pas de l’application d’un standard établi, le terme « normalisation » a été utilisé. |
||
Références |
Termium. « normalization ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=normalization&index=alt&codom2nd_wet=1#resultrecs. |
||
|
multiple inheritance
|
Multiple inheritance means that a class A may have more than one immediate superclass. The extension of a class with multiple immediate superclasses is a subset of the intersection of all extensions of its superclasses. The intension of a class with multiple immediate superclasses extends the intensions of all its superclasses, i.e., its traits are more restrictive than any of its superclasses. If multiple inheritance is used, the resulting “class hierarchy” is a directed graph and not a tree structure. If it is represented as an indented list, there are necessarily repetitions of the same class at different positions in the list. For example: Person is both an Actor and a Biological Object. |
Héritage multiple |
L’héritage multiple désigne le fait qu’une instance d’une classe |
Note de traduction |
|||
Références |
Termium. « directed graph ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=directed+graph&index=alt&codom2nd_wet=1#resultrecs. |
||
|
multiple instantiation
|
Multiple Instantiation is the term that describes the case that an instance of class A is also regarded as an instance of one or more other classes B1...n at the same time. When multiple instantiation is used, it has the effect that the properties of all these classes become available to describe this instance. For instance, some particular cases of destruction may also be activities (e.g., Herostratos’ deed), but not all destructions are activities (e.g., destruction of Herculaneum). In comparison, multiple inheritance describes the case that all instances of a class A are implicitly instances of all superclasses of A, by virtue of the definition of the class A, whereas the combination of classes used for multiple instantiation is a characteristic of particular instances only. It is important to note that multiple instantiation is not allowed using combinations of disjoint classes. |
Instanciation multiple |
L’instanciation multiple désigne le fait qu’une instance d’une classe |
Note de traduction |
|||
Références |
|
||
|
endurant, perdurant
|
“The difference between enduring and perduring entities (which we shall also call endurants and perdurants) is related to their behaviour in time. Endurants are wholly present (i.e., all their proper parts are present) at any time they are present. Perdurants, on the other hand, just extend in time by accumulating different temporal parts, so that, at any time they are present, they are only partially present, in the sense that some of their proper temporal parts (e.g., their previous or future phases) may be not present. E.g., the piece of paper you are reading now is wholly present, while some temporal parts of your reading are not present any more. Philosophers say that endurants are entities that are in time, while lacking however temporal parts (so to speak, all their parts flow with them in time). Perdurants, on the other hand, are entities that happen in time, and can have temporal parts (all their parts are fixed in time).” (Gangemi et al. 2002, pp. 166-181). |
Endurant, Perdurant |
« La différence entre des entités endurantes et perdurantes (des endurants et des perdurants) repose sur leur fonctionnement dans le temps : les endurants sont présents dans leur entièreté (c.-à-d. qu’ils comprennent toutes leurs parties constituantes) peu importe le moment auquel ils sont présents. Les perdurants, quant à eux, se construisent dans le temps par l’accumulation d’éléments, de telle sorte qu’ils ne sont toujours que partiellement présents dans la mesure où certains de leurs éléments temporellement déterminés (p. ex. leurs incarnations passées ou futures) peuvent ne pas être présents. Par exemple, une feuille de papier [n.d.t. dont le contenu fait l’objet d’une lecture] est pleinement présente, bien que certains éléments de la lecture ne le soient plus. Les philosophes considèrent les endurants comme des entités situées dans le temps, mais qui n’ont pas de parties temporelles, car celles-ci évoluent dans le temps avec eux. Au contraire, les perdurants sont des entités qui s’incarnent dans le temps et qui peuvent avoir des parties temporelles, car celles-ci sont toutes fixées temporellement » (Gangemi et al., 2002, pp. 166-181). |
Note de traduction |
Le terme « behaviour » a été traduit par « fonctionnement » plutôt que par « comportement » puisqu’il s’agit d’une chose et non pas d’une personne. Le terme « phase » a été traduit par « incarnation » plutôt que par « phase » puisqu’il s’agit de l’état d’une chose à un moment précis de son évolution et non pas du changement lui-même. Le terme « flow » a été traduit par « évoluer » afin d’illustrer la nature fluctuante du concept. |
||
Références |
|
||
|
shortcut
|
A shortcut is a formally defined single property that represents a deduction or join of a data path in the CIDOC CRM. The scope notes of all properties characterized as shortcuts describe in words the equivalent deduction. Shortcuts are introduced for the cases where common documentation practice refers only to the deduction rather than to the fully developed path. For example, museums often only record the dimension of an object without documenting the Measurement that observed it. The CIDOC CRM declares shortcuts explicitly as single properties in order to allow the user to describe cases in which he has less detailed knowledge than the full data path would need to be described. For each shortcut, the CIDOC CRM contains in its schema the properties of the full data path explaining the shortcut. |
Raccourci |
Un raccourci est une propriété singulière formellement définie qui représente un chemin sémantique (obtenu par déduction ou par union) dans le CIDOC CRM. Les notes d’application de toutes les propriétés caractérisées de raccourcis décrivent verbalement les déductions ou unions concernées. Les raccourcis sont utilisés lorsque la pratique documentaire réfère uniquement au résultat déduit plutôt qu’au chemin sémantique complet. Par exemple, les institutions muséales ne recensent souvent que les dimensions d’un objet sans pour autant documenter le [n.d.t. voir Des raccourcis dans les Principes de modélisation]. |
Note de traduction |
Le terme « join of a data » a été traduit par « union » plutôt que par « fusion », car il s’agit de les réunir sans en annihiler l’une ou l’autre. |
||
Références |
Termium. « join ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=join&index=ent&codom2nd_wet=1#resultrecs. |
||
|
monotonic reasoning
|
Monotonic reasoning is a term from knowledge representation. A reasoning form is monotonic if an addition to the set of propositions making up the knowledge base never determines a decrement in the set of conclusions that may be derived from the knowledge base via inference rules. In practical terms, if experts enter subsequently correct statements to an information system, the system should not regard any results from those statements as invalid, when a new one is entered. The CIDOC CRM is designed for monotonic reasoning and so enables conflict-free merging of huge stores of knowledge. |
Raisonnement monotone |
Le raisonnement monotone (un terme issu du domaine de la représentation des connaissances) stipule qu’une forme est monotone si une addition à l’ensemble de propositions qui forme la base de connaissances ne détermine jamais de décrément de l’ensemble des conclusions qui peuvent être dérivées (par des règles d’inférence) d’une base de connaissance. [n.d.t. Un décrément est une quantité constante prédéterminée dont on soustrait la valeur d’une variable.] En pratique, si des experts intègrent à un système d’information des énoncés corrects, ce système ne devrait considérer aucun de ces énoncés invalides lorsqu’un nouvel énoncé est ajouté. C’est ainsi qu’est conçu le CIDOC CRM, de sorte qu’il assure une fusion d’importants ensembles de connaissances sans conflits. [n.d.t. voir la section sur la Monotonicité dans les Principes de modélisation]. |
Note de traduction |
Ajout d’une définition du décrément selon sa définition logicielle (quantité constante prédéterminée dont on soustrait la valeur d’une variable) plutôt que mathématique (diminution de la valeur d’une quantité variable). |
||
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. |
||
|
disjoint
|
Classes are disjoint if the intersection of their extensions is an empty set. In other words, they have no common instances in any possible world. |
Disjoin·e |
Des classes sont disjointes si l’intersection de leurs extensions est un ensemble vide; en d’autres termes, il n’y a pas de possibilité qu’elles aient des instances communes. [n.d.t. voir la section De la disjonction dans les Principes de modélisation]. |
Note de traduction |
|||
Références |
|
||
|
primitive
|
The term primitive as used in knowledge representation characterizes a concept that is declared and its meaning is agreed upon, but that is not defined by a logical deduction from other concepts. For example, mother may be described as a female human with child. Then mother is not a primitive concept. Event however is a primitive concept. Most of the CIDOC CRM is made up of primitive concepts. |
Primitive |
Une primitive (utilisée dans le cadre de la représentation de connaissances) est un concept qui est déclaré et dont la signification est acceptée, mais qui ne peut être définie par une déduction logique reposant sur d’autres concepts. Par exemple, « mère » est un concept qui peut être décrit comme « femme qui a un enfant », de sorte qu’il n’est pas primitif [n.d.t. car il peut être déduit des concepts femme et enfant], alors que |
Note de traduction |
« Female » est un terme qui est couramment utilisé en anglais sans être considéré péjoratif. Cependant, en français, l’utilisation du terme « femelle » pour désigner des humains du sexe féminin est généralement considérée condescendante. Le terme « femme » a donc été utilisé. Techniquement, « being with child » indique qu’une femme est enceinte et non pas qu’elle a eu un enfant. Cependant, le contexte semble indiquer que c’est cette dernière signification qu’avaient en tête les auteurs, de sorte que cette traduction a été privilégiée. |
||
Références |
Termium. « primitive ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=primitive&index=ent&codom2nd_wet=1#resultrecs. |
||
|
Open World
|
The “Open World Assumption” is a term from knowledge base systems. It characterizes knowledge base systems that assume the information stored is incomplete relative to the universe of discourse they intend to describe. This incompleteness may be due to the inability of the maintainer to provide sufficient information or due to more fundamental problems of cognition in the system’s domain. Such problems are characteristic of cultural information systems. Our records about the past are necessarily incomplete. In addition, there may be items that cannot be clearly assigned to a given class. In particular, absence of a certain property for an item described in the system does not mean that this item does not have this property. For example, if one item is described as Biological Object and another as Physical Object, this does not imply that the latter may not be a Biological Object as well. Therefore, complements of a class with respect to a superclass cannot be concluded in general from an information system using the Open World Assumption. For example, one cannot list “all Physical Objects known to the system that are not Biological Objects in the real world”, but one may of course list “all items known to the system as Physical Objects but that are not known to the system as Biological Objects”. |
Monde Ouvert |
L’hypothèse du « monde ouvert » porte sur les systèmes de bases de connaissances et stipule que l’information qui y est stockée est incomplète en comparaison de l’univers discursif que cette information représente. Cette incomplétude peut être due à l’incapacité du responsable [n.d.t. de la base de connaissance] de fournir des informations complètes ou encore à des problèmes plus fondamentaux du domaine eu égard à la cognition, problèmes qui sont caractéristiques des systèmes d’information sur le patrimoine culturel. En effet, les enregistrements au sujet du passé sont nécessairement incomplets et certains éléments pourraient ne pas être facilement attribuables à une classe préétablie. Qui plus est, l’absence d’une propriété pour un élément décrit dans un système [n.d.t. d’information] n’implique pas automatiquement que cet élément n’a pas la propriété en question. Par exemple, si un élément est décrit comme un [n.d.t. voir la section sur la Minimalité dans les Principes de modélisation]. |
Note de traduction |
|||
Références |
|
||
|
complement
|
The complement of a class A with respect to one of its superclasses B is the set of all instances of B that are not instances of A. Formally, it is the set-theoretic difference of the extension of B minus the extension of A. Compatible extensions of the CIDOC CRM should not declare any class with the intension of them being the complement of one or more other classes. To do so will normally violate the desire to describe an Open World. For example, for all possible cases of human gender, male should not be declared as the complement of female or vice versa. What if someone is both or even of another kind? |
Complément |
Le complément d’une classe |
Note de traduction |
La dernière phrase du texte original semble avoir pour objectif d’inclure toutes les personnes, mais elle est formulée de manière quelque peu cavalière et ne s’aligne pas avec l’approche des autres exemples mentionnés de sorte qu’elle pourrait être considérée marginalisante et peu inclusive. Puisqu’elle n’apporte pas d’information supplémentaire, elle a été retirée du texte traduit. |
||
Références |
|
||
|
query containment
|
Query containment is a problem from database theory: A query X contains another query Y, if for each possible population of a database the answer set to query X contains also the answer set to query Y. If query X and Y were classes, then X would be superclass of Y. |
Inclusion des requêtes |
L’inclusion des requêtes [n.d.t relève de la théorie des bases de données et statue] que pour une requête |
Note de traduction |
Le terme « query containment » a été traduit par « inclusion des requêtes ». Le « containment » est généralement traduit dans le domaine de l’algèbre par « inclusion » et dans le domaine logiciel par « contenance ». Puisqu’il s’agit d’un problème fondamentalement théorique et algorithmique, il est apparu préférable de se rapprocher de l’usage mathématique. |
||
Références |
Groz, Benoît. « Inclusion et équivalence de requêtes conjonctives ». Rapport de stage, Institut national de recherche en sciences et technologies du numérique, 2008. https://www.lri.fr/~groz/documents/rapport.pdf. Termium. « containment ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=containment&index=ent&codom2nd_wet=1#resultrecs. |
||
|
interoperability
|
Interoperability means the capability of different information systems to communicate some of their contents. In particular, it may mean that
Generally, syntactic interoperability is distinguished from semantic interoperability. Syntactic interoperability means that the information encoding of the involved systems and the access protocols are compatible, so that information can be processed as described above without error. However, this does not mean that each system processes the data in a manner consistent with the intended meaning. For example, one system may use a table called “Actor” and another one called “Agent”. With syntactic interoperability, data from both tables may only be retrieved as distinct, even though they may have exactly the same meaning. To overcome this situation, semantic interoperability has to be added. The CIDOC CRM relies on existing syntactic interoperability and is concerned only with adding semantic interoperability. |
Interopérabilité [syntactique] |
L’interopérabilité réfère à la capacité de différents systèmes d’information de communiquer de l’information [n.d.t. entre eux], ce qui implique :
Généralement, l’interopérabilité syntactique se distingue de l’interopérabilité sémantique par le fait que l’information encodée et les protocoles d’accès syntactiques sont compatibles de telle sorte que l’information peut être traitée sans erreur. Par contre, cela ne garantit pas que chaque système traite les données en adéquation avec la signification initiale des données. Par exemple, un système peut avoir une table « Acteur » alors qu’un autre peut avoir une table « Agent » [n.d.t. qui traitent toutes deux le même type d’information]. L’interopérabilité syntactique ne permet d’extraire les données que de manière distincte malgré que leur sens soit le même. La prise en compte de la signification des données lors de leur traitement nécessite en effet l’usage de l’interopérabilité sémantique en plus de l’interopérabilité syntactique. Le CIDOC CRM se repose sur cette dernière et n’a pour objectif que d’ajouter l’interopérabilité sémantique. [n.d.t. voir aussi Interopérabilité sémantique]. |
Note de traduction |
|||
Références |
|
||
|
semantic interoperability
|
Semantic interoperability means the capability of different information systems to communicate information consistent with the intended meaning. In more detail, the intended meaning encompasses
Obviously, communication about data structure must be resolved first. In this case consistent communication means that data can be transferred between data structure elements with the same intended meaning or that data from elements with the same intended meaning can be merged. In practice, the different levels of generalization in different systems do not allow the achievement of this ideal. Therefore, semantic interoperability is regarded as achieved if elements can be found that provide a reasonably close generalization for the transfer or merge. This problem is being studied theoretically as the query containment problem. The CIDOC CRM is only concerned with semantic interoperability on the level of data structure elements. |
Interopérabilité sémantique |
L’interopérabilité sémantique réfère à la capacité de différents systèmes d’information de communiquer de l’information [n.d.t. entre eux] en adéquation avec sa signification initiale, ce qui comprend :
La communication des éléments structurels doit être résolue en premier lieu. Une communication adéquate implique à cet égard que les données transférées d’une structure à l’autre conservent leur signification, ou que les données référant aux mêmes éléments et ayant la même signification soient fusionnées. En pratique cependant, en raison des niveaux de généralisation qui varient d’un système à l’autre, cela n’est souvent pas possible. L’interopérabilité sémantique est donc considérée atteinte si des éléments attestant une généralisation raisonnablement comparable au transfert ou à la fusion [n.d.t. des données concernées] sont identifiés. Cela est un problème théorique étudié sous le nom du problème de l'inclusion des requêtes »; le CIDOC CRM, pour sa part, ne se concentre que sur l'interopérabilité sémantique des éléments structurés. [n.d.t. voir aussi Interopérabilité syntactique]. |
Note de traduction |
Le terme « merge » a été traduit par « fusion », lequel semble être la traduction la plus courante dans le domaine du traitement de l’information. Le terme « query containment » a été traduit par « inclusion des requêtes ». Le « containment » est généralement traduit dans le domaine de l’algèbre par « inclusion » et dans le domaine logiciel par « contenance ». Puisqu’il s’agit d’un problème fondamentalement théorique et algorithmique, il est apparu préférable de se rapprocher de l’usage mathématique. |
||
Références |
Groz, Benoît. « Inclusion et équivalence de requêtes conjonctives ». Rapport de stage, Institut national de recherche en sciences et technologies du numérique, 2008. https://www.lri.fr/~groz/documents/rapport.pdf. Termium. « containment ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=containment&index=ent&codom2nd_wet=1#resultrecs. ———. « merge ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=merge&index=ent&codom2nd_wet=1#resultrecs. |
||
|
property quantifiers
|
We use the term "property quantifiers" for the declaration of the allowed number of instances of a certain property that can refer to a particular instance of the range class or the domain class of that property. These declarations are ontological, i.e., they refer to the nature of the real world described and not to our current knowledge. For example, each person has exactly one father, but collected knowledge may refer to none, one or many. |
Quantificateurs de propriété |
Le terme « quantificateurs de propriété » désigne la déclaration du nombre autorisé d’instances d’une propriété qui peut référer à une instance particulière d’une classe de portée ou de domaine de cette propriété. Ces déclarations sont ontologiques, c.-à-d. qu’elles concernent la nature du monde « réel » qui est décrit plutôt que la connaissance de celui-ci. Par exemple, chaque personne a exactement un père [n.d.t. biologique] même si les connaissances recensées peuvent n’en indiquer aucun ou plusieurs. [n.d.t. voir la section Quantificateurs de propriétés dans la section Compatibilité avec le CIDOC CRM]. |
Note de traduction |
|||
Références |
Termium. « quantifier ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=quantifier&index=ent&codom2nd_wet=1#resultrecs. |
||
|
universal
|
The fundamental ontological distinction between universals and particulars can be informally understood by considering their relationship with instantiation: particulars are entities that have no instances in any possible world; universals are entities that do have instances. Classes and properties (corresponding to predicates in a logical language) are usually considered to be universals. (after Gangemi et al. 2002, pp. 166-181). |
universel |
La distinction ontologique fondamentale entre universel et particulier peut être comprise informellement en examinant la relation de chacun avec son instanciation : alors que les particuliers n’ont aucune instance possible, peu importe le monde dans lequel ils se trouvent, les universels sont des entités qui, elles, ont des instances. Les classes et propriétés (qui correspondent en langage logique à des prédicats) sont généralement considérées être des universels (Gangemi & al. 2002, p. 166-181). |
Note de traduction |
|||
Références |
|
||
|
Knowledge Creation Process
|
All knowledge contained in an information system must have been introduced into that system by some human agent, either directly or indirectly. Despite this fact, many, if not most, statements within such a system will lack specific attribution of authority. That being said, in the domain of cultural heritage, it is common practice that, for the processes of collection documentation and management, there are clearly and explicitly elaborated systems of responsibility outlining by whom and how knowledge can be added and or modified in the system. Ideally these systems are specified in institutional policy and protocol documents. Thus, it is reasonable to hold that all such statements that lack explicit authority attribution within the information system can, in fact, be read as the official view of the administrating institution of that system. Such a position does not mean to imply that an information system represents at any particular moment a completed phase of knowledge that the institution promotes. Rather, it means to underline that, in a CH context, a managed set of data, at any state of elaboration, will in fact embody an adherence to some explicit code of standards which guarantees the validity of that data within the scope of said standards and all practical limitations. So long as the information is under active management it remains continuously open to revision and improvement as further research reveals further understanding surrounding the objects of concern. A distinct exception to this rule is represented by information in the data set that carries with it an explicit statement 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 information in a CIDOC CRM model that is based on an explicit creation event for that piece of information, where the creator’s identity has been given, is attributed to the authority and assigned to the responsibility of the actor identified as causal in that event. For any information in the system connected to knowledge creation events that do not explicitly reference their creator, as well as any information not connected to creation events, the responsibility falls back to the institution responsible for the database/knowledge graph. That means that for information only expressed through shortcuts such as P2 has type, where no knowledge creation event has been explicitly specified, the originating creation event cannot be deduced and the responsibility for the information can never be any other body than the institution responsible for the whole information system. In the 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. |
Processus de création de connaissances |
Toute connaissance contenue dans un système d’information doit avoir été introduite dans ce système par un agent humain, que ce soit de manière directe ou indirecte. Malgré cela, plusieurs, si ce n’est la plupart, des énoncés de tels systèmes n’ont pas d’information associée quant à la personne ayant autorité sur eux. Néanmoins, le milieu patrimonial a des pratiques d’assignation de l’autorité établissant comment et par qui une information peut être introduite ou modifiée dans un système, en particulier dans le contexte de la documentation et de la gestion des collections. Ces pratiques sont idéalement recensées dans le cadre de politiques institutionnelles et de protocoles documentaires. Il est donc raisonnable de considérer que, dans le cadre de tels systèmes d’information, tout énoncé n’ayant pas une assignation explicite d’autorité représente la position officielle de l’institution responsable du système. Cette posture [n.d.t. du CIDOC CRM] n’implique cependant pas qu’un système d’information représente un état abouti des connaissances promues par l’institution qui en est responsable. Cette posture a plutôt pour objectif de mettre en évidence qu’un ensemble de données patrimoniales (à un quelconque degré d’élaboration) incarne une adhésion à un ensemble de standards qui garantissent la validité des données dans le cadre de celui-ci et de ses limitations. Tant que l’information [n.d.t. contenue dans le système d’information] est activement maintenue, elle demeure sujette à des améliorations, modifications et révisions au fur et à mesure que la recherche à son sujet présente de nouveaux éléments à son égard ou à l’égard de ce qui l’entoure. De l’information dans un ensemble de données auquel est associé un énoncé explicite de responsabilité constitue une exception notable à cette règle. Dans CIDOC CRM, de tels énoncés de responsabilité sont exprimés par des évènements de création de connaissances tels que
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 qui s’y trouvent sont possibles. Si l’institution hôte accepte la responsabilité de la maintenance 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 artefact], l’autorité associée par défaut aux énoncés qui s’y trouvent sera celle de l’institution initiale [n.d.t. 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 De l’auctorialité des contenus d’une base de connaissances dans les Principes de modélisation]. |
Note de traduction |
Le terme « information system » a été traduit par « système d’information ». |
||
Références |
Termium. « Information System ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-eng.html?lang=eng&i=1&srchtxt=INFORMATION+SYSTEM&index=ent&codom2nd_wet=1#resultrecs. |
||
|
transitivity
|
Transitivity is defined in the standard way found in mathematics or logic: A property P is transitive if the domain and range is the same class and for all instances x, y, z of this class the following is the case: If x is related by P to y and y is related by P to z, then x is related by P to z. The intention of a property as described in the scope note will decide whether a property is transitive or not. For example, the property P121 overlaps with between instances of E53 Place is not transitive, while the property P89 falls within (contains) between instances of E53 Place and the property P46 is composed of (forms part of) between instances of E18 Physical Thing are both transitive. Transitivity is especially useful when CIDOC CRM is implemented in a system with deduction. |
Transitivité |
La transitivité (définie selon des principes mathématiques et logiques) signifie qu’une propriété [n.d.t. voir De l’héritage et de la transitivité dans les Principes de modélisation]. |
Note de traduction |
|||
Références |
|
||
|
symmetry |
Symmetry is defined in the standard way found in mathematics or logic: A property P is symmetric if the domain and range are the same class and for all instances x, y of this class the following is the case: If x is related by P to y, then y is related by P to x. The intention of a property as described in the scope note will decide whether a property is symmetric or not. An example of a symmetric property 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. |
Symétrie |
La symétrie (définie selon des principes mathématiques et logiques) signifie qu’une propriété |
Note de traduction |
|||
Références |
|
||
|
reflexivity |
Reflexivity is defined in the standard way found in mathematics or logic: A property P is reflexive if the domain and range are the same class and for all instances x, of this class the following is the case: x is related by P to itself. The intention of a property as described in the scope note will decide whether a property is reflexive or not. An example of a reflexive property is E53 Place. P89 falls within (contains): E53 Place. |
Réflexivité |
La réflexivité (définie selon des principes mathématiques et logiques standards) signifie qu’une propriété |
Note de traduction |
|||
Références |
|
||
Applied Form - Application formelle
|
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. A CRM conformant documentation system can be implemented using RDF Schema or OWL, but also in Relational or Object-Oriented schema. CIDOC CRM instances can be encoded in RDF, JSON LD, XML, OWL and others. More specifically, the CIDOC CRM is expressed in terms of the primitives of semantic data modelling. As such, it consists of:
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. |
Le CIDOC CRM est une ontologie (dans le sens informatique du terme) prenant la forme d’un modèle sémantique orienté-objet destiné à la conversion vers des formats lisibles par des machines (p. ex. RDF Schema, OWL), mais formulé afin d’être compris tant par les informaticiens que par les experts de la documentation. Une documentation conforme au CIDOC CRM peut-être implémentée en utilisant RDF Schema ou OWL, mais aussi des schémas relationnels ou orientés-objets. Les instances de CIDOC CRM peuvent être encodées en RDF, JSON-LD, XML, OWL ou d'autres formats. Plus spécifiquement, le CIDOC CRM est exprimé en utilisant les primitives de la modélisation sémantique de données. À ce titre, le modèle est constitué de :
La définition présentée ici du CIDOC CRM est complète, bien qu’elle demeure une présentation intentionnellement concise et succincte de ses 81 classes et 160 propriétés uniques. Celle-ci n’a donc pas pour objectif de décliner l’héritage des propriétés par sous-classes à travers la hiérarchie des classes (ce qui exigerait la déclaration de plusieurs milliers de propriétés plutôt que de 160). Par contre, cette définition contient toute l’information nécessaire à l’inférence et à la génération automatique d’une déclaration complète des propriétés, ce qui inclut les propriétés héritées. |
Note de traduction |
|
|---|---|
Références |
JSON-LD Working Group. « JSON-LD - JSON for Linking Data ». JSON-LD, 16 janvier 2014. https://json-ld.org/. OWL Working Group. « OWL - Semantic Web Standards ». Ontologie. Cambridge, USA-MA: World Wide Web Consortium (W3C), 11 décembre 2012. https://www.w3.org/OWL/. RDF Working Group. « RDF - Semantic Web Standards ». Modèle. Cambridge, USA-MA: World Wide Web Consortium (W3C), 25 février 2014. https://www.w3.org/RDF/. XML Working Group. « Extensible Markup Language (XML) ». World Wide Web Consortium (W3C), 11 octobre 2016. https://www.w3.org/XML/. |
Naming Conventions - Convention d’appellation
|
The following naming conventions have been applied throughout the CIDOC CRM:
|
La convention suivante a été appliquée à travers le CIDOC CRM :
|
Note de traduction |
Le terme « naming convention » est parfois traduit par « convention d’appellation » ou « convention de nommage »; le terme « convention d’appellation » a été privilégié, car il semble davantage utilisé de manière générale (après avoir fait une brève recherche en ligne) et est entériné par Termium. |
|---|---|
Références |
OWL Working Group. « OWL - Semantic Web Standards ». Ontologie. Cambridge, USA-MA: World Wide Web Consortium (W3C), 11 décembre 2012. https://www.w3.org/OWL/. Termium. « Convention Appellation Courriels ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-eng.html?lang=eng&i=1&index=frt&srchtxt=CONVENTION%20APPELLATION%20COURRIELS. |
Inheritance and Transitivity - De l’héritage et de la transitivité
|
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. |
Le CIDOC CRM est un système de classe dotées d’héritage, de telle manière qu’une propriété Les propriétés transitives sont explicitement indiquées comme telles dans les notes d’application du CIDOC CRM, si bien que les propriétés dénuées de cette mention doivent être considérées comme non transitives. |
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 |
|
Shortcuts - Des raccourcis
|
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”. |
Certaines propriétés sont déclarées être des raccourcis de chemins sémantiques plus exhaustifs et détaillés qui relient les mêmes classes de domaine et de portée que la propriété-raccourci, mais utilisent une ou plusieurs classes intermédiaires. Par exemple, la propriété La classe |
Note de traduction |
|
|---|---|
Références |
|
About the logical expressions used in the CIDOC CRM - Des expressions logiques utilisées dans le CIDOC CRM
|
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)). In terms of semantic data modelling, 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:
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. |
Les définitions du CIDOC CRM sont annotées d’axiomes qui fournissent de l’information sur l’expression formelle de l’ontologie. Cette section introduit les assomptions qui sous-tendent l’expression logique du CIDOC CRM (pour une revue détaillée de l’expression logique de la modélisation sémantique de données, voir (Reiter, 1984)). En termes de modélisation de données sémantiques, les classes et propriétés sont utilisées pour exprimer des connaissances ontologiques par le biais de contraintes telles que des liens de sous-classe/sous-propriété (p. ex. Au contraire, la représentation de connaissances sous forme de logique du premier ordre repose sur un langage permettant d’encoder de manière formelle une ontologie. Ce langage peut être mis en correspondance directe avec la modélisation sémantique de données :
L’ontologie est exprimée logiquement par le biais d’axiomes qui correspondent aux contraintes de la modélisation sémantique. Dans la définition des classes et propriétés de CIDOC CRM, les axiomes sont énoncés dans la section « Logique ». Plusieurs options sont possibles lorsque vient le temps de rédiger des énoncés sous une forme de logique du premier ordre; ce document privilégie une notation compacte standard utilisée dans plusieurs ouvrages et articles scientifiques. Les définitions [n.d.t. pertinentes] sont présentées dans le tableau ci-dessous. |
Note de traduction |
Le terme « assomption » est peu courant, mais est préféré dans un contexte logique ou mathématique, raison pour laquelle il a été utilisé plutôt que « supposition » ou « hypothèse ». |
|---|---|
Références |
|
|
Symbol |
Name |
reads |
Truth value |
Symbole |
Nom |
Lecture |
Valeur de vérité |
|
Operators |
Opérateurs |
||||||
|
∧ |
conjunction |
and |
(φ ∧ ψ) is true if and only if both φ and ψ are true |
∧ |
conjonction |
et |
(φ ∧ ψ) est vrai si et seulement si à la fois φ et ψ sont vrais |
|
∨ |
disjunction |
or |
(φ ∨ ψ) is true if and only if at least one of either φ or ψ is true |
∨ |
disjonction |
ou |
(φ ∨ ψ) est vrai si et seulement si l’un de φ ou ψ est vrai |
|
¬ |
negation |
not |
¬φ is true if and only if φ is false |
¬ |
négation |
non |
¬φ est vrai si et seulement si φ est faux |
|
⇒ |
implication |
implies, if … then ... |
(φ ⇒ ψ) is true if and only if it is not the case that φ is true and ψ is false |
⇒ |
implication |
implique que, si… alors... |
(φ ⇒ ψ) est vrai si et seulement si ce n’est pas le cas que φ est vrai et ψ est faux |
|
⇔ |
equivalence |
is equivalent to, if … and only if … |
φ ⇔ ψ is true if and only if both φ and ψ are true or both φ and ψ are false |
⇔ |
équivalence |
est équivalent à, si… et seulement si... |
φ ⇔ ψ est vrai si et seulement si à la fois φ et ψ sont vrais ou qu’à la fois φ et ψ sont faux |
|
Quantifiers |
|||||||
|
∃ |
existential quantifier |
exists, there exists at least one |
∃ |
quantificateur existentiel |
existe, il existe au moins un |
||
|
∀ |
Universal quantifier |
forall, for all |
∀ |
quantificateur universel |
pour tous |
|
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). Properties of properties, indicated by a '.1' after the property number are described as ternary predicate symbols. For example, the property P14.1 in the role of is described as the ternary predicate symbol corresponding to property P14 carried out by (performed) : P14(x,y) ⇒ E7(x) P14(x,y)⇒ E39(y) P14(x,y,z) ⇒ [P14(x,y) ∧ E55(z)] 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) |
Le lien de sous-classe susmentionné entre (∀x) [E21(x) ⇒E20(x)] (à savoir : pour tout individu x, si x est un E21 alors x est un E20). Dans la définition des classes et propriétés de ce document le(s) quantificateur(s) universel(s) sont omis par soucis de simplicité, de sorte que cet axiome prend la forme suivante : E21(x) ⇒E20(x) De la même manière, la contrainte du domaine de la propriété P152(x,y) ⇒E21(x) (à savoir : pour tous les individus x et y, si x est un P152 de y, alors x est un E21). Les propriétés de propriétés « propriété .1 » sont nommées par des symboles de prédicats ternaires; par convention la propriété P14(x,y) ⇒ E7(x) P14(x,y)⇒ E39(y) P14(x,y,z) ⇒ [P14(x,y) ∧ E55(z)] Cela devrait être utilisé par le lecteur afin de comprendre les axiomes utilisés dans la définition des classes et des propriétés. (Meghini & Doerr, 2018) offrent plus d’informations sur la formulation de logique du premier ordre dans le CIDOC CRM. |
Note de traduction |
Les termes « quantifiant » ou « quantificateur » peuvent tous deux être utilisés pour désigner des « quantifiers”, la seconde option a été privilégiée pour éviter toute confusion avec le gérondif. |
|---|---|
Références |
Termium. « quantifier ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=quantifier&index=ent&codom2nd_wet=1#resultrecs. |
Property Quantifiers - Quantificateurs de propriétés
|
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) |
Les quantificateurs des propriétés sont présentés ici aux fins de clarification sémantique seulement et ne devraient pas être considérés comme des recommandations d’implémentation. Le CIDOC CRM a été conçu afin d'accommoder des options alternatives ou des informations incomplètes [n.d.t. afin d’accommoder plusieurs interprétations ou compréhensions d’un même phénomène], de sorte que toutes les propriétés devraient être implémentées avec un domaine et une portée optionnels et répétables [n.d.t. c.-à-d. qu’une même propriété peut être utilisée à plusieurs reprises avec de mêmes instances de son domaine et de sa portée] (« relation plusieurs-à-plusieurs (0,n:0,n) »). [n.d.t. Cette question des contraintes de cardinalité, qui précise les principes de généralisation d’une classe], porte généralement sur les implémentations d’un système [n.d.t. plutôt que sur sa conception], de sorte qu’il n’en est pas exhaustivement question ici et que l’expression « contraintes de cardinalité » n'est pas préconisée. Le tableau suivant énumère les quantificateurs de propriété utilisés dans ce document (dans l’ordre de leur notation) ainsi qu’une explication en langage naturel [n.d.t. de chacun d’entre eux]. Les notations verbale et numérique sont juxtaposées dans ce document aux fins de clarté : la notation verbale utilise des syntagmes tels que « un à plusieurs » alors que la notation numérique utilise des expressions telles que « (0,n:0,1) ». Les termes « un », « plusieurs » et « nécessaire » [n.d.t. revêtent leur sens habituel et] intuitif; le terme « dépendant » indique une situation où une instance de la portée d’une propriété ne peut pas exister sans une instance de cette propriété elle-même. En d’autres termes, la propriété est « nécessaire » à sa portée (Meghini, C. & Doerr, M., 2018). |
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é]. Une contrainte de cardinalité précise si une entité « parent » peut appartenir à plusieurs entités « enfants » (principe du recouvrement ou overlapping) ou à un seul (principe de la disjonction). |
|---|---|
Références |
Termium. « cardinalité ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=cardinalit%C3%A9&index=frt&codom2nd_wet=1#resultrecs. |
|
many to many (0,n:0,n)
|
Unconstrained: An individual domain instance and range instance of this property can have zero, one or more instances of this property. In other words, this property is optional and repeatable for its domain and range. |
plusieurs à plusieurs (0,n:0,n)
|
Illimité : Une instance du domaine et une instance de la portée de cette propriété peuvent n’avoir aucune, une ou plusieurs instances de cette propriété. En d’autres termes, cette propriété est optionnelle et répétable [n.d.t. c.-à-d. qu’une même propriété peut être utilisée à plusieurs reprises avec de mêmes instances de] son domaine et de sa portée. |
Note de traduction |
Une propriété répétable est une propriété pouvant apparaître plus d'une fois dans un enregistrement avec le(s) même(s) domaine et/ou portée. |
||
|---|---|---|---|
Références |
Termium. « répétable ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=&index=alt&srchtxt=CATEGORIE%20REPETABLE. |
||
|
one to many (0,n:0,1)
|
An individual domain instance of this property can have zero, one or more instances of this property, but an individual range instance cannot be referenced by more than one instance of this property. In other words, this property is optional for its domain and range, but repeatable for its domain only. In some contexts, this situation is called a “fan-out”. |
un à plusieurs (0,n:0,1) |
Une instance individuelle du domaine de cette propriété peut n’avoir aucune, une ou plusieurs instance(s) de cette propriété, mais une instance individuelle de sa portée ne peut pas faire l’objet d’une référence par plus d’une instance de cette même propriété. En d’autres termes, le domaine et la portée de cette propriété sont optionnels, mais seul son domaine est répétable [n.d.t. c.-à-d. qu’une même propriété peut être utilisée à plusieurs reprises avec une même instance de son domaine]. Cette situation est parfois qualifiée de « sortance ». |
Note de traduction |
Une propriété répétable est une propriété pouvant apparaître plus d'une fois dans un enregistrement avec le(s) même(s) domaine et/ou portée. Une recherche sommaire indique que le terme « fan-out » est surtout usité dans le domaine des circuits booléens et de l’intelligence artificielle, où il est parfois question d’arité sortante ou de sortance. |
||
Références |
Termium. « fan-out ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=fan-out&index=ent&codom2nd_wet=1#resultrecs. ———. « répétable ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=&index=alt&srchtxt=CATEGORIE%20REPETABLE. Wikipédia. « Fan-out ». Dans Wikipédia. San Francisco, US-CA: Wikipédia, 11 novembre 2020. https://fr.wikipedia.org/w/index.php?title=Fan-out&oldid=176479075. |
||
|
many to one (0,1:0,n)
|
An individual domain instance of this property can have zero or one instance of this property, but an individual range instance can be referenced by zero, one or more instances of this property. In other words, this property is optional for its domain and range, but repeatable for its range only. In some contexts, this situation is called a “fan-in”. |
plusieurs à un (0,1:0,n) |
Une instance du domaine de cette propriété peut n’avoir aucune ou une seule instance de cette propriété, mais une instance de sa portée peut être référencée par aucune, une ou plusieurs instances de cette même propriété. En d’autres termes, le domaine et la portée de cette propriété sont optionnels, mais seule sa portée est répétable [n.d.t. c.-à-d. qu’une même propriété peut être utilisée à plusieurs reprises avec une même instance de sa portée]. Cette situation est parfois qualifiée d’« entrance ». |
Note de traduction |
Une propriété répétable est une propriété pouvant apparaître plus d'une fois dans un enregistrement avec le(s) même(s) domaine et/ou portée. Une recherche sommaire indique que le terme « fan-in » est surtout usité dans le domaine des circuits booléens et de l’intelligence artificielle où il est parfois question d’arité entrante ou d’entrance. |
||
Références |
Termium. « fan-in ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=fan-in&index=ent&codom2nd_wet=1#resultrecs. ———. « répétable ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=&index=alt&srchtxt=CATEGORIE%20REPETABLE. Wikipédia. « Fan-in ». Dans Wikipédia. San Francisco, US-CA: Wikipédia, 11 novembre 2020. https://fr.wikipedia.org/w/index.php?title=Fan-in&oldid=176479056. |
||
|
many to many, necessary (1,n:0,n) |
An individual domain instance of this property can have one or more instances of this property, but an individual range instance can have zero, one or more instances of this property. In other words, this property is necessary and repeatable for its domain, and optional and repeatable for its range. |
plusieurs à plusieurs, nécessaire (1,n:0,n) |
Une instance individuelle du domaine de cette propriété peut avoir une ou plusieurs instance(s) de cette propriété, mais une instance individuelle de sa portée peut n’avoir aucune, une ou plusieurs instances de cette même propriété. En d’autres termes, le domaine de cette propriété est nécessaire et répétable [n.d.t. c.-à-d. qu’une même propriété peut être utilisée à plusieurs reprises avec une même instance de son domaine] alors que sa portée est optionnelle et répétable [n.d.t. c.-à-d. qu’une même propriété peut être utilisée à plusieurs reprises avec une même instance de sa portée]. |
Note de traduction |
|||
Références |
|
||
|
one to many, necessary (1,n:0,1)
|
An individual domain instance of this property can have one or more instances of this property, but an individual range instance cannot be referenced by more than one instance of this property. In other words, this property is necessary and repeatable for its domain, and optional but not repeatable for its range. In some contexts, this situation is called a “fan-out”. |
un à plusieurs, nécessaire (1,n:0,1) |
Une instance individuelle du domaine de cette propriété peut n’avoir qu’une seule ou plusieurs instance(s) de cette propriété, mais une instance individuelle de sa portée ne peut pas être référencée par plus d’une instance de cette même propriété. En d’autres termes, le domaine de cette propriété est nécessaire et répétable [n.d.t. c.-à-d. qu’une même propriété peut être utilisée à plusieurs reprises avec une même instance de son domaine], mais sa portée est optionnelle. Dans certains contextes, cette situation est qualifiée de « sortance ». |
Note de traduction |
Une propriété répétable est une propriété pouvant apparaître plus d'une fois dans un enregistrement avec le(s) même(s) domaine et/ou portée. Une recherche sommaire indique que le terme « fan-out » est surtout usité dans le domaine des circuits booléens et de l’intelligence artificielle, où il est parfois question d’arité sortante ou de sortance. |
||
Références |
Termium. « fan-out ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=fan-out&index=ent&codom2nd_wet=1#resultrecs. ———. « répétable ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=&index=alt&srchtxt=CATEGORIE%20REPETABLE. Wikipédia. « Fan-out ». Dans Wikipédia. San Francisco, US-CA: Wikipédia, 11 novembre 2020. https://fr.wikipedia.org/w/index.php?title=Fan-out&oldid=176479075. |
||
|
many to one, necessary (1,1:0,n) |
An individual domain instance of this property must have exactly one instance of this property, but an individual range instance can be referenced by zero, one or more instances of this property. In other words, this property is necessary and not repeatable for its domain, and optional and repeatable for its range. In some contexts, this situation is called a “fan-in”. |
plusieurs à un, nécessaire (1,1:0,n) |
Une instance du domaine de cette propriété peut n’avoir qu’une seule instance de cette propriété, mais une instance de sa portée peut être référencée par aucune, une ou plusieurs instances de cette même propriété. En d’autres termes, le domaine de cette propriété est nécessaire et non répétable [n.d.t. c.-à-d. qu’une même propriété ne peut être utilisée qu'une seule fois avec une instance spécifique de son domaine], mais sa portée est optionnelle et répétable [n.d.t. c.-à-d. qu’une même propriété peut être utilisée à plusieurs reprises avec une même instance de sa portée]. Cette situation est parfois qualifiée d’« entrance ». |
Note de traduction |
Une propriété répétable est une propriété pouvant apparaître plus d'une fois dans un enregistrement avec le(s) même(s) domaine et/ou portée. Une recherche sommaire indique que le terme « fan-in » est surtout usité dans le domaine des circuits booléens et de l’intelligence artificielle, où il est parfois question d’arité entrante ou d’entrance. |
||
Références |
Termium. « fan-in ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=fan-in&index=ent&codom2nd_wet=1#resultrecs. ———. « répétable ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=&index=alt&srchtxt=CATEGORIE%20REPETABLE. Wikipédia. « Fan-in ». Dans Wikipédia. San Francisco, US-CA: Wikipédia, 11 novembre 2020. https://fr.wikipedia.org/w/index.php?title=Fan-in&oldid=176479056. |
||
|
one to many, dependent (0,n:1,1) |
An individual domain instance of this property can have zero, one or more instances of this property, but an individual range instance must be referenced by exactly one instance of this property. In other words, this property is optional and repeatable for its domain, but necessary and not repeatable for its range. In some contexts, this situation is called a “fan-out”. |
un à plusieurs, dépendant (0,n:1,1) |
Une instance individuelle du domaine de cette propriété peut n’avoir aucune, une ou plusieurs instance(s) de cette propriété, mais une instance individuelle de sa portée ne doit être référencée que par une seule instance de cette même propriété. En d’autres termes, le domaine de cette propriété est optionnel et répétable [n.d.t. c.-à-d. qu’une même propriété peut être utilisée à plusieurs reprises avec une même instance de son domaine], mais sa portée est nécessaire et non répétable [n.d.t. c.-à-d. qu’une même propriété ne peut être utilisée qu'une seule fois avec une instance spécifique de sa portée]. Cette situation est parfois qualifiée de « sortance ». |
Note de traduction |
Une propriété répétable est une propriété pouvant apparaître plus d'une fois dans un enregistrement avec le(s) même(s) domaine et/ou portée. Une recherche sommaire indique que le terme « fan-out » est surtout usité dans le domaine des circuits booléens et de l’intelligence artificielle où il est parfois question d’arité sortante ou de sortance. |
||
Références |
Termium. « fan-out ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=fan-out&index=ent&codom2nd_wet=1#resultrecs. ———. « répétable ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=&index=alt&srchtxt=CATEGORIE%20REPETABLE. Wikipédia. « Fan-out ». Dans Wikipédia. San Francisco, US-CA: Wikipédia, 11 novembre 2020. https://fr.wikipedia.org/w/index.php?title=Fan-out&oldid=176479075. |
||
|
one to many, necessary, dependent (1,n:1,1)
|
An individual domain instance of this property can have one or more instances of this property, but an individual range instance must be referenced by exactly one instance of this property. In other words, this property is necessary and repeatable for its domain, and necessary but not repeatable for its range. In some contexts, this situation is called a “fan-out”. |
un à plusieurs, nécessaire, dépendant (1,n:1,1) |
Une instance individuelle du domaine de cette propriété peut n’avoir qu’une seule ou plusieurs instance(s) de cette propriété, mais une instance individuelle de sa portée ne doit être référencée que par une seule instance de cette même propriété. En d’autres termes, le domaine de cette propriété est nécessaire et répétable [n.d.t. c.-à-d. qu’une même propriété peut être utilisée à plusieurs reprises avec une même instance de son domaine] et sa portée est nécessaire mais non répétable [n.d.t. c.-à-d. qu’une même propriété ne peut être utilisée qu'une seule fois avec une instance spécifique de sa portée]. Cette situation est parfois qualifiée de « sortance ». |
Note de traduction |
Une propriété répétable est une propriété pouvant apparaître plus d'une fois dans un enregistrement avec le(s) même(s) domaine et/ou portée. Une recherche sommaire indique que le terme « fan-in » est surtout usité dans le domaine des circuits booléens et de l’intelligence artificielle, où il est parfois question d’arité entrante ou d’entrance. |
||
Références |
Termium. « fan-in ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=fan-in&index=ent&codom2nd_wet=1#resultrecs. ———. « répétable ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=&index=alt&srchtxt=CATEGORIE%20REPETABLE. Wikipédia. « Fan-in ». Dans Wikipédia. San Francisco, US-CA: Wikipédia, 11 novembre 2020. https://fr.wikipedia.org/w/index.php?title=Fan-in&oldid=176479056. |
||
|
many to one, necessary, dependent (1,1:1,n) |
An individual domain instance of this property must have exactly one instance of this property, but an individual range instance can be referenced by one or more instances of this property. In other words, this property is necessary and not repeatable for its domain, and necessary and repeatable for its range. In some contexts, this situation is called a “fan-in”. |
plusieurs à un, nécessaire, dépendant (1,1:1,n) |
Une instance individuelle du domaine de cette propriété doit n’avoir qu’une seule instance de cette propriété, mais une instance individuelle de sa portée peut être référencée par une ou plusieurs instances de cette même propriété. En d'autres termes, le domaine de cette propriété est nécessaire et non répétable [n.d.t. c.-à-d. qu’une même propriété ne peut être utilisée qu'une seule fois avec une instance spécifique de son domaine], tandis que la portée est nécessaire et répétable [n.d.t. c.-à-d. qu’une même propriété peut être utilisée à plusieurs reprises avec une même instance de sa portée]. Cette situation est parfois qualifiée d’« entrance ». |
Note de traduction |
Une propriété répétable est une propriété pouvant apparaître plus d'une fois dans un enregistrement avec le(s) même(s) domaine et/ou portée. Une recherche sommaire indique que le terme « fan-in » est surtout usité dans le domaine des circuits booléens et de l’intelligence artificielle, où il est parfois question d’arité entrante ou d’entrance. |
||
Références |
Termium. « fan-in ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=1&srchtxt=fan-in&index=ent&codom2nd_wet=1#resultrecs. ———. « répétable ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=&index=alt&srchtxt=CATEGORIE%20REPETABLE. Wikipédia. « Fan-in ». Dans Wikipédia. San Francisco, US-CA: Wikipédia, 11 novembre 2020. https://fr.wikipedia.org/w/index.php?title=Fan-in&oldid=176479056. |
||
|
one to one (1,1:1,1) |
An individual domain instance and range instance of this property must have exactly one instance of this property. In other words, this property is necessary and not repeatable for its domain and for its range. |
un à un (1,1:1,1) |
Une instance individuelle du domaine et une instance de la portée de cette propriété doivent avoir exactement une instance de cette propriété. En d’autres termes, le domaine et la portée de cette propriété sont nécessaires et non répétables [n.d.t. c.-à-d. qu’une même propriété ne peut être utilisée qu’une seule fois avec une instance spécifique de son domaine et une instance spécifique de sa portée]. |
Note de traduction |
Une propriété répétable est une propriété pouvant apparaître plus d'une fois dans un enregistrement avec le(s) même(s) domaine et/ou portée. |
||
Références |
Termium. « répétable ». Dans Termium Plus. Ottawa, CA-ON: Gouvernement du Canada, 8 octobre 2009. https://www.btb.termiumplus.gc.ca/tpv2alpha/alpha-fra.html?lang=fra&i=&index=alt&srchtxt=CATEGORIE%20REPETABLE. |
||
|
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 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. Note that the quantification of all properties of properties, “.1” properties, is “many-to-many” and, therefore, does not appear explicitly in their definitions. |
Le CIDOC CRM définit certains dépendants entre les propriétés et les classes sous la forme de leur domaine et de leur portée. Ceux-ci peuvent être l’une ou une combinaison des options suivantes :
Les dépendants possibles sont définis dans le tableau ci-haut. Si une propriété n’est pas spécifiée pour une instance de son domaine ou de sa portée, il est entendu que la propriété existe, mais qu’une valeur associée à une part ou à l’autre de la propriété est inconnue. Dans le cas des propriétés optionnelles, la méthodologie proposée par le CIDOC CRM n’établit pas de distinction entre une valeur inconnue et une propriété qui ne serait pas du tout applicable. Par exemple, un objet peut avoir un·e propriétaire sans que l’identité de ce·tte propriétaire ne soit connue. Dans le cadre du CIDOC CRM , une telle situation ne peut être distinguée d’un cas où l’objet n’aurait aucun·e propriétaire. Bien entendu, de tels détails peuvent être indiqués à l’aide de notes textuelles. Parce que la quantification de toutes les propriétés de propriétés – les propriétés « .1 » – est « plusieurs à plusieurs » elle n'apparaît pas explicitement dans leurs définitions. |
Note de traduction |
Le terme « dépendant » a été préféré au terme « dépendance » en guise de traduction de « dependencies » puisqu’il transmet davantage le fait qu’il s’agit d’un élément qui s’inscrit dans la suite d’un autre (qui en dépend) plutôt qu’un élément qui a lui-même « besoin » d’un autre élément (qui est en situation de dépendance). |
|---|---|
Références |
|