Un artefact est un objet produit par l’humain. Un artéfact peut être, par exemple, un couteau en silex, une mosaïque ou une maison entière.

Généralement on s’intéresse à ses caractéristiques, à sa typologie, à sa production, à ses usages, à ses propriétaires successifs, à sa localisation, aux images et autres objets symboliques dont ils est éventuellement le support, etc.

Un exemple de modélisation générique des artéfacts se trouve dans ce diagramme de classes.

Ce modèle conceptuel a été réalisé avec le logiciel diagrams.net (draw.io) (cliquer sur le diagramme deux fois pour afficher). Concernant le logiciel, voir cette page.

Téléchargez le fichier XML au format .drawio ici et ouvrez-le dans diagrams.net.

Concernant les artéfacts trouvés lors d’une fouille, voir la modélisation de la fouille archéologique.

On pourrait s’intéresser davantage aux typologies d’artéfacts : dans ce cas l’objet d’études ne porterait plus sur un objet physique mais sur un concept, i.e. un type d’objet physique (par ex. la montgolfière), dont on connaît éventuellement quelques exemplaires. Dans ce cas, la modélisation serait différente. Dans le diagramme des classes proposé, c’est l’objet physique qui est au centre du questionnement et non le concept.

Si on adopte le point de vue du CIDOC CRM (qui est utile pour guider l’activité de conceptualisation sans être toutefois appliqué de manière rigide) un artefact, en tant qu’objet physique, peut se présenter sous la forme d’un Man-Made Object – E22, si sa subsistance physique est autonome, ou d’une Man-Made Feature – E25 , s’il s’agit d’une partie d’un objet telle la tête d’une statue (tant qu’elle se trouve sur la statue – séparée de la statue c’est un objet indépendant) ou la poignée d'un vase, ou alors d’une portion de surface de l’objet, telle une griffure à caractère symbolique ou une grotte (excavée dans une montagne – une grotte naturelle est une E26 Physical Feature). On pourra associer à chacune de ces deux classes un type qui en précise l’identité. Le type sera défini comme classe distincte, ce qui permettra d’ajouter les définitions des types et d’éviter les méprises que provoquent les synonymies dans les appellations (à défaut d’une définition précise du concept).

On peut aussi se limiter à utiliser une classe englobante, parente des deux précédentes, E24 Physical Man-Made Thing, comme il est proposé dans le modèle-exemple, et à préciser l’identité par un type opportun (que ce soit une feature ou un objet). La cardinalité 0,n : 1 de la propriété has type indique que le type est unique pour un objet et qu’il en définit ainsi l’identité. Si on s’intéresse à des multiples classements possibles, on peut utiliser la même classe, Physical Man-Made Thing Type, mais en l’associant avec la propriété is classified by ce qui permet —au vu de la cardinalité 0,n : 0,n— d’associer plusieurs types au même objet. On exprimera ainsi une classification ou typologie générique d’un objet distincte du type qui en définit l’identité (par ex. épée ou montre à quartz). Le modèle conceptuel prévoit aussi un rapport de spécialisation entre types, avec la propriété specializes type, ce qui permet de construire des taxonomies de concepts plus ou moins précis (par ex. classifications temporelles, styles artistiques, etc.).

En application de la grammaire de la modélisation conceptuelle on va distinguer entre propriétés-valeur et propriétés-relation. Ces dernières expriment des relations entre les classes (et donc entre leurs objets/instances). Étant donné que les propriétés-valeurs contiennent des chaines de caractères ou des chiffres, les données produites avec ces propriétés seront semi-structurées : la colonne indique le sens de la propriété mais la cellule contient une simple valeur, par ex. un type sous forme de chaine de caractères, et non un objet identifié avec précision, par exemple une instance bien identifiée de la classe Type. En revanche, les propriétés-relation permettent de produire des données structurées en établissant, par ex., une relation entre un objet et son type, ce dernier étant défini clairement par sa définition et son label, et associé à tous les objets relevant de ce type par sa clé primaire, utilisée comme clé étrangère dans la relation. Pour plus de précisions à ce sujet, voir les travaux mentionnés sur cette page concernant la modélisation conceptuelle et le diagramme des classes.

Lors de la production du modèle conceptuel (ou diagramme des classes) il est très important de bien réfléchir à cette distinction et de vérifier que sous les propriétés-valeurs ne se cachent pas, en réalité, des objets qu’il faudrait modéliser sous forme de classe. Par exemple, si on renseigne des lieux, avec nom et coordonnées géographiques, à plusieurs endroits du modèle sous forme de propriétés-valeur (lieu de production de l’objet, lieux d’utilisation, lieu de conservation actuelle, etc.) on va produire des données semi-structurées qui seront certainement redondantes et difficiles à gérer. Si on créé une classe Geographical Place, possédant les propriétés name, longitude et latitude, et qu’on l’associe avec différentes propriétés en fonction des cas, on aura un modèle plus robuste et maniable. On pourra par ex. corriger les coordonnées géographiques d’un lieu sans devoir les chercher/remplacer partout dans le système d’information si elles ont été saisies sous forme de propriétés-valeur.

