# L'alignement des données avec Wikidata dans les institutions culturelles : le cas des entités personnes et institutions au musée d'Orsay

Mélina Conter

► To cite this version:

Mélina Conter. L'alignement des données avec Wikidata dans les institutions culturelles : le cas des entités personnes et institutions au musée d'Orsay. Sciences de l'Homme et Société. 2025. dumas-05384135

HAL Id: dumas-05384135

https://dumas.ccsd.cnrs.fr/dumas-05384135v1

Submitted on 26 Nov 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
ÉCOLE NATIONALE DES CHARTES
UNIVERSITÉ PARIS, SCIENCES & LETTRES

Mélina Conter

licencié.e ès histoire de l'art et archéologie
diplômé.e de master muséologie

# L'Alignement des données avec
Wikidata dans les institutions
culturelles

## Le cas des entités personnes et institutions au
musée d'Orsay

Mémoire pour le diplôme de master
« Technologies numériques appliquées à l'histoire »

2025
<figure><img src="image_2.png" /></figure>
# Résumé

**En français** Wikidata naît dans les années 2010, en plein enthousiasme pour les technologies du Web de données et pour le mouvement de l'Open Data. Ce mémoire s'attache à expliquer son rôle, aujourd'hui central, aussi bien au sein de l'écosystème Wikimédia que dans l'ouverture et l'échange des données culturelles et scientifiques. Il donne les différentes étapes clés dans la conception d'un processus d'alignement de données institutionnelles avec Wikidata : l'analyse de l'état des données et le mapping, la génération de propositions d'alignement ainsi que l'élaboration d'une méthode de validation. Enfin, il aborde les enjeux de pérennisation de ces alignements ainsi que les possibilités qu'ils offrent pour l'institution et le monde de la recherche. Pour cela, il s'appuie sur l'exemple du projet d'alignement du musée d'Orsay réalisé lors d'un stage.

**In english** Wikidata emerged in the 2010s, during a period of strong enthusiasm for Web of Data technologies and the Open Data movement. This thesis aims to explain its current central role, both within the Wikimedia ecosystem and in the sharing and opening of cultural and scientific data. It outlines the key steps in designing a process for aligning institutional data with Wikidata : analyzing the state of the data and performing the mapping, generating alignment proposals, and developing a validation method. Finally, it discusses the challenges of sustaining these alignments and the opportunities they offer for institutions and the research community. To illustrate this, it draws on the example of the data alignment project carried out at the Musée d'Orsay during an internship.

**Mots-clés** : musée d'Orsay ; EPMO ; alignement ; Wikidata ; Web de données ; référentiel ; interopérabilité ; institution culturelle ; institution patrimoniale ; gouvernance des données ; graphe de connaissance ; mapping.

**Informations bibliographiques** : Mélina Conter, *L'Alignement des données avec Wikidata dans les institutions culturelles. Le cas des entités personnes et institutions au musée d'Orsay*, mémoire de master « Technologies numériques appliquées à l'histoire », dir.
Lauryne Lemosquet, École nationale des chartes, 2025.
Remerciements

M
Es remerciements vont tout d'abord à mon tuteur de stage et ma tutrice de mémoire, Be-
noit Deshayes et Lauryne Lemosquet, qui m'ont pleinement soutenue et accompagnée
dans ma réflexion et la rédaction de ce mémoire. Je tiens également à remercier les équipes
du SDPN et de la documentation du musée d'Orsay ainsi que celle du pôle de préfiguration
du centre de ressources et de recherche Daniel Marchesseau pour leur accueil chaleureux et
nos échanges passionnants sur leur expérience, leurs missions et les enjeux qu'ils rencontrent
dans leur métier. J'aimerai aussi remercier mon compagnon, Pierre-Louis Calatayud, ma fa-
mille et mes amis qui ont été un profond soutien pour poursuivre la rédaction de ce mémoire
malgré certaines péripéties malheureuses de la vie.
<figure><img src="image_3.png" /></figure>
# Bibliographies thématiques

## Wikidata

* « Freebase (web) », Wikipédia (), URL : https://fr.wikipedia.org/w/index.php?title=Freebase_(web)&oldid=213070377 (visité le 31/08/2025).

* GLAM/Metadata standards and Wikimedia — Meta, URL : https://meta.wikimedia.org/wiki/GLAM/Metadata_standards_and_Wikimedia (visité le 14/08/2025).

* Help :Dates - Wikidata, URL : https://www.wikidata.org/wiki/Help:Dates (visité le 14/08/2025).

* Help :Deduplication — Wikidata, URL : https://www.wikidata.org/w/index.php?title=Help:Deduplication (visité le 04/09/2025).

* LAPÔTRE (Raphaëlle) et DESHAYES (Benoît), Utilisation de data.bnf.fr pour alimenter Wikidata (SemWeb.Pro), Paris, FIAP Jean Monnet, nov. 2015.

* LINK (Copy), EMAIL, X, LINKEDIN, FACEBOOK, LINE, REDDIT, QZONE, WEIBO (Sina), WECHAT, et al., Automatic transliteration can help Alexa find data across language barriers, août 2018, URL : https://www.amazon.science/blog/automatic-transliteration-can-help-alexa-find-data-across-language-barriers (visité le 31/08/2025).

* NEUBERT (Joachim), « Wikidata as a linking hub for knowledge organization systems? », dans Proceedings of the 17th European Networked Knowledge Organization Systems Workshop co-located with the 21st International Conference on Theory and Practice of Digital Libraries 2017 (TPDL 2017), Thessalonique, Grèce, 2017, t. 1937, URL : https://ceur-ws.org/Vol-1937/paper2.pdf.

* ODELL (Jere), LEMUS-ROJAS (Mairelys) et BRYS (Lucille), « Wikidata and Gender Equity in Publishing », Wikidata for Scholarly Communication Librarianship (, juill. 2022), DOI : 10.7912/8spa-6s68.

* « Production participative », Wikipédia (), URL : https://fr.wikipedia.org/w/index.php?title=Production_participative&oldid=225084894 (visité le 23/08/2025).
* *Smithsonian Libraries and Archives & Wikidata : Adding Artist Files to Wikidata* - Smithsonian Libraries and Archives / Unbound, URL: https://blog.library.si.edu/blog/2022/05/18/wikidata-artists-files/ (visité le 18/05/2025).

* *SPARQL/Wikidata Query Service* — Wikibooks, URL: https://en.wikibooks.org/wiki/SPARQL/Wikidata_Query_Service (visité le 22/08/2025).

* *Statistics - Wikidata*, URL: https://www.wikidata.org/wiki/Special:Statistics (visité le 31/08/2025).

* *Template :Ancient world properties* — Wikidata, URL: https://www.wikidata.org/wiki/Template:Ancient_world_properties (visité le 22/08/2025).

* V.RANDEČIĆ (Denny), PINTSCHER (Lydia) et KRÖTZSCH (Markus), « Wikidata : The Making Of », dans *Companion Proceedings of the ACM Web Conference 2023*, New York, NY, USA, 2023 (WWW ’23 Companion), p. 615-624, DOI: 10.1145/3543873.3585579.

« Wikibase », *Wikipedia* (), URL: https://en.wikipedia.org/w/index.php?title=Wikibase&oldid=1300524437 (visité le 22/08/2025).

« Wikidata », *Wikipédia* (), URL: https://fr.wikipedia.org/w/index.php?title=Wikidata&oldid=225737951 (visité le 28/06/2025).

« Wikidata », *Wikipedia* (), URL: https://en.wikipedia.org/w/index.php?title=Wikidata&oldid=1310468402 (visité le 10/09/2025).

* *Wikidata :External identifiers* — Wikidata, URL: https://www.wikidata.org/wiki/Wikidata:External_identifiers (visité le 13/08/2025).

* *Wikidata :Glossaire* — Wikidata, URL: https://www.wikidata.org/wiki/Wikidata:Glossary/fr (visité le 31/08/2025).

* *Wikidata :service des requêtes SPARQL/optimisation de la requête* — Wikidata, URL: https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/query_optimization/fr (visité le 22/08/2025).

* *Wikidata :Utilisateurs autoconfirmés* — Wikidata, URL: https://www.wikidata.org/wiki/Wikidata:Autoconfirmed_users/fr (visité le 05/09/2025).

* XU (Silei), LIU (Shicheng), CULHANE (Theo), PERTSEVA (Elizaveta), WU (Meng-Hsi), SEMNANI (Sina J.) et LAM (Monica S.), *Fine-tuned LLMs Know More, Hallucinate Less with Few-Shot Sequence-to-Sequence Semantic Parsing over Wikidata*, nov. 2023, DOI: 10.48550/arXiv.2305.14202, arXiv: 2305.14202 [cs].

# Le Web et le Web Sémantique

*About us*, URL: https://www.w3.org/about/ (visité le 08/09/2025).
BERMÈS (Emmanuelle), « Convergence et interoperabilité : l’apport du web de données », dans *77e congrès de l’IFLA*, Puerto Rico, 2011, URL : http://conference.ifla.org/past/ifla77/149-bermes-fr.pdf (visité le 23/07/2025).

BERMÈS (Emmanuelle), ISAAC (Antoine) et POUPEAU (Gautier), « 2. Convergence et interoperabilité : vers le Web de données », *Bibliothèques* (, 2013), p. 29-46, URL : https://shs.cairn.info/le-web-semantique-en-bibliotheque--9782765414179-page-29 (visité le 21/08/2025).

— *Le Web sémantique en bibliothèque*, 2013, DOI : 10.3917/elec.berm.2013.01.

BERNERS-LEE (Tim), HENDLER (James) et LASSILA (Ora), « The Semantic Web », *Scientific American*, 284-5 (2001), p. 34-43, JSTOR : 26059207, URL : https://www.jstor.org/stable/26059207 (visité le 27/08/2025).

*Interface de programmation d'application (API)*, URL : https://www.cnil.fr/fr/definition/interface-de-programmation-dapplication-api (visité le 24/08/2025).

*Linked Data - Design Issues*, URL : https://www.w3.org/DesignIssues/LinkedData.html (visité le 01/09/2025).

*Schema.org - Schema.org*, URL : https://schema.org/ (visité le 01/09/2025).

*Web sémantique et modèle de données*, URL : https://data.bnf.fr/fr/semanticweb (visité le 28/08/2025).

## Alignements et méthodologie

*Aide :QuickStatements* — *Wikidata*, URL : https://www.wikidata.org/wiki/Help:QuickStatements/fr (visité le 05/09/2025).

DESHAYES (Benoit), *Alignement des entités artistes pour le site des Collections du musée du Louvre / Janus*, juin 2021, URL : https://meta.wikimedia.org/wiki/Webinaire_wiki,_data_et_GLAM_2021/Programme/R%C3%A9sum%C3%A9s_des_interventions (visité le 29/07/2025).

« OpenRefine », *Wikipédia* (), URL : https://fr.wikipedia.org/w/index.php?title=OpenRefine&oldid=210052560 (visité le 14/08/2025).

*OpenRefine Reconciliation Services / OpenRefine Wikibase* · *GitLab*, oct. 2024, URL : https://gitlab.com/nfdi4culture/openrefine-reconciliation-services/openrefine-wikibase (visité le 24/08/2025).

*OpenRefine user manual / OpenRefine*, déc. 2022, URL : https://openrefine.org/docs (visité le 24/08/2025).

*QuickStatements 3.0 - Meta-Wiki*, URL : https://meta.wikimedia.org/wiki/QuickStatements_3.0 (visité le 05/09/2025).
*Reconcilable Data Sources*, URL: https://github.com/OpenRefine/OpenRefine/wiki/Reconcilable-Data-Sources (visité le 17/08/2025).

*Reconciling with Wikibase | OpenRefine*, déc. 2023, URL: https://openrefine.org/docs/manual/wikibase/reconciling (visité le 17/08/2025).

*Scoring mechanism — OpenRefine-Wikibase reconciliation interface 1.0 documentation*, URL: https://openrefine-wikibase.readthedocs.io/en/latest/scoring.html (visité le 24/08/2025).

*Welcome to the documentation of the OpenRefine-Wikibase reconciliation interface — OpenRefine-Wikibase reconciliation interface 1.0 documentation*, URL: https://openrefine-wikibase.readthedocs.io/en/latest/index.html (visité le 24/08/2025).

# Données : ouverture, gouvernance, modèles et référentiels

*A propos de data.bnf.fr*, URL: https://data.bnf.fr/fr/about (visité le 28/08/2025).

*À propos de data.gouv.fr*, URL: https://www.data.gouv.fr/pages/about/a-propos_data-gouv/ (visité le 07/09/2025).

*Accueil - Agorha*, URL: https://agorha.inha.fr/ (visité le 27/08/2025).

*Analyse des tendances Médias par l'IA - Les traitements réalisés par les outils d'intelligence artificielle utilisés sur data.ina.fr | data.ina.fr*, URL: https://data.ina.fr/traitements-ia (visité le 13/08/2025).

*Analyse des tendances Médias par l'IA - Règles générales et méthodologies pour calculer ces résultats | data.ina.fr*, URL: https://data.ina.fr/regles-generales (visité le 12/08/2025).

*BARYLA (Christiane), Thésaurus iconographique*, Text, janv. 1985, URL: https://bbf.enssib.fr/consulter/bbf-1985-02-0180-002 (visité le 26/08/2025).

*Bienvenue sur le site de la Transition bibliographique*, URL: https://www://www://www://www.transitio-bibliographique.fr/ (visité le 22/08/2025).

*CHALLON (Maxime), Les référentiels en institutions patrimoniales : évolution des pratiques et repositionnement. L'exemple des référentiels de l'Institut National de l'Audiovisuel, mémoire de master « Technologies numériques appliquées à l'histoire », École nationale des chartes, 2020.*

*CONGRESS (The Library of Congress), Library of Congress Names - LC Linked Data Service: Authorities and Vocabularies | Library of Congress, from LC Linked Data Service: Authorities and Vocabularies*
*Vocabularies (Library of Congress)*, webpage, URL : https://id.loc.gov/authorities/names.html (visité le 26/08/2025).

*Définitions et concepts – Science Ouverte Université Grenoble Alpes*, URL : https://scienceouverte.univ-grenoble-alpes.fr/donnees/stocker/definitions-concepts/ (visité le 04/09/2025).

*Dublin Core*, URL : https://www.bnf.fr/fr/dublin-core (visité le 01/09/2025).

*Echanger les données culturelles : profil d'application LIDO-MC | Ministère de la Culture*, juin 2014, URL : https://www.culture.gouv.fr/fr/thematiques/innovation-numerique/faciliter-1-acces-aux-donnees-et-aux-contenus-culturels/partager-et-valoriser-les-donnees-et-les-contenus-culturels/echanger-les-donnees-culturelles-profil-d-application-lido-mc (visité le 01/09/2025).

*Europeana Data Model Primer*, mars 2013.

*Evaluer le niveau de qualité d'un jeu de données | Guides de data.gouv.fr*, sept. 2024, URL : https://guides.data.gouv.fr/guides-open-data/guide-qualite/evaluer-le-niveau-de-qualite-dun-jeu-de-donnees (visité le 05/09/2025).

« Format MARC », *Wikipédia* (), URL : https://fr.wikipedia.org/w/index.php?title=Format_MARC&oldid=223562358 (visité le 26/08/2025).

*GOËTA (Samuel)*, « Les grandes étapes de la définition des principes de l'open data », dans *Les données de la démocratie. Open data, pouvoirs et contre-pouvoirs*, 2024 (Société numérique), p. 59-80, URL : https://shs.cairn.info/les-donnees-de-la-democratie--9782376620716-page-59 (visité le 31/08/2025).

— « Les racines multiples de l'open data », dans *Les données de la démocratie. Open data, pouvoirs et contre-pouvoirs*, 2024 (Société numérique), p. 28-57, URL : https://shs.cairn.info/les-donnees-de-la-democratie--9782376620716-page-28 (visité le 31/08/2025).

*Home / CIDOC CRM*, URL : https://cidoc-crm.org/ (visité le 21/08/2025).

*INSTITUT NATIONAL D'HISTOIRE DE L'ART (INHA), #LundisNum | 11 février 2019* - *Gautier Poupeau : rassembler les métadonnées des collections de l'INA*, févr. 2025, URL : https://www.youtube.com/watch?v=KYOzoRPks8Q (visité le 22/08/2025).

*Loi n° 78-753 du 17 juillet 1978 portant diverses mesures d'amélioration des relations entre l'administration et le public et diverses dispositions d'ordre administratif, social et fiscal*, juill. 1978, URL : https://www.legifrance.gouv.fr/loda/id/JORFTEXT000000339241 (visité le 19/07/2025).

*MESGUICH (Véronique)*, *Les bibliothèques face au monde des données*, Villeurbanne, 2023 (Papiers).
MINISTÈRE DE LA CULTURE, *Ouverture des données publiques culturelles : guide pratique*,
2019.

*Modèle de langage*, URL : https://www.cnil.fr/fr/definition/modele-de-langage
(visité le 31/08/2025).

OPEN KNOWLEDGE FOUNDATION, *Manuel de l'Open Data*, URL : https://opendatahandbook.org/guide/fr/ (visité le 19/07/2025).

*Politique de qualité des données* | BnF - Site institutionnel, URL : https://www.bnf.fr/fr/politique-de-qualite-des-donnees (visité le 13/08/2025).

POUPEAU (Gautier), « La donnée : nouvelle perspective pour les bibliothèques », dans *Vers de nouveaux catalogues*, 2016, p. 159-171, DOI : 10.3917/elec.berme.2016.01.0159.

— « Le « lac de données », une infrastructure technique pour déployer la gouvernance des données à l'Ina », dans *Les nouveaux paradigmes de l'archive*, dir. Claire Scopsi, Clothilde Roullier, Martine Sin Blima-Barru et Édouard Vasseur, *Pierrefitte-sur-Seine*, 2024 (Actes), DOI : 10.4000/books.pan.7253.

*Qu'est-ce que le modèle IFLA LRM?*, URL : https://www transition-bibliographique.fr/enjeux/definition-ifla-lrm/ (visité le 26/08/2025).

*Records in Contexts : un nouveau modèle de description archivistique*, URL : https://francearchives.gouv.fr/fr/article/334841641 (visité le 26/08/2025).

*Reg-Arts*, URL : https://regarts.huma-num.fr/ (visité le 06/09/2025).

*Reg Arts : À propos*, URL : https://regarts.huma-num.fr/a-propos (visité le 06/09/2025).

Règlement (UE) 2022/868 du Parlement européen et du Conseil du 30 mai 2022 portant sur la gouvernance européenne des données et modifiant le règlement (UE) 2018/1724 (règlement sur la gouvernance des données) (Texte présentant de l'intérêt pour l'EEE), mai 2022, URL : http://data.europa.eu/eli/reg/2022/868/oj/fra (visité le 22/08/2025).

SERDA CONSEIL, *Rapport de la gouvernance de l'information numérique, des datas et de l'IA*,
rapp. tech. 14e, 2025, p. 56, URL : https://www.calameo.com/read/004059613353fdba67430?authid=d1nnc9jqNx9p (visité le 28/06/2025).

*The relational database* | IBM, URL : https://www.ibm.com/history/relational-database (visité le 27/08/2025).

VAN 'T ZELFDE (Reinier) et VERHEUSEN (Astrid), *RKD Research The Digital Hub for Art Historical Research*, text, juin 2024, URL : https://www.enssib.fr/bibliothekenumerique/notices/73130-rkd-research-the-digital-hub-for-art-historical-research (visité le 20/07/2025).

*VIAF : accès facile à des fichiers d'autorités de noms*, nov. 2024, URL : https://www.oclc.org/fr/viaf.html (visité le 01/09/2025).
*What is LIDO?*, URL: https://cidoc.mini.icom.museum/working-groups/lido/lido- overview/about-lido/what-is-lido/ (visité le 21/08/2025).

## Le Musée d'Orsay

*Article R422-1 - Code du patrimoine*, URL: https://www.legifrance.gouv.fr/codes/ articleLC/LEGIARTI000042982266 (visité le 20/08/2025).

*Article R422-2 - Code du patrimoine*, URL: https://www.legifrance.gouv.fr/codes/ articleLC/LEGIARTI000046359267 (visité le 20/08/2025).

*Base salons*, URL: https://salons.musee-orsay.fr/ (visité le 06/09/2025).

CARLIER (Sylvie), *Quelles ressources documentaires actuelles pour une base de données artistes? L'exemple du musée d'Orsay*. mémoire d'étude pour le diplôme de conservateur de bibliothèque, Ecole Nationale Supérieure des Sciences de l'Information et des Bibliothèques, 1998.

CARS (Laurence des), COZ (Françoise le) et JULÉ (Sylvie), « A New Professional Application at the Musée d'Orsay (Paris) », dans *International Cultural Heritage Informatics Meeting : Proceedings from ICHIM 2001. Politechnico di Milano, Milan, Italy, September 3-7, 2001 - Volume 1 : Full Papers*, dir. David Bearman et Franca Garzotto, 2001, p. 573-580, URL : https://www.archimuse.com/publishing/ichim01_vol1/cars.pdf.

Décret n° 2003-1300 du 26 décembre 2003 portant création de l'Etablissement public du musée d'Orsay, déc. 2003, URL : https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000000611798 (visité le 20/08/2025).

Décret n° 2010-558 du 27 mai 2010 relatif à l'Etablissement public du musée d'Orsay et du musée de l'Orangerie, mai 2010, URL : https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000022272160 (visité le 20/08/2025).

ÉTABLISSEMENT PUBLIC DES MUSÉES D'ORSAY ET DE L'ORANGERIE, *Rapport d'activité 2018*, 2018.

JULÉ (Sylvie) et MODIRI (Elsa Badie), « Changer de système de gestion des collections au musée d'Orsay : un vrai défi! », dans *Documenter les collections de musées*, 2016, p. 141-144, DOI : 10.3917/ldf.merle.2016.01.0141.

*Le Centre de ressources et de recherche Daniel Marchesseau*, mai 2025, URL : https:// www.epmo-musees.fr/fr/le-centre-de-ressources-et-de-recherche-daniel-marchesseau (visité le 16/05/2025).

*Le musée d'Orsay et ses collections*, URL : https://www.epmo-musees.fr/fr/le-musee-dorsay-et-ses-collections (visité le 11/08/2025).
LOI n° 2002-5 du 4 janvier 2002 relative aux musées de France, janv. 2002, URL : https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000000769536/ (visité le 21/06/2025).

« Microsoft SQL Server », Wikipédia (), URL : https://fr.wikipedia.org/w/index.php?title=Microsoft_SQL_Server&oldid=228343551 (visité le 24/08/2025).

Mix'n'match, URL : https://mix-n-match.toolforge.org/#/catalog/118 (visité le 01/09/2025).

Paragraphe unique : Normes techniques relatives à la tenue de l'inventaire et du registre des dépôts (Articles D451-16 à D451-21), mai 2011, URL : https://www.legifrance.gouv.fr/codes/section_lc/LEGITEXT000006074236/LEGISCTA000024240927/#LEGISCTA000024240927 (visité le 20/08/2025).

Répertoire des artistes et personnalités | Musée d'Orsay, URL : https://www.musee-orsay.fr/fr/ressources/repertoire-artistes-personnalites (visité le 01/09/2025).
# Introduction

« Le recensement des sites sur Internet et des bases de données françaises et étrangères fait apparaître la nécessité d'un travail fondé sur la coopération et l'échange d'informations. En effet, tous ces établissements constituant des bases ont besoin d'un ensemble de données qu'aucun n'est en mesure d'élaborer dans sa totalité à un niveau suffisant, alors même que d'autres établissements similaires possèdent une partie de ces données et ont des besoins et insuffisances analogues. »

