Etape 1 : Modélisation des activités en CIDOC-CRM

Qu’est-ce que le CIDOC-CRM ? Ce modèle de référence (CRM) a été conçu par le Comité international pour la documentation (CIDOC) pour le patrimoine culturel. Le modèle, dont les travaux ont débuté en 1995, est devenu.

Ce modèle sémantique est une ontologie de l'information relative au patrimoine culturel, c'est-à-dire une formalisation des relations qui unissent les concepts fondamentaux de ce type d'information. La présentation en est basée sur l'approche « orientée objet ». [71] [73]

L’approche par évènement, centrale dans cette ontologie, nous a poussés à l’envisager pour modéliser les activités IIPE, en suivant les conseils d’Anila Angjeli et Patrick LeBoeuf.

Comment procéder ?

Il nous a fallu nous familiariser avec la terminologie de CIDOC CRM: comprendre ce qu’est une classe, une propriété, un domaine, une cible.

La syntaxe s’articule ainsi : la classe source / domaine (assimilable au sujet)  la propriété (assimilable au verbe)  la classe cible (assimilable à l’objet).

Une classe peut être déclarée comme sous classe d’une autre classe : chaque instance de cette sous classe hérite des propriétés de la classe. La palette des classes et des propriétés développées par le CRM est conçue pour des objets muséographiques dans le but de les contextualiser autant que de les décrire.

Une instance exemplarise une classe : par exemple, la Contribution n°1 au séminaire sur les politiques d’éducation est une instance de la classe F14 Œuvre individuelle.

Une classe déclare une propriété: une activité peut avoir lieu (P7), consister en (P9), motiver / être motivée par (P17).

Ces propriétés du CIDOC correspondent aux relations des FRBR.

Il faut respecter le vocabulaire mais également les conventions de notation : l’identifiant (une lettre E pour entité et P pour propriété et un chiffre) précède la classe.

Il faut souligner le rôle central :

- d’une part du site web du CIDOC CRM dont les vidéos expliquent remarquablement comment construire les schémas de modélisation et modéliser l’information dynamique (par exemple les séminaires) [73].

Sont particulièrement centraux pour notre modélisation les tutoriels concernant l’activité, l’intervalle de temps et le lieu.

- d’autre part, des expériences déjà menées concernant l’information du secteur public qui nous ont confortées dans la faisabilité de cette modélisation. [72]

Comment aborder la modélisation de l’activité IIPE avec le CIDOC CRM ? La structure du CIDOC CRM permet d’abord de rendre compte de la place centrale du plan à moyen terme, autour duquel gravitent les projets et leurs activités IIPE. En effet, l’entité

temporelle E7 Activity -qui a une existence bornée (début/fin) - permet de hiérarchiser les différents niveaux d’œuvre, depuis le plan à moyen terme, en passant par les projets, puis les activités IIPE.

Le CIDOC permet ensuite d’introduire la notion d’événement de l’activité IIPE. Grâce au CRM, on peut modéliser les processus : workflow de production d’une activité (et sa validation), de production d’une publication, de stockage d’une ressource électronique et de documentation des processus.

E52 Time Span =

“Monitoring and Evaluating HIV and AIDS Education Programme in Africa”

E7 Activity = Activity 1

“North Sudan Education Sector

Project P8-002-Emergencies E7 Activity =

Project P8-004-Quality

Figure 8 : Modélisation avec le CIDOC CRM

Une activité IIPE est facilement contextualisable à l’aide des entités temporelles et des entités

« persistantes »³⁵, indépendantes du temps (les « choses, les personnes).

Par exemple, lorsqu’un séminaire ou un colloque ont lieu, on peut préciser : - l’intervalle de temps pendant lequel il s’est tenu (classe E52 Localisation dans le temps³⁶) et la localisation dans l’espace (E53 Place) qu’identifie E48 Place Name mais aussi - les agents impliqués dans son déroulement : E39 Actor, E21 Person, E74 Group, - et même préciser leur fonction par la propriété P14. l. in the role of associée à E55 Type.

Le CIDOC CRM permet donc de représenter avec quelques propriétés l’activité dans ses aspects spatio-temporels.

Il permet aussi de retracer finement des changements concernant un groupe et ses acteurs. En utilisant les classes E85 Joining / E86 Leaving et de leurs propriétés, on indique un changement d’instance dans la classe E21 Person au sein d’une groupe (E74 Groupe), cela au cours d’une période donnée (E52 Intervalle de temps) : changement de membre dans l’équipe, changements de responsable d’une activité, cas fréquents dans notre institution. (Figure 3)

35 Notons que les classes des entités temporelles ne peuvent être reliées à celles des entités persistantes : elles sont « disjointes ». 

36 Traduction de la classe E52, Timespan, proposée par M. LeBœuf. 

Il est également possible de rendre compte d’un changement du lieu où se déroule une activité.

Schématiser les informations et travailler sur leur structuration nous a aussi permis de mettre à plat la signification de chaque activité. Nous avons procédé à un travail quasi sémantique pour qualifier ce qui est évident ou implicite, pour chaque classe et ses relations. La présentation en graphe du CIDOC CRM offre une vision globale des classes et de leurs relations.

A ce stade, nous avons souhaité mesurer les conséquences de la coexistence de deux modèles FRBRER et CIDOC CRM.

Après avis auprès d’experts de la Bibliothèque nationale de France, ont été pointés les risques d’incompatibilité de ces deux modèles, et d’incohérence dans le traitement des données pour une future implémentation.

Nous avons donc finalement opté pour la reformulation orientée objet du modèle FRBR. En effet, à la croisée des univers bibliographiques (modèle FRBR) et muséographiques (CIDOC CRM) a été créé en 2008 un hybride : le FRBROO « qui s’appuie sur la démarche du CRM, met l’accent sur les processus ». [77]

L’objectif est de construire avec un modèle unique la passerelle permettant de relier les activités aux productions et documents qu’elle génère.