Concernant ces dernières, si on souhaite en ajouter une certaine quantité pour le même objet, il vaut mieux ne pas le faire directement dans la classe de l’artéfact, en multipliant par conséquent indéfiniment les colonnes d’une table dans le modèle logique, mais en créant une classe supplémentaire, appelée Property, qui aura un Property Type opportun et ses valeurs propres. On pourra ainsi renseigner, dans une logique type-valeur (ou clé-valeur pour un stockage au format JSON), autant de propriétés qu’on le souhaite et, de plus, renseigner uniquement les informations qu’on connaît pour un objet alors que virtuellement des dizaines de propriétés sont possibles mais non renseignées. On pourrait aussi restreindre les propriétés possibles pour tel ou tel type d’objet, cf. la propriété is declared for object type de l’exemple.

Le risque de cette modélisation générique, qui certes permet d’avancer rapidement au début, est de découvrir plus tard (lorsqu’il est trop tard) qu’on n’a pas suffisamment conceptualisé son domaine de recherche et qu’il y a plein d’objets cachés sous les propriétés-valeur, possédant elles-mêmes des propriétés spécifiques qu’il sera impossible de saisir faute de les avoir identifiées clairement au début.

Enfin, dans l’exemple du modèle conceptuel proposé, qui est conceptualisé à partir de la classe E24 Physical Man-Made Thing du CIDOC CRM, trois ensembles de propriétés ont été pris en considérations. D’autres pourront bien entendu être ajoutés en fonction du questionnement de la recherche. Pour cette partie, il est utile de s’inspirer des différents exemples et cas de figure présentés dans la Functional Overview sur le site du CIDOC CRM.

Il importe de relever que, si sur le modèle conceptuel on tracera toutes les classes et propriétés utiles, afin de conceptualiser l’ensemble de l’information nécessaire à l’étude de son champs de recherche, on ne va pas nécessairement produire toutes les tables et toutes les propriétés dans le modèle logique. En effet, on ne doit renseigner les données que pour les domaines où on imagine un traitement systématique de l’information, comprenant au minimum une vingtaine d’objets par classes ou plus, et des informations concernant une partie significatives des propriétés. Pour une dizaine d’objets et des propriétés lacunaires on se limitera à une prise de notes sous forme de texte. La conceptualisation globale de l’information du domaine est toutefois toujours utile.

1. La production et la modification des objets

Différentes classes sont prévues par le CIDOC CRM : E12 Production, E11 Modification, E79 Part Addition, etc. Elles héritent toutes des propriétés de leur classe parente E7 Activity dont certaines peuvent s’avérer utiles en fonction des sujets. Dans le modèle-exemple il est proposé d’utiliser une classe générique Manipulation, spécialisation d’Activity dans le sens de la manipulation d’un objet depuis sa production jusqu’à sa destruction, munie d’un type qui en définit l’identité. Cette classe modélise toute manipulation d’un artéfact et associe la personne qui a effectué la manipulation en indiquant les différents types de celle-ci, de la production à l’usage à la modification, etc. Différentes propriétés pourront être ajoutées en fonctions des besoins du projet de recherche.

2. Droit exercé sur l’objet et localisation physique

Dans une approche générique analogue à la précédente, une classe Subjection to a right indique quel est la personne ou l’organisme qui possède ou conserve un artéfact, a des droits sur lui, etc. La cardinalité de la propriété is subjection to indique que pour chaque droit exercé par un groupe ou une personne il faut créer une instance différente de la classe Subjection to a Right (c’est-à-dire une ligne dans la table de la base de données), qui aura souvent une date de début et de fin différente. On pourra ainsi traiter les propriétaires successifs de l’artefact.

À noter que la substance ontologique d’un droit exercé et celle de la localisation physique de l’objet sont différentes. Si on s’intéresse aux rapport sociaux de propriété etc. on utilisera la classe Subjection to a Right alors que si l’information porte sur l’endroit de conservation de l’objet on utilisera Geographical Location.

3. Représentation et iconographie

Si on veut associer un objet représenté (personne, symbole, etc.) à un artéfact (mosaïque, amphore, etc.) on peut utiliser les propriétés P62 depicts (is depicted by) → E1 CRM Entity ou P65 shows visual item (is shown by) → E36 Visual Item. On peut aussi complexifier le modèle en associant l’objet visuel présent sur le support physique de l’artefact : « the more fully developed path from E24 Physical Man-Made Thing through P65 shows visual item (is shown by), E36 Visual Item, P138 represents (has representation) to E1 CRM Entity » (cf. la définition de P62 depicts ).

On trouvera des exemples plus complets dans ce cas d’usage : Image Information,Objects and Carriers. Etant donné la complexité du sujet, le modèle-exemple se limite à ajouter une classe Depicted object type qui indique la typologie de l’objet représenté. Mais on pourrait associer directement des personnes, des divinités, etc. en créant les classes appropriées et en y ajoutant les propriétés correspondantes (dans le modèle-exemple la classe personne est associée par la propriété depicts person).