Connecter un catalogue d'expositions wiki à Wikidata : premières réflexions

Il existe, depuis quelques années, un outil discret mais remarquable : le Catalogue des expositions du Centre Pompidou, un wiki MediaWiki augmenté de Semantic MediaWiki, qui documente de façon raisonnée l’ensemble des expositions produites par l’institution depuis 1977. Commissaires, espaces, cycles, itinérances, le catalogue construit une mémoire structurée de l’activité expositionnelle temporaire du Pompidou.

Lors d’une discussion avec les responsables actuelles du projet, une question s’est imposée : que se passerait-il si ces données rejoignaient l’écosystème Wikidata ?

Un wiki sémantique, déjà à mi-chemin

Le choix de Semantic MediaWiki n’est pas anodin. SMW permet de structurer les contenus sous forme de triplets RDF, d’attribuer des propriétés typées aux entités, et d’exposer des données interrogeables via SPARQL. C’est exactement le modèle que Wikidata utilise. En ce sens, le catalogue est déjà, structurellement, à mi-chemin entre une base documentaire classique et un graphe de connaissances.

Ce qui manque, c’est le lien explicite entre les deux mondes.

Ce que la connexion apporterait

Connecter le catalogue à Wikidata ne signifie pas fusionner les deux bases ni déléguer la gouvernance éditoriale. Il s’agit plutôt de créer des ponts : aligner les entités du catalogue (expositions, commissaires, espaces d’exposition) avec leurs équivalents dans Wikidata, et réciproquement enrichir Wikidata avec des identifiants pointant vers le catalogue.

Les bénéfices sont de plusieurs ordres. Les entités documentées dans le catalogue deviendraient accessibles depuis l’écosystème Wikidata/Wikipedia, avec tout ce que cela implique en termes de visibilité et de citabilité. Les commissaires et artistes pourraient être mis en relation avec d’autres référentiels déjà agrégés dans Wikidata : BnF, VIAF, Getty ULAN. Et le catalogue lui-même gagnerait en interopérabilité, ses données devenant réutilisables par des outils tiers sans travail supplémentaire.

Une démarche en phases

La connexion que j’envisage s’articulerait en plusieurs étapes progressives, pensées pour être non intrusives et réversibles.

La première phase consisterait en un audit du schéma existant et une cartographie des entités. Le catalogue repose sur une logique documentaire interne, sans schéma formellement publié. Avant tout alignement, il faut donc comprendre les propriétés SMW effectivement utilisées, leur sémantique implicite, et les entités qu’elles décrivent. Ce travail de rétro-ingénierie produirait deux livrables simultanément : un schéma documenté du catalogue, utile indépendamment de la suite, et une base de données d’entités prête pour la réconciliation Wikidata.

La deuxième phase serait celle de la réconciliation et de l’import. À partir des listes d’entités extraites, OpenRefine permettrait d’identifier les correspondances avec Wikidata de façon semi-automatique. Les alignements seraient soumis à validation humaine avant tout import pour éviter les erreurs d’homonymie ou les fusions incorrectes. En parallèle, la création d’une propriété Wikidata dédiée au catalogue (sur le modèle des identifiants externes déjà existants pour d’autres bases patrimoniales) permettrait de matérialiser le lien de façon pérenne.

Une troisième phase, plus prospective, concernerait la mise en correspondance du schéma avec CIDOC-CRM. L’exposition est précisément le type d’événement que CIDOC-CRM modélise bien : E7 Activity, agents, lieux, temporalités. Aligner le schéma SMW sur ce standard ouvrirait des perspectives d’interopérabilité bien au-delà de Wikidata, et positionnerait le catalogue comme ressource de référence à l’échelle internationale.

Le catalogue ne publie pas de schéma formel. Mais en parcourant les fiches, notamment celle de l’exposition Salvador Dalí rétrospective 1920-1980, il est possible d’en reconstituer la structure. Chaque fiche d’exposition s’organise autour d’une “fiche signalétique” dont les champs révèlent les propriétés SMW centrales :

Les sections structurées de chaque fiche complètent ce schéma avec des propriétés implicites supplémentaires :

Ce tableau est une première ébauche, à affiner avec les contributeurs du catalogue. Il met cependant en évidence trois points de tension avec CIDOC-CRM qui méritent attention.

Le premier concerne les rôles des agents. Dans les fiches actuelles, les rôles (“Commissaire général”, “Architecte”, “Conseiller”) sont encodés en texte libre à l’intérieur des champs, plutôt que comme propriétés typées distinctes. CIDOC-CRM gère cette situation via la propriété P14.1 in the role of, qui permet d’associer un rôle à une participation sans ambiguïté. C’est probablement là que l’alignement apporterait le gain sémantique le plus immédiat. Les artistes sont majoritairement dans wikidata.

Le second concerne les oeuvres exposées. Elles apparaissent sous forme de listes textuelles avec indication de la salle, sans être des entités propres liées à d’autres bases (numéros d’inventaire, identifiants collections). Le potentiel d’enrichissement est ici considérable, mais aussi la complexité : lier des oeuvres à leurs entrées dans la base des collections du MNAM-CCI (videomuséum) ou dans des référentiels externes supposerait un travail de réconciliation spécifique. Que faire pour les oeuvres qui ne font pas parties de la collection ?

Le troisième point concerne les données qui n’ont pas d’équivalent direct dans CIDOC-CRM de base : le budget, la fréquentation, les données de production éditoriale avec leurs cotes d’archives. Ces informations sont documentairement précieuses mais sortent du périmètre de l’ontologie standard. Elles nécessiteraient soit des extensions locales, soit un choix explicite de les laisser hors du périmètre d’alignement dans un premier temps.

Outils envisagés

Les outils disponibles pour ce type de projet sont nombreux, mais ils ne s’adressent pas aux mêmes profils ni aux mêmes étapes. Il vaut la peine de les distinguer.

OpenRefine est l’outil central de la phase de réconciliation. Son connecteur Wikidata permet d’apparier semi-automatiquement une liste d’entités locales avec des items Wikidata existants, en s’appuyant sur les labels, alias et propriétés. L’interface reste accessible à un profil documentaire sans compétences en développement, et le processus est entièrement contrôlable avant tout import.

QuickStatements prend le relais pour l’import en masse dans Wikidata. Il accepte des fichiers CSV structurés et traduit chaque ligne en une instruction d’édition sur Wikidata. C’est l’outil standard pour alimenter Wikidata à partir de données réconciliées, sans passer par l’API.

Wikidata Toolkit est une bibliothèque Java open source conçue pour lire et écrire des données Wikidata de façon programmatique, notamment via les dumps ou l’API MediaWiki. C’est l’option la plus puissante pour une automatisation à grande échelle ou un traitement récurrent, mais elle suppose un environnement de développement Java. Dans le cadre d’un projet comme celui-ci, elle deviendrait pertinente à partir du moment où la maintenance des liens nécessite des mises à jour régulières et volumineuses.

Côté SMW, la connexion se matérialise simplement : il suffit d’ajouter une propriété de type “identifiant externe” dans les fiches du catalogue, pointant vers l’item Wikidata correspondant. SMW dispose nativement des mécanismes pour typer et afficher ce genre de lien. C’est une modification légère du schéma existant, sans migration de données.

Ce billet est une invitation à réfléchir ensemble, et, peut-être, à construire quelque chose. Si vous travaillez sur des problématiques similaires (documentation d’exposition, Wikidata, Semantic MediaWiki, CIDOC-CRM) n’hésitez pas à me contacter.