C'est sur ce constat que s'est construit le mémoire de 1998 de Sylvie Carlier, élève à l'ENS-SIB<fnref n="1" />, proposant des réflexions de développement pour les bases de données documentaires du musée d'Orsay. Cette réflexion s'inscrit dans une période où un des enjeux majeurs est le partage des informations documentaires au sein des réseaux institutionnels. Si l'utilisation du Web se démocratise déjà, c'est l'avènement du Web sémantique et du Web de données dans les années 2000 qui bouleversera fortement les pratiques documentaires et le rapport des institutions à leurs données en répondant en partie à ce besoin de partage. Poussées par l'enthousiasme pour ces nouvelles technologies et le mouvement d'ouverture des données, des initiatives coopératives de mise en commun de la connaissance naissent. Parmi celles-ci, Wikidata, mis en ligne en 2012, devient rapidement une passerelle incontournable pour créer ces ponts entre des jeux de données ou des ressources scientifiques et culturelles. La plateforme incarne aujourd'hui non seulement une base de données transversale mais aussi un facilitateur pour ce « travail fondé sur la coopération et l'échange d'informations »<fnref n="2" />. La création de ces liens nécessite systématiquement la mise en place d'un processus d'alignement qui recouvre les étapes suivantes :

- « identifier les points de contacts entre son jeu de données et ceux qui existent par ailleurs ;

- déterminer précisément la nature du lien entre ses entités et celles du jeu de données avec lequel [on] veut se relier ;

<footnote n="1">1. École Nationale Supérieur des Sciences de l'Information et des Bibliothèques</footnote>

<footnote n="2">2. Sylvie Carlier, *Quelles ressources documentaires actuelles pour une base de données artistes?*
*L'exemple du musée d'Orsay*. mémoire d'étude pour le diplôme de conservateur de bibliothèque, Ecole Nationale Supérieure des Sciences de l'Information et des Bibliothèques, 1998, Résumé du mémoire.</footnote>
— et mettre au point la meilleure méthode pour créer ces liens, manuellement
ou automatiquement » <fnref n="3" />

C'est dans ce cadre que le musée d'Orsay a choisi de réaliser un projet d'alignement concernant les entités personnes et institutions de sa base de données actuelle avec la base de données Wikidata. Une grande partie de ces entités est publiée dans le Répertoire des artistes et personnalités <fnref n="4" />, accessible en ligne. Un premier alignement a déjà été réalisé à partir de 2014, à l'initiative de la communauté de Wikidata à partir des entités publiées sur le répertoire via l'outil Mix'n'Match <fnref n="5" />. Les résultats visibles sur la plateforme représentent aujourd'hui environ trente-sept mille entités alignées sur la base. Bien que le jeu de données extrait des pages du répertoire public soit régulièrement mis à jour depuis le lancement du projet, ces mises à jour ne sont pas systématiques ni régulières. De plus, le musée d'Orsay a pour ambition un alignement qui comprend également les entités non publiées. Le projet consistera donc en la réalisation d'un processus interne au musée, en bénéficiant de l'expertise du personnel scientifique de la documentation et de la conservation.

Ce mémoire a été réalisé dans le cadre d'un stage au musée d'Orsay, dans la direction de la conservation et des collections <fnref n="6" />, au sein du Service des Données Patrimoniales et Numériques (SDPN) <fnref n="7" />. Le service a pour mission la gestion de la base principale des collections, de la médiathèque, l'accompagnement des projets d'édition numérique, des projets de valorisation numérique des collections et des activités scientifiques du musée. La création officielle du service remonte à 2018 <fnref n="8" /> dans le cadre de la préfiguration du Centre de ressource et de recherche Daniel Marchesseau et de la valorisation de ces ressources documentaires <fnref n="9" />.

Ainsi ce mémoire s'attachera à étudier les enjeux rencontrés par les institutions cultu-
relles et patrimoniales dans l'alignement de données avec Wikidata, en s'appuyant sur l'exemple
de l'alignement des entités personnes et institutions au musée d'Orsay. Pour cela, il décrira
tout d'abord le contexte dans lequel Wikidata est devenu une passerelle incontournable entre
les référentiels institutionnels, puis il expliquera les différentes étapes de la mise en place
d'un processus d'alignement avec cette plateforme. Enfin, il montrera comment rendre ces

<footnote n="3">3. Emmanuelle Bermès, Antoine Isaac et Gautier Poupeau, *Le Web sémantique en bibliothèque*, 2013, DOI: 10.3917/elec.berm.2013.01, pp.104-105.</footnote>

<footnote n="4">4. *Répertoire des artistes et personnalités / Musée d'Orsay*, URL : https://www.musee-orsay.fr/fr/resources/repertoire-artistes-personnalites (visité le 01/09/2025).</footnote>

<footnote n="5">5. *Mix'n'match*, URL : https://mix-n-match.toolforge.org/#/catalog/118 (visité le 01/09/2025).</footnote>

<footnote n="6">6. Voir annexe B, section I.</footnote>

<footnote n="7">7. Voir annexe B, section II.</footnote>

<footnote n="8">8. Appelé d'abord « Pôle de données patrimoniales digitales » - Établissement public des musées d'Orsay et de l'Orangerie, *Rapport d'activité 2018*, 2018, p.24.</footnote>

<footnote n="9">9. Le Centre de ressources et de recherche Daniel Marchesseau, mai 2025, URL : https://www.epmo-musees.fr/fr/le-centre-de-ressources-et-de-recherche-daniel-marchesseau (visité le 16/05/2025).</footnote>
alignements pérennes et leur utilité au sein d'une institution.
<figure><img src="image_4.png" /></figure>
# Première partie

## Wikidata : une concrétisation du Web de données pour les institutions patrimoniales et culturelles
<figure><img src="image_5.png" /></figure>
Cette première partie retrace la manière dont les institutions culturelles sont passées de
systèmes documentaires centrés sur les référentiels et les notices à des environnements ouverts
et interopérables. L'informatisation a entraîné la mise en place de normes et de modèles adap-
tés à chaque domaine, puis les besoins de mutualisation ont favorisé l'émergence de formats
communs, de protocoles d'échanges et d'agrégateurs. Avec l'arrivée du Web sémantique et du
Web de données, l'attention s'est déplacée des documents vers les entités et leurs relations,
ouvrant la voie à de nouvelles pratiques de valorisation et de circulation des données. C'est
dans ce contexte d'évolution et d'ouverture qu'apparaît Wikidata, conçu comme un hub <fnref n="10" />
d'identifiants et un graphe de connaissances collaboratif pour les institutions culturelles et
patrimoniales.

<footnote n="10">10. Voir Chapitre 3, section II.</footnote>
# Chapitre 1

## L'Évolution des pratiques documentaires et de valorisation de la donnée en institutions culturelles et patrimoniales

Pour remplir leurs missions, les institutions culturelles et patrimoniales se reposent avant tout sur leur système documentaire, au cœur de leurs activités. Ce chapitre en décrira les éléments fondamentaux et l'évolution des pratiques documentaires liées à l'informatisation et la création des réseaux d'institutions.

### I. Les référentiels et la notice documentaire : les fondations des systèmes documentaires en institutions culturelles

Un système documentaire est un ensemble organisé de méthodes, d'outils et de processus permettant de créer, gérer, stocker, diffuser et archiver des documents (physiques ou numériques) au sein d'une organisation. Il vise à structurer, sécuriser et optimiser l'accès à l'information pour répondre aux besoins opérationnels, réglementaires et stratégiques d'une entreprise ou d'une institution. Dans le cadre des institutions culturelles ou patrimoniales, ces systèmes reposent essentiellement sur deux principes : l'élaboration d'un référentiel et la création de notices documentaires.

Les référentiels aident à structurer le système documentaire en définissant des clés
qui permettent d'associer de manière contrôlée des termes aux documents, ressources et
objets gérés par l'institution. Ces clés permettent alors une description et une indexation
méthodologique des ressources, documents ou objets conservés par l'institution en respectant
un vocabulaire normalisé. Elles en facilitent la recherche et l'accessibilité par leur uniformité
et sont communément désignées sous le terme de vocabulaire contrôlé. Ces vocabulaires, dans
leur forme la plus simple, consistent en une liste de termes choisis, normés et contrôlés.

Les vedettes, très utilisées dans le monde des bibliothèques, représentent un exemple très commun de l'application d'un vocabulaire contrôlé. Elles ont d'abord pris la forme de fiches ou de catalogues et étaient catégorisées selon le type de clé qu'elles désignent. Par exemple, une vedette-auteur permet de retrouver les ouvrages à partir du nom de son auteur et une vedette-matière permet de décrire un concept ou sujet abordé par les documents de l'institution. Il est arrivé qu'elles présentent également, pour des raisons de praticité face à un vocabulaire très extensif, des renvois vers les autres formes acceptées d'un terme.

Un plan de classement, que ce soit en documentation muséale ou en archives, peut aussi constituer un reflet du référentiel de l'institution. Par exemple, le classement peut suivre le vocabulaire employé pour les toponymes, pour les noms d'artistes ou bien encore pour les producteurs des fonds en fonction des usages. L'informatisation progressive du milieu de l'information et de la documentation à partir du milieu du XXᵉ siècle apporte également deux nouveaux concepts à la constitution d'un référentiel : la notice d'autorité et le thésaurus.

La notice d'autorité représente, contrairement à la vedette, la description du concept
au-delà de l'indication de sa graphie normée et retenue par le référentiel. Elle indique non
seulement la vedette du terme retenu mais exposera aussi les formes rejetées (synonymes,
variantes ou abréviations) et des informations complémentaires telles que des dates, des défi-
nitions ou une re-contextualisation du terme. Elle prend ainsi en charge la désambiguïsation
des concepts représentés dans le vocabulaire contrôlé en renvoyant, pour des concepts dont
la sémantique est proche, vers les notices et vedettes dédiées. Ces notices sont regroupées
dans des fichiers d'autorité comme celui de la Bibliothèque du Congrès aux États-Unis<fnref n="1" />. Le
thésaurus est une autre forme de vocabulaire contrôlé qui se développe dans les années 1950²
et qui est adopté massivement avec l'informatisation. Il instaure des relations entre les termes
normalisés qui peuvent être de différentes natures :

— Les relations hiérarchiques : par exemple, d'un concept général à un concept plus

<footnote n="1">1. The Library of Congress, *Library of Congress Names - LC Linked Data Service : Authorities and Vocabularies* | Library of Congress, from LC Linked Data Service : Authorities and Vocabularies (Library of Congress), webpage, URL : https://id.loc.gov/authorities/names.html (visité le 26/08/2025).</footnote>

<footnote n="2">2. Maxime Challon, *Les référentiels en institutions patrimoniales : évolution des pratiques et repositionnement. L'exemple des référentiels de l'Institut National de l'Audiovisuel*, mémoire de master « Technologies numériques appliquées à l'histoire », École nationale des chartes, 2020, p.20.</footnote>
précis

— Les relations d'équivalence : les synonymes, variante de graphie, abréviations...

— Les relations associatives : indication d'une proximité sémantique entre deux termes
Ces relations permettent de mieux illustrer la complexité des termes spécifiques au domaine
décrit par le vocabulaire et donc d'assurer une plus grande fluidité et logique entre les nuances
du langage naturel et le vocabulaire restreint du référentiel.

Les référentiels sont conçus, alimentés et enrichis à l'échelle de chaque institution via l'évolution de leurs missions et de leur périmètre documentaire. Par conséquent, du fait de leur nature, les vocabulaires contrôlés qui en découlent décrivent des domaines précis et souvent propres aux institutions qui les ont créés. Ils n'ont donc pas pour vocation première de servir en-dehors de leur cadre original. « Seulement, deux institutions aux activités proches créent deux vocabulaires similaires, se distinguant par la complétude de certaines vedettes ou par des variantes de graphies. » <fnref n="3" />. Il arrive aussi qu'un référentiel originellement conçu par une institution ou dans le cadre d'un projet de recherche soit emprunté ou réapproprié par une institution dont le périmètre documentaire se recoupe avec le domaine ou les disciplines abordées. C'est le cas du thésaurus Garnier, originellement conçu en 1976, à la demande du Ministère de la Culture <fnref n="4" />, dans le cadre de l'inventaire général des monuments et des richesses artistiques de France <fnref n="5" /> afin de créer un référentiel normalisé dédié à l'iconographie des représentations figurées sous la forme d'un thésaurus. De par sa grande richesse, précision et complexité, il est utilisé dans des musées, comme c'est le cas pour les collections du département des Sculptures du musée du Louvre <fnref n="6" />. Il est également employé par l'Institut National d'Histoire de l'Art (INHA) dans le cadre de sa plateforme Aghora <fnref n="7" /> qui a développé une version adaptée à l'indexation de leurs ressources et documents concernés.

Les systèmes documentaires des institutions culturelles ou patrimoniales reposent également sur le principe de notice documentaire visant à décrire, de façon structurée, une

<footnote n="3">3. *Ibid.*, p.10.</footnote>

<footnote n="4">4. Christiane Baryla, *Thésaurus iconographique*, Text, janv. 1985, URL : https://bbf.enssib.fr/consulter/bbf-1985-02-0180-002 (visité le 26/08/2025).</footnote>

<footnote n="5">5. « [...] désigné couramment comme Inventaire général ou même simplement inventaire, est un service national créé par décret du 4 mars 1964 sur l'initiative d'André Malraux et d'André Chastel. L'Inventaire général a pour mission de "recenser, étudier et faire connaître les éléments du patrimoine qui présentent un intérêt culturel, historique ou scientifique". » - « Inventaire général du patrimoine culturel », *Wikipédia* (), URL : https://fr.wikipedia.org/w/index.php?title=Inventaire_g%C3%A9n%C3%A9ral_dueoratrimoine_culturel&oldid=227424402 (visité le 26/08/2025).</footnote>

<footnote n="6">6. D'après l'expérience personnelle de l'autrice de ce mémoire.</footnote>

<footnote n="7">7. « AGORHA donne un accès unifié aux bases de données produites par l'INHA et ses partenaires. Ces données sont issues de programmes de recherche scientifique en histoire de l'art et archéologie. La plateforme se développe continuellement, témoignant de la diversité des problématiques de ces disciplines. » - *Accueil - Agorha*, URL : https://agorha.inha.fr/ (visité le 27/08/2025).</footnote>
ressource, un document ou un objet géré par l'institution afin de pouvoir l'identifier. Elle résulte généralement d'un travail de classement, de catalogage ou d'inventaire des collections de l'institution. Les informations qu'elle comporte varient selon le domaine de l'institution et la nature des documents ou objets décrits. Elle présentera généralement :

