Terminologie
Date de création : 2020-10-20
Dernière mise à jour : 2023-05-26
|
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. Reprint, 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 identifier 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. In some contexts (e.g., the programming language C++) the term parent class is used synonymously with superclass. For example: “Biological Object subsumes Person” is synonymous with “Biological Object is a superclass of Person”. It needs fewer traits to identify an item as a Biological Object than to identify it as a Person |
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 Dans certains contextes (p. ex. le langage de programmation C ++), le terme « classe parent » est utilisé comme synonyme de super-classe. 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 Man Made Object. An instance of a property is a factual relation between an instance of the domain and an instance of the range of the property that matches the criteria of the intension of the property. For example: The 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 |
</td>
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 à des 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. |
Disjoint•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, ceci 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, ceci 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. Ceci 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 |
|||