- un identifiant unique (cote, numéro d'inventaire)

- une description bibliographique ou matérielle (title, author, date, support, dimensions, support, technique, agencement etc.)

- des informations contextuelles comme par exemple la provenance, les conditions d'accès, les droits d'utilisation, ses liens avec les autres notices etc.

- des éléments d'indexation provenant généralement du référentiel institutionnel (vedettes-matière, thésaurus, listes)

Traditionnellement, en musée, ce principe se traduit par la notice d'œuvre, en bibliothèque par la notice bibliographique et en archive il peut se rapprocher d'un instrument de recherche décrivant un fond ou une unité documentaire. La notice documentaire permet non seulement d'identifier mais aussi d'assurer la conservation et de permettre le repérage du document, de la ressource ou de l'objet concerné. Lors de l'informatisation des systèmes documentaires, les informations contenues dans la notice documentaire seront alors qualifiées de métadonnées 8 . Ces métadonnées sont généralement catégorisées en plusieurs types :

- « **Métadonnées descriptives** : servent à décrire une ressource à des fins de compréhension, découverte ou identification du contenu (par exemple : titre, auteur, indexation par des mots-clés).

- **Métadonnées techniques** : permettent d'identifier, caractériser, définir l'environnement technique des objets numériques et leur contexte de production (par exemple : la taille, les formats, l'appareil de prise de vue dans le domaine des images).

- **Métadonnées administratives (ou de gestion)** : servent à gérer la vie de l'objet numérique. Il s'agit ici d'authentifier, de définir le contexte de l'information à pérenniser ainsi que tout ce qui concerne la propriété intellectuelle : droits d'accès ou d'usage. Les métadonnées administratives garantissent l'intégrité des fichiers et le suivi de leurs éventuelles modifications.

- **Métadonnées instancielles ou structurelles** : donnent des informations sur les fichiers qui composent un document et précisent les relations qui existent entre eux. Ces métadonnées détaillent la structure d'un objet numé-

<footnote n="8">8. « Les métadonnées sont la carte d'identité d'un document. Elles permettent de l'identifier, de le décrire, d'expliquer l'origine de sa création, son utilité et ses destinataires. Au-delà de cette seule description, elles facilitent la recherche et le partage des ressources, leur préservation autant que la gestion des droits et l'authentification des documents. » - Selon le dictionnaire de l'ENSSIB.</footnote>
rique en vue de maintenir sa logique interne et de permettre son exploitation et son affichage. La structure peut être logique (par exemple, une table des matières avec des titres de chapitre) ou physique (par exemple, le support sur lequel un document numérique est enregistré).

— Métadonnées sémantiques : lorsqu'elles sont conformes à un vocabulaire standardisé ou une autorité de contrôle (par exemple, une classification, un thésaurus, une ontologie, etc.). »<fnref n="9" />

La notice documentaire et les référentiels sont donc deux concepts fondamentaux qui se complètent et permettent aux institutions l'établissement d'un système documentaire efficace répondant au besoin d'accessibilité et d'organisation de l'information ainsi que de description des collections. Ces concepts se sont traduits, lors de la transposition des systèmes documentaires vers des modèles informatiques, dans les applications métiers et les bases de données<fnref n="10" />. Au musée d'Orsay, l'application métier de gestion des collections M'Osaïque présente un fonctionnement par modules. Là où le module œuvres permet l'accès aux notices documentaires dans leur conception traditionnelle, celui sur les personnes et institutions représente une partie du vocabulaire contrôlé utilisé par l'institution.

## II. L'émergence des normes, formats et modèles communs : des réseaux et des échanges nationaux et internationaux

Avec le développement des métiers de l'information et de la documentation, les institutions culturelles sont progressivement entrées en contact via la fondation d'associations et organismes dédiés aux domaines et aux métiers. Ceux-ci ont d'abord souvent pris une échelle nationale comme l'AAF (Association des Archivistes Français), l'AAM (*American Association of Museums*) et l'ABF (Association des bibliothécaires de France) puis une échelle internationale tel que l'ICA (Conseil international des archives), l'ICOM (*International Council of Museums*) et l'IFLA (*International Federation of Library Associations and Institutions*).

Ce cadre engendre un mouvement professionnel visant l'harmonisation des pratiques métiers et la pérennité de la description des collections ou fonds conservés. De ce mouvement

<footnote n="9">9. Véronique Mesguich, *Les bibliothèques face au monde des données*, Villeurbanne, 2023 (Papiers).</footnote>

<footnote n="10">10. « La notice dite documentaire est l'adaptation au milieu informatique de la fiche cartonnée. Ce mimétisme de pratiques antérieures est caractéristique des phases d'appropriation d'un nouveau média : la notice informatique a reproduit toutes les caractéristiques de la fiche cartonnée tout en exploitant les avantages de l'outil informatique (recherche, ubiquité, échange ...). » - G. Poupeau, « La donnée : nouvelle perspective pour les bibliothèques », dans *Vers de nouveaux catalogues*, 2016, p. 159-171, DOI : 10.3917/elec.berme.2016.01.0159.</footnote>
ment découlent des chartes de déontologie, des recommandations de bonnes pratiques et des normes descriptives en ce qui concerne le contenu et la structure de la notice documentaire. L'informatisation des systèmes documentaires engendre aussi le besoin de rendre les méta-données contenues dans ces notices lisibles par les machines, ce qui pousse à l'apparition de formats qui sont souvent la transposition des normes établies plus tôt. C'est le cas par exemple de la norme ISAD(G)<fnref n="11" /> qui connaît sa traduction dans le format XML-EAD et de la norme ISBD<fnref n="12" /> avec le format MARC<fnref n="13" />.

La transition d'un système documentaire physique à un système documentaire informatisé a aussi poussé les professionnels et institutions à réfléchir à la gestion, l'organisation, la structure et la cohérence de ces nouvelles bases de données. Les premiers développements se sont appuyés sur le modèle relationnel, introduit par Edgar Frank Codd en 1970¹⁴, qui organisait l'information en tables reliées entre elles. En 1974, IBM lance le projet expérimental *System R* qui a pour objectif d'appliquer le modèle de Codd concrètement à une base de données informatique. Dans ce cadre, deux ingénieurs de l'entreprise (Donald D. Chamberlin et Raymond F. Boyce) développent le langage SQL<fnref n="15" /> qui permet d'interroger ces bases relationnelles. Le système documentaire était alors souvent transposé tel quel en créant, par exemple, une table représentant les notices documentaires et une table pour chaque type d'entités représenté dans le référentiel (auteurs, matières, lieux etc.) C'est dans ce cadre qu'émerge la conception de modèles conceptuels de données qui permet de définir les liens et la nature des liens entre les entités décrites par le référentiel et les notices documentaires en s'adaptant aux besoins propres à chaque domaine.

Ainsi, le modèle FRBR (*Functional Requirements for Bibliographic Records*)<fnref n="16" />, élaboré

<footnote n="11">11. « Norme générale et internationale de description archivistique », *Wikipédia* (), URL : https://fr.wikipedia.org/w/index.php?title=Norme_g%C3%A9n%C3%A9rale_et_internationale_de_description_archivistique&oldid=224203090 (visité le 21/08/2025).</footnote>

<footnote n="12">12. « International Standard Bibliographic Description », *Wikipédia* (), URL : https://fr.wikipedia.org/w/index.php?title=International_Standard_Bibliographic Description&oldid=224122589 (visité le 21/08/2025).</footnote>

<footnote n="13">13. « Format MARC », *Wikipédia* (), URL : https://fr.wikipedia.org/w/index.php?title=Format_MARC&oldid=223562358 (visité le 26/08/2025).</footnote>

<footnote n="14">14. *The relational database / IBM*, URL : https://www.ibm.com/history/relational-database (visité le 27/08/2025).</footnote>

<footnote n="15">15. « SQL (sigle pour Structured Query Language, "langage de requêtes structurées") est un langage informatique normalisé servant à exploiter des bases de données relationnelles. La partie langage de manipulation des données de SQL permet de rechercher, d'ajouter, de modifier ou de supprimer des données dans les bases de données relationnelles. [...] Créé en 1974, normalisé depuis 1986, le langage est reconnu par la grande majorité des Systèmes de gestion de bases de données relationnelles (SGBDR) du marché. » - « Structured Query Language », *Wikipédia* (), URL : https://fr.wikipedia.org/w/index.php?title=Structured_Query_Language&oldid=227998039 (visité le 27/08/2025).</footnote>

<footnote n="16">16. « Spécifications fonctionnelles des notices bibliographiques », *Wikipédia* (), URL : https://fr.wikipedia.org/w/index.php?title=Sp%C3%A9cifications_fonctionnelles_des_notices_bibliographiques&oldid=222724835 (visité le 26/08/2025).</footnote>
par l'IFLA dans les années 1990, a été conçu pour les bibliothèques, afin de mieux rendre compte de la complexité des ressources textuelles et éditoriales. Il distingue quatre niveaux hiérarchiques (œuvre, expression, manifestation et item) qui permettent de décrire de manière précise les objets multiples qu'un même contenu intellectuel peut engendrer (traductions, éditions, exemplaires). Ce modèle a ensuite été consolidé dans une version unifiée, l'IFLA-LRM (Library Reference Model) <fnref n="17" />, qui propose un cadre encore plus cohérent et simplifié pour l'ensemble des entités gérées dans les bibliothèques.

À l'inverse, le CIDOC-CRM (Conceptual Reference Model) <fnref n="18" /> se concentre sur des objets uniques, principalement dans le domaine muséal. Il repose sur une approche événementielle : chaque objet est décrit à travers les événements qui jalonnent son existence (création, acquisition, restauration, exposition, etc.), ce qui permet de saisir son histoire et son contexte d'usage. Là où FRBR et l'IFLA-LRM visent la gestion des relations entre exemplaires multiples, le CIDOC-CRM s'attache à modéliser l'unicité des artefacts et la richesse de leurs trajectoires dans le temps.

Enfin, pour le domaine archivistique, le modèle *Records in Contexts - Conceptual Model* (RiC-CM) <fnref n="19" />, proposé par le Conseil international des archives, répond à la nécessité de représenter des ensembles hiérarchisés de documents produits dans le cadre d'activités administratives ou institutionnelles. RiC-CM s'appuie sur une logique relationnelle, afin de dépasser les limites de la hiérarchie stricte de la norme ISAD(G) et de mieux exprimer la pluralité des contextes de production des archives.

Ces modèles témoignent donc de la spécificité des objets auxquels ils s'appliquent : objets multiples en bibliothèques, objets uniques dans les musées, objets hiérarchisés dans les archives. Ils ne sont pas directement interopérables, car chacun traduit une conception propre de l'information documentaire, adaptée aux pratiques professionnelles de son domaine. Leur coexistence illustre à la fois la richesse et la fragmentation des approches de modélisation dans les institutions culturelles.

L'émergence de ces formats et modèles est également poussée par un besoin de partage de l'information. Ces partages se font d'abord à l'échelle des réseaux formés par les professionnels et les institutions et sont stimulés par différentes motivations. En bibliothèque, un ouvrage est souvent, par nature, multiple. De ce fait, le partage des notices bibliographiques devient alors rapidement un enjeu important afin d'accélérer et de faciliter le travail du cata-

<footnote n="17">17. *Qu'est-ce que le modèle IFLA LRM?*, URL : https://www.transitio-bibliographique.fr/enjeux/definition-ifla-lrm/ (visité le 26/08/2025).</footnote>

<footnote n="18">18. *Home / CIDOC CRM*, URL : https://cidoc-crm.org/ (visité le 21/08/2025).</footnote>

<footnote n="19">19. *Records in Contexts : un nouveau modèle de description archivistique*, URL : https://francearchives.gouv.fr/fr/article/334841641 (visité le 26/08/2025).</footnote>
logage. Ce partage peut également être motivé par les missions scientifiques des institutions, notamment dans l'accompagnement de la recherche et l'enrichissement des connaissances de la ou des disciplines qu'elle couvre. Le partage des notices d'œuvre, des instruments de recherches, des ressources gérées par l'institution offrent la possibilité de croiser les sources et de réaliser des réflexions plus globales, comme dans les sciences humaines et sociales.

Cependant, plusieurs conditions sont nécessaires à un échange de données fructueux. Il faut d'abord prendre en compte l'émergence des multiples formats et modèles de données, de leurs évolution et de la généralisation de leur adoption ou non à l'échelle d'un même domaine qui peut complexifier leur compatibilité. À cela s'ajoute la question des référentiels. Deux institutions peuvent se partager des notices bibliographiques dans un même format mais si le vocabulaire employé pour l'indexation et la désignation de l'auteur de l'ouvrage ne correspondent pas, l'interopérabilité n'est pas complète. Il faut donc répondre à de nouveaux besoins d'interopérabilité entre les différents formats et modèles spécifiques à un même domaine (bibliothèques, musées, archives etc.), mais aussi entre les référentiels.

### III. L'agrégation et l'interopérabilité : une volonté de mutualisation et de valorisation transversale

Avec l'apparition de besoins nouveaux liés au partage de l'information, les systèmes documentaires ont progressivement dû dépasser leur seule vocation interne pour envisager la circulation de leurs données vers d'autres institutions. Cette logique d'ouverture vise à faciliter l'accès aux ressources, mais aussi à permettre leur réutilisation et leur valorisation dans un cadre plus large, qu'il soit disciplinaire, national ou international. Dans ce contexte, plusieurs protocoles d'interopérabilité se sont développés, en particulier pour répondre aux questions de compatibilité entre formats de données. Une première approche consiste à imposer une conversion complète d'un format A vers un format B, ce qui suppose une forte similarité dans les deux formats concernés, qu'ils reposent sur la même norme descriptive ou qu'ils décrivent des documents de même nature. Le protocole Z39.50, développé dès les années 1980 pour les bibliothèques, illustre ce mode d'interopérabilité « par conversion et copie »<fnref n="20" />. Dans ce cas, les notices échangées sont traduites pour être intégrées dans le système cible, ce qui permet de constituer des bases enrichies mais cette méthode repose sur une homogénéité importante entre les structures documentaires en présence. Une autre ap-

<footnote n="20">20. E. Bermès, A. Isaac et G. Poupeau, « 2. Convergence et interopérabilité : vers le Web de données », *Bibliothèques* (, 2013), p. 29-46, URL : https://shs.cairn.info/le-web-semantique-en-bibliotheque--9782765414179-page-29 (visité le 21/08/2025).</footnote>
proche privilégie le recours au « plus petit dénominateur commun » 21, selon une logique de simplification vers un modèle plus généraliste. C'est le cas du protocole OAI-PMH 22, mis en place dans les années 1990, qui agrège les données de différentes sources en les convertissant dans le format Dublin Core 23. Cette méthode garantit une interopérabilité technique, mais elle entraîne souvent une perte de granularité et de nuances par rapport au format d'origine. Si ces protocoles permettent une interopérabilité plus ou moins complète entre les formats et modèles, la question se complexifie lorsqu'il s'agit des référentiels. Lorsque deux institutions emploient des vocabulaires proches, la compatibilité reste relativement simple ; en revanche, dès que les vocabulaires descriptifs divergent, l'interopérabilité devient partielle.

Historiquement, la valorisation des données documentaires produites par les institutions prenait souvent la forme de portails Web qui mettaient en avant les activités de l'institution, ses missions et l'exposition des collections dont elle a la charge. Ces portails sont alors généralement pensés comme des bases de données en système clos, limitées au périmètre documentaire de l'institution. Si les formulaires de recherche qui y sont intégrés permettent l'accès aux informations recherchées par l'internaute, ces dernières ne sont pas accessibles aux moteurs de recherche. Ces ressources appartiennent alors au « Web profond » ou « Web caché » 24. La valorisation et la découvrabilité des données institutionnelles dépend alors de sa capacité à s'inscrire sur le Web en se rendant « visible au sein de ce cheminement naturel » 25 que constitue la navigation d'un internaute.

Pour répondre au besoin d'accessibilité et de valorisation des données auprès des différents publics des institutions tout en facilitant leur réutilisation dans des contextes disciplinaires ou institutionnels plus larges, les agrégateurs de données sont apparus comme un vecteur privilégié. L'émergence des agrégateurs de données, qu'ils soient disciplinaires, nationaux ou internationaux, met toujours en évidence les problématiques d'interopérabilité précédemment abordées. Ils doivent présenter de manière harmonisée des données issues d'institutions variées, conciliant la nécessité de normalisation avec la volonté de préserver la richesse des notices d'origine. L'agrégateur impose alors généralement un modèle de données commun. Celui-ci doit alors parvenir à intégrer des informations provenant de modèles hé-

<footnote n="21">21. *Ibid*.</footnote>

<footnote n="22">22. « OAI-PMH est le sigle de l'Open Archives Initiative - Protocol for Metadata Harvesting, ce qui signifie “protocole pour la collecte de métadonnées de l'Initiative pour les Archives ouvertes” » - *Protocole OAI-PMH*, URL : https://www.bnf.fr/fr/protocole-oai-pmh (visité le 01/09/2025)</footnote>

<footnote n="23">23. « Le Dublin Core est un format descriptif simple et générique créé en 1995 à Dublin (Ohio) par OCLC (Online Computer Library Center) et le NCSA (National Center for Supercomputing Applications). » - *Dublin Core*, URL : https://www.bnf.fr/fr/dublin-core (visité le 01/09/2025)</footnote>

<footnote n="24">24. Id., *Le Web sémantique en bibliothèque...*, p.24.</footnote>

<footnote n="25">25. *Ibid.*, p.23.</footnote>
térogènes, en opérant le moins de compromis possible afin de limiter la perte d'information et de sa granularité. L'exemple du schéma LIDO-MC<fnref n="26" />, conçu par le Ministère de la culture dans le cadre de sa fonction d'agrégateur national, illustre cette recherche. Ce schéma est une adaptation du format LIDO<fnref n="27" /> (originellement développé par l'ICOM) : il s'agit d'un modèle pivot, pensé pour l'agrégation, qui vise à concilier les différences structurelles et descriptives des formats sources tout en garantissant leur interopérabilité à un niveau international.

Dans le cadre de l'agrégation, les vocabulaires contrôlés et les formats de métadonnées constituent les véritables clés d'accès et de découvrabilité, mais leur articulation demeure un enjeu central de l'interopérabilité documentaire. Dans ce cas, deux solutions sont souvent employées : imposer un référentiel unique au niveau de l'agrégateur, ou accepter la coexistence de plusieurs référentiels, ce qui conserve l'intégrité et la complexité des métadonnées mais provoque l'apparition de doublons et rend la recherche plus laborieuse.

L'informatisation des fichiers d'autorité a permis d'identifier des clés transversales aux différents domaines qui peuvent servir de liens unificateurs et ainsi de valoriser les entités clés que sont les personnes, les événements, les lieux et les concepts. Comme le souligne Emmanuelle Bermès lors du 77e congrès de l'IFLA en 2011²⁸, « ce type d'entité [...] est également le type même de ressources qui peuvent être partagées au-delà des limites d'un type d'institution culturelle en particulier ». C'est sur ces éléments pivots que se base souvent l'imposition d'un référentiel commun, cherchant à identifier et normaliser les entités transversales pour assurer l'interopérabilité. Cette approche a donné naissance à des initiatives collaboratives comme VIAF (Virtual International Authority File)<fnref n="29" />, qui permet à différentes institutions bibliothécaires nationales de partager un même référentiel d'autorités en créant

<footnote n="26">26. *Echanger les données culturelles : profil d'application LIDO-MC / Ministère de la Culture*, juin 2014, URL : https://www.culture.gouv.fr/fr/thematiques/innovation-numerique/faciliter-l-acces-aux-donnees-et-aux-contenus-culturels/partager-et-valoriser-les-donnees-et-les-contenus-culturels/echanger-les-donnees-culturelles-profil-d-application-lido-mc (visité le 01/09/2025).</footnote>

<footnote n="27">27. « LIDO – Lightweight Information Describing Objects is a format for contributing collection objects information for resource discovery. The LIDO XML schema is intended for delivering metadata, for use in a variety of online services, from an organization's online collections database to portals of aggregated resources, as well as exposing, sharing, and connecting data on the web. » - What is LIDO?, URL : https://cidoc.mini.icom.museum/working-groups/lido/lido-overview/about-lido/what-is-lido/ (visité le 21/08/2025).</footnote>

<footnote n="28">28. E. Bermès, « Convergence et interopérabilité : l'apport du web de données », dans *77e congrès de l'IFLA*, Puerto Rico, 2011, URL : http://conference.ifla.org/past/ifla77/149-bermes-fr.pdf (visité le 23/07/2025).</footnote>

<footnote n="29">29. « Le service VIAF (Virtual International Authority File) est destiné aux bibliothèques et à leurs utilisateurs, et entend simplifier l'accès aux principaux fichiers d'autorité de noms du monde entier. Les contributeurs du VIAF envoient régulièrement des données d'autorité avec lesquelles le VIAF établit des correspondances, des liens et des groupes. Toutes les descriptions d'une entité donnée sont fusionnées dans un groupe qui réunit les différents noms de cette entité. » - VIAF : accès facile à des fichiers d'autorités de noms, nov. 2024, URL : https://www.oclc.org/fr/viaf.html (visité le 01/09/2025).</footnote>
des liens entre leurs fichiers d'autorité respectifs, facilitant ainsi l'identification univoque des personnes, organisations et œuvres à l'échelle internationale.

L'émergence du Web et le développement des plateformes d'agrégation ont ainsi transformé les enjeux de l'interopérabilité documentaire. Dans le cadre de leurs missions scientifiques et de valorisation, les institutions culturelles sont désormais amenées à envisager une interopérabilité qui dépasse les frontières traditionnelles de leurs domaines spécifiques.
# Chapitre 2

## Le Web sémantique et le Web de données

L'essor du Web a bouleversé l'accès à l'information, mais ses premiers développements restaient centrés sur les documents et leur mise en forme, sans réelle prise en compte du sens des contenus. Le Web sémantique, puis le Web de données, ont cherché à dépasser cette limite en proposant une structuration compréhensible par les machines et réutilisable à grande échelle. Ce chapitre retrace cette évolution et montre comment ces technologies ouvrent de nouvelles perspectives pour l'interconnexion, la valorisation et la diffusion des données culturelles.

### I. Du Web documentaire au Web de données

Le World Wide Web, tel que nous le connaissons aujourd'hui, constitue un système d'information distribué qui fonctionne sur Internet depuis sa création au CERN en 1989¹. Cette architecture repose sur quatre technologies fondamentales :

- Le protocole HTTP <fnref n="2" /> qui permet la communication d'informations entre les machines.

- Les URL <fnref n="3" /> qui servent d'identifiants uniques pour chaque ressource présente sur le

<footnote n="1">1. « World Wide Web », Wikipédia (), URL : https://fr.wikipedia.org/w/index.php?title=World_Wide_Web&oldid=227641401 (visité le 01/09/2025).</footnote>

<footnote n="2">2. « L'Hypertext Transfer Protocol, généralement abrégé HTTP, littéralement "protocole de transfert hypertexte", est un protocole de communication client-serveur développé pour le World Wide Web. HTTPS (avec S pour secure, soit "sécurisé") est la variante sécurisée par le chiffrement et l'authentification. » - « Hypertext Transfer Protocol », Wikipédia (), URL : https://fr.wikipedia.org/w/index.php?title=Hypertext_Transfer_Protocol&oldid=227153874 (visité le 01/09/2025).</footnote>

<footnote n="3">3. « Une ou un URL (sigle de l'anglais : Uniform Resource Locator, littéralement "localisateur uniforme de ressource"), informellement appelée adresse web, est une chaîne de caractères qui indique sous une forme</footnote>
Web.

— Le système d'hypertexte <fnref n="4" /> qui relie les ressources du Web entre-elles et qui permet à l'utilisateur de naviguer d'une ressource à une autre.

— Le langage HTML<fnref n="5" /> qui permet de structurer le contenu de chaque ressource et l'interprétation de cette structure par la machine, via un navigateur, pour restituer la ressource sous une forme lisible pour les utilisateurs humains.

À l'origine, le sens du contenu des ressources sur le Web n'est donc pas fait pour être interprété par une machine, seulement la structure et la présentation des ressources. De ce fait, les informations contenues dans ces ressources sont difficilement manipulables et ré-exploitables automatiquement <fnref n="6" />.

Le Web sémantique est défini dans l'article fondateur de 2001 dans le journal *Scientific American* comme suit : « The Semantic Web is not a separate Web but an extension of the current one, in which information is given well-defined meaning, better enabling computers and people to work in cooperation. » <fnref n="7" />. Le Web sémantique était alors envisagé comme un moyen de transformer le Web en un environnement où les machines peuvent non seulement accéder aux informations, mais aussi en comprendre le sens et les traiter de manière intelligente, permettant une meilleure exploitation des pages Web, par exemple. Le Web sémantique repose alors sur la conception de métadonnées structurées dédiées aux ressources présentes sur le Web.

Ces métadonnées sont exprimées en se basant sur le modèle *Resource Description Framework*.

<footnote>standardisée comment accéder à une ressource du World Wide Web à travers Internet. Les URL commencent par un protocole Internet suivi du caractère deux-points ; la suite est souvent constituée d'un nom de domaine et d'un chemin d'accès. » - « Uniform Resource Locator », Wikipédia (), URL : https://fr.wikipedia.org/w/index.php?title=UniformResourceLocator&oldid=227298870 (visité le 01/09/2025).</footnote>

<footnote n="4">4. « Un hypertexte est un texte ou un ensemble de documents informatiques qui permet de passer d'un document à l'autre grâce à un système de renvois appelés hyperliens, ou liens hypertextes. Ceux-ci prennent la plupart du temps la forme d'un texte souligné en bleu, bien qu'ils puissent également être placés sur une photo, une image, un bouton, etc. » - « Hypertexte », Wikipédia (), URL : https://fr.wikipedia.org/w/index.php?title=Hypertexte&oldid=227596283 (visité le 01/09/2025).</footnote>

<footnote n="5">5. « Le HyperText Markup Language, généralement abrégé HTML ou, dans sa dernière version, HTML5, est le langage de balisage conçu pour écrire les pages web. Il s'agit d'un format ouvert très utilisé en informatique. Comme son nom l'indique, HTML permet d'écrire de l'hypertexte. Il permet aussi de structurer sémantiquement le texte, de créer des formulaires de saisie, d'inclure des ressources multimédias dont des images, des vidéos et des programmes informatiques. » - « Hypertext Markup Language », Wikipédia (), URL : https://fr.wikipedia.org/w/index.php?title=Hypertext Markup Language&oldid=227281544 (visité le 01/09/2025).</footnote>

<footnote n="6">6. « Most of the Web's content today is designed for humans to read, not for computer programs to manipulate meaningfully. Computers can adeptly parse Web pages for layout and routine processing—here a header, there a link to another page—but in general, computers have no reliable way to process the semantics [...] » - Tim Berners-Lee, James Hendler et Ora Lassila, « The Semantic Web », *Scientific American*, 284-5 (2001), p. 34-43, JSTOR : 26059207, URL : https://www.jstor.org/stable/26059207 (visité le 27/08/2025), p.36.</footnote>

<footnote n="7">7. *Ibid.*, p.37.</footnote>
mework (RDF) qui établit des relations sémantiques sous forme de triplets qui suivent la structure « sujet-prédicat-objet » (voir figure 2.1). L'information exprimée par le triplet est appelée une assertion. RDF joue alors le même rôle qu'HTML sur le Web traditionnel : il définit la structure de l'information. L'ensemble de ces triplets forme ce qu'on appelle un graphe.

<figure><img src="image_6.png" /><figcaption>FIGURE 2.1 – Schéma d’un triplet RDF</figcaption></figure>

Une fois ces graphes constitués, il devient nécessaire de pouvoir les interroger et en ex-
traire des informations pertinentes. SPARQL (*SPARQL Protocol and RDF Query Language*)
est le langage de requête standardisé par le W3C<fnref n="8" /> conçu pour interroger les graphes RDF.
SPARQL permet de formuler des requêtes complexes en exploitant la structure des triplets
sujet-prédicat-objet, offrant ainsi aux machines et aux utilisateurs la capacité d'extraire des
informations précises à partir de vastes ensembles de données sémantiques interconnectées.

Dans le modèle RDF, chaque sujet et chaque objet peut être identifié par une URI
(Uniform Resource Identifier), c'est-à-dire un identifiant unique qui garantit l'univocité de
la ressource décrite. Cette logique permet de lever toute ambiguïté : deux ressources ayant
la même URI renvoient nécessairement au même concept du monde réel. L'objet d'un triplet
peut être soit une ressource (elle-même identifiée par une URI), soit un littéral, c'est-à-dire
une valeur brute comme un nombre, une date, ou une chaîne de caractères (voir figure 2.2).

<footnote n="8">8. « Web inventor Tim Berners-Lee founded the World Wide Web Consortium in 1994 to ensure the long-term growth of the web. He remains W3C’s Emeritus Director and Honorary Member of the Board of Directors. From the start the World Wide Web Consortium (W3C) has been an international multi-stakeholder community where member organizations, a full-time staff, and the public work together to develop open web standards. » - About us, URL : https://www.w3.org/about/ (visité le 08/09/2025).</footnote>
<figure><img src="image_7.png" /><figcaption>FIGURE 2.2 – Schéma montrant un exemple de graphe RDF.</figcaption></figure>

Le prédicat, quant à lui, exprime la nature de la relation entre le sujet et l'objet. C'est un élément central du modèle RDF, car il ne s'agit pas seulement de relier deux entités mais de préciser le sens de cette relation. Les prédicats sont eux aussi identifiés par des URI (voir figure 2.2), ce qui permet de les partager et de les réutiliser dans différents contextes.

Afin de normaliser et de donner un cadre commun à ces relations, le Web séman-
tique s'appuie sur des ontologies. Une ontologie définit un vocabulaire contrôlé décrivant les
concepts d'un domaine ainsi que les relations possibles entre eux. Elle joue donc un rôle de
« grammaire commune » qui permet à différents systèmes d'interpréter de manière cohérente
les triplets publiés. Dans une ontologie, les entités sont regroupées en classes (par exemple,
Personne, Œuvre, Lieu). Une classe peut être spécialisée en sous-classes (Peintre comme
sous-classe de Personne)(voir figure 2.3), ce qui permet de représenter les hiérarchies et d'héri-
ter de propriétés qui leur seraient dédiées. De la même manière, certaines propriétés peuvent
être définies comme des super-propriétés qui englobent d'autres relations plus spécifiques.
Cette organisation hiérarchique permet d'assurer à la fois la cohérence et la ré-utilisabilité
des données publiées dans différents contextes institutionnels et disciplinaires.
<figure><img src="image_8.png" /><figcaption>FIGURE 2.3 – Schéma montrant un exemple d'utilisation d'une ontologie dans un graphe RDF.</figcaption></figure>

Pour formaliser ces structures et garantir leur interoperabilité, les ontologies s'appuient sur des standards élaborés par le W3C, en particulier *RDF Schema* (RDFS) et *OWL* (*Web Ontology Language*). Ces deux langages de représentation fournissent les outils nécessaires pour décrire les concepts d'un domaine, les relations qui les unissent (par exemple : « au-teur de », « situé à »), ainsi que les contraintes logiques qui les régissent (par exemple : un *Peintre* est nécessairement une sous-classe de *Personne*). RDFS propose un vocabulaire de base pour définir classes et propriétés, tandis qu'OWL permet de spécifier des hiérarchies complexes, des équivalences, des propriétés inverses ou encore des relations de type transitives ou symétriques.

L'ensemble de ces mécanismes (URI uniques, triplets RDF, littéraux, relations séman-
tisées et ontologies) constitue l'infrastructure du Web sémantique. Ils permettent de relier les
données en graphes de connaissances, interprétées automatiquement et réutilisées à grande
échelle.

Le Web sémantique constitue donc avant tout un cadre conceptuel : il fournit les prin-
cipes et les outils nécessaires pour donner un sens aux données, mais il ne précise pas encore
comment les publier et les exploiter directement dans l'environnement du Web existant, fondé
sur des technologies éprouvées comme HTTP, HTML ou les URL.

C'est pour répondre à ce besoin qu'a été formulée, en 2006 par Tim Berners-Lee 9, la

<footnote n="9">9. *Linked Data - Design Issues*, URL: https://www.w3.org/DesignIssues/LinkedData.html (visité le 01/09/2025).</footnote>
notion de Web de données (Linked Data). Celui-ci n'est pas un nouveau Web, mais l'applica-
tion concrète des principes du Web sémantique sur l'infrastructure déjà en place. Autrement
dit, il transpose aux données les mécanismes qui ont fait le succès du Web documentaire : là
où le Web reliait des documents entre eux par des hyperliens, le Web de données relie des
entités et des concepts au sein de graphes de connaissances accessibles en ligne. Pour mieux
comprendre cette continuité, on peut mettre en parallèle les briques fondamentales des deux
environnements (voir figure I.)

<table><caption>TABLE 2.1 – Parallèle entre les fondements du Web et ceux du Web de données</caption>
   <thead>
    <tr>
     <td>
      Web « classique »
     </td>
     <td>
      Web de données
     </td>
    </tr>
   </thead>
   <tbody>
    <tr>
     <td>
      URL : identifient et localisent des documents sur le Web
     </td>
     <td>
      URI : identifient de manière unique des ressources (concepts, entités, objets du monde réel)
     </td>
    </tr>
    <tr>
     <td>
      HTML : langage de balisage qui structure et présente les documents pour les humains
     </td>
     <td>
      RDF : modèle de description qui structure les données pour qu'elles soient comprises par les machines
     </td>
    </tr>
    <tr>
     <td>
      Hyperliens : relient des pages entre elles pour créer un réseau documentaire
     </td>
     <td>
      Triplets RDF : relient des ressources entre elles pour former un graphe de connaissances
     </td>
    </tr>
    <tr>
     <td>
      HTTP : protocole de communication qui permet l'accès universel aux documents
     </td>
     <td>
      HTTP : réutilisé pour rendre les URI des ressources accessibles et interrogeables sur le Web
     </td>
    </tr>
    <tr>
     <td>
      Navigation/Recherche : moteurs de recherche indexant le contenu textuel des pages
     </td>
     <td>
      SPARQL : langage de requête permettant d'interroger les graphes de connaissances et d'extraire des informations précises
     </td>
    </tr>
   </tbody>
  </table>

II. L'influence du Web de données sur les pratiques institutionnelles

Le premier impact tangible du Web de données dans les institutions culturelles concerne
la visibilité de leurs ressources dans l'écosystème du Web. Les moteurs de recherche, ont pro-
gressivement intégré la capacité d'interpréter les données sémantiques pour enrichir leurs ré-
sultats de recherche et améliorer la pertinence des réponses apportées aux utilisateurs. Cette
 évolution s'est concrétisée, par exemple, par l'adoption massive de Schema.org, vocabulaire
collaboratif lancé en 2011 par une initiative conjointe des principaux moteurs de recherche
(Google, Bing, Yahoo! et Yandex) et aujourd'hui maintenu par le W3C<fnref n="10" />. Schema.org pro-

<footnote n="10">10. *Schema.org - Schema.org*, URL: https://schema.org/ (visité le 01/09/2025).</footnote>
pose un vocabulaire commun standardisé qui permet aux institutions et agrégateurs d'auto-
rité d'intégrer des métadonnées sémantiques, directement dans leurs pages Web. C'est le cas
notamment des pages représentant des entités sur la plateforme data.bnf.fr (voir annexe C)
Cette approche pragmatique a démocratisé l'usage des données structurées en proposant une
solution accessible qui ne nécessite pas de refonte complète des systèmes existants. Cela per-
met alors de répondre en partie au besoin de découvrabilité et d'accessibilité lié aux missions
des institutions en s'adaptant aux nouveaux usages du public au sein de l'écosystème du Web.

L'intérêt que suscite le Web de données influence également l'émergence de nouveaux
modèles conceptuels de données en prolongeant la réflexion amorcée par les premiers modèles
développés pour les institutions<fnref n="11" /> qui recentrent la modélisation sur les entités et les données
plutôt que les documents, objets ou ressources. Comme formulé par Gauthier Poupeau : « La
notion de graphe a conduit à l'idée de “détruire” le méta-document que constituait la notice
ou encore de faire “éclater” la notice. Les données ne sont plus enfermées à l'intérieur d'une
notice, mais liées les unes aux autres dans un espace global d'information. Dès lors, il devient
possible de dépasser la vision documentaire des informations de signalement qui avait émergé
avec l'idée de notice, qui limitait notre réflexion et maintenait artificiellement des frontières,
en particulier entre le document et sa description, lorsqu'il s'agissait de lier les informations
entre elles. »<fnref n="12" />.

Ces technologies poussent également au décloisonnement des différents systèmes docu-
mentaires qui peuvent exister dans certaines institutions en fonction de leur périmètre do-
cumentaire ou de la nature de leurs missions. Par exemple, la plateforme data.bnf.fr illustre
le passage d'une logique centrée sur la notice bibliographique à une approche où les don-
nées d'autorité deviennent les véritables points d'entrée vers l'information. La plateforme est
alimentée par les différents silos de données de la BNF <fnref n="13" />. Les données sont alors structu-
rées en s'inspirant du modèle IFLA-LRM (voir annexe D) et les entités (personnes, œuvres,
lieux) acquièrent une autonomie qui transcende leur fonction descriptive initiale pour deve-
nir des ressources informationnelles à part entière <fnref n="14" />. Les relations du modèle sont également
exprimées en triplets, en employant majoritairement des ontologies adaptées et largement
diffusées. Cette nouvelle cohérence et interopérabilité des données permet de les interroger

<footnote n="11">11. Voir la section II.</footnote>

<footnote n="12">12. G. Poupeau, « Le « lac de données », une infrastructure technique pour déployer la gouvernance des données à l'Ina », dans *Les nouveaux paradigmes de l'archive*, dir. Claire Scopsi, Clothilde Roullier, Martine Sin Blima-Barru et Édouard Vasseur, *Pierrefitte-sur-Seine*, 2024 (Actes), DOI: 10.4000/books.pan.7253.</footnote>

<footnote n="13">13. BnF Catalogue général, BnF Archives et manuscrits, Gallica, Expositions virtuelles et ressources pédagogiques, Sites collectés par le Dlweb, Imprimeurs parisiens 16e, Reliures, Bibliographies. - *A propos de data.bnf.fr*, URL : https://data.bnf.fr/fr/about (visité le 28/08/2025)</footnote>

<footnote n="14">14. Web sémantique et modèle de données, URL : https://data.bnf.fr/fr/semanticweb (visité le 28/08/2025).</footnote>
dans leur globalité, sans se soucier des spécificités de chaque système documentaire, de chaque
ressource décrite, de chaque référentiel, via le SPARQL *endpoint* de la BNF (voir annexe E).

Les technologies du Web sémantique permettent donc de créer des ponts entre différents
jeux de données, que ce soit en interne ou vers des jeux de données externes. Cette capacité
d'interconnexion repose sur l'existence d'ontologies largement adoptées qui facilitent l'inter-
opérabilité à plusieurs niveaux. D'une part, il existe des ontologies qui permettent de déter-
miner des équivalences entre concepts issus de différents vocabulaires. Le langage OWL offre
notamment des propriétés spécifiques pour établir ces correspondances telles que « owl :equi-
valentClass » pour signaler que deux classes représentent le même concept, « owl :equiva-
lentProperty » pour indiquer l'équivalence entre propriétés, ou encore « owl :sameAs » pour
identifier des ressources individuelles identiques. Ces mécanismes permettent aux machines
de reconnaître automatiquement qu'une « foaf :Person » (provenant de l'ontologie FOAF)
correspond à une « schema :Person » (issue de Schema.org), facilitant ainsi l'agrégation de
données hétérogènes. D'autre part, l'operability s'étend aux référentiels eux-mêmes grâce
à des vocabulaires spécialisés comme SKOS (*Simple Knowledge Organization System*). SKOS
propose un modèle standardisé pour représenter les thésaurus, taxonomies et autres sys-
tèmes d'organisation de la connaissance sous forme de graphes RDF. Il permet d'établir des
relations d'équivalence de différents degrés de granularité : « skos :exactMatch » pour des
correspondances exactes entre concepts, « skos :closeMatch » pour des correspondances ap-
proximatives, ou encore « skos :broadMatch » et « skos :narrowMatch » pour exprimer des
relations hiérarchiques entre concepts issus de vocabulaires distincts. Cette approche graduée
permet de préserver la richesse sémantique de chaque référentiel tout en établissant des ponts
conceptuels entre eux.

Les grands agrégateurs transversaux, qui rassemblent des collections issues d'institu-
tions culturelles diverses (archives, musées, sites archéologiques, monuments, bibliothèques...),
se sont également approprié ces technologies. Europeana illustre cette démarche à travers
plusieurs utilisations. Lancée en 2008 <fnref n="15" />, cette bibliothèque numérique européenne a déve-
loppé sa propre ontologie, l' *Europeana Data Model* (EDM) <fnref n="16" />, spécifiquement conçue pour
constituer un modèle d'operability suffisamment souple et générique pour accueillir des
métadonnées issues de domaines culturels variés. L'EDM réutilise sélectivement des éléments
de standards établis comme Dublin Core pour les métadonnées descriptives de base, tout
en intégrant OAI-ORE (*Object Reuse and Exchange*) pour décrire les agrégations de res-
sources numériques. Contrairement à une approche basée sur un standard communautaire

<footnote n="15">15. « Europeana », Wikipédia (), URL : https://fr.wikipedia.org/w/index.php?title=Europeana&oldid=220071047 (visité le 30/08/2025).</footnote>

<footnote n="16">16. *Europeana Data Model Primer*, mars 2013.</footnote>
unique, l'EDM définit un petit ensemble de propriétés et de classes centrales auxquelles
des constructions plus spécialisées peuvent être rattachées via des *mappings* sémantiques<sup>17</sup>.
Cette architecture modulaire vise à permettre à Europeana d'enrichir sémantiquement les
notices d'autorité en exploitant des référentiels externes. Par exemple, la notice d'autorité
d'un « agent » (personne ou personne morale) peut potentiellement être alimentée par les
données de chaque agrégateur et institution membre du réseau, ainsi que par des référentiels
publics comme VIAF, Wikidata ou DBpedia. Pour cela la plateforme s'appuie sur des méca-
nismes de reconnaissance automatique d'entités équivalentes et les signale via les propriétés
d'équivalence citées plus tôt, empruntées à SKOS par exemple.

Ainsi, l'essor du Web de données a contribué à transformer en profondeur les pratiques
documentaires, en déplaçant l'attention des formats de métadonnées et des protocoles d'inter-
opérabilité vers les entités et leurs référentiels. Cette évolution s'inscrit dans un mouvement
plus large d'enthousiasme pour les potentialités du Web sémantique et de l'Open Data, qui
ouvre de nouvelles perspectives pour la valorisation et la réutilisation des données culturelles.
Les grands agrégateurs, tels qu'Europeana, illustrent déjà la capacité de ces infrastructures à
relier des ensembles hétérogènes grâce à des modèles communs. En parallèle, se développent
également des graphes de connaissances portés tant par des acteurs privés, comme le Google
Knowledge Graph<sup>18</sup>, que par des initiatives ouvertes et participatives. Parmi ces dernières,
DBpedia illustre une approche consistant à extraire de manière structurée les données de
Wikipédia tout en permettant à la communauté de contribuer à l'ontologie qui organise ces
données. Freebase, quant à elle, proposait une base alimentée par la communauté et a été
progressivement remplacée par des initiatives plus ambitieuses comme Wikidata, visant à
constituer un socle partagé de connaissances interconnectées, réutilisable et enrichi collecti-
vement.

<footnote n="17">17. Le *mapping* sémantique est défini à la section III.</footnote>

<footnote n="18">18. « Le Knowledge Graph de Google est une base de connaissance utilisée par Google pour compiler les résultats de son moteur de recherche avec des informations sémantiques issues par ailleurs de sources diverses. » - « Google Knowledge Graph », Wikipédia (), URL : https://fr.wikipedia.org/w/index.php?title=Google_Knowledge_Graph&oldid=224916174 (visité le 01/09/2025)</footnote>
# Chapitre 3

## Le choix de Wikidata : un hub d'identifiants d'autorité

Né au croisement du Web de données et du mouvement Open Data, Wikidata incarne une nouvelle étape dans la structuration et la circulation des connaissances. Conçu comme une base collaborative et multilingue, il repose sur un modèle inspiré du RDF et offre un cadre souple pour décrire des entités, relier des données et en assurer la traçabilité. Ce chapitre revient sur les origines du projet, ses principes fondateurs et son évolution vers un graphe de connaissances majeur, devenu un point d'ancrage incontournable pour les institutions culturelles et patrimoniales.

### I. Un projet au croisement de l'Open Data et du Web de données

Les années 2000 à 2010 sont marquées par un engouement non seulement pour le Web de données et les nouvelles possibilités qu'il offre mais aussi pour le mouvement de l'Open Data ou de l'ouverture des données.

> « Loin d'être un phénomène récent, l'ouverture des données s'inscrit dans un héritage historique et conceptuel varié comprenant la transparence et le droit d'accès à l'information, la liberté de l'information et le logiciel libre, le partage des données de la recherche, la modernisation des administrations, les industries de l'information et l'entraînement des modèles d'intelligence artificielle.<fnref n="1" /> »

<footnote n="1">1. Samuel Goëta, « Les racines multiples de l'open data », dans *Les données de la démocratie. Open data, pouvoirs et contre-pouvoirs*, 2024 (Société numérique), p. 28-57, URL : https://shs.cairn.info/les-donnees-de-la-democratie--9782376620716-page-28 (visité le 31/08/2025).</footnote>
C'est un mouvement global, qui prend racine dans plusieurs pays et organisations internationales et qui se concrétise sous la forme de lois, de chartes, d'initiatives ou de recommandations comme la loi CADA de 1978 en France<fnref n="2" />. La démocratisation du Web accélère le développement du mouvement et c'est dans ce cadre que deux acteurs principaux participent à la définition de ce qu'est l'Open Data. Le premier est l'Open Knowledge Foundation, fondée en 2005, qui définit ainsi ce qu'est une donnée ouverte : « [...] une donnée qui peut être librement utilisée, réutilisée et redistribuée par quiconque - sujette seulement, au plus, à une exigence d'attribution et de partage à l'identique. »<fnref n="3" /> et qui ajoute plusieurs critère notamment :

— « Disponibilité et accès : Les données doivent être disponible dans leurs ensembles et pour un coût raisonnable de reproduction, de préférence téléchargeable sur internet. Les données doivent être aussi disponibles dans un format pratique et sous forme modifiable.

— Réutilisation et Redistribution : Les données doivent être disponibles sous une licence autorisant la réutilisation et la redistribution incluant le croisement avec d'autres ensembles de données.

— Participation universelle : tout le monde doit être en mesure d'utiliser, de réutiliser et redistribuer - il ne devrait y avoir aucune discrimination contre les champs de l'activité ou contre des personnes ou des groupes. Pour exemple, des restrictions 'non-commercial' qui empêcheraient les utilisations 'commerciales' ou des restrictions d'utilisation à certaines fins (par exemple seulement dans l'éducation) ne sont pas autorisées. »

Le deuxième acteur est Tim Berners-Lee, au centre de l'enthousiasme pour le Web de données et l'open data, qui s'illustre dans une conférence en 2009 lors de laquelle il réclame l'ouverture des données brutes (« Row data now »)<fnref n="4" /> puis dans la définition d'une échelle progressive de la qualité des données ouvertes en 2010 (voir figure 3.1). Cette échelle de qualité crée le lien entre les données ouvertes et le Web de données en valorisant l'utilisation des URI et surtout le lien entre les différents jeux de données.

<footnote n="2">2. Dont le tire 1er porte sur « [...] la liberté d'accès aux documents administratifs et de la réutilisation des informations publiques » - *Loi n° 78-753 du 17 juillet 1978 portant diverses mesures d'amélioration des relations entre l'administration et le public et diverses dispositions d'ordre administratif, social et fiscal*, juill. 1978, URL : https://www.legifrance.gouv.fr/loda/id/JORFTEXT000000339241 (visité le 19/07/2025).</footnote>

<footnote n="3">3. Open Knowledge Foundation, *Manuel de l'Open Data*, URL : https://opendatahandbook.org/guide/fr/ (visité le 19/07/2025).</footnote>

<footnote n="4">4. S. Goëta, « Les grandes étapes de la définition des principes de l'open data », dans *Les données de la démocratie. Open data, pouvoirs et contre-pouvoirs*, 2024 (Société numérique), p. 59-80, URL : https://shs.cairn.info/les-donnees-de-la-democratie--9782376620716-page-59 (visité le 31/08/2025).</footnote>
<figure><img src="image_9.png" /><figcaption>FIGURE 3.1 – Capture d’écran du site https://5stardata.info/fr/.</figcaption></figure>

C’est dans ce contexte que le projet de Wikidata est né. Le projet trouve son origine en 2005, lorsque trois doctorants de Karlsruhe (Markus Krötzsch, Max Völkel et Denny Vrandečić) proposent le projet de *Semantic Wikipedia*, qui visait à enrichir Wikipédia avec des données structurées et lisibles par des machines. Ce projet donnera naissance au logiciel Semantic MediaWiki et nourrira l’idée d’une base de données pour centraliser les données factuelles utilisées par toutes les versions linguistiques de Wikipédia. En 2011, Wikimedia Deutschland accepte de porter le projet, avec le soutien financier de divers acteurs dont Google. Le développement commence en 2012 à Berlin et Wikidata est mis en ligne le 29 octobre 2012⁵. Wikidata s’inscrit dans les idéaux portés par la fondation Wikimedia ainsi que ceux de l’Open Data et de la conception originale du Web de données par Tim Berners-Lee :

— « Community : the confidence that sensible people will work together to make the world a better place.

— Sharing : the goal of making knowledge, and digital resources in general, freely available to every human.

— Explication : the goal to formally specify information in explicit, unambiguous, and machine-processable ways »<fnref n="6" />.

Wikidata se présente aujourd’hui sous la forme d’un graphe de connaissances « librement améliorable »<fnref n="7" />. Son modèle de données s’inspire fortement du modèle RDF en reprenant le principe du triplet (voir figure 3.2). Les entités, peu importe leur nature, sont appelées

<footnote n="5">5. Denny Vrandečić, Lydia Pintscher et Markus Krötzsch, « Wikidata : The Making Of », dans *Companion Proceedings of the ACM Web Conference 2023*, New York, NY, USA, 2023 (WWW ’23 Companion), p. 615-624, DOI : 10.1145/3543873.3585579.</footnote>

<footnote n="6">6. *Ibid.*</footnote>

<footnote n="7">7. « Wikidata », *Wikipédia* (), URL : https://fr.wikipedia.org/w/index.php?title=Wikidata&oldid=225737951 (visité le 28/06/2025).</footnote>
des éléments et possèdent un identifiant commençant pas la lettre Q d'où leur surnom très répandus de « Qids ». Les propriétés ont un identifiant qui commence par P et les objets sont appelés valeurs. L'ensemble du triplet est appelé une déclaration là où le modèle RDF parlait d'assertion.

Le projet donne la possibilité à la communauté de collaborer à la fois à la conception de l'ontologie mais aussi à l'enrichissement des données. Ainsi, au triplet d'origine s'ajoute la possibilité de vérifier la provenance de la donnée avec l'ajout de la référence mais aussi de préciser le sens ou la portée de l'information contenue dans le triplet via des qualificatifs (voir figure 3.2).

<figure><img src="image_10.png" /><figcaption>FIGURE 3.2 – Représentation en français du modèle de données de Wikidata avec un groupe de déclarations et des références dépliées. Voir Wikidata :Glossaire — Wikidata.</figcaption></figure>

Pour chaque ressource (élément, propriété, classe, super-classe, qualificatifs) Wikidata supporte des labels, une description et des alias multilingues. Si le sourçage des données et des informations permet d'apporter de la crédibilité au projet par la vérifiabilité de ces dernières, il implique aussi que la plateforme supporte l'exposition d'informations contradictoires en reflétant les contradictions préexistantes dans les sources citées.

Ces spécificités en font un modèle unique qui permet l'organisation d'un environnement
pleinement collaboratif et une souplesse afin de décrire, à différents degrés de granularité, une très grande variété de concepts et d'entités.

Wikidata avait pour origine la volonté de centraliser les données structurées essentielles des articles Wikipédia dans différentes langues portant sur un même sujet. Au fur et à mesure de son évolution, son rôle s'est étendu à différents usages au sein des projets portés par la Fondation Wikimédia. L'infobox en est une représentation parmi les plus visibles. Elle permet, pour chaque article Wikipédia, de générer un résumé des informations essentielles sur le sujet abordé en respectant la langue d'affichage de l'article (voir figure 3.3)

<figure><img src="image_11.png" /><figcaption>FIGURE 3.3 – Capture d'écran partielle de l'infobox de l'article Wikipédia français sur Rosa Bonheur.</figcaption></figure>

Cette infobox illustre aussi le rôle de Wikidata par rapport à un autre outil Wikimédia Commons<fnref n="8" />. Lorsqu'une photo, un logo ou un fichier sonore apparaît dans l'infobox c'est que

<footnote n="8">8. « Wikimedia Commons (souvent nommé Commons) est une bibliothèque numérique collaborative et gratuite lancée en 2004. Elle héberge des images, des sons, d'autres médias audiovisuels et des données JSON. Elle centralise des médias tels que photographies, dessins, schémas, fichiers son, partitions, cartes géographiques, textes écrits et parlés, animations et vidéos, objets 3D qui ont une utilité pour les projets du mouvement Wikimédia. » - « Wikimedia Commons », *Wikipédia* (), URL : https://fr.wikipedia.org/w/index.php?title=Wikimedia_Commons&oldid=227567500 (visité le 31/08/2025).</footnote>
celui-ci est relié à l'élément correspondant dans Wikidata. De façon générale, les éléments Wikidata servent également de référentiel commun pour indexer, décrire et relier les ressources présentes dans les autres outils de la galaxie Wikimédia et permettent la conception de projets transversaux grâce à une meilleure interopérabilité.

## II. Une expansion massive

Depuis son lancement en 2012, Wikidata n'a cessé d'enregistrer un nombre d'utilisateurs actifs exponentiel (voir figure 3.4) et un volume de données toujours plus important comme le montraient déjà les statistiques en 2023 (voir figure 3.5).

<figure><img src="image_12.png" /><figcaption>FIGURE 3.4 – Évolution de la moyenne par mois de contributeurs actifs sur Wikidata depuis 2012 - stats.wikimedia.org.</figcaption></figure>
<table><caption>Table 1: Statistics about Wikidata as of February 2023</caption><tbody><tr><td rowspan="3">Contributors</td><td>registered</td><td>565,000</td></tr><tr><td>unregistered (distinct IPs)</td><td>1.6 million</td></tr><tr><td>active per month</td><td>> 46,000</td></tr><tr><td>Items</td><td>total</td><td>>101 million</td></tr><tr><td rowspan="2">Properties</td><td>total</td><td>>10,800</td></tr><tr><td>for external identifiers</td><td>> 7,800</td></tr><tr><td rowspan="3">Statements</td><td>total</td><td>>1.44 billion</td></tr><tr><td>for external identifiers</td><td>>206 million</td></tr><tr><td>per item (average)</td><td>14.3</td></tr><tr><td rowspan="2">Edits</td><td>overall</td><td>>1.8 billion</td></tr><tr><td>per day (12 month avg)</td><td>699,000</td></tr><tr><td>Monthly page views (12 month avg)</td><td></td><td>420 million</td></tr><tr><td>Wikipedia articles using Wikidata</td><td></td><td>74%</td></tr></tbody></table>

FIGURE 3.5 – Statistiques sur Wikidata en février 2023 - Vrandečić, Pintscher et Krötzsch, *Wikidata : The Makin Of*, 2023

En 2025, le nombre total d'éléments (*items*)<fnref n="9" /> est indiqué à environs cent-dix-huit millions et le nombre total de déclarations (*statements*) à un milliard soixante-cinq millions<fnref n="10" />.

En 2020, un aperçu de la nature des éléments renseignés sur Wikidata a été réalisé qui démontre un périmètre recouvrant une très grande variété de domaines et disciplines (voir figure 3.6).

Son volume important de données, régulièrement mises à jour et enrichies, son péri-mètre large et la ré-utilisabilité des données liées à la licence CC0¹¹ en ont fait une base de connaissance versatile et incontournable dans plusieurs domaines. Elle a servi, par exemple, à améliorer les réponses des assistants « intelligents » comme Alexa (développé par Amazon)<fnref n="12" /> mais également à entraîner des modèles d'intelligence artificielle. Des résultats intéressants peuvent être observés notamment dans le cas des LLM (*Large Language Model*)<fnref n="13" /> en aug-

<footnote n="9">9. *Statistics - Wikidata*, URL : https://www.wikidata.org/wiki/Special:Statistics (visité le 31/08/2025).</footnote>

<footnote n="10">10. « Wikidata », *Wikipedia* (), URL : https://en.wikipedia.org/w/index.php?title=Wikidata&oldid=1310468402 (visité le 10/09/2025).</footnote>

<footnote n="11">11. Les données de Wikidata sont soumises à la licence CC0 définie comme telle : « [...] une licence libre Creative Commons permettant au titulaire de droits d'auteur de renoncer au maximum à ceux-ci dans la limite des lois applicables, afin de placer son œuvre au plus près des caractéristiques du domaine public. La licence CC0 concerne tous ceux qui mettent à disposition du contenu. Elle autorise toute personne à réutiliser librement ses travaux, les améliorer, les modifier, quel que soit le but et sans aucune restriction de droit, sauf celles imposées par la loi. » - « Licence CC0 », *Wikipédia* (), URL : https://fr.wikipedia.org/w/index.php?title=Licence_CC0&oldid=222588689 (visité le 01/09/2025).</footnote>

<footnote n="12">12. Copy link, Email, X, LinkedIn, Facebook, Line, Reddit, QZone, Sina Weibo, WeChat, et al., *Automatic transliteration can help Alexa find data across language barriers*, août 2018, URL : https://www.amazon.science/blog/automatic-transliteration-can-help-alexa-find-data-across-language-barriers (visité le 31/08/2025).</footnote>

<footnote n="13">13. Un modèle de language est un : « Modèle statistique de la distribution d'unité linguistiques (par exemple : lettres, phonèmes, mots) dans une langue naturelle. Un modèle de langage peut par exemple prédire le mot suivant dans une séquence de mots. On parle de modèles de langage de grande taille ou</footnote>
<figure><img src="image_13.png" /><figcaption>FIGURE 3.6 – Statistiques sur la nature des éléments Wikidata, 2020 - « Qu'y-a-t-il dans Wikidata ? »</figcaption></figure>

mentant la précision des réponse et en réduisant l'occurrence des « hallucinations » <fnref n="14" /> <fnref n="15" />. Il
sert également à alimenter d'autres graphes de connaissance tel que le *Google Knowledge Graph*. Après avoir racheté la société Metaweb en 2010, Google récupère la gestion du projet Freebase et finit par y mettre un terme en 2015 <fnref n="16" />, peu après le lancement de Wikidata. Cette décision est accompagnée d'un versement des données de Freebase dans Wikidata et de la

<footnote>“Large Language Model” (LLM) en anglais pour les modèles possédant un grand nombre de paramètres (généralement de l’ordre du milliard de poids ou plus) comme GPT-3, BLOOM, Megatron NLG, Llama ou encore PaLM. » - *Modèle de langage*, URL : https://www.cnil.fr/fr/definition/modele-de-langage (visité le 31/08/2025).</footnote>

<footnote n="14">14. « Dans le domaine de l'intelligence artificielle, une hallucination ou une confabulation est une réponse fausse ou trompeuse qui est présentée comme un fait certain [...] » - « Hallucination (intelligence artificielle) », *Wikipédia* (), URL : https://fr.wikipedia.org/w/index.php?title=Hallucination_(intelligence_artificielle)&oldid=226869105 (visité le 31/08/2025).</footnote>

<footnote n="15">15. Silei Xu, Shicheng Liu, Theo Culhane, Elizaveta Pertseva, Meng-Hsi Wu, Sina J. Semnani et Mo-nica S. Lam, *Fine-tuned LLMs Know More, Hallucinate Less with Few-Shot Sequence-to-Sequence Semantic Parsing over Wikidata*, nov. 2023, DOI: 10.48550/arXiv.2305.14202, arXiv: 2305.14202 [cs].</footnote>

<footnote n="16">16. « Freebase (web) », *Wikipédia* (), URL : https://fr.wikipedia.org/w/index.php?title=Freebase_(web)&oldid=213070377 (visité le 31/08/2025).</footnote>
création du projet *Google Knowledge Graph*. Ce graphe est mis à jour et enrichi par « issues de différentes sources, telles que le World Factbook de la CIA (CIA World Factbook), Wikidata, ou encore Wikipédia. »<fnref n="17" />. Ce projet permet notamment l'intégration de petits encadrés à leur moteur de recherche contenant « une information structurée et détaillée centrée sur l'objet de la recherche, en plus de la liste d'hyperliens vers d'autres sites. L'objectif est de permettre aux utilisateurs de résoudre leur requête sans avoir besoin de naviguer vers d'autres sites pour accéder aux informations capitales. »<fnref n="18" />.

La communauté des GLAM<fnref n="19" /> trouve également plusieurs intérêts dans ce graphe de connaissance, notamment en terme d'exposition de leurs données et ressources. Plusieurs institutions ont commencé à s'impliquer directement dans l'enrichissement des données de Wikidata, donnant une meilleure visibilité aux ressources qu'elles mettent à disposition de leur public. Dans le cadre d'une conférence organisée par SemWebPro en 2015, Raphaëlle Lapôtre et Benoît Deshayes ont présenté la manière dont la BNF pouvait alimenter et enrichir le graphe de connaissance de Wikidata à partir des données de data.bnf.fr<fnref n="20" />. Le projet est décrit ainsi : « Comme le service data.bnf.fr expose des données d'autorité, structurées et réutilisables, et que le projet Wikidata a pour ambition de fournir des données de qualité, les deux projets se complètent heureusement et une démarche contributive s'est mise en place pour ajouter à Wikidata alignements, données et références à partir de data.bnf.fr. En retour, avec les liens mis en place, la BnF bénéficie d'un nouvel accès à ses ressources documentaires, tout en remplissant sa mission de diffusion de données patrimoniales. »

Cette visibilité passe non seulement par les références ajoutées aux déclarations mais aussi par les déclarations de propriétés permettant de lier un élément Wikidata à un référentiel extérieur (type *external-id*). Ces deux interventions sont exposées sur la plateforme de Wikidata elle-même et via l'interrogation de la base avec le SPARQL enpoint, mais également dans toutes les réutilisations faites par les outils de la galaxie Wikimédia (voir figure 3.7).

Le nombre de propriétés de type *external-id* s'élève aujourd'hui à 9669²¹. De plus, les propriétés, peu importe leur type, peuvent être créées à l'initiative de la communauté mais également en collaboration avec les institutions souhaitant participer à leur conception. C'est le cas, par exemple, de la propriété « dossier d'artiste détenu par » (P9493) dont la conception fut proposée par la *Smithsonian Librairies and Archives*. pour son projet d'alignement de ses dossiers d'artistes<fnref n="22" />.

<footnote n="17">17. « Google Knowledge Graph »...</footnote>

<footnote n="18">18. *Ibid*.</footnote>

<footnote n="19">19. Galleries, Libraries, Archives and Museums</footnote>

<footnote n="20">20. Raphaëlle Lapôtre et Benoît Deshayes, *Utilisation de data.bnf.fr pour alimenter WikiData (Sem-Web.Pro)*, Paris, FIAP Jean Monnet, nov. 2015.</footnote>

<footnote n="21">21. Voir la requête SPARQL donnant le nombre de propriétés Wikidata de type *external-id*.</footnote>

<footnote n="22">22. « When we found that we had a need that was not yet represented in Wikidata, we worked with the</footnote>
<figure><img src="image_14.png" /><figcaption>FIGURE 3.7 – Capture d’écran de la page Wikipédia en français de Rosa Bonheur</figcaption></figure>

Par sa flexibilité et sa capacité à s’adapter à la description de tout type de ressources ou de concepts ainsi qu’à créer des liens entre les référentiels externes, « Implicitly, Wikidata serves as an organically growing hub, linking all these authorities. »<fnref n="23" />. Les notices d’autorité et référentiels, qu’ils soient exposés par les institutions elles-mêmes ou regroupés par des agrégateurs, peuvent être reliés via le modèle de données de Wikidata, peu importe le domaine ou la discipline concernée.

<footnote>wiki community to create one that could be used by any institution with similar resources : a new property to note an artist has an artist file about them at a particular library. » - *Smithsonian Libraries and Archives & Wikidata: Adding Artist Files to Wikidata - Smithsonian Libraries and Archives / Unbound*, URL : https://blog.library.si.edu/blog/2022/05/18/wikidata-artists-files/ (visité le 18/05/2025).</footnote>

<footnote n="23">23. Joachim Neubert, « Wikidata as a linking hub for knowledge organization systems? », dans *Proceedings of the 17th European Networked Knowledge Organization Systems Workshop co-located with the 21st International Conference on Theory and Practice of Digital Libraries 2017 (TPDL 2017)*, Thessalonique, Grèce, 2017, t. 1937, URL : https://ceur-ws.org/Vol-1937/paper2.pdf.</footnote>
# Deuxième partie

Création d'un processus d'alignement
vers Wikidata : les étapes clés
<figure><img src="image_15.png" /></figure>
Après avoir retracé, dans la première partie de ce mémoire, l'évolution des pratiques documentaires en institution culturelle, replacé ces mutations dans l'histoire du Web de données et présenté le rôle particulier de Wikidata dans cet écosystème, il s'agit à présent de passer à la mise en œuvre concrète d'un processus d'alignement. Celui-ci ne peut être envisagé comme une simple opération technique, mais comme une chaîne d'étapes où se combinent gouvernance institutionnelle, génération de correspondances et validation scientifique. La présente partie propose ainsi de décrire les principaux jalons de cette construction : l'influence du contexte et de l'état de la donnée sur le travail de « mapping », les outils permettant de produire des propositions d'alignements, et enfin les méthodes de validation. C'est dans ce dernier moment, décisif pour assurer la fiabilité scientifique du processus, qu'intervient l'application 2AMO, conçue pour répondre aux besoins spécifiques d'un projet d'alignement patrimonial.
# Chapitre 4

## Le Mapping : facteurs d'influence sur l'état de la donnée et établissement des liens sémantiques

### I. La gouvernance des données en institution culturelle

La première étape d'un processus d'alignement consiste toujours en une analyse approfondie de la donnée source et de la donnée de référence, en l'occurrence, celle de Wikidata. En ce qui concerne le projet d'alignement du musée d'Orsay, cette analyse vise principalement une meilleure compréhension de l'état actuel de la donnée des personnes et institutions en retraçant son histoire au sein du musée. Les enjeux concernant la donnée institutionnelle relèvent du domaine de la gouvernance des données. Cette notion connaît une grande variété de définitions, notamment en fonction de son contexte d'application. Elle peut se comprendre à grande échelle, comme celle d'un territoire<fnref n="1" />, tel que l'illustre le règlement sur la gouvernance des données proposé par la Commission Européenne « visant à créer un cadre facilitant la disponibilité et le partage sécurisé (et en confiance) de données (des organismes publics, des entreprises privées et des citoyens) au sein de l'Union européenne »²³. Cette échelle peut

<footnote n="1">1. « La gouvernance des données peut être : un concept socio-politique relatif à la gouvernance des flux de données à toutes les échelles territoriales. Ce champ se compose de “normes, principes et règles régissant divers types de données” (publique et/ou privées), au delà de la gestion purement technique des données. » - « Gouvernance des données », Wikipédia (), URL : https://fr.wikipedia.org/w/index.php?title=Gouvernance_des_donn%C3%A9es&oldid=222988453 (visité le 10/08/2025)</footnote>

<footnote n="2">2. « Règlement sur la gouvernance des données », Wikipédia (), URL : https://fr.wikipedia.org/w/index.php?title=R%C3%A8glement_sur_la_gouvernance_des_donn%C3%A9es&oldid=224722415 (visité le 22/08/2025).</footnote>

<footnote n="3">3. Règlement (UE) 2022/868 du Parlement européen et du Conseil du 30 mai 2022 portant sur la gouvernance européenne des données et modifiant le règlement (UE) 2018/1724 (règlement sur la gouvernance des données) (Texte présentant de l'intérêt pour l'EEE), mai 2022, URL : http://data.europa.eu/eli/</footnote>
également être celle d'une entreprise, d'un organisme<fnref n="4" />. La gouvernance des données en institution rencontre plusieurs enjeux communs avec celle d'une entreprise du fait de l'échelle et la structure de l'organisme.

Ce qui relie principalement les diverses définitions de la gouvernance des données reste la notion de décisions, prises à différentes échelles de l'organisme, ayant un impact sur la donnée. Dans le cas des institutions culturelles, ces décisions sont guidées par plusieurs facteurs importants tels que l'histoire de l'institution elle-même, sa conformité aux lois et normes ainsi que l'évolution des métiers et de leurs pratiques. Par ailleurs, cette dynamique s'inscrit dans un mouvement plus large d'adoption de stratégies de gouvernance de l'information numérique dans le secteur public, qui représente la majorité des institutions culturelles. Selon le rapport SERDA de 2025, 41% des organisations publiques interrogées déclarent s'être engagées dans une démarche de gouvernance des données<fnref n="5" />, majoritairement de manière partielle et progressive, en expérimentant par métier, par fonction ou par domaine avant de bâtir un programme global de mise en œuvre.

Il est donc essentiel de comprendre les facteurs qui motivent les choix en matière de gouvernance et la manière dont ils influencent la donnée. La section suivante décrira ces facteurs via l'exemple du musée d'Orsay et s'appuiera sur ceux de l'Institut national de l'audiovisuel (INA) et de la BNF pour compléter la réflexion développée.

Les données les plus importantes (en terme de volume et de gouvernance) conservées et produites en institutions culturelles et patrimoniales sont souvent dites documentaires. Ces données sont non seulement le reflet des missions de l'institution mais sont aussi héritées des anciens modes de production, stockage, modélisation, utilisation et gestion de ces dernières. L'histoire de l'institution est alors centrale, de par cette notion d'héritage, dans la compréhension de leur état actuel. Le musée d'Orsay a connu plusieurs changements organisationnels importants depuis son ouverture en 1986⁶. Les deux plus importants sont probablement ses rattachements successifs au musée Hébert en 2003⁷ puis au musée de l'Orangerie en 2010

<footnote>reg/2022/868/oj/fra (visité le 22/08/2025).</footnote>

<footnote n="4">4. « une stratégie d'entreprise relative à la gestion de ses données, de leur flux, leurs accès, leur stockage, leur mise à jour, et leur consommation en son sein, afin d'en optimiser la valeur et l'efficience de traitement. » - « Gouvernance des données », Wikipédia (), URL : https://fr.wikipedia.org/w/index.php?title=Gouvernance_des_donn%C3%A9es&oldid=222988453 (visité le 22/08/2025)</footnote>

<footnote n="5">5. Voir Serda Conseil, *Rapport de la gouvernance de l'information numérique, des datas et de l'IA*, rapp. tech. 14e, 2025, p. 56, URL : https://www.calameo.com/read/004059613353fdba67430?authid=d1nnc9jqNx9p (visité le 28/06/2025), p.14.</footnote>

<footnote n="6">6. *Le musée d'Orsay et ses collections*, URL : https://www.epmo-musees.fr/fr/le-musee-dorsay-et-ses-collections (visité le 11/08/2025).</footnote>

<footnote n="7">7. Décret n° 2003-1300 du 26 décembre 2003 portant création de l'Etablissement public du musée d'Orsay, déc. 2003, URL : https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000000611798 (visité le 20/08/2025).</footnote>
lors de son changement de statut pour son intégration au sein de l'Établissement public du musée d'Orsay et de l'Orangerie <fnref n="8" />. Ces nouveaux statuts impliquent la récupération de la gestion d'une partie des données des musées de l'Orangerie et du musée Hébert. Le musée d'Orsay, comme décrit précédemment est également doté de plusieurs statuts légaux particuliers : musée de France (2002) <fnref n="9" />, musée national (1986) <fnref n="10" /> et grand département patrimonial (2014) <fnref n="11" />. Ces statuts, bien que peu contraignants légalement en ce qui concerne la production et le diffusion de données, imposent tout de même le renseignement scientifique des collections <fnref n="12" />, la participation à la recherche dans le domaine couvert par le musée d'Orsay et lui confère un rôle de référent scientifique à l'échelle nationale <fnref n="13" />. Le statut de musée de France oblige également à la maintenance d'un inventaire patrimonial <fnref n="14" /> des collections ainsi qu'un récolement décennal <fnref n="15" /> qui répondent à des normes de renseignements et de description. Dans le cadre de son rôle de référent national et de sa participation à la recherche, le musée d'Orsay possède depuis son ouverture une documentation qui sert le renseignement scientifique des œuvres conservées mais surtout l'accueil des chercheurs. Les missions des institutions peuvent être définies par des lois et décrets qui peuvent leur donner un statut spécifique, définir directement ses missions et imposer des obligations. Par exemple, la BNF et l'INA, le CNC et les bibliothèques habilitées ont dû faire face à une modification majeure de leurs périmètres lorsqu'elles furent désignées comme organismes dépositaires pour le dépôt légal dans le cadre de l'élargissement des typologies concernées <fnref n="16" />. À l'INA, il a fallu mettre en place la captation, la documentation et l'archivage d'un nombre bien plus important de

<footnote n="8">8. Décret n° 2010-558 du 27 mai 2010 relatif à l'Etablissement public du musée d'Orsay et du musée de l'Orangerie, mai 2010, URL : https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000022272160 (visité le 20/08/2025).</footnote>

<footnote n="9">9. LOI n° 2002-5 du 4 janvier 2002 relative aux musées de France, janv. 2002, URL : https://www.legifrance.gouv.fr/jorf/id/JORFTEXT000000769536/ (visité le 21/06/2025).</footnote>

<footnote n="10">10. Statut acquis dès sa création.</footnote>

<footnote n="11">11. *Article R422-2 - Code du patrimoine*, URL : https://www.legifrance.gouv.fr/codes/articleLC/LEGIARTI000046359267 (visité le 20/08/2025).</footnote>

<footnote n="12">12. Voir l'article 2 de la LOI n° 2002-5 du 4 janvier 2002 relative aux musées de France.</footnote>

<footnote n="13">13. « Les grands départements remplissent à la demande du responsable du service des musées de France à la direction générale des patrimoines et de l'architecture, des missions d'étude, de recherche et de conseil dans le domaine de l'histoire de l'art et de la conservation des biens culturels. » - *Article R422-1 - Code du patrimoine*, URL : https://www.legifrance.gouv.fr/codes/article_lc/LEGIARTI000042982266 (visité le 20/08/2025).</footnote>

<footnote n="14">14. *Paragraphe unique : Normes techniques relatives à la tenue de l'inventaire et du registre des dépôts (Articles D451-16 à D451-21)*, mai 2011, URL : https://www.legifrance.gouv.fr/codes/section_lc/LEGITEXT000006074236/LEGISCTA000024240927/#LEGISCTA000024240927 (visité le 20/08/2025).</footnote>

<footnote n="15">15. Voir l'article 12 de la LOI n° 2002-5 du 4 janvier 2002 relative aux musées de France.</footnote>

<footnote n="16">16. Le dépôt légal a connu un élargissement progressif, mais qui s'est accéléré à partir de la deuxième moitié du XXème siècle avec l'ajout des œuvres « vidéographiques » et « audiovisuelles » (Décret n°75-696 du 30 juillet 1975), puis des « progiciels, bases de données, systèmes experts et autres produits de l'intelligence artificielle » (LOI n° 92-546 du 20 juin 1992 relative au dépôt légal).</footnote>
chaînes de télévision et de radio<sup>17</sup>. D'autres lois majeures ont pu affecter la production et l'état de la donnée institutionnelle telles que l'application du Règlement général sur la protection des données (RGPD), entré en application en 2018 dans la loi française, et les lois liées à l'ouverture des données, en particulier la loi CADA de 1978<sup>18</sup>. Ces lois ont poussé les administrations et institutions publiques à produire des données plus accessibles par leur publication et leur format, à les décrire et à les rendre réutilisables tout en anonymisant les données à caractère personnel.

La structure de la donnée, sa modélisation, son format et son stockage sont aussi très influencés par les normes, généralement développées à l'échelle nationale ou internationale, par typologies de données. Ces normes peuvent être imposées ou non par les autorités comme le Ministère de la Culture. Elles peuvent concerner aussi bien des méthodologies métiers comme la description des documents et biens conservés que des formats ou bien encore des modèles de données (CIDOC-CRM, IFLA-LRM). Par exemple, la BNF est co-responsable avec l'ABES, à l'échelle nationale, de la transition bibliographique visant à se conformer au modèle IFLA-LRM<sup>19</sup>. Au musée d'Orsay, la production des données liées à la description scientifique des œuvres est très fortement influencée par les recommandations et normes mises en places et maintenues par l'ICOM.

La gouvernance des données couvre l'ensemble des activités liées au cycle de vie des données, incluant leur production, le contrôle de leur qualité et la vérification de leur compléture. Elle définit aussi qui a l'autorité pour prendre les décisions concernant la mise en place des politiques et mesures de gouvernance. Au musée d'Orsay, la supervision globale de la base de donnée principale sur les œuvres était pendant longtemps dédiée à une équipe affiliée au service culturel. En raison de leur expertise, le contrôle de la fiabilité et de la complétude des informations scientifiques était délégué principalement aux métiers de la documentation et de la conservation. Cette dernière fut amenée, avec l'informatisation d'un nombre croissant

<footnote n="17">17. « Historiquement crée avec la scission de l'ORTF en 1974 pour la collecte des archives audiovisuelles, la recherche et la formation professionnelle, l'INA a subi un bouleversement dans les années 1990 avec la loi du 20 juin 1992 sur le dépôt légal audiovisuel instaurant le dépôt légal des radios publiques — en 1994 —, des télévisions nationales hertziennes — en 1995 —, et de la télévision par câble et numérique et de radios privées — en 2002, captées directement, permettant alors de s'affranchir du dépôt physique par les producteurs et d'augmenter en masse les données de l'Institut. » - M. Challon, *Les référentiels en institutions patrimoniales : évolution des pratiques et repositionnement. L'exemple des référentiels de l'Institut National de l'Audiovisuel...*, p.31.</footnote>

<footnote n="18">18. *Loi n° 78-753 du 17 juillet 1978 portant diverses mesures d'amélioration des relations entre l'administration et le public et diverses dispositions d'ordre administratif, social et fiscal...*</footnote>

<footnote n="19">19. « Le programme Transition bibliographique a été lancé en 2015 par l'Agence bibliographique de l'enseignement supérieur (ABES) et la Bibliothèque nationale de France (BNF), les deux agences bibliographiques françaises. Il a pour objectif d'améliorer l'exposition des données bibliographiques et d'autorités dans le web de données en leur appliquant le modèle FRBR puis IFLA-LRM et en adoptant de nouvelles règles de catalogage dérivées du code RDA (Ressources : description et accès). » - *Bienvenue sur le site de la Transition bibliographique*, URL : https://www.transitio-bibliographique.fr/ (visité le 22/08/2025).</footnote>
d'activités, l'augmentation de la charge de travail et le changement de solution de gestion de
la base de données à augmenter son nombre de membres jusqu'à se transformer, lors d'une
réorganisation, en un service dédié à la donnée patrimoniale et numérique. Cette organisa-
tion, toujours actuelle, correspond à celle décrite dans l'introduction de ce mémoire. Elle
comprend notamment une équipe de deux gestionnaires entièrement dédiées à la base de
données The Museum System (TMS). Les gestionnaires actuelles sont toujours responsables
de la supervision globale de la base et donc de la complétude, fiabilité et qualité des don-
nées. Pour cela, des protocoles de vérifications réguliers sont mis en place afin d'identifier les
éventuelles anomalies de la donnée, souvent liées aux nouvelles saisies et aux mises à jour des
données. L'équipe du SDPN est également chargée d'assurer le lien entre l'application métier
M'Osaïque<fnref n="20" /> et la solution TMS ainsi que d'organiser les grands travaux d'enrichissement et
de correction. Le musée d'Orsay n'est pas le seul à désigner des responsables pour la donnée.
La BNF possède, par exemple, un département entièrement consacré aux métadonnées et
l'INA une direction « data & technologies ». La BNF, en lien avec son rôle d'autorité, a fait
le choix de mettre en place une politique de qualité pour ses données documentaires<fnref n="21" />. Cette
politique inclut la mise en place d'un référentiel de qualité qui sert d'indicateur au public
comme aux chercheurs, l'intégration d'une politique de la donnée dans le catalogage, prin-
cipale source des données documentaires, et la création d'une équipe dédiée à l'exhaustivité
des signalements. L'INA, dans le cadre des données utilisées pour la plateforme data.ina.fr
utilise plusieurs indicateurs et protocoles de vérification pour assurer leur cohérence et leur
qualité, tout au long de la chaîne de production. Par exemple, en ce qui concerne la trans-
cription automatique de la parole, le Word Error Rate (WER) ou taux d'erreur par mot
est utilisé et vérifié pour ne pas dépasser un certain seuil <fnref n="22" />. Au delà de ces indicateurs, un
protocole de « contrôle de pertinence » est également mis en place pour les personnalités <fnref n="23" />.
Ce protocole met en place une vérification humaine des personnalités les plus identifiées dans
les transcriptions du mois afin de garantir l'absence d'anomalie dans leur identification.

À ces facteurs décisionnels s'ajoutent des enjeux métiers changeants tels que l'informa-
tisation de l'inventaire patrimonial et des informations scientifiques et culturelles, ainsi que
celle des outils de régie des œuvres et d'administration du musée. Les outils de gestion des
données du musée évoluent donc naturellement pour répondre à ces nouveaux enjeux. C'est

<footnote n="20">20. Elle permet aux différents corps de métiers du musée d'assurer principalement les missions de docu-
mentation, de conservation et de régie des œuvres.</footnote>

<footnote n="21">21. *Politique de qualité des données | BnF - Site institutionnel*, URL : https://www.bnf.fr/fr/politique-de-qualite-des-donnees (visité le 13/08/2025).</footnote>

<footnote n="22">22. Analyse des tendances Médias par l'IA - Les traitements réalisés par les outils d'intelligence artificielle utilisés sur data.ina.fr | data.ina.fr, URL : https://data.ina.fr/traitements-ia (visité le 13/08/2025).</footnote>

<footnote n="23">23. Analyse des tendances Médias par l'IA - Règles générales et méthodologies pour calculer ces résultats | data.ina.fr, URL : https://data.ina.fr/regles-generales (visité le 12/08/2025).</footnote>
dans les années 1990 que les premières traces des données informatiques sur les personnes apparaissent au musée d'Orsay, contenues dans deux bases différentes : la base « œuvres » et la base « artistes »<fnref n="24" />. La première servait à renseigner les collections du musée via des notes d'œuvres et comprenait, malgré l'existence de la « base artiste », une table dédiée aux auteurs des œuvres. Elle était alimentée et gérée via le progiciel Basis. La deuxième servait à la gestion et au repérage des dossiers d'artistes de la documentation du musée<fnref n="25" />. Elle fut d'abord développée sous le progiciel Texto puis, pour des raisons de volume et de praticité, en utilisant le Système de gestion de bases de données relationnelles (SGBDR) Oracle<fnref n="26" />. Ces deux bases ont coexisté jusqu'à ce que le musée commence à se pencher sur l'informatisation des déplacements des œuvres et la mutualisation des données des œuvres avec celles de la documentation. Cette volonté de mutualisation des données s'inscrit dans un mouvement de gouvernance des données, commun à bon nombre d'organisations, visant à passer d'une gestion en silos, souvent limitée à des besoins très ciblés, à un mode de gestion de la donnée commune. Au musée d'Orsay, cette tendance est clairement poussée par un besoin et une volonté d'un meilleur contrôle sur les données par les métiers dans le cadre de leur expertise, d'une meilleure accessibilité de ces dernières pour les différents corps de métiers impliqués et d'une plus grande automatisation de la gestion de certaines procédures administratives ou liées à la régie. Cette mutualisation s'est traduite en 1998²⁷ par le développement de la nouvelle application métier et base de données appelée « Base Orsay », fruit de la réflexion incluant les différents métiers du musée. Cette volonté de mutualisation des données est un phénomène commun avec d'autres institutions bien que son origine et ses raisons puissent être différentes. L'INA développe depuis 2015 un projet de « lac de données », visant également à se détacher de la gestion des données en silos<fnref n="28" />. Ce projet consiste à trouver la manière de relier et refondre les différents systèmes d'informations, chacun conçu pour une activité spécifique de l'institution tels que la gestion des archives professionnelles, la mission du dépôt légal mais aussi les devoirs juridiques et enfin les activités commerciales. Ces silos, jusqu'ici hermétiques, transmettaient leurs informations par copie. Le « lac de donnée » permet d'abord une meilleures compréhension, maîtrise, cohérence et accessibilité de la donnée au sein de l'INA. Le projet est motivé par la réduction de la redondance des données et la

<footnote n="24">24. S. Carlier, *Quelles ressources documentaires actuelles pour une base de données artistes ? L'exemple du musée d'Orsay...*</footnote>

<footnote n="25">25. Ibid.</footnote>

<footnote n="26">26. Ibid.</footnote>

<footnote n="27">27. Sylvie Julé et Elsa Badie Modiri, « Changer de système de gestion des collections au musée d'Orsay : un vrai défi ! », dans *Documenter les collections de musées*, 2016, p. 141-144, DOI : 10.3917/ldf.merle.2016.01.0141.</footnote>

<footnote n="28">28. Institut national d'histoire de l'art (INHA), #LundisNum | 11 février 2019 - Gautier Poupeau : rassembler les métadonnées des collections de l'INA, févr. 2025, URL : https://www.youtube.com/watch?v=KYOzoRPks8Q (visité le 22/08/2025).</footnote>
facilitation de développement de projets transversaux. Il garanti aussi une maintenance du système d'information simplifiée et plus économique. La BNF, quant à elle, fait non seulement face à un volume très important mais aussi à son rôle d'agrégateur national et d'autorité. Dans ce cadre, la création de la plateforme data.bnf.fr et du SPARQL endpoint<sup>29</sup> en se basant sur le principe du web sémantique lui permet de regrouper les données à partir des différents silos existants.

Pour mieux répondre aux différents usages nécessaires, l'application « Base Orsay » fonctionnait selon un système de modules, incluant un module dédié au répertoire des artistes qui comprenait donc les données de l'ancienne « base artiste »<sup>30</sup>. Bien qu'elle ait connu un succès critique pour son ergonomie et son accessibilité, l'obsolescence de l'application commence à se faire sentir vers la fin des années 2010. Une obsolescence non seulement technologique mais aussi et encore par rapport à la pratique réelle des métiers dans l'institution. Les principaux manquements de l'application à ce sujet sont décrits par Mmes. Julé et Modiri en 2016 comme suit :

— « [...] de nouveaux besoins fonctionnels sont apparus (gestion prévisionnelle des mouvements, gestion des acquisitions, etc.) avec, dans le même temps, une accélération des rythmes de travail et une augmentation conséquente des mouvements des œuvres ; [...]

— l'essor du document numérique dans le courant des années 2000 a montré toutes les limites de cette application qui n'accepte qu'une seule image d'une œuvre et aucune pièce jointe. »<sup>31</sup>

C'est en partant de ce constat que la nouvelle application métier M'Osaïque fut développée à partir de 2016. Cette dernière fonctionne toujours selon le système de module. Le module dédié au répertoire des artistes, hérité de la « Base Orsay », devient le module Personnes et Institutions. Parallèlement, la gestion informatisée de tous ces nouveaux usages demandait des moyens technologiques et humains plus importants et, surtout, une modélisation de la base données plus adaptée. C'est pourquoi, à la suite d'un appel d'offre au début

<footnote n="29">29. Point de requêtage des données ouvertes et liées de la BNF (modèle en LOD). Voir https://data.bnf.fr/sparql/.</footnote>

<footnote n="30">30. « The integration of this information, done by the museum documentary team, soon proved difficult because of the number of files to check. To give an idea of the task at hand, 34,000 artists were registered with a total estimation of 100,000 references. But the fact that it was not comprehensive made the very use of the database irrelevant. It was therefore decided to "freeze" the database and to merge it with the artists of the Base Orsay. » - Laurence des Cars, Françoise le Coz et S. Julé, « A New Professional Application at the Musée d'Orsay (Paris) », dans *International Cultural Heritage Informatics Meeting : Proceedings from ICHIM 2001. Politechnico di Milano, Milan, Italy, September 3-7, 2001 - Volume 1 : Full Papers*, dir. David Bearman et Franca Garzotto, 2001, p. 573-580, URL : https://www.archimuse.com/publishing/ichim01_vol1/cars.pdf</footnote>

<footnote n="31">31. S. Julé et E. B. Modiri, « Changer de système de gestion des collections au musée d'Orsay... ».</footnote>
des années 2010, Gallery System fut choisi pour sa solution de gestion des collections TMS, toujours sur un modèle de base de données relationnelle. TMS, en plus d'offrir une modélisation des données bien plus adaptée en termes de tables et de granularité de l'information, est utilisé par plusieurs dizaines de musées à l'international. Son modèle de données facilite alors la collaboration, les prêts et la mise en place de projets communs avec ses autres clients, un autre des enjeux clés de cette époque. Pour que la solution puisse être mise en place, un long travail de migration des données de la « Base Orsay » vers TMS fut nécessaire<fnref n="32" />. En premier lieu, ce sont les notices d'œuvres et gestion de la régie qui furent transférées dans la nouvelle base (en incluant données des personnes et institutions). Puis ce fut au tour des données liées au fonctionnement administratif du musée (prêts, historique des expositions, données liées au musée de l'Orangerie et au musée Hébert).

Les données des personnes et institutions du musée d'Orsay sont aujourd'hui réunies au sein d'un même ensemble de tables (voir annexe F section I.) couvrant leur identité (dénomination, nature, domaine, biographie etc.) et leurs informations temporelles et géographiques. Ces personnes et institutions possèdent également des liens entre elles, qui représentent les renvois présents dans les dossiers papier de la documentation, et avec les œuvres conservées. La table principale nommée « Constituents » représente environ 104 000 entités différentes. Malgré les vérifications, les données présentent plusieurs incohérences héritées des deux facteurs principaux : la source de leur production et le changement de modèle de données lors de la migration de la « Base Orsay » vers TMS. Il est important de préciser que des travaux de complétion, de correction et de mise à jour des informations liés à la migration de ces données sont toujours en cours.

Pour les artistes et personnalités, la logique de classement utilisée à la documentation du musée des dossiers papier se reflète dans la structure et le contenu des données. Dans la table principale décrivant toutes les entités personnes et institutions se trouve une colonne servant à indiquer le genre ou la nature de l'entité selon les catégories suivantes :

- homme

- femme

- personne morale

- inconnu

- institution

- personnel EPMOO

- autre

La documentation fonctionnant principalement selon un classement par domaine (personnalités, peinture, sculpture, photographie, arts décoratifs, arts graphiques, architecture) puis

<footnote n="32">32. Environ 2 ans selon notre entretien avec les gestionnaires des données TMS au musée d'Orsay</footnote>
par ordre alphabétique, il arrive alors assez fréquemment qu'une personne morale porte le nom de la personne physique qui en est à l'origine et soit donc rangée dans le même dos-sier. Ainsi, il arrive, par exemple, qu'une entité dans TMS représente aussi bien la personne morale que physique. Cela explique pourquoi une entité typée homme peut avoir pour nom principal celui de la personne morale. Dans le cas du domaine des peintures, plus spécifique-ment pour les peintures étrangères, le classement est également géographique. C'est de ce classement qu'est hérité le référentiel utilisé actuellement pour les pays dans les informations géographiques. Or, la majorité des données géographiques a été saisie il y a un certain temps et il est possible de constater une obsolescence dans la dénomination de certains pays. La migration des données d'un modèle à un autre cause également son lot de difficultés et d'inco-hérences, principalement dues à une différence de granularité de l'information et de formats de la donnée. Les biographies, par exemple, contenaient bon nombre d'informations sur les liens familiaux ou bien sur la profession exercée par l'entité qui, dans TMS, sont des données à part entière avec leurs propres tables. Là où la « Base Orsay » stockait généralement les informations temporelles concernant les entités en utilisant seulement l'année (AAAA), TMS possède une table dédiée permettant le stockage d'une date complète (JJ/MM/AAAA).

Cette analyse de la gouvernance des données au musée d'Orsay révèle ainsi les fac-teurs déterminants dans l'état actuel des données sur les personnes et institutions : l'histoire institutionnelle, les obligations légales, l'évolution des pratiques métiers et les changements technologiques. Ces éléments conditionnent directement la qualité, la structure et la complé-tude des données qui seront confrontées à celles de Wikidata dans le processus d'alignement.

Il convient maintenant d'analyser les spécificités du modèle de données et des pratiques éditoriales de Wikidata pour comprendre les enjeux de cette confrontation.

## II. Wikidata : web sémantique et pratiques éditoriales collaboratives

Tout comme la donnée en institution, l'analyse des pratiques éditoriales et du modèle de données de Wikidata s'avère essentielle pour comprendre les défis de l'alignement. Ces éléments déterminent non seulement la structure et la qualité des données disponibles, mais aussi leur hétérogénéité et leurs biais potentiels. Cette compréhension permettra d'anticiper les difficultés de correspondance entre les deux jeux de données et d'adapter la stratégie d'alignement en conséquence.

Wikidata possède un modèle de données en graphe, s'inscrivant dans les technologies du Web de données et les principes du web sémantique. Le modèle reprend la structure des
triplets RDF dans lequel le sujet est un élément Wikidata, le prédicat est une propriété, l'objet est une valeur et l'assertion du triplet se nomme déclaration. Ces équivalences sont enrichies par trois principes importants : la référence ou source, qui a été mentionnée plus tôt dans la pratique du sourçage, les qualificatifs et les rangs. Ces trois particularités permettent « [...] d'étendre, d'annoter ou de contextualiser les déclarations au-delà de ce que peut exprimer une simple paire propriété/valeur. » <fnref n="33" />. Si les qualificatifs permettent d'ajouter de la nuance, une précision sur la valeur du triplet ou la sémantique de la propriété utilisée, les rangs, eux, permettent d'indiquer un statut pour une valeur donnée lorsque plusieurs valeurs existent pour un même couple sujet/propriété. Les rangs peuvent indiquer trois statuts possibles pour une valeur <fnref n="34" /> :

— *preferred* ou préféré : pour une valeur à jour ou correctement sourceée

— *normal* : le rang par défaut de toute nouvelle valeur

— *deprecated* ou obsolète : pour une valeur dépréciée

Une autre des particularités importantes du modèle de donnée de Wikidata est le type de la valeur dans le triplet. Ces types influent tout d'abord sur la façon dont la donnée est stockée dans la base (format de la donnée, précisions obligatoires etc.) <fnref n="35" /> et permet aussi d'indiquer des restrictions de types lors de la définition des propriétés. Généralement une propriété n'accepte qu'un seul type de valeur <fnref n="36" />. La figure 4.1 montre les différents types originellement acceptés par Wikidata <fnref n="37" /> et le nombre de propriétés liées. Pour des raisons de précision et de complexité de format, d'autres types de données ont été ajoutés pour des domaines spécifiques tels que les expressions mathématiques, les lexèmes, les formes lexicographiques, les notations musicales etc.

L'ontologie de Wikidata permet une pratique collaborative à tous les niveaux de description : les sujets, les propriétés et les qualificatifs sont tous définis et décrits par la communauté via les pages de discussion. Cette ontologie permet aussi la définition et la description de l'ontologie elle-même. Ainsi, le type de valeur « Propriété » existe, permettant de lier des propriétés entre elles. Bien que les décisions ayant un impact très important sur le modèle restent supervisées par les administrateurs et la fondation Wikimédia, les changements, même majeurs, sont toujours débattus avec la communauté. C'est cette grande souplesse décidée dès la conception de l'outil, qui a permis à la plateforme d'éviter, lorsqu'un nouveau cas

<footnote n="33">33. Voir la page Wikidata sur les qualificatifs.</footnote>

<footnote n="34">34. Voir la page Wikidata sur les rangs.</footnote>

<footnote n="35">35. Par exemple, une quantité impliquera toujours une unité.</footnote>

<footnote n="36">36. Par exemple, une propriété définissant un marqueur temporel devra avoir un type de valeur « Point in time ».</footnote>

<footnote n="37">37. Ces types sont liés au fonctionnement de Wikibase, la solution utilisée pour faire fonctionner Wikidata. Voir « Wikibase », *Wikipedia* (), URL : https://en.wikipedia.org/w/index.php?title=Wikibase&oldid=1300524437 (visité le 22/08/2025).</footnote>
Built-in data types

<table><thead><tr><td>Data type</td><td>Number of properties</td></tr></thead><tbody><tr><td>External identifier</td><td>9,619</td></tr><tr><td>Item</td><td>1,700</td></tr><tr><td>Quantity</td><td>673</td></tr><tr><td>String</td><td>343</td></tr><tr><td>URL</td><td>112</td></tr><tr><td>Commons media file</td><td>86</td></tr><tr><td>Point in time</td><td>67</td></tr><tr><td>Monolingual text</td><td>63</td></tr><tr><td>Property</td><td>22</td></tr><tr><td>Geographic coordinates</td><td>10</td></tr><tr><td>Tabular data</td><td>6</td></tr><tr><td>Geographic shape</td><td>3</td></tr></tbody></table>

Extra data types

<table><caption>FIGURE 4.1 – Nombre de propriétés par type de valeurs - Wikidata Help :Data_type.</caption><thead><tr><td>Data type</td><td>Number of properties</td></tr></thead><tbody><tr><td>Mathematical expression</td><td>36</td></tr><tr><td>Sense</td><td>19</td></tr><tr><td>Lexeme</td><td>15</td></tr><tr><td>Form</td><td>10</td></tr><tr><td>Musical Notation</td><td>6</td></tr></tbody></table>

d'usage est proposé, que ce dernier soit incompatible avec l'ontologie définie à la création 38.

Cette très grande implication des utilisateurs n'est pas sans impact sur la qualité, la granularité et la complétude des données. La contribution des utilisateurs est rythmée et motivée par les intérêts et connaissances de chacun mais surtout par les grandes vagues d'édition organisées par des projets, campagnes ou événements spécifiques suscitant un engagement fort de la communauté. Ces vagues influencent grandement l'enrichissement des données et, si elles permettent une augmentation très importante de la quantité de données en peu de temps, il n'est pas rare que certains projets montrent des angles morts et laissent de côté des sujets et propriétés spécifiques. L'impact de ces vagues d'édition est particulièrement visible lorsqu'un changement majeur (la création d'une propriété, d'un qualificatif, d'une nouvelle norme etc.), en lien avec le sujet à l'origine de la vague, apparaît et n'est pas

<footnote n="38">38. « By selecting a fexible, statement-centric data model – inspired by SMW, and in turn by RDF – Wikidata does not enforce a fixed schema upon groups of concepts. This is a maximal departure from the historic Wikidata plan (Section 3), and even from the more fexible (but still template-based) Freebase. There are advantages to such fexibility (e.g., Freebase struggled with evolving schemas or unexpected needs), but it also leads to reduced coherence and uniformity across groups of similar concepts, which is an obstacle to re-use. » - D. Vrandečić, L. Pintscher et M. Krötzsch, « Wikidata... »</footnote>
systématiquement ajouté ou modifié à *posteriori*. Cela peut rendre la pratique éditoriale de la vague obsolète. La diversité linguistique des utilisateurs de Wikidata constitue aussi un autre facteur impactant les pratiques éditoriales des utilisateurs. Les pratiques concernant les champs en texte libre ou bien l'usage de certaines propriétés peuvent être liés à la langue utilisée. Par exemple, la forme des données descriptives d'un élément Wikidata tels que la description ou les labels peuvent varier en fonction des langues. En anglais, pour la description d'êtres humains, il arrivera très régulièrement que les dates de vie et de mort soient mentionnées, et que les labels secondaires soient beaucoup plus nombreux (voir figure 4.2). Ces caractéristiques ne se retrouvent pas systématiquement dans les autres langues.

<table><thead><tr><th>Langue</th><th>Libellé</th><th>Description</th><th>Également connu comme</th></tr></thead><tbody><tr><td>par défaut pour toutes les langues</td><td>Pas de libellé défini</td><td>-</td><td></td></tr><tr><td>français</td><td>Rosa Bonheur</td><td>artiste-peintre et sculptrice française</td><td>Marie Rosalie Bonh...</td></tr><tr><td>anglais</td><td>Rosa Bonheur</td><td>French artist (1822-1899)</td><td>Marie Rosalie Bonh...<br>Rosalie Bonheur<br>Marie Rosa Bonheur<br>Marie-Rosalie Bonh...<br>Rosa Bohneur<br>M^Telle^R Rosa Bo...<br>Bonheur<br>bonheur r.<br>Bonheur Rosa<br>R. Bonheur</td></tr><tr><td>anglais américain</td><td>Rosa Bonheur</td><td>Aucune description fournie</td><td></td></tr><tr><td>espagnol</td><td>Rosa Bonheur</td><td>pintora y escultora francesa</td><td>Marie Rosalie Bonh...<br>Marie-Rosalie Bonh...</td></tr></tbody></table>

Toutes les langues saisies

<caption>FIGURE 4.2 – Capture d'écran des libellés et des descriptions pour l'élément Q241732 (Rosa Bonheur).</caption>

Si certains biais sont dus à la nature collaborative et multilingue de Wikidata, d'autres sont intrinsèquement liés à la pratique de sourçage. Ce sont généralement des biais communs retrouvés dans l'historiographie de bon nombre de domaines de recherche et donc dans les sources utilisées pour renseigner les éléments Wikidata. Ces sources sont, pour la plupart, considérées comme d'autorité par les utilisateurs, du fait de leur reconnaissance dans le domaine concerné ou parce qu'elles représentent une source d'information unique sur le sujet. Ces sources se recoupent donc fortement avec celles utilisées par les métiers de la documentation.
tation et de la conservation pour renseigner les entités personnes et institutions au musée d'Orsay. Par conséquent, les biais engendrés par ces sources sont souvent communs à l'institution et à Wikidata. Par exemple, une publication de 2022 montre que 82% des éléments ayant pour nature « être humain » et dotés de la propriété P21 (sexe ou genre) sont qualifiés de « masculin » contre seulement 18% « féminin » et moins de 1% pour les autres genres <fnref n="39" />. Ces statistiques se vérifient toujours, à peu de différences près, via le site humaniki.wmcloud.org, pour un état de la donnée daté de juin 2025. Si l'on se base sur les types des entités sur la table « Constituents » de TMS au musée d'Orsay, sur un total d'environ quatre-vingt-six mille sept cents personnes physiques, environ dix mille trois cent sont caractérisés en tant que « femmes » contre soixante-seize mille trois cents pour les « hommes » <fnref n="40" />. Cela représente environ 11,8% de femmes contre 88,2% d'hommes <fnref n="41" />.

Les créateurs les moins bien renseignés sont souvent les personnes morales et ce, probablement pour plusieurs raisons : les monographies publiées concernent très largement des personnes physiques mais les personnes morales sont également bien plus difficiles à documenter car il arrive régulièrement que l'on ait peu de sources primaires à leur sujet (archives disparues ou peu nombreuses) et, par leur nature, ces dernières changent très souvent de nom, d'activité ou de type de production. Cette sous-représentation se retrouve également dans la base de données TMS du musée d'Orsay puisque les ateliers, les entreprises et les organismes étant considérés comme des créateurs en arts décoratifs sont généralement caractérisés par le type « personne morale ». Or, les entités ce type s'élèvent au nombre d'environ sept mille cinq cents <fnref n="42" /> soit moins que le nombre de femmes.

Cette analyse révèle que Wikidata présente une structure et des biais propres, principalement liés à sa nature collaborative et multilingue. Cependant, certains biais se recoupent avec ceux présents dans la base du musée d'Orsay, notamment concernant la représentation genrée et la sous-documentation des personnes morales. La compréhension de ces caractéristiques spécifiques et de leurs origines constitue un préalable indispensable à l'établissement du mapping, étape qui doit tenir compte de ces particularités pour optimiser la qualité des correspondances et identifier les limites du processus d'alignement.

<footnote n="39">39. Jere Odell, Mairelys Lemus-Rojas et Lucille Brys, « Wikidata and Gender Equity in Publishing », *Wikidata for Scholarly Communication Librarianship* (, juill. 2022), DOI: 10.7912/8spa-6s68.</footnote>

<footnote n="40">40. Voir le *mapping*, section Genre.</footnote>

<footnote n="41">41. Comme précisé à la section I., ces types servent plus d'indicateurs qu'ils ne représentent la réalité du fait des anomalies qu'ils présentent dans leur attribution suite à la migration de SGBDR.</footnote>

<footnote n="42">42. Voir le *mapping*, section Nature d'entité.</footnote>
III. Le mapping : correspondances sémantiques et for-
mats des données

Dans un processus d'alignement, après avoir identifié le jeu de données à aligner, il faut
déterminer les correspondances entre le modèle de données d'origine et celui de Wikidata.
Cette étape préparatoire nommée mapping permet d'établir une traduction des concepts
utilisés dans le jeu de données source vers l'ontologie et les référentiels utilisés par Wikidata.
Pour cela, cette section expliquera les différentes méthodologies possibles et les défis qu'elles
peuvent engendrer ainsi que la manière d'évaluer leur pertinence. Cette évaluation, dans le
cadre du projet d'alignement du musée d'Orsay, s'appuie non seulement sur l'état actuel
des données extraites de la base TMS mais également sur les alignements préexistants sur
Wikidata réalisés par la communauté.

La méthode la plus rapide pour établir un lien direct entre les deux modèles est de
passer par un identifiant externe commun. Comme décrit précédemment, les valeurs pos-
sibles d'une propriété Wikidata sont déterminées par un type de donnée. Il existe un grand
nombre de propriétés dédiées au type « external-id » ou identifiant externe (voir figure 4.1).
Ces dernières permettent d'établir une correspondance entre un élément Wikidata et son
équivalent dans un autre référentiel, généralement public. Ce référentiel peut être une base
de données, un répertoire de fichiers de contrôles d'autorité ou bien les articles d'une en-
cyclopédie <fnref n="43" />. Cette correspondance est souvent déjà elle-même le résultat d'une opération
d'alignement antérieure. Parmi ces propriétés se trouvent, par exemple, les identifiants de ré-
férentiels d'autorité internationaux tels que VIAF(P214) pour les données des bibliothèques
nationales, International Standard Name Identifier (ISNI)(P213) pour identifier des person-
nalités ou ISBN(P957 et P212) pour les ouvrages. Un grand nombre de ces propriétés sont
également dédiées aux référentiels d'institutions culturelles variées telles que le Getty Mu-
seum avec la ULAN <fnref n="44" />(P245), les archives nationales du Royaume-Uni(P3029) ou bien encore
la Deutsche Digitale Bibliothek (P4948) pour les éléments de son catalogue, pour ne donner
que quelques exemples. Cette méthode est particulièrement efficace lorsque le jeu de données
décrit des entités telles que des personnes, des publications, des concepts réutilisables par
d'autres organisations ou domaines de recherches. Les personnes et institutions décrites dans
la base TMS du musée d'Orsay représentent des entités qui se recoupent, pour beaucoup, avec
les référentiels artistes, créateurs, personnalités de diverses autres institutions culturelles. Ces
croisements de domaines sont bien illustrés par la présence importante de déclarations pour

<footnote n="43">43. Wikidata: *External identifiers* — Wikidata, URL: https://www.wikidata.org/wiki/Wikidata:External_identifiers (visité le 13/08/2025).</footnote>

<footnote n="44">44. Union List of Artist Names. Voir https://www.getty.edu/research/tools/vocabularies/ulan/.</footnote>
des propriétés typées « external-id » pour un même élément Wikidata tel que Rosa Bonheur (Q156843) qui est représenté dans 91 référentiels différents<sup>45</sup>. Elle ne peut cependant pas être utilisée de manière systématique à l'échelle du jeu de données concerné que si ce dernier comprend, pour la totalité des entités décrites, au moins un identifiant extérieur préexistant sur Wikidata. Il est donc nécessaire d'évaluer en amont d'une part la quantité d'entités déjà décrites par un identifiant exploitable sur Wikidata dans le jeu de données source et, d'autre part, dans quelle proportion les propriétés correspondant à ces identifiants sont utilisées dans Wikidata. Cela permet alors de décider de la pertinence de la méthode pour le jeu de données en question. Bien que très efficace, cette méthode n'était pas applicable aux personnes et institutions du musée d'Orsay puisqu'une quantité très faible d'entités avait été signalée sur la base TMS comme possédant un identifiant externe<sup>46</sup>.

Une méthode plus généraliste pour les jeux de données encore non alignés avec des référentiels préexistants sur Wikidata est celle du *mapping* sémantique. Cela consiste généralement en la sélection des propriétés et qualificatifs qui permettent de créer les correspondances sémantiques entre le modèle du jeu de données d'origine et celui de Wikidata. C'est cette méthode qui a été choisie dans le cadre du projet d'alignement au musée d'Orsay<sup>47</sup>. Tout d'abord, il est important de noter qu'il arrive assez fréquemment, du fait de différences de granularité de l'information dans les modèles de données ou de la prise en charge de nuances sémantiques spécifiques, qu'un concept du modèle source corresponde à des propriétés différentes sur Wikidata et vice-versa. Le *mapping*<sup>48</sup> montre, par exemple, que si la différence entre la notion de nom de plume et celle de nom pseudonyme existe dans la base TMS du musée d'Orsay, celle-ci est absente sur Wikidata. Ces deux notions y sont regroupées sous la notion de pseudonyme.

Les listes de propriétés réalisées dans le cadre de différents projets Wikidata permettent,
en fonction du domaine dans lequel le jeu de données source s'inscrit, de constituer un point
de départ à la réflexion en ce qui concerne le choix des propriétés. Par exemple, il existe une
liste concernant l'étude de l'Antiquité de façon générale (littérature, archéologie, mythologies,
référentiels d'institutions concernées etc.)<sup>49</sup>.

Dans le cas d'un jeu de données extrait d'un modèle utilisant des ontologies sémantiques,
il est possible d'exploiter les correspondances déjà établies au sein du modèle de Wikidata
pour ses exports RDF. C'est le cas, par exemple, des libellés et descriptions des éléments
Wikidata qui sont définis par des emprunts directs aux ontologies skos et schema (voir le

<footnote n="45">45. Voir la requête SPARQL référençant ces différentes propriétés.</footnote>

<footnote n="46">46. Seulement quelques dizaines.</footnote>

<footnote n="47">47. Voir le *mapping*.</footnote>

<footnote n="48">48. Voir le *mapping*, section Prénoms / Noms.</footnote>

<footnote n="49">49. *Template :Ancient world properties* — Wikidata, URL : https://www.wikidata.org/wiki/
Template:Ancient_world_properties (visité le 22/08/2025).</footnote>
tableau 4.1). Des mappings vers différents formats et standards communs dans la communauté

<table><caption>TABLE 4.1 – Correspondances entre les libellés Wikidata et les ontologies externes</caption><thead><tr><td>Relation sémantique</td><td>Vocabulaire emprunté</td><td>Description</td></tr></thead><tbody><tr><td>Libellé principal</td><td>rdfs:label, skos:prefLabel, schema:name</td><td>Le libellé principal (nom) d'un élément Wikidata ap- paraît sous ces trois formes dans les dumps RDF.</td></tr><tr><td>Alias / libellé alternatif</td><td>skos:altLabel</td><td>Les alias sont exprimés à l'aide de skos:altLabel, conformément à SKOS.</td></tr><tr><td>Description</td><td>schema:description</td><td>Les descriptions des élé- ments sont fournies via schema:description.</td></tr></tbody></table>

des GLAM<fnref n="50" /> ont également déjà été réalisés, à différents degrés de complétude, vers des propriétés et classes équivalentes<fnref n="51" />. C'est le cas, par exemple, pour l'ontologie Dublin Core avec 24 classes et 33 propriétés.

Cette méthode de mapping implique également une comparaison du taux et de la qualité de renseignement de chaque concept aussi bien du côté institutionnel que de Wikidata afin de pouvoir décider de la pertinence de l'utilisation ou non de la correspondance dans le processus d'alignement. Une utilisation trop faible d'une propriété ou d'un qualificatif sur Wikidata ou, à l'inverse, un taux de renseignement trop faible d'un concept dans le jeu de données d'origine peut justifier l'exclusion de son utilisation lors de l'étape suivante : la génération de proposition d'alignement. Par exemple, au musée d'Orsay, les entités typées « femmes » peuvent présenter parmi leurs noms secondaires, un nom marital. La propriété équivalente sur Wikidata (P2562) n'est que très relativement utilisée à l'échelle du nombre d'entités qualifiées de féminines. Dans ce processus d'évaluation des usages il faut tenir compte de la différence entre le nombre total d'utilisations d'un concept ou de déclaration d'une propriété et le nombre d'entités distinctes concernées. Cette différence est d'autant plus importante que le but est d'évaluer l'utilité d'une correspondance. Si l'on considère le but premier du processus mis en place comme étant un alignement de masse et rapide, il est alors préférable de trouver des correspondances générales correspondant à la majorité des entités traitées. Pour un volume plus petit ou une plus grande précision dans la génération des proposition d'alignement, il est préférable de conserver des correspondances plus spécifiques.

Il reste intéressant de pousser la recherche de correspondances précises dans le cas où

<footnote n="50">50. Galleries, Librairies, Archives and Museums</footnote>

<footnote n="51">51. GLAM/Metadata standards and Wikimedia — Meta, URL : https://meta.wikimedia.org/wiki/GLAM/Metadata_standards_and_Wikimedia (visité le 14/08/2025).</footnote>
la publication des alignements réalisés serait envisagée par le biais de Wikidata. Cette publication implique nécessairement l'emploi d'une propriété typée « external-id » dédiée au jeu de données à aligner. Le *mapping* peut alors servir de support pour choisir les déclarations à ajouter, les qualificatifs à utiliser dans l'optique d'enrichir les éléments Wikidata correspondants ou de la création de nouveaux éléments.

L'évaluation des usages passe également par l'identification de pratiques éditoriales spécifiques aux propriétés utilisées, à la langue visée et au domaine dans lequel s'inscrivent les données. Par exemple, les données d'ordre géographique soulèvent régulièrement un problème lorsque la propriété n'utilise pas de valeurs de type coordonnées géographiques mais un élément Wikidata représentant des continents, des pays, des régions, des communes etc. En fonction des facteurs décrits plus tôt, il arrive que des vagues d'édition privilégient la géographie historique et d'autres l'utilisation des toponymes actuels. Ainsi, il n'est pas rare qu'une personne soit indiquée comme étant née en URSS ou dans le Saint-Empire Germanique. En fonction du référentiel et de la méthodologie employés par l'institution dans le jeu de données source, la qualité des correspondances établies pourra être affectée. De plus, la règle de la majorité de ces propriétés telles que celles indiquant la date de mort ou la date de naissance est de donner le lieu le plus précis possible. La précision majoritaire pour les lieux de naissance ou de mort sur Wikidata est la commune. Cependant, il arrive assez fréquemment que, par soucis de suivre la règle du plus précis, la valeur de la propriété soit un arrondissement ou un quartier. Cela s'observe, dans le cadre des alignements précédemment réalisés par la communauté pour le musée d'Orsay avec les villes de Lyon et Paris (voir la requête SPARQL donnant la liste des personnes nées dans des arrondissements municipaux dans les alignements préexistants sur Wikidata.). Or, le niveau de précision géographique le plus restreint dans la base TMS du musée d'Orsay est la commune.

Dans le cadre du projet d'alignement du musée d'Orsay, l'évaluation de ces usages s'est fait via des requêtes SQL pour la base de données TMS et, pour Wikidata, en effectuant des requêtes SPARQL sur l'ensemble de la base lorsque cela était possible. En effet, pour des raisons techniques, le SPARQL *endpoint* de Wikidata limite le temps de réalisation d'une requête à soixante secondes<fnref n="52" />. Lorsqu'une requête prend trop de temps, cela provoque une erreur dite « time out ». Une requête à l'échelle de la base peut, très régulièrement provoquer cette erreur. Il faut alors trouver un moyen de réduire le champ de la requête<fnref n="53" />, par nature

<footnote n="52">52. « There is a hard query deadline configured which is set to 60 seconds. That is true both for the GUI and the public SPARQL endpoint. If your query does not execute in the allowed time, try to optimize it, or reduce the amount of data it returns. » - *SPARQL/Wikidata Query Service* — Wikibooks, URL : https://en.wikibooks.org/wiki/SPARQL/Wikidata_Query_Service* (visité le 22/08/2025)</footnote>

<footnote n="53">53. Voir les recommandations sur l'optimisation des requêtes sur la page d'aide : *Wikidata:service des requêtes SPARQL/optimisation de la requête* — Wikidata, URL : https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/query_optimization/fr (visité le 22/08/2025).</footnote>
de l'élément sujet du triplet, par exemple. Cela n'est pas toujours suffisant et il arrive sou-
vent qu'il ne soit pas possible d'avoir une idée globale du taux d'utilisation d'une propriété,
d'un qualificatif ou d'un couple propriété-valeur. Il est cependant envisageable de réaliser
cette évaluation en sélectionnant un échantillon d'éléments Wikidata, servant alors de vé-
rité terrain, qui serait cohérent avec le jeu de données source. Le musée d'Orsay bénéficiant
d'un alignement partiel réalisé par la communauté auparavant, il a également été possible
de récupérer les données sur les usages pour les environ trente-sept mille éléments Wikidata
concernés.

Le mapping représente également une occasion de signaler et comparer les différences
des formats de stockage des valeurs. Les données temporelles sont un exemple commun. Ces
dernières correspondent au type *time* ou Point dans le temps. Le stockage de la valeur d'une
date complète correspond à un horodatage basé sur la norme ISO 8601<sup>54</sup>. La structure de
la donnée temporelle de Wikidata ajoute à cet horodatage plusieurs précisions, directement
représentées dans le modèle dédié (voir figure 4.3). Parmi les précisions prévues par le modèle,
si le fuseau horaire (*timezone*) et les valeurs de « before » et « after » ne sont finalement pas
utilisées<sup>55</sup>, la précision et le calendrier sont toujours d'actualité dans les pratiques.

<caption>FIGURE 4.3 – Extrait du dump JSON de l'élément Wikidata Q241732 (Rosa Bonheur) représentant la valeur de sa date de naissance</caption>

```json
"mainsnak": {
  "snaktype": "value",
  "property": "P569",
  "hash": "cd3e799398c3cbc1edbed5cb36c64b0382096091",
  "datatype": {
    "value": {
      "time": "+1822-03-16T00:00:00Z",
      "timezone": 0,
      "before": 0,
      "after": 0,
      "precision": 11,
      "calendarmodel": "http://www.wikidata.org/entity/Q1985727"
    },
    "type": "time"
  },
  "datatype": "time"
}
```

<footnote n="54">54. *Help :Dates - Wikidata*, URL: https://www.wikidata.org/wiki/Help:Dates (visité le 14/08/2025).</footnote>

<footnote n="55">55. « We do not use before and after fields and use qualifiers instead to indicate time period. Timezone is also not used the encoding (Z) suggest UTC timezone (the date in London), but general practice on Wikidata is to save dates as reported in literature, which usually means in local timezone. » - *Ibid*.</footnote>
Wikidata supporte le calendrier grégorien et le calendrier julien, définis respectivement par leur URI Wikidata. La précision indique, quant à elle, l'échelle de précision de la date renseignée. La page d'aide consacrée aux dates sur Wikidata la définie comme suit : « [...] valeur explicite encodée en entier court. Les nombres ont la signification suivante : 0 = milliard d'années, 1 = centaine de million d'années, etc., 6 = millénaire, 7 = siècle, 8 = décennie, 9 = année, 10 = mois, 11 = jour, 12 = heure, 13 = minute, 14 = seconde. ». Il y est aussi précisé que « Les précisions plus grandes que 11 (jours) ne sont plus prises en charge depuis 2021. ». Le modèle permet alors de supporter un grand nombre de pratiques telles qu'elles existent dans les sources des données en fonction des domaines. L'analyse des données du musée d'Orsay montre plusieurs formats pour les données temporelles : comme décrit précédemment, une date peut être représentée seulement par l'année (AAAA) mais également par une date complète (JJ/MM/AAAA). Cette identification des différences de format permet d'évaluer dans quelle mesure il est possible de faire correspondance l'information transmise par la donnée. Dans le cas du musée d'Orsay il est possible d'établir les correspondances nécessaires en reliant l'année simple à au niveau 9 de précision de Wikidata et la date complète au niveau 11⁵⁶.

En définitive, le *mapping* sémantique constitue une étape fondamentale qui dépasse la
simple mise en correspondance de champs de données. Il s'agit d'un travail d'interprétation
et de négociation entre deux modèles conceptuels, visant à établir des ponts sémantiques
robustes et pertinents. L'évaluation minutieuse des usages, des formats et des pratiques édi-
toriales, tant du côté du jeu de données source que de Wikidata, permet de construire des
correspondances fiables et précises. La rigueur de cette phase préparatoire est déterminante,
car elle conditionne directement la précision et la fiabilité des résultats de l'étape suivante :
la génération des propositions d'alignement.

<footnote n="56">56. Voir le *mapping*, section *Données temporelles*.</footnote>
# Chapitre 5

## Génération de propositions d'alignement : les outils et leurs contraintes

Après avoir retracé l'évolution de la gouvernance des données au musée d'Orsay et analysé les spécificités du modèle Wikidata, puis établi les correspondances sémantiques nécessaires lors de l'étape de *mapping*, il convient à présent d'aborder la génération concrète de propositions d'alignement. Cette phase, qui mobilise les acquis des étapes précédentes, nécessite le recours à des outils spécialisés dont le choix et l'utilisation conditionnent directement la qualité des résultats obtenus. La génération de propositions d'alignement consiste à trouver le ou les éléments Wikidata ayant le plus de chances de correspondre au même concept qu'à celui décrit dans le jeu de données source. Ces éléments seront alors désignés sous le terme « candidat ». Le *mapping* prend une place centrale dans la génération de propositions d'alignement puisqu'il permet d'indiquer aux outils de génération, quelles données comparer et comment les comparer. Ce chapitre décrira le fonctionnement général des outils les plus répandus et communément utilisés dans le cadre d'alignements avec Wikidata et exposera les critères qui ont poussé le musée d'Orsay à choisir OpenRefine. Il expliquera ensuite l'étape du prétraitement et formatage des données nécessaire en fonction de l'outil sélectionné.

### I. Les outils les plus communs et leur fonctionnement général

Aujourd'hui, les outils les plus communément employés pour la génération de propositions d'alignements sont Mix'n'Match et le service de réconciliation de Wikidata via le logiciel
OpenRefine ou directement via son API<fnref n="1" />.

Mix'n'match est un outil développé par Magnus Manske<fnref n="2" /> dès les premières années d'existence de Wikidata<fnref n="3" /> qui permet de réaliser des alignements entre des entrées issues de bases de données externes et des éléments Wikidata.

Le service de réconciliation Wikidata repose sur le protocole de réconciliation, initialement développé par Metaweb pour permettre à l'outil Gridworks (devenu OpenRefine en 2012⁴, un projet communautaire) de communiquer avec la base Freebase. Après l'arrêt de Freebase en 2015, ce protocole a été généralisé et adopté par d'autres fournisseurs de données<fnref n="5" />. L'utilisation du service est documentée dès 2019⁶ et sa maintenance est aujourd'hui assurée par la communauté d'OpenRefine. Le service est également accessible directement via une API dont le manifeste est accessible à l'URL https://wikidata.reconci.link/api. Le protocole est quant à lui, maintenu par « the Entity Reconciliation Community Group » du W3C<fnref n="7" /> et existe actuellement sous sa version 2.0.

L'utilisation de ces outils suit essentiellement les mêmes principes. Elle nécessite systématiquement le renseignement des correspondances établies lors du mapping afin que pour chaque entité du jeu de données source, l'outil puisse opérer des comparaisons avec les éléments Wikidata pertinents. Ces comparaisons sont principalement basées sur le nom de l'entité et sur les propriétés renseignées. L'import du jeu de données source dans l'outil implique sa conformité aux formats supportés par ce dernier et donc généralement une étape prétraitement du jeu de données source. Cette étape se fond parfois avec celle du renseignement des correspondances issues du mapping selon l'outil. Il existe aussi systématiquement un moyen d'indiquer la ou les natures (propriété P31) des entités du jeu de données importé. Une fois la génération terminée, l'outil propose, pour chaque entrée du jeu de données source, plusieurs,

<footnote n="1">1. « Une API (application programming interface ou “interface de programmation d’application”) est une interface logicielle qui permet de “connecter” un logiciel ou un service à un autre logiciel ou service afin d’échanger des données et des fonctionnalités. » - *Interface de programmation d’application (API)*, URL : https://www.cnil.fr/fr/definition/interface-de-programmation-d’application-api (visité le 24/08/2025).</footnote>

<footnote n="2">2. A l'origine de plusieurs outils à destination de la communauté de Wikidata dans le but d'en faciliter son enrichissement, son édition et d'améliorer la qualité des données tels que Terminator, Wikidata Game ou Quickstatements. Voir Vrandečić, Pintscher et Krötzsch, 2023.</footnote>

<footnote n="3">3. Plusieurs catalogues importés dans l'outil ont connu un premier import en 2014 et la première activité enregistrée sur le dépôt du code en ligne date de 2013. Cependant aucune date précise n'est mentionnée pour la mise à disposition de l'outil ou sa création.</footnote>

<footnote n="4">4. « OpenRefine », *Wikipédia* (), URL : https://fr.wikipedia.org/w/index.php?title=OpenRefine&oldid=210052560 (visité le 14/08/2025).</footnote>

<footnote n="5">5. Voir la liste des autres services de réconciliation compatibles avec OpenRefine : *Reconcilable Data Sources*, URL : https://github.com/OpenRefine/OpenRefine/wiki/Reconcilable-Data-Sources (visité le 17/08/2025).</footnote>

<footnote n="6">6. Antonin Delpeuch, « Running a Reconciliation Service for Wikidata », dans *Proceedings of the 1st Wikidata Workshop (Wikidata 2020)*, 2020, t. 2773, URL : https://ceur-ws.org/Vol-2773/paper-17.pdf.</footnote>

<footnote n="7">7. Voir la page W3C du groupe : https://www.w3.org/groups/cg/reconciliation/.</footnote>
un seul ou aucun candidat.

## II. Comment choisir le bon outil ?

La pertinence d'un outil peut s'évaluer selon différents critères impliquant ses performances, les moyens humains et techniques de l'institution, sa cohérence avec la méthodologie choisie pour la validation des propositions d'alignement et les objectifs du projet de l'institution. Ainsi nous expliquerons ces critères en s'appuyant principalement sur ceux ayant motivé l'utilisation du service de réconciliation Wikidata via OpenRefine.

Tout d'abord, l'outil doit prendre en charge, lors de l'établissement des correspondances, les particularités du jeu de données source. Bien que cela n'est pas été un obstacle pour le projet du musée d'Orsay, plusieurs cas de figure pourraient poser problème pour d'autres institutions. Par exemple, dans le cas où une institution souhaiterait aligner un référentiel dans lequel les noms des entités seraient écrits en différentes langues, voir différents alphabets, il faudra s'assurer que l'outil permet la comparaison avec les labels de toutes les langues. Si Mix'n'Match ne précise pas dans sa documentation cette possibilité, le service de réconciliation de Wikidata, remplit bien ce critère puisque le choix de la langue du service de réconciliation n'affecte que l'affichage des labels des candidats trouvés<fnref n="8" />.

La qualité et la précision des propositions générées par l'outil constituent également un critère déterminant en fonction des attentes de l'institution et de l'usage qu'il sera fait des alignements. Cette qualité est tout d'abord régie par l'algorithme de comparaison employé par l'outil qu'il est donc important de comprendre. Le service de réconciliation propose un système de score de confiance attribué à chaque candidat, afin de donner un indicateur à l'utilisateur concernant cette qualité. Ce dernier est calculé selon les critères suivants<fnref n="9" /> :

- Si la réconciliation se fait via un identifiant tiers (VIAF, ULAN etc.) et qu'un candidat est trouvé, le score est automatiquement de 100.

- Si la réconciliation se fait seulement sur le nom de l'entrée, le score est simplement

<footnote n="8">8. « When reconciling using this interface, items and properties will be displayed in your chosen language if the label is available. The matching score of the reconciliation is not influenced by your choice of language for the service : items are matched by considering all labels and returning the best possible match. The language of your dataset is also irrelevant to your choice of language for the reconciliation service ; it simply determines which language labels to return based on the entity chosen. » - Documentation d'OpenRefine, section Reconciling, *Language settings* : https://openrefine.org/docs/manual/wikibase/reconciling</footnote>

<footnote n="9">9. Voir les fichiers engine.py, wikidatavalue.py et utils.py du dossier wdreconcile sur le dépôt GitLab du service de réconciliation : https://gitlab.com/nfdi4culture/openrefine-reconciliation-services/openrefine-wikibase/-/tree/68b58b6edf65f0599ae5b60cb65d38c2f8356927/wdreconcile.</footnote>
calculé selon une comparaison des chaînes de caractère approximative. Cette mé-
thode utilise la bibliothèque python « thefuzz » avec la fonction « fuzz_token_sort_ratio() »
qui utilise la distance de Levenshtein une fois les mots de la chaîne de caractère
triés<fnref n="10" />.

— Si la réconciliation se fait sur le nom et sur les propriétés : le score de chaque propriété est calculé en fonction du type de donnée <fnref n="11" />. Ces scores viennent pondérer celui du nom et donner un score total.

— Dans le cas où un candidat n'a pas le bon type, son score est divisé par deux.

Ainsi, l’algorithme utilisé par le service de réconciliation assure une comparaison cohérente et transparente qui s’adapte à chaque typologie de données. La précision et cohérence des propositions obtenues dépend également de la façon dont l’outil détermine et utilise la nature des entités du jeu de données source dans son algorithme de comparaison. Dans les documentation des outils, cette nature est généralement qualifiée de « type ». Le service de réconciliation et Mix’n’Match présentent tous les deux un système similaire en offrant la possibilité d’indiquer un type général, s’appliquant à l’ensemble des entités ou bien en précisant, via la propriété P31, un type par entité. Or, non seulement le jeu de données du musée d’Orsay ne permet pas l’attribution d’un type précis pour l’ensemble de ses entités mais il ne permet pas non plus d’attribuer un type fiable à chaque entité pour les raisons évoquées plus tôt <fnref n="12" />. A la différence de Mix’n’Match, l’indication d’un type plus généraliste, représentant une super-classe comprenant plusieurs autres types, élargi le champ de recherche des candidats. Cela permet alors d’outre-passer les incohérences et anomalies présentes dans le jeu de données du musée d’Orsay.

En fonction du temps alloué au projet d'alignement, la durée de la génération des pro-
positions peut présenter un atout ou un obstacle. Puisque l'outil n'a pas été retenu pour le
projet du musée d'Orsay, il n'a pas été possible de mesurer cette durée pour Mix'n'Match lors
du projet du musée d'Orsay. La génération des propositions via le service de réconciliation
prend un temps plus ou moins important en fonction de plusieurs facteurs tels que le nombre
d'entrées dans le projet, le nombre de propriétés signalées au service de réconciliation, le
volume total des données, la limitation du nombre de candidats et la stabilité du service
choisi. Pour un échantillon de 10 000 entités, et une dizaine de propriétés dont trois colonnes
avec des cellules multivaluées, la réconciliation des entités personnes et institutions du musée
d'Orsay a pris un peu plus de 4h. Cette durée est également déterminée par la stabilité du

<footnote n="10">10. Voir la documentation de thefuzz sur le dépôt Github du projet : https://github.com/seatgeek/thefuzz</footnote>

<footnote n="11">11. Voir la section « Scoring Mecanism » de la documentation technique du service de réconciliation : *Scoring mechanism — OpenRefine-Wikibase reconciliation interface 1.0 documentation*, URL : https://openrefine-wikibase.readthedocs.io/en/latest/scoring.html (visité le 24/08/2025).</footnote>

<footnote n="12">12. Voir Partie II, section I.</footnote>
service de réconciliation au moment de son utilisation qui peut provoquer la génération d'erreurs pour certaines entités ou lots d'entités. Il faut alors relancer la réconciliation pour les entités concernées et ce, jusqu'à ce qu'aucune erreur ne soit renvoyée ce qui augmente la durée de la génération. Un volume important de données et l'utilisation d'un nombre important de propriétés tendent à une plus forte occurrence de ces erreurs <fnref n="13" />. Pour pallier à cela, si le choix se portait sur l'utilisation de l'API du service de réconciliation, il faudrait réaliser des tests de charge des requêtes envoyées à l'API afin d'optimiser leur taille. OpenRefine, quant à lui, gère automatiquement la taille des lots d'entités envoyés au service de réconciliation ce qui permet de réguler le taux d'erreur renvoyé. Le stage au musée d'Orsay n'ayant duré que quatre mois, ces tests de charges ont été abandonnés, faute de temps.

Le profil de la ou les personnes destinées à utiliser l'outil sont aussi déterminantes dans sa sélection. Le formatage nécessaire à l'import des données dans l'outil, l'intégration du *mapping* et le prétraitement des données afin qu'elles soient compatibles et cohérentes avec l'algorithme de comparaison présente un degré plus ou moins important de complexité et donc, certaines connaissances et compétences techniques. Par exemple, utiliser l'API du service de réconciliation par elle-même demandera une maîtrise de l'envoi de requêtes via le protocole HTTP et de la structuration de requêtes contenant les entités et leurs données en format JSON en respectant le schéma imposé (voir figure 5.4). Mix'n'Match propose un import sous forme de fichier .CSV, .TSV ou bien à partir d'une Google Sheets (voir figure 5.1) dont les en-têtes des colonnes doivent respecter la liste précisée à la figure tableau 5.1. Open-Refine, quant à lui, présente une grande souplesse dans les formats acceptés lors de l'import : « TSV, CSV, *SV, Excel (.xls and .xlsex), JSON, XML, RDF as XML, and Google Data documents ». <fnref n="14" /> et permet également le prétraitement des données directement à l'intérieur de l'outil. La prise en main des outils dépendent également de la familiarité préalable de la ou les personnes qui les manipulent, de la clarté et facilité d'utilisation de l'interface et de la qualité de la documentation destinée aux utilisateurs <fnref n="15" />. OpenRefine et le service de réconciliation possèdent tous les deux une documentation fournie <fnref n="16" />. De plus, OpenRefine présente une interface instinctive (voir figure 5.2) qui accompagne le paramétrage de l'intégration du *mapping* pour le service de réconciliation avec une analyse automatique des types représentés

<footnote n="13">13. Selon plusieurs tests réalisés lors du projet d'alignement</footnote>

<footnote n="14">14. Selon l'interface d'import.</footnote>

<footnote n="15">15. Par opposition à la documentation technique</footnote>

<footnote n="16">16. Voir le manuel d'utilisation d'OpenRefine : OpenRefine user manual / OpenRefine, déc. 2022, URL : https://openrefine.org/docs (visité le 24/08/2025) et la documentation du service de réconciliation de Wikidata Welcome to the documentation of the OpenRefine-Wikibase reconciliation interface — OpenRefine-Wikibase reconciliation interface 1.0 documentation, URL : https://openrefine-wikibase.readthedocs.io/en/latest/index.html (visité le 24/08/2025).</footnote>
parmi les entités ou encore une autocomplétion des champs en texte libre. Dans le cas du musée d'Orsay, les compétences de la personne chargée de la génération des alignements lors du stage permettaient l'exploitation de chacun des trois outils.

L'outil sélectionné doit aussi s'intégrer au mieux dans le processus d'alignement défini par le projet de l'institution en respectant la volonté ou non d'une publication des données des alignements ainsi que la méthode de validation choisie. Dans le cas du musée d'Orsay, le choix s'est porté sur une validation scientifique en interne par le personnel de la documentation et de la conservation via l'application 2AMO. Bien que le processus d'alignement mis en place par le musée d'Orsay envisage la publication des alignements réalisés sur Wikidata (voir section I.), cela ne concernerait que les entités du répertoire des artistes et personnalités. L'exposition au public de l'entièreté des entités de la table « Constituent » n'était également pas envisageable, pour des raisons de sécurité, puisqu'elle contient également des informations sur des personnes privées comme les donateurs, les prêteurs et certains membres du personnel de l'EPMOO qui ne sont pas forcément des personnalités publiques<fnref n="17" />. Mix'n'Match fut donc exclu des choix potentiels de par l'obligation de rendre les données publiques et la publication sur Wikidata qui s'en suit, sans que l'institution en garde le contrôle. Concernant l'intégration avec le processus de validation, les trois outils présentent des niveaux de compatibilité variables. Mix'n'Match et OpenRefine disposent tous deux de fonctionnalités de validation intégrées, contrairement à l'API de réconciliation qui ne la supporte que partiellement. Cependant, du point de vue de l'automatisation du flux des données, l'API de réconciliation présente un avantage significatif. OpenRefine, en tant que solution logicielle autonome, nécessite un export manuel des résultats pour les transférer vers l'application de validation 2AMO. Cette étape supplémentaire rend l'intégration moins fluide par rapport à l'API de réconciliation, dont les réponses au format JSON permettent une automatisation plus poussée du processus (voir figure 5.5). OpenRefine conserve toutefois un atout en matière d'operérabilité grâce à son export au format .CSV, format simple et largement compatible avec de nombreux outils et technologies, facilitant les traitements nécessaires à la construction de la base de données relationnelle permettant le fonctionnement de 2AMO.

Par ailleurs, si le projet d'alignement s'inscrit dans une démarche à long terme, il convient de vérifier la pérennité du ou des outils choisis. Dans ce domaine, les trois outils semblent être régulièrement mis à jour. En ce qui concerne OpenRefine, le logiciel est toujours maintenu à jour par la communauté du projet<fnref n="18" />. Quant au service de réconciliation de Wikidata compatible avec OpenRefine, la dernière activité sur le dépôt contenant son code date d'il y a 6 mois au moment de la rédaction de ce mémoire et sa maintenance est constante

<footnote n="17">17. Voir le typage des entités TMS partie II, chapitre 4, section I.</footnote>

<footnote n="18">18. La dernière version disponible lors de la rédaction de ce mémoire date d'avril 2025.</footnote>
depuis sa création en 2002 <fnref n="19" />.

Le choix d'utiliser le service de réconciliation de Wikidata via la solution logicielle OpenRefine offre au musée d'Orsay un compromis, entre fluidité du processus d'alignement, gestion du temps alloué au projet, compatibilité avec ses objectifs et sa méthode de validation.

### III. Import du jeu de donnée, prétraitement, paramétrage de l'outil de réconciliation et extraction des résultats

Comme précisé dans la section précédente, les outils permettant la génération de propositions d'alignement imposent des formats de fichier pour importer les données dans l'outil ainsi que des formats de données attendus par les algorithmes de comparaison. Cette section détaillera les étapes nécessaires dans l'import des données et leur prétraitement pour l'utilisation du service de réconciliation de Wikidata via OpenRefine en s'appuyant sur la documentation du processus d'alignement du musée d'Orsay réalisée lors du stage.

Un import de données dans un outil implique nécessairement l'extraction du jeu de données concerné depuis la base de données institutionnelle. Au musée d'Orsay, l'extraction du jeu de données s'est faite à partir d'une base miroir de la base opérationnelle, mise à jour quotidiennement, et stockée sur un serveur SQL Serveur <fnref n="20" />. L'extraction est réalisée par le biais d'une requête SQL <fnref n="21" /> conçue pour récupérer les données nécessaires à la génération des propositions d'alignement. Elle se base donc sur les correspondances sélectionnées dans le *mapping* à cet effet <fnref n="22" />. Le résultat de la requête est récupéré au format .CSV. Cette extraction est aussi l'occasion d'exclure les entités qui n'ont pas pour objectif d'être alignés ou bien qui n'ont que de très faibles chances de trouver un équivalent sur Wikidata. Par exemple, une « salle polyvalente » de telle ou telle ville qui aurait servi de lieu d'exposition. Cette exclusion est réalisée au moment de la sélection de la liste des identifiants TMS correspondants aux « ConstituentID » de la table « Constituents » à insérer dans la requête

<footnote n="19">19. Voir l'activité du dépôt du code sur GitLab : *OpenRefine Reconciliation Services / OpenRefine Wikibase* · GitLab, oct. 2024, URL : https://gitlab.com/nfdi4culture/openrefine-reconciliation-services/openrefine-wikibase (visité le 24/08/2025)</footnote>

<footnote n="20">20. « Microsoft SQL Server est un système de gestion de base de données (SGBD) en langage SQL incorporant entre autres un SGBDR (SGBD relationnel) développé et commercialisé par la société Microsoft. » - « Microsoft SQL Server », *Wikipédia* (), URL : https://fr.wikipedia.org/w/index.php?title=Microsoft_SQL_Server&oldid=228343551 (visité le 24/08/2025)</footnote>

<footnote n="21">21. Voir annexe I section Les données pour OpenRefine.</footnote>

<footnote n="22">22. Voir les cellules colorées en bleu dans le *mapping*.</footnote>
SQL d'extraction. Cette liste est composée d'un échantillon représentatif en termes de volume et des différents types d'entités présents sur la base. En ce qui concerne les dates de naissance et de mort, la requête SQL applique la règle suivante : par défaut, la date sous le format AAAA est récupérée dans la table « ConGeo ». Dans le cas où une date plus complète existerait dans la table « ConDates », cette dernière écrase la date par défaut et prend le format JJ/MM/AAAA. Cette règle permet une comparaison plus précise pour un élément déterminant dans l'alignement d'une personne physique.

Comme évoqué plus tôt (voir section II.)la durée de la génération des propositions d'alignement dépend en partie du nombre d'entités à traiter. De ce fait, pour des raisons de faisabilité dans le temps imparti, l'échantillon comprend environ 10 000 entités, soit 10% des entités de la table « Contituents ». Chaque type d'entité est représenté dans l'échantillon afin de pouvoir, une fois les premiers travaux d'alignement réalisés, analyser le potentiel d'alignement des différents types et si certains soulèvent des cas de figure complexes. Cet échantillon a été réalisé à l'aide d'un script Python qui sélectionne les entités de façon aléatoire sur l'ensemble de la table « Constituent ». Il inclut tous les types, permet de paramétrer la taille de l'échantillon choisi et donne le pourcentage de répartition des types<fnref n="23" />.

Une fois l'extraction du jeu de données à aligner réalisé, le fichier .CSV peut directement être importé dans OpenRefine afin de créer un « projet »<fnref n="24" />. Pour permettre au service de réconciliation de fonctionner de façon optimale, quelques prétraitements de la donnée ont été nécessaires<fnref n="25" />. Ces derniers s'appuient en grande partie sur l'analyse poussée du jeu de données source et sur le *mapping* qui permettent de mettre en valeur les anomalies, incohérences et valeurs de champs existantes. Premièrement, un nettoyage des anomalies parfois présentes sur les dates de naissance et de mort afin d'être conforme aux formats de dates attendus par le service de réconciliation<fnref n="26" />. Ensuite, la suppression des valeurs qui ne présentent pas de pertinence pour effectuer une comparaison. Par exemple, la colonne « Rôle », qui contient tous les liens entre les entités et la création d'une œuvre, a été mise en correspondance lors du *mapping* avec la propriété « Occupation »(P106). Or, si la majorité des valeurs qu'elle contient correspond bien à une profession, quelques-unes, liées aux pratiques éditoriales sur la base TMS, ne sont pas pertinentes dans ce contexte. C'est le cas des valeurs « producteur de fonds », « exécutant », « anciennement attribué à », « attribué à », « D'après », « atelier

<footnote n="23">23. Voir annexe I section Les données pour OpenRefine.</footnote>

<footnote n="24">24. OpenRefine fonctionne selon un système d'espace de travail isolé qui contient un jeu de données importé et l'historique des opérations appliquées à celui-ci. L'interface du projet prend l'apparence générale d'une table.</footnote>

<footnote n="25">25. Voir annexe I section Quelques traitement de données.</footnote>

<footnote n="26">26. « The precision of Wikibase dates is taken into account when matching them against strings. Query dates are expected to be supplied in ISO format (YYYY-MM-DD) and will match the Wikibase date perfectly if they fall into the range described by the precision. It is also possible to supply query dates in YYYY-MM or YYYY format. » *Scoring mechanism — OpenRefine-Wikibase reconciliation interface 1.0 documentation...*</footnote>
de », « praticien » ou encore « genre de ». Un autre prétraitement a été effectué concernant l'uniformisation de certains noms de pays qui ont parfois été hérités de l'ancien classement de la documentation (voir section I.) mais aussi parfois mis à jour ou saisis dans la base plus récemment. L'exemple le plus flagrant est la coexistence de la « Russie » et de la « Russie, Fédération de ». Enfin, lorsque plusieurs valeurs existent pour un seul couple entité-propriété (une cellule multivaluée), un « déballage » des cellules multivaluées en se basant sur le séparateur « ; ». Cette étape permet au service de réconciliation de comprendre et prendre en compte l'existence de ces valeurs multiples afin de renvoyer des résultats plus pertinents.

Une fois la donnée préformatée et nettoyée, il faut ensuite ajuster les paramètres de l'outil de génération d'alignement selon les critères mentionnés plus tôt<fnref n="27" />. Le paramétrage du service de réconciliation depuis l'interface d'OpenRefine permet (voir figure 5.2) :

- D'indiquer les correspondances sélectionnées et considérées comme pertinentes lors du mapping.

- De sélectionner le type ou une super-classe de type pour éléments Wikidata avec lesquels les entités seront comparées.

- De limiter le nombre de candidats renvoyés.

Face à l'hétérogénéité des natures des entités du jeu de données du musée d'Orsay, il a été choisi de comparer les entités avec des éléments Wikidata dont la nature appartient aux sous-classes de « personne ou organisations ». Il a également été décidé de ne pas limiter le nombre de candidats renvoyés afin de pouvoir, dans des cas complexes liés aux entités morales, laisser la liberté au personnel scientifique du musée de juger de la pertinence de ces derniers.

Une fois la génération des propositions d'alignement terminée, OpenRefine affiche les candidats et leurs scores sous chaque nom d'entité du jeu de données importé (voir figure 5.3). Afin de faciliter la récupération des résultats obtenus, une nouvelle colonne contenant la liste des candidats et leur score correspondant, sous format JSON, a été générée via une formule Python<fnref n="28" />.

Finalement, le projet est exporté sous forme de fichier .CSV.<fnref n="29" />

La génération de propositions d'alignement, si elle repose sur des outils performants et des choix méthodologiques précis, ne constitue toutefois qu'une étape intermédiaire du processus. Ces propositions, souvent nombreuses et de qualité inégale, nécessitent encore un examen critique afin de distinguer les correspondances réellement pertinentes des rapprochements erronés. C'est à ce stade que la validation entre en jeu : elle assure la fiabilité scientifique de l'alignement et conditionne son usage à long terme.

<footnote n="27">27. Voir section II.</footnote>

<footnote n="28">28. Voir annexe I section Extraction des résultats de l'API.</footnote>

<footnote n="29">29. Voir annexe I section Export du projet en csv.</footnote>
## Importer ou mettre à jour un catalogue

<figure><img src="image_16.png" /></figure>

<figure><img src="image_17.png" /></figure>

<figure><img src="image_18.png" /><figcaption>FIGURE 5.1 – Captures d'écran de l'interface d'import de Mix'n'Match (voir https://mix-n-match.toolforge.org/#/import/).</figcaption></figure>
<table><caption>TABLE 5.1 – Les en-têtes de colonne acceptés par Mix'n'Match (voir https://meta.wikimedia.org/wiki/Mix'n'match/Import/fr)</caption><thead><tr><td>En-tête</td><td>Description de la donnée</td><td>Format/Type</td><td>Obligatoire</td></tr></thead><tbody><tr><td>id</td><td>Identifiant de l'entrée dans le catalogue</td><td>Texte ou nombre</td><td>Oui</td></tr><tr><td>name</td><td>Nom de l'entrée dans le catalogue</td><td>Texte</td><td>Oui</td></tr><tr><td>desc (ou description)</td><td>Brève description de l'entrée (255 caractères maximum)</td><td>Texte</td><td>Non</td></tr><tr><td>url</td><td>URL de l'entrée dans le catalogue. Si omis, générée via P1630 + identifiant. Attention aux URLs obsolètes si le format a changé récemment</td><td>URL</td><td>Non</td></tr><tr><td>type</td><td>Type d'entité (supprime le type par défaut)</td><td>QID (ex. Qxxx)</td><td>Non</td></tr><tr><td>born</td><td>Date de naissance</td><td>YYYY, YYYY-MM ou YYYY-MM-DD</td><td>Non</td></tr><tr><td>died</td><td>Date de décès</td><td>YYYY, YYYY-MM ou YYYY-MM-DD</td><td>Non</td></tr><tr><td>autoq</td><td>QID supposé correct (créera un « auto-match »)</td><td>QID (ex. Qxxx)</td><td>Non</td></tr><tr><td>q</td><td>QID confirmé comme correspondant exact (créera une « correspondance manuelle »)</td><td>QID (ex. Qxxx)</td><td>Non</td></tr><tr><td>Pxxx</td><td>Toute propriété Wikidata. Valeurs texte ou QID. P625 peut être renseigné sous forme de coordonnées (« lat/lon »)</td><td>Selon propriété</td><td>Non</td></tr></tbody></table>
<figure><img src="image_19.png" /><figcaption>FIGURE 5.2 – Capture d'écran de l'interface de paramétrage du service de réconciliation Wikidata d'Openrefine.</figcaption></figure>

<figure><img src="image_20.png" /><figcaption>FIGURE 5.3 – Capture d'écran du résultat du service de réconciliation Wikidata dans Open-Refine.</figcaption></figure>
<caption>FIGURE 5.4 – Exemple de structure du contenu d'une requête simple pour l'API de réconciliation Wikidata</caption>

```json
"q0": {
  "query": "Rosa Bonheur",
  "type": "Q5",
  "limit": 5,
  "properties": [
    {
      "pid": "P569",
      "v": "1822-03-16"
    },
    {
      "pid": "P570",
      "v": "1899-05-25"
    },
    {
      "pid": "P106",
      "v": ["Peintre", "Sculptrice"]
    },
    {
      "pid": "P19",
      "v": "Bordeaux"
    },
    {
      "pid": "P20",
      "v": "By"
    }
  ],
  "type_strict": "should"
}
```
FIGURE 5.5 – Exemple de structure d'une réponse pour une requête simple via l'API de réconciliation Wikidata.

```json
"q0": {
  "result": [
    {
      "description": "artiste-peintre et sculptrice française",
      "features": [
        {
          "id": "P569",
          "value": 100
        },
        {
          "id": "P570",
          "value": 100
        },
        {
          "id": "P19",
          "value": 100
        },
        {
          "id": "P20",
          "value": 29
        },
        {
          "id": "P106",
          "value": 100
        },
        {
          "id": "all labels",
          "value": 100
        }
      ]
    },
    "id": "Q241732",
    "match": true,
    "name": "Rosa Bonheur",
    "score": 90.53333333333335,
    "type": [
      {
        "id": "Q5",
        "name": "être humain"
      }
    ]
  }
}
```
# Chapitre 6

## L'enjeu de la validation : l'application 2AMO

Les résultats de la génération de propositions d’alignement résultent en l’obtention de plusieurs, un seul ou aucun candidat pour chaque entité du jeu de données source. Il faut alors concevoir la méthode qui permettra de décider de la validité ou non des résultats obtenus. L’étape de la validation n’est pas seulement un geste technique consistant à accepter ou rejeter une correspondance : elle engage directement la qualité scientifique des résultats, la fiabilité des alignements et, en conséquence, la crédibilité de l’institution lorsqu’elle les publie. Autrement dit, elle conditionne la valeur ajoutée d’un travail d’alignement au-delà de la simple génération automatique de correspondances.

Cet enjeu est d'autant plus important que la validation intervient à l'interface de deux logiques parfois contradictoires :

- celle de la rigueur scientifique, qui suppose une vérification fine, nuancée et contextualisée des alignements ;

- et celle de la gestion de grands volumes de données, qui appelle à l'efficacité, à la rapidité et parfois à l'automatisation partielle ou totale des choix.

Il apparaît alors essentiel d’étudier, sur le spectre des méthodologies possibles, lesquelles correspondent le mieux au contexte institutionnel en termes de moyens humains, de temps et d’objectifs pour le processus d’alignement. Ces méthodologies dépendent principalement de deux axes : les personnes chargées de la validation (communauté ou experts internes), et le degré d’automatisation des choix.

Le développement de l'application 2AMO permet ainsi au musée d'Orsay d'impliquer le personnel de la documentation et de la conservation dans l'étape de la validation tout en l'accompagnant face au volume conséquent des entités à aligner, dans la maîtrise des concepts liés à Wikidata et dans l'adoption de règles communes de traitement. Cet outil