illustre la manière dont une interface peut devenir un espace de médiation entre expertise scientifique et assistance technique, en proposant à la fois des fonctionnalités de validation manuelle, des options de semi-automatisation et une ergonomie pensée pour accélérer les décisions. 2AMO prend la forme d'une application web développée en Python <fnref n="1" /> en utilisant le *framework* <fnref n="2" /> Flask <fnref n="3" />. Les données directement liées au fonctionnement de l'application (gestion des utilisateurs, historiques et enregistrement des décisions et pré-calculs liés à l'affichage des données) <fnref n="4" /> sont enregistrées dans une base de données relationnelle créée à cet effet et stockée sur le serveur interne qui sert aussi à déployer l'application sur le réseau interne du musée. La conception de cette base et le fonctionnement de l'application sont documentés dans les annexe I et annexe J via la documentation du processus d'alignement de 2AMO.

L'analyse qui suit met en lumière les différentes modalités de validation mobilisées dans le cadre du projet : les grands principes qui régissent l'étape de la validation, le rôle central de la validation scientifique, ainsi que les compromis envisageables entre automatisation et contrôle humain à travers l'exemple de 2AMO.

# I. La mise en place d'une méthode de validation

La validation intervient toujours après la génération des propositions d'alignement. Elle consiste principalement en la décision de valider ou refuser l'équivalence entre une entrée du jeu de données source et un candidat. Ces deux actions jouent un rôle principal puisqu'elles se retrouvent avec quelques nuances, dans *Mix'n'Match* <fnref n="5" /> et *OpenRefine* <fnref n="6" /> puisqu'ils gèrent également l'étape de la validation. Dans l'application 2AMO, ces choix <fnref n="7" /> sont principalement concrétisés par le bouton « Valider les candidats sélectionnés » <fnref n="8" /> qui valide tous les candidats sélectionnés par l'utilisateur et refuse les autres. La définition précise des choix possibles assure la cohérence des travaux de validation en fonction des objectifs du projet d'alignement.

Pour assurer le suivi de ces travaux, les décisions réalisées sont enregistrées et stockées sous la forme de statuts attribués aux entités du jeu de données source. Le projet du musée d'Orsay procède à l'attribution de ces statuts pour les entités de la base TMS en plusieurs

<footnote n="1">1. Python est un langage de programmation de haut niveau (proche du langage naturel), et polyvalent. Il est employé et maintenu par une large communauté pour des projets de natures très diverses.</footnote>

<footnote n="2">2. « Framework », *Wikipédia* (), URL : https://fr.wikipedia.org/w/index.php?title=Framework&oldid=223845162#cite note-FranceTerme-3 (visité le 23/08/2025).</footnote>

<footnote n="3">3. Flask est un *microframework* conçu en Python qui apporte une solution légère et relativement peu complexe d'utilisation dans le développement d'application web</footnote>

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

<footnote n="5">5. Voir le schéma décisionnel simplifié de l'étape de validation de Mix'n'Match à l'annexe G.</footnote>

<footnote n="6">6. Voir le schéma décisionnel simplifié de l'étape de validation d'OpenRefine à l'annexe H.</footnote>

<footnote n="7">7. Voir le Schema global du processus d'alignement à l'section I.</footnote>

<footnote n="8">8. Voir la documentation de l'application (annexe J) pour la route « valider ».</footnote>
FIGURE 6.1 – Liste des statuts attribués aux entités extraites de la base de donnée TMS dans celle de l'application 2AMO

- **NULL**: soit aucune valeur. Un ou plusieurs candidats ont été trouvés pour l'entité lors de la génération de propositions d'alignement mais aucune décision n'a encore été prise.

- **aligne**: au moins un candidat a été validé pour l'entité en question.

- **non妙aligne**: aucun candidat n'a été trouvé pour l'entité lors de la génération de propositions d'alignement ou que tous les candidats ont été refusés.

- **match_communaute**: un alignement existe déjà sur Wikidata et il a été réalisé par la communauté via P2268 (identifiant Musée d'Orsay d'un artiste ou d'une personnalité).

- **publie**: au moins un candidat a été validé pour l'entité en question et l'alignement a été publié sur Wikidata via la propriété P2268 (identifiant Musée d'Orsay d'un artiste ou d'une personnalité).

temps. Les premiers statuts sont attribués lors de la construction de la « table_tms »⁹¹⁰, représentant les entités extraites de la base TMS du musée dans la base relationnelle de l'application, dans la colonne « statut_validateur » (voir figure 6.1). L'absence de statut (« NULL ») et le statut « non妙aligné » sont basés sur les résultats de la génération de proposition d'alignement sur OpenRefine. Le statut « match_communauté » a été créé pour pouvoir exclure, dans un premier temps, les entités TMS alignées par la communauté Wikidata du processus de validation. Il permet tout de même, si la décision est trouvée pertinente ultérieurement, de rééntégrer ces entités dans les travaux de validation pour effectuer une vérification des alignements réalisés par la communauté. Dans un deuxième temps, ces statuts sont attribués selon les décisions réalisées par les utilisateurs de l'application. Pour cela, chaque proposition d'alignement, est stockée dans la table « relation_tms_candidat »<fnref n="11" /> où chaque enregistrement représente un couple entité TMS-candidat Wikidata et possède un identifiant unique. Cet identifiant est ensuite repris dans la table « historique », dédiée à l'enregistrement de toutes les décisions réalisées par les utilisateurs, nommées ici « actions ». Lorsqu'un utilisateur valide au moins un candidat ou qu'il refuse tous les candidats pour une entité TMS, le statut de cette dernière change du « NULL » à « aligne » ou « non妙aligne ».

L'attribution de statuts et la définition des choix possibles et de leur impact sur le statut de l'entité ou l'entrée du jeu de données source sont donc essentielles pour toute méthodologie de validation des propositions d'alignement. Elles permettent le suivi des travaux de validation et la cohérence des actions possibles dans l'outil de validation avec les objectifs du projet.

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

<footnote n="10">10. Voir documentation du processus d'alignement (annexe I), section Construction des tables</footnote>

<footnote n="11">11. Voir section II.</footnote>
II. Le choix d'une validation scientifique interne

Wikidata, par sa nature collaborative, a trouvé dans le crowdsourcing<fnref n="12" /> un moyen efficace d'impliquer sa communauté dans la validation et l'enrichissement des données. Parallèlement, de plus en plus d'institutions culturelles et scientifiques s'engagent dans l'inscription de leurs données et de leur patrimoine au sein de la galaxie Wikimédia. Cette participation institutionnelle ouvre de nouvelles perspectives mais soulève aussi des enjeux spécifiques, qui ne se confondent pas totalement avec ceux de la validation communautaire, même s'ils peuvent se recouper sur certains points.

La validation communautaire s'appuie sur la contribution ouverte d'un grand nombre d'utilisateurs. Les alignements vers des référentiels ou des données institutionnelles peuvent être initiés de différentes manières. Ils peuvent résulter de la motivation d'utilisateurs individuels souhaitant enrichir Wikidata avec des informations fiables. Ils peuvent également être portés par des projets thématiques, développés dans le cadre de la galaxie Wikimédia et en lien avec Wikidata, qui visent à organiser et structurer ces alignements de manière collective. Ces initiatives s'appuient généralement sur des outils conçus par et pour la communauté afin de faciliter le travail collaboratif tel que Mix'n'Match. Cette méthode favorise un avancement rapide du travail d'alignement grâce à la mobilisation d'une large communauté, et reflète la dynamique collaborative propre à Wikidata. Elle peut toutefois présenter une certaine hétérogénéité dans la qualité des validations, en raison de la diversité des profils et des niveaux d'expertise des contributeurs mais également de l'engagement de ces derniers et de leur familiarité avec le jeu de données source et les outils employés.

La validation scientifique en interne repose elle aussi sur la mise en place de règles et de critères communs pour la définition des choix possibles. L'internalisation de cette définition et sa délégation au personnel scientifique accroît la cohérence de la validation de part leur expertise. De plus, leur grande familiarité avec le jeu de données source leur offre une plus grande facilité dans la distinction des cas ambigus ou complexes, comme les homonymies, les graphies de noms proches, ou les conséquences des variations de la qualité du jeu de données source sur les candidats proposés. Tout cela permet une meilleure qualité, fiabilité et réutilisabilité des alignements tout en conférant une légitimité académique et institutionnelle aux résultats, ce qui renforce la crédibilité du projet. Cet aspect peut être particulièrement important lorsque les résultats des travaux d'alignement sont publics. Les décisions prises et les critères appliqués étant documentés, cela enrichit la compréhension collective du référentiel et peut nourrir de futures recherches ou projets. Cette démarche permet aussi à l'institution

<footnote n="12">12. Parfois traduit en français par « production participative. ». Voir la définition proposée par Wikipédia : « Production participative », Wikipédia (), URL : https://fr.wikipedia.org/w/index.php?title=Production_participative&oldid=225084894 (visité le 23/08/2025).</footnote>
de contrôler ses priorités, en choisissant de mettre en avant certains ensembles ou thématiques selon ses besoins patrimoniaux ou stratégiques. Au musée d'Orsay, la priorité s'est portée sur les entités représentant des personnes physiques puisqu'elles composent la grande majorité des entités représentées dans la base de donnée TMS (environ 83%) mais également sur le répertoire des artistes et personnalités (environ 95%) et provoque plus rarement des cas de validation très complexes par rapport aux personnes morales.

Cette méthode n'est cependant pas exempte de contraintes. Même partiellement automatisée, elle implique une mobilisation du personnel scientifique et peut entrer en tension avec leurs autres missions. Elle suppose aussi un investissement initial pour formaliser les critères et mettre en place des outils adaptés. Il est en outre nécessaire de prévoir un accompagnement spécifique, avec une sensibilisation à l'écosystème de la galaxie Wikimédia, et plus particulièrement au fonctionnement de Wikidata. Le personnel doit également être formé à l'outil choisi pour la validation. Au musée d'Orsay, le choix s'est porté sur une participation à la validation sur la base du volontariat. Il fallut donc appuyer cette sensibilisation via l'utilité du processus d'alignement dans sa globalité pour le musée et celle de l'implication du personnel de la documentation et de la conservation pour les résultats obtenus. Plusieurs présentations ont été réalisées à ce sujet, notamment dans le cadre de la préfiguration du centre de ressources et de recherche.

Cette méthode remet aussi en question l'utilisation des outils habituels pour l'étape de la validation. Tout comme la validation communautaire, la validation interne est confrontée au besoin d'un outil supportant le travail collaboratif ce qui exclu OpenRefine qui n'est pas conçu pour un usage multi-utilisateurs. Il est aussi nécessaire que l'outil puisse suivre la définition des choix et des statuts précisés en amont en faisant le moins de compromis possibles. C'est principalement à cause d'une cohérence trop faible avec ces choix et statuts qu'il a été choisi de développer l'application 2AMO, offrant une interface de validation interne au service des décisions scientifiques.

Tout d'abord, l'interface devait présenter toutes les informations nécessaires à la réalisation des décisions de validation tout en étant la plus accessible, ergonomique et intuitive possible. Pour cela, les interfaces de Mix'n'Match représentent un bon modèle d'inspiration. Son interface dite « classique » (voir figure 6.4) affiche un résumé des informations essentielles sur chaque entrée du catalogue et son candidat principal. La validation du candidat se fait via le bouton « Confirmer », son refus via le bouton « Supprimer » et le refus de tous les candidats via le bouton « all ». L'interface en mode « jeu » dédie l'entièreté de la page web à une entrée du catalogue. De ce fait, elle développe davantage les informations de l'entrée du catalogue. Les candidats peuvent être choisis à partir de leur correspondance directe de
nom sur Wikidata, à partir de leur correspondance de nom avec un article Wikipédia lié à
un élément Wikidata, à partir d'une correspondance préexistante sur un autre catalogue. Les
informations des candidats sont elles aussi plus développées sous la forme d'un résumé des
données pour Wikidata, d'un extrait de l'article pour Wikipédia, de la description de l'entrée
pour une entrée d'un autre catalogue.

L'exposition claire des informations de l'entité TMS et des candidats ainsi que la mise en évidence des possibilités d'action sont donc elles aussi à l'honneur dans l'interface de validation de l'application 2AMO figure 6.2.

La récupération des données des candidats se fait via des requêtes SPARQL sur Wiki-
data en temps réel<fnref n="13" /> afin de ne pas avoir à les stocker dans base de données de l'application.
Les requêtes exécutées varient si le candidat est un une personne physique ou non. Un travail
éditorial de choix des informations à afficher a été réalisé en amont afin de ne pas surcharger
visuellement l'interface. Ce travail se base essentiellement sur le *mapping* en reprenant en
grande majorité les propriétés liées aux correspondances établies, même lorsque ces dernières
ne faisaient pas partie de la sélection servant à la génération de propositions d'alignement.
En effet, bien que ces dernières, par leur format ou par la différence trop importante de
granularité de l'information, n'aient pas été jugées pertinentes pour l'étape précédente, elles
apportent tout de même un degré d'information supplémentaire important dans le cadre de
la validation. Le *mapping* réalisé par Orsay contient par exemple un exemple de ce cas de
figure en ce qui concerne la biographie des entités. Comme précisé dans la section I., le champ
biographie contient encore aujourd'hui bon nombre d'informations sur les liens professionnels
et familiaux de l'entité. Or, ces informations sont représentées via différentes propriétés sur
Wikidata<fnref n="14" />. Il a donc été décidé de les inclure dans la requête SPARQL dédiée aux per-
sonnes physiques<fnref n="15" />. Wikidata, par nature, permet aussi l'ajout de plusieurs déclarations sur
un même élément qui concernent la même propriété ce qui provoque alors l'existence de plu-
sieurs valeurs pour cette propriété. L'interface de validation de 2AMO affiche ces multiples
valeurs pour différentes raisons. Tout d'abord, la diversité des données en fonction des sources
employées sur Wikidata ou sur TMS pour renseigner les entités telles que les dates et lieux
de vie et de mort ou les dates de création et de dissolution d'une personne morale. Ensuite,
la multiplicité naturelle liée à la nature de l'information représentée comme par exemple
les noms alternatifs, les nationalités, les relations familiales, les relations professionnelles, les
professions exercées ou bien, pour les personnes morales les sièges de l'organisation et les
pays d'appartenance<fnref n="16" />. L'affichage des données des entités extraites de TMS se font égale-

<footnote n="13">13. Voir annexe L.</footnote>

<footnote n="14">14. Voir le *mapping*, section Relations. réalisé lors du processus d'alignement</footnote>

<footnote n="15">15. Voir Annexe section I.</footnote>

<footnote n="16">16. Voir annexe A.II.</footnote>
ment en direct via une requête SQL interrogeant une table conçue à cet effet, stockée sur
le même serveur que la base principale de l'application. Cette table résume les informations
sélectionnées pour l'affichage, en s'appuyant également sur le mapping, afin de simplifier les
requêtes SQL nécessaires à la récupération des données<fnref n="17" />.

Au-delà de sa conception graphique, ses fonctionnalités ont également été pensées pour
accompagner au mieux le personnel scientifique. Tout d'abord, l'intégration des préférences
par domaines représentés à la documentation du musée qui valorise l'expertise de chaque
utilisateur de l'application figure 6.3.

Ensuite, la possibilité de passer une entité <fnref n="18" />, similaire au bouton « Entrée suivante » de
l'interface jeu de Mix'n'Match. Elle permet de pallier au manque de granularité de certains
domaines en laissant la possibilité de ne pas exprimer d'avis sur l'entité lorsqu'elle ne corres-
pondrait pas précisément à l'expertise de l'utilisateur. Par exemple, le domaine « peinture »
représentera aussi bien les peintres français que les peintres étrangers. La prise en compte
du doute nécessairement apporté par la volonté de précision et de nuance d'une validation
scientifique a aussi poussé à l'intégration de liens vers la page du répertoire de l'entité TMS
si cette dernière est publiée et vers les pages Wikidata des candidats. Ces liens permettent
l'accès à des informations supplémentaires dans le cas où elles seraient nécessaires pour tran-
cher des cas de figure complexes. Le répertoire donne, par exemple, accès aux œuvres que le
musée conserve en lien avec l'entité TMS pendant que la page Wikidata présente plus d'in-
formations sur l'activité, la vie, les œuvres du candidat voir des images le représentant. Une
validation scientifique implique également la possibilité de changer d'avis sur une décision de
validation. L'historique des actions de l'utilisateur offre la possibilité d'une vision globale de
ses décisions et permet l'annulation de chacune d'entre elles. L'interface de validation per-
met aussi de contourner un des principaux désavantages de la validation dans OpenRefine et
Mix'n'Match : la possibilité de ne valider qu'un seul candidat Wikidata par entité. Or, une
entreprise, un atelier, une usine change régulièrement de nom, d'emplacement, d'activité ou
de gérant au fil de son existence. Ainsi, là ou Wikidata aura tendance à créer un élément
par phase d'existence de la personne morale, la base TMS du musée d'Orsay ne comprendra
souvent qu'une seule entité ayant plusieurs noms, plusieurs périodes d'activité et plusieurs
liens vers des personnes physiques. Il arrive alors assez régulièrement qu'une entité TMS cor-
responde à plusieurs éléments Wikidata. Pour remplir cette obligation, l'application 2AMO
propose d'abord de sélectionner les candidats correspondants puis de les valider <fnref n="19" />. L'appli-
cation devant permettre la collaboration à l'échelle du musée, elle est déployée sur un serveur
interne. Le système de gestion des utilisateurs permet de garder une trace de chaque décision

<footnote n="17">17. Voir section III.</footnote>

<footnote n="18">18. Voir la documentation de l'application (annexe J), section Route /validation/passer/<int:tms_id>.</footnote>

<footnote n="19">19. Voir la documentation de l'application (annexe J), section Route /validation/valider/<int:tms_id>.</footnote>
réalisée dans la base de données de l'application<fnref n="20" />. Ces décisions sont alors appelées actions
et sont caractérisées par leur nature, le moment de leur réalisation et l'utilisateur qui en est
à l'origine. Cela permet un suivi poussé de l'avancement des travaux de validation. Dans ce
même objectif, l'onglet permettant le choix des préférences donne également un aperçu des
statistiques des travaux de validation par domaine figure 6.3. Pour éviter qu'une entité soit
traitée par deux utilisateurs en même temps, l'application dispose d'un système de verrou
qui s'enclenche dès l'apparition de l'entité dans l'interface d'un utilisateur<fnref n="21" />. L'entité est
déverrouillée dès que l'utilisateur prend une décision (validation, refus ou passer l'entité) ou
au bout d'un certain défini dans les paramètres globaux de l'application.

L'application 2AMO, par son interface graphique et ses fonctionnalités, est donc pensée
en tant qu'outil d'accompagnement à la validation scientifique des propositions d'alignement,
en s'inspirant des modèles préexistant et en s'adaptant aux domaines de spécialités couverts
par le personnel de la documentation et de la conservation. Elle s'adapte aux usages multi-
utilisateurs et favorise la nuance dans les décisions de validation.

<footnote n="20">20. Voir le modèle de la base de données de l'application (section II.), tables utilisateurs et historique</footnote>

<footnote n="21">21. Voir la documentation de l'application (annexe J), section Paramètres globaux.</footnote>
<figure><img src="image_21.png" /><figcaption>FIGURE 6.2 – Capture d'écran de l'interface de validation 2AMO.</figcaption></figure>
<figure><img src="image_22.png" /><figcaption>FIGURE 6.3 – Capture d'écran de l'onglet de paramétrage des préférences de 2AMO.</figcaption></figure>

<figure><img src="image_23.png" /><figcaption>FIGURE 6.4 – Capture d'écran de l'interface classique de validation de Mix'n'Match pour le catalogue de la ULAN.</figcaption></figure>
<figure><img src="image_24.png" /><figcaption>FIGURE 6.5 – Capture d'écran de l'interface en mode jeu de validation de Mix'n'Match pour le catalogue de la ULAN.</figcaption></figure>
III. Un spectre entre l'automatisation complète et la
validation manuelle

Si la durée de la validation de la totalité des propositions d'alignement dépend en
grande partie du nombre de personnes impliquées, de leur engagement dans le processus et
de l'instauration de règles claires, elle peut aussi être altérée par son degré d'automatisation.
Un degré élevé représente un gain de temps considérable, particulièrement lorsque le jeu
de données à aligner présente un volume très important. Une automatisation totale de la
validation implique généralement une gestion non pas par une communauté ou par les métiers
experts des domaines que les données sources décrivent mais plutôt par des profils plus
techniques (ingénieurs, informaticiens, développeurs...). Une automatisation complète peut
prendre plusieurs formes. Elle peut être réalisée par un modèle IA programmé et entraîné
à cet effet. C'est le cas par exemple de l'outil TextRazor utilisé à l'INA dans sa chaîne de
traitement pour la plateforme data.ina.fr <fnref n="22" />. Ce dernier permet de faire de la reconnaissance
d'entités nommées dans le texte issu de la transcription des programmes captés. Les entités
sont ensuite automatiquement alignées avec Wikidata selon un référentiel propre à TextRazor
qui dépend de ses mises à jour. Cet alignement sert alors de passerelle vers le référentiel
documentaire de l'INA. Cette méthode implique systématiquement la génération d'un taux
plus ou moins grand de faux positifs <fnref n="23" /> ou faux négatifs <fnref n="24" /> puisque, malgré le perfectionnement
des modèles via l'entraînement et les référentiels et règles qui leurs sont imposées, il est très
rare voir impossible que leurs résultats soient parfaits.

Elle peut aussi reposer sur des critères et des règles prédéfinies et plus ou moins com-
plexes ou précises. Par exemple, sur le catalogue Mix'n'Match du premier alignement du
répertoire des artistes du musée d'Orsay <fnref n="25" />, dans l'outil de suivi des utilisateurs ayant réalisé
le plus de validation se trouvent plusieurs « robots ». C'est à dire des programmes, eux-même
gérés par des utilisateurs de la galaxie Wikimédia, qui ont pour but de valider automatique-
ment des propositions d'alignement selon certains critères. Les règles suivies par ces « ro-
bots » sont parfois décrites par leur nom tels que « Automatic name/date matcher » ou bien
« Auxiliary data matcher » qui valident automatiquement une proposition d'alignement en

<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...</footnote>

<footnote n="23">23. « Un faux positif est le résultat d'une prise de décision dans un choix à deux possibilités (positif et négatif), déclaré positif, là où il est en réalité négatif. Le résultat peut être issu d'un test d'hypothèse, d'un algorithme de classification automatique, ou tout simplement d'un choix arbitraire. » - « Faux positif », *Wikipédia* (), URL : https://fr.wikipedia.org/w/index.php?title=Faux_positif&oldid=220030120 (visité le 23/08/2025).</footnote>

<footnote n="24">24. Un faux négatif est l'inverse d'un faux positif. Voir la note de bas de page précédente pour la définition de faux positif.</footnote>

<footnote n="25">25. Voir le catalogue : https://mix-n-match.toolforge.org/#/catalog/118</footnote>
se basant sur les données des noms, dates et les données supplémentaires. Dans OpenRefine, la validation automatique d'une proposition d'alignement se base sur le score général renvoyé par l'API de réconciliation. Au-delà d'un certain score, si un seul candidat est compris entre le seuil et 100, ce dernier est validé par défaut. Il est cependant possible de décocher cette option lors du paramétrage de la réconciliation (voir figure 5.2).

Il est également possible d'impliquer les métiers experts du domaine couvert par les données sources dans la définition des règles et critères suivis par le programme ou l'algorithme de validation pour en garantir leur cohérence scientifique. Cela permet de réduire les faux positifs ou faux négatifs mais ne garantit pas forcément le niveau de nuance d'une validation manuelle qui est parfois nécessaire pour l'alignement de concepts complexes. De plus, l'automatisation poussée des alignements, surtout lorsqu'elle vise une publication sur Wikidata ou d'autres plateformes ouvertes, peut soulever des réticences au sein des équipes du musée. En effet, les responsables de la qualité des données peuvent y voir une menace pour leur maîtrise des informations diffusées. Cette appréhension s'explique notamment par la confrontation directe des données institutionnelles avec l'écosystème de Wikidata où les incohérences entre sources deviennent visibles, voire mises en exergue. La publication des alignements ne se limite donc pas à un simple risque d'exposition des contradictions : elle peut aussi, aux yeux du public, éroder la crédibilité des données de l'institution. Dans ce contexte, l'implication des métiers s'avère doublement stratégique. D'une part, elle limite les erreurs en amont ; d'autre part, elle permet aux équipes de s'approprier les résultats, et ainsi d'en évaluer plus finement la qualité. Une telle démarche favorise une adoption progressive des alignements, tout en préservant la confiance dans les données publiées.

A l'inverse, une validation totalement manuelle est envisageable dans le cas d'un faible volume de données ou bien de l'engagement d'un nombre important de personnes dans le processus. Elle est bien plus compatible avec une validation scientifique en permettant un degré de nuance et un regard expert sur chaque proposition d'alignement. La gestion des cas complexes comme lorsqu'une entité du jeu de données source correspond à plusieurs entités sur Wikidata est beaucoup devient plus simple. Cela est arrivé assez régulièrement en ce qui concerne les personnes morales au musée d'Orsay, comme détaillé plus tôt. Le processus devient alors certes plus long mais gagne en qualité, en contrôle et en fiabilité.

Confronté à un volume de données important et souhaitant impliquer les métiers experts dans la validation des propositions d'alignement, le musée d'Orsay a choisi de réaliser une interface qui accompagne et facilite une validation scientifique interne et majoritairement manuelle. Cet accompagnement se traduit par l'introduction de processus semi-automatisés et une optimisation de l'interface pour réduire le temps passé sur chaque proposition d'ali-
gnement.

En premier lieu, lors du traitement des données injectées dans la base de données de l'application, une méthodologie d'exclusion des candidats hors périmètre a été mise en place. Des règles simples d'exclusion, en amont de la validation permettent de réduire le nombre de candidats par entité du jeu de données source et d'éviter de devoir refuser manuellement une proposition d'alignement absurde. Les entités de la base TMS et leurs candidats ont été comparés une première fois selon leurs date de naissance et de mort. Si toutes les dates d'un candidat provoquent un écart de plus de 100 ans lors de la comparaison, ce dernier est exclu des propositions d'alignement pour l'entité TMS concernée<sup>26</sup>. Ce traitement n'était cependant pas possible pour les personnes morales car la date de fondation ou de dissolution de ces dernières n'est que très peu renseignée dans la base TMS. Il a également été envisagé d'exclure des candidats selon leur profession, sans passer par une comparaison avec l'entité TMS associée. Cependant, la table « Constituent » de la base TMS comprend des personnes physiques ayant exercé une très grande variété de professions. Non seulement certains artistes ont pu être sportifs amateurs ou semi-professionnels, mais les personnalités issues de la documentation comprennent également des politiciens, des critiques d'art, des membres de l'aristocratie, des membres du clergé etc. Il était donc difficilement envisageable d'appliquer ce type d'exclusion sans risquer d'écarter les propositions d'alignement pertinentes.

Dans un second temps, la réflexion s'est portée sur l'optimisation de l'interface de validation et de ses fonctionnalités. Tout d'abord, un système de score a été mis en place pour comparer les données les plus déterminantes dans la validation des propositions d'alignement tels que le nom ainsi que les dates et lieux de naissance et de mort. Ce système génère un score par type de donnée de -1, 0 ou 1 pour chaque candidat. Ces scores servent principalement à déterminer la couleur d'affichage de la donnée dans l'interface, servant d'indicateur visuel à l'utilisateur pour une compréhension rapide des correspondances pour chaque candidat<sup>27</sup>. Pour calculer ces scores, plusieurs algorithmes ont été employés selon la nature de la donnée (chaîne de caractère ou date). Ces scores sont stockés dans la table « relation_tms_candidats »<sup>28</sup> dans les colonnes dont le nom débute par « score_flag ». Au moment de l'affichage des données des candidats, ces scores sont récupérés et chaque niveau de score est associé à une couleurUn score de +1 affichera la donnée en vert, une score de 0 affichera la donnée en jaune-orangé et un score de -1 affichera la donnée en rouge.

A cela s'ajoute l'ordre d'affichage des candidats pour une entité. En les triant par ordre

<footnote n="26">26. Voir la documentation du processus d'alignement (annexe I), section Exclusion des candidats ayant des dates avec un écart de + de 100 ans avec celles de TMS.</footnote>

<footnote n="27">27. Ces indicateur sont appelés « flags » ou drapeaux. Voir la documentation du processus d'alignement (annexe I), section Calcul des flags des données principales pour l'affichage dans l'application et voir la documentation de l'application (annexe J), section Fonction get_score_flag_color_class.</footnote>

<footnote n="28">28. Voir section II.</footnote>
décroissant sur le score renvoyé par l'API de réconciliation de Wikidata, l'entité présentant
globalement les meilleures correspondances avec l'entité TMS est présentée en premier.

La façon dont l'application choisit quelle entité TMS proposer à la validation est régie
par deux règles principales : l'entité doit respecter les préférences de domaines de l'utili-
sateur, puis un système de priorisation des propositions d'alignement fait remonter celles
qui ont au moins un candidat avec tous les scores à 1 ou avec un score global le plus élevé
possible 29. Cette deuxième règle accélère l'avancement des travaux de validation en faisant
passer en priorité les entités ayant de fortes chances d'avoir au moins un véritable équivalent
sur Wikidata.

Dans le cadre d'une interface, il est également possible de proposer des variantes des fonctionnalités de base concernant la validation, dans le but de réduire au maximum le nombre de clics nécessaires à l'indication du choix de l'utilisateur. L'interface de l'application 2AMO comprend, par exemple, un bouton pour refuser tous les candidats possibles d'une entité dans le cas où aucun ne serait pertinent 30 (voir figure 6.2). Les pistes d'amélioration de l'application comprennent également l'implémentation d'un bouton qui combinerait la fonction de sélection et de validation pour un candidat. Ce bouton serait alors présent pour chaque candidat 31.

Une fois les fonctionnalités de l'interface bien maîtrisées, plusieurs options de validation semi-automatiques, basées sur les retours de métiers impliqués et sur les résultats obtenus pourront être proposées. Parmi celles envisagées pour le projet d'alignement du musée d'Orsay se trouvent :

- Une règle générale qui validerait automatiquement tous les candidats présentant un score de 1 dans tous les scores calculés pour l'application et qui refuserait tous les candidats présentant seulement des scores à -1.

- Une règle qui validerait ou refuserait automatiquement tous les candidats, basée sur le score global renvoyé par l'API de réconciliation, en déterminant un seuil bas pour la validation et un seuil haut pour le refus.

L'instauration de règles de validation automatiques après le début des travaux de validation prend en compte la pratique développée par les métiers sur l'interface, les règles qu'ils ont décidé d'appliquer en fonction des différents cas de figure, les cas particuliers qu'ils ont pu rencontrer et permet de mettre en commun leurs retours pour améliorer l'interface.

<footnote n="29">29. Voir la documentation de l'application (annexe J), section Fonction get_entite_tms.</footnote>

<footnote n="30">30. Voir la documentation de l'application (annexe J), section Route /validation/refuser-tous-candidats/<int:tms_id>.</footnote>

<footnote n="31">31. Voir documentation de l'application (annexe J), parmi les pistes d'amélioration, section Rajout d'un bouton de choix et validation immédiate sur chaque candidat.</footnote>
Pour conclure, si une validation manuelle présente beaucoup d'avantages dans le contrôle
des résultats du processus d'alignement, la qualité des alignements réalisés et la gestion des
cas de figure complexes, cette dernière implique une durée des travaux de validation impor-
tante face à un grand volume de donnée. Il est possible de trouver un entre-deux et d'accélérer
ces travaux en incorporant des règles d'automatisation simples en amont ou pendant les tra-
vaux. L'interface de validation prend également toute son importance en rendant les décisions
plus rapides par ses fonctionnalités et son affichage.
Troisième partie

Quelle pérennité pour les alignements
avec Wikidata ?
<figure><img src="image_25.png" /></figure>
Après avoir décrit la construction des alignements et les modalités de leur validation, il reste à s'interroger sur ce qu'il advient de ces correspondances une fois établies. Un alignement n'a de sens que s'il s'inscrit dans la durée et trouve une utilité concrète pour l'institution qui l'a produit. Cette troisième partie aborde donc une double question : celle de la pérennité des alignements, d'abord, en examinant leur stabilité face à la volatilité des données, les conditions de leur réitération et les choix techniques qui conditionnent leur stockage et leur traçabilité ; celle de leur valorisation ensuite, en montrant comment ces correspondances peuvent être exploitées au sein des institutions culturelles, publiées sur Wikidata et intégrées dans le Web de données. Il s'agit en somme de comprendre comment transformer un travail d'alignement ponctuel en un véritable levier stratégique, capable de renforcer la qualité documentaire interne tout en ouvrant les collections à de nouvelles formes de circulation et de visibilité.
# Chapitre 7

## La pérennité des alignements et du processus

Une fois les alignements avec Wikidata réalisés et validés, les institutions culturelles se trouvent confrontées à des questions stratégiques déterminantes pour la valorisation de leur travail : comment garantir la durabilité de ces correspondances établies entre leurs données et celles de Wikidata ? Comment s'assurer que l'investissement en temps et en ressources humaines consenti pour ce projet d'alignement continuera à porter ses fruits sur le long terme ? La pérennité d'un processus d'alignement ne se limite pas à la simple conservation des résultats obtenus. Elle englobe un ensemble complexe de considérations techniques, organisationnelles et méthodologiques qui déterminent la viabilité du projet dans la durée. Les institutions doivent arbitrer entre différentes contraintes (budgétaires, humaines et techniques) et diverses exigences de qualité, d'accessibilité et de maintenance. Cette réflexion sur la durabilité soulève plusieurs interrogations fondamentales. Faut-il concevoir le processus d'alignement comme une opération ponctuelle, circonscrite dans le temps, ou comme un mécanisme réitérable qui accompagnera l'évolution continue des collections ? Comment anticiper et gérer la volatilité inhérente aux données, qu'elles proviennent des bases institutionnelles ou de Wikidata elle-même ? Quelles stratégies adopter pour le stockage, la traçabilité et la documentation des alignements produits ? Ces questions trouvent des réponses différentes selon le contexte institutionnel, les objectifs poursuivis et les moyens disponibles. L'expérience du musée d'Orsay, avec le développement de l'application 2AMO et la mise en place d'un processus d'alignement évolutif, offre un cas d'étude concret pour examiner ces enjeux de pérennité et les solutions pratiques qui peuvent y être apportées.
## I. Processus d'alignement ponctuel ou réitérable ?

Comme nous l'avons expliqué lors de la partie précédente, la conception d'un processus d'alignement dépend grandement des objectifs du projet de l'institution, de ses effectifs, du temps et des moyens qu'il est possible d'y allouer. Selon ces mêmes critères, il est possible qu'une institution choisisse de rendre le processus d'alignement réitérable ou non. Dans le cas du musée d'Orsay, l'alignement qui sera réalisé par le personnel du musée sur l'échantillon de dix mille entités servira de test pour réaliser l'alignement du reste des entités présentes dans la table « Constituents »<fnref n="1" />. de la base de données TMS. En fonction des retours du personnel participant à la validation sur les cas de figures plus ou moins complexes rencontrés et de l'analyse des résultats obtenus, il sera possible de déterminer s'il faut intégrer des changements au processus tel qu'il est conçu actuellement. Le processus a donc d'abord pour vocation à se poursuivre en adaptant la méthodologie pour mieux évaluer les priorités et les automatisations possibles (voir partie II, chapitre 6, section III.). Une fois la majorité des entités traitée, il est envisagé de relancer le processus en se basant potentiellement sur deux facteurs : le temps passé depuis la fin du premier projet d'alignement et le taux de création de nouvelles entités dans la table « Constituents » (voir figure 7.1).

Rendre le processus réitérable implique de prendre en compte la maintenance des outils, scripts et autre moyens technologiques qui y sont employés. Cela renvoie aussi bien au point soulevé sur l'importance de la maintenance de l'outil de génération des propositions d'alignements (voir partie II, chapitre 5, section II.) qu'à la maintenance des solutions choisies pour l'étape de la validation. En ce qui concerne l'utilisation du service de réconciliation et d'OpenRefine, le musée d'Orsay dépend des projets communautaires chargés de leur maintenance. L'application 2AMO, quant à elle, repose principalement sur la maîtrise par l'équipe du SDPN des technologies du web (HTML, CSS et JavaScript) et du langage Python ainsi que la maintenance et la mise à jour de la base de données principale de l'application. Si le choix s'est d'abord porté sur ces technologies par facilité pour le développement de l'application lors du stage, il réside aussi dans la forte expérience en développement Web de certains membres du SDPN. Le langage Python bénéficie également d'une très large communauté d'utilisateurs et une documentation extensive disponible en ligne pour les différentes bibliothèques utilisées. La maintenance de l'application a été facilitée par la production de la documentation de ses fonctionnalités principales (voir annexe J) et le respect des conventions de commentaires à l'intérieur du code source lui-même. Le code source et la méthode de déploiement de l'application sur le serveur interne du musée sont également postés sur un dépôt GitHub privé, accessible aux membres de l'équipe du SDPN chargés de la maintenance

<footnote n="1">1. Voir annexe F, section I.</footnote>
du processus, ce qui participe à rendre la résolution de *bugs* potentiels plus simple. Le dépôt permet, grâce à son interface, de suivre précisément les différentes modifications et versions du code ainsi que la réalisation de tests.

Enfin, bien que cela ne soit pas envisagé dans le cas du musée d'Orsay, si l'institution prévoit de changer de solution de gestion des données ou de modèle de données, il est nécessaire d'adapter le processus, voire de le refondre dans sa totalité, afin qu'il corresponde au nouvel écosystème numérique dans lequel il s'inscrit.

De façon générale, à l'échelle d'un processus d'alignement, la documentation joue un rôle crucial lorsque la réitération du processus est envisagée. Cette documentation sert d'appui aux personnes chargées de sa maintenance et doit s'adapter à leurs compétences techniques. La documentation interne au code et scripts, lorsque cela est nécessaire, doit aussi permettre une prise en main rapide des fonctionnalités de ces derniers en respectant les normes et bonnes pratiques en vigueur.

Le choix entre un processus ponctuel ou réitérable conditionne donc l'ensemble de l'architecture technique et organisationnelle du projet d'alignement. Dans le cas du musée d'Orsay, l'approche réitérable adoptée implique une attention particulière à la maintenance des outils développés et à la documentation des procédures. Cette approche présente l'avantage de pouvoir s'adapter aux évolutions des données, mais elle soulève également la question de la stabilité des correspondances établies. En effet, la réitérabilité du processus n'est viable que si l'on peut s'appuyer sur des données suffisamment stables pour maintenir la validité des alignements dans le temps. Or, les données institutionnelles comme celles de Wikidata sont sujettes à des modifications régulières qui peuvent remettre en question les correspondances initialement validées. Cette volatilité des données constitue donc un enjeu majeur pour la pérennité des alignements.
<figure><img src="image_26.png" /><figcaption>FIGURE 7.1 – Taux moyen de création d’entités dans la table « Constituents » par mois (2018-2025)</figcaption></figure>

## II. Volatilité des données Wikidata et institutionnelles

La pérennité des alignements repose également dans la durabilité de la validité des choix réalisés lors de la validation. Cette validité dépend avant tout de la méthodologie et l'outil de validation employés mais aussi sur les données utilisées lors des comparaisons réalisées par la génération des propositions d'alignements. Que ce soient les données institutionnelles ou celles qui proviennent de Wikidata, les correspondances établies s'appuient sur l'état des données au moment de la réalisation du projet d'alignement.

Les données de Wikidata sont elles aussi, sujettes à des changements réguliers allant de l'édition manuelle simple pour modifier le rang d'une information ou ajouter une déclaration supplémentaire à l'édition massive réalisée par des robots. Ces éditions massives peuvent être liées à un changement de définition du cadre d'utilisation d'une propriété ou d'un qualificatif. Elles peuvent aussi provenir d'un projet thématique monté par un collectif ou un groupe transversal impliqué dans la galaxie Wikimédia, provoquant des vagues d'édition<fnref n="2" />. Il arrive aussi que des administrateurs ou des utilisateurs proposent la fusion ou la suppression d'un élément lorsqu'un doublon de ce dernier est repéré<fnref n="3" />.

<footnote n="2">2. Voir partie II, chapitre 4, section II.</footnote>

<footnote n="3">3. Pour plus d'information sur les raisons d'occurrence de ces doublons et la gestion suggérée par la communauté voir : *Help :Deduplication* — Wikidata, URL : https://www.wikidata.org/w/index.php?title=Help:Deduplication (visité le 04/09/2025).</footnote>
Les changements dans les données peuvent parfois être concomitants et similaires en institution et sur Wikidata, puisque les sources utilisées pour alimenter les deux bases de données peuvent se recroiser 4. La mise en ligne d'une nouvelle source qu'elle soit une publication scientifique, d'un jeu de données issu d'une autre institution ou d'une organisation publique, provoque généralement le même genre de modifications, mais pas nécessairement au même moment.

Au musée d'Orsay, l'ensemble des données concernant les personnes et institutions ne semble pas présenter un fort taux d'édition (voir figure 7.2). La majorité des changements proviennent de corrections ou d'ajouts lorsque qu'une entité est concernée par une exposition, un prêt, un don ou un projet de recherche particulier. Cependant, afin de garder une trace des changements sur les données utilisées lors de la validation, la table dédiée à l'affichage des données extraites de la base de données TMS pour l'application 2AMO est dotée d'une colonne « db_update » (voir section III.) qui permet de connaître la dernière mise à jour des données. Il est possible de comparer l'horodatage de mise à jour des données de cette table avec ceux des actions dans la table dédiée à l'historique des choix réalisés par les utilisateurs (voir table « historique », annexe I section II.) afin de connaître la conformité avec l'état actuel de la base des informations utilisées lors de la validation ou le refus des candidats. Le projet OpenRefine réalisé pour la génération des propositions d'alignement garde également des métadonnées qui permettent de dater l'état des données utilisées par le service de réconciliation pour établir les comparaisons (date de création du projet par exemple).

La volatilité des données constitue donc un défi constant pour la pérennité des alignements. Les modifications régulières sur Wikidata comme dans les bases institutionnelles peuvent remettre en question la validité des correspondances établies. Pour faire face à cette instabilité, il devient essentiel de mettre en place des mécanismes de traçabilité permettant de dater les informations utilisées lors de la validation, comme le fait le musée d'Orsay avec les colonnes d'horodatage dans l'application 2AMO. Cette nécessité de traçabilité soulève naturellement la question plus large du stockage des alignements et des formats à adopter pour garantir leur exploitation sur le long terme.

<footnote n="4">4. Voir partie II, chapitre 4, section II.</footnote>
<figure><img src="image_27.png" /><figcaption>FIGURE 7.2 – Évolution du taux moyen de modifications mensuelles de la table « Constituents » (2018-2025)</figcaption></figure>

III. Stockage, traçabilité et formats des alignements

L'institution, une fois avoir réalisé des alignements, doit être en mesure de les utiliser et donc d'appréhender la question de leur stockage, leur traçabilité et leur format. En ce qui concerne le stockage, deux grandes catégorisations sont souvent citées lorsqu'il s'agit de données en entreprise ou en institution :

— Le stockage froid : dédié aux données dites « froides », « qui ne sont que très peu utilisées et donc très peu accédées. C'est un peu l'équivalent d'un carton de documents dans un grenier. On peut potentiellement un jour en avoir besoin, mais on ne l'ouvre quasiment jamais. On s'attend ainsi à ce que les temps de récupération de données froides soient un peu plus longs. »<fnref n="5" />.

— Le stockage chaud : dédié aux données dites « chaudes » ou « données actives, qui sont accédées souvent, voire de façon intensive. »<fnref n="6" />.

Si la « notion de température des données se distingue de la notion de durée de conserva-

<footnote n="5">5. *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).</footnote>

<footnote n="6">6. Ibid.</footnote>
tion »<fnref n="7" />, les données froides sont tout de même plus souvent dédiées au stockage sur le long terme comme l'archivage d'une base de données ou de ressources numériques en tous genre. La température des données implique aussi généralement une différence du support de stockage et de l'infrastructure technique pour accéder aux données. Les supports utilisés pour un stockage froid, coûteront généralement moins cher puisque moins performants en rapidité l'accessibilité et moins gourmands en énergie. Des données chaudes nécessiteront une plus grande rapidité d'accessibilité et donc des supports souvent plus chers et une infrastructure avec une consommation énergétique plus haute de par son activité presque permanente. La température des données résultant de l'alignement dépend grandement des supports et infrastructure préexistantes dans l'institution mais aussi des objectifs du projet d'alignement. En fonction de leur utilité interne, il est possible que ces données soient fréquemment consulteres. Dans le cadre d'un processus *one-shot*, c'est-à-dire, qui n'a pas pour vocation à être réitérable, un stockage à froid pourrait alors se présenter comme une solution optimale si les objectifs du projet d'alignement n'impliquent pas leur utilisation fréquente. Dans le cas du musée d'Orsay, si l'utilité des alignements est détaillée dans le chapitre suivant, leur stockage dans une base relationnelle sur un serveur dédié à l'utilisation de l'application en font pour l'instant des données chaudes. Les alignements concernant les entités publiées dans le répertoire des artistes et personnalités seront également publiés sur Wikidata via la propriété (P2268) en ajoutant une déclaration aux entités préexistantes. Cette publication peut être considérée comme un « stockage » de l'information résultant de la validation d'un ou plusieurs candidats Wikidata pour une entité de la base de données TMS. Dans le cas du musée d'Orsay, ce « stockage » n'est que partiel mais il permet une copie d'une partie de l'information sur la base de données de Wikidata et un accès rapide via le SPARQL endpoint. Lorsque le personnel scientifique aura validé un nombre important d'alignement, les identifiants des candidats Wikidata validés pourront s'inscrire dans la table « AltNum » de la base de données TMS<fnref n="8" /> dédiée à cet effet. Cela permettra une exploitation de ces alignements plus simple puisqu'insérés dans le système documentaire général du musée et donc accessibles via l'application métier M'Osaïque, par exemple. Ce mode de stockage est toujours considéré comme chaud puisque la base de données est modifiée et accédée en permanence pour les missions du musée.

Bien que le modèle de données proposé par TMS ne s'y prête pas, il est envisageable pour certaines institutions de stocker les alignements validés sous forme de triplets RDF en s'appuyant sur une propriété de correspondance (voir partie I, chapitre 2, section II.). La plateforme data.bnf.fr enregistre l'équivalence établie vers un même concept via la propriété

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

<footnote n="8">8. Voir annexe F section I.</footnote>
« skos:exactMatch ». Dans la figure section III., le lien vers l'élément Wikidata est clairement
visible.

<figure><img src="image_28.png" /><figcaption>FIGURE 7.3 – Extrait de l’export des données RDF en format JSON-LD de la page dédiée à George Sand sur data.bnf.fr.</figcaption></figure>

Si la traçabilité de ces données résultant du projet rejoint les propos liés à la volatilité des données dans la section précédente, elle implique aussi, dans le cadre de la publication sur Wikidata des alignements, de pouvoir différencier les alignements réalisés par la communauté de ceux publiés par l'institution. Ainsi, la « table_tms » de la base principale de l'application 2AMO propose deux statuts différents dans la colonne « statut_validation » : « match_communauté » ou « publie » (voir figure 6.1).

Le choix des modalités de stockage des alignements conditionne directement leur ex-
ploitation future. Entre stockage chaud et froid, formats propriétaires et standards ouverts,
base relationnelle et triplets RDF, chaque solution répond à des besoins et contraintes spécifiques. L'expérience du musée d'Orsay illustre cette diversité d'approches : stockage dans une base relationnelle pour l'application 2AMO, publication partielle sur Wikidata via la propriété P2268, et intégration future dans la table « AltNum » de TMS. La pérennité d'un processus d'alignement repose ainsi sur un équilibre entre contraintes techniques, organisationnelles et budgétaires. Les choix effectués pour la réitérabilité, la gestion de la volatilité des données et les modalités de stockage déterminent la capacité de l'institution à tirer parti de ses alignements sur le long terme. Mais une fois ces questions de durabilité résolues, se pose naturellement la question de l'exploitation concrète de ces correspondances : comment les alignements produits peuvent-ils enrichir les missions de l'institution et s'inscrire dans l'écosystème plus large du Web de données ?
# Chapitre 8

## L'utilisation des alignements et l'inscription dans le Web de données

Au-delà des enjeux techniques et méthodologiques de leur production, les alignements avec Wikidata ne trouvent leur pleine valeur que dans leur exploitation effective. Une fois établis et pérennisés, ces liens entre référentiels institutionnels et base de connaissance collaborative ouvrent un éventail de possibilités qui dépassent le simple exercice d'interopérabilité. Ce chapitre explore trois dimensions complémentaires de cette exploitation. D'abord, la publication des alignements sur Wikidata constitue un vecteur de visibilité scientifique qui permet aux données institutionnelles de s'inscrire dans l'écosystème du Web de données tout en valorisant l'expertise spécifique de l'institution. Ensuite, ces correspondances offrent un outil précieux pour l'amélioration interne de la qualité des données, en révélant les lacunes ou incohérences par confrontation avec les informations présentes sur Wikidata. Enfin, les alignements facilitent l'interopérabilité entre référentiels institutionnels et ouvrent la voie à de nouveaux projets de recherche collaboratifs. L'objectif est de démontrer que les alignements constituent un moyen stratégique d'inscription dans le Web sémantique et de valorisation des données culturelles, tout en servant l'amélioration continue de la qualité documentaire des institutions.

### I. Un outil de visibilité et de valorisation scientifique

La publication des alignements sur Wikidata dépasse la simple mise à disposition de correspondances entre référentiels. Elle s'inscrit dans une démarche de valorisation scientifique qui permet aux institutions culturelles de faire rayonner leurs collections et leur expertise au-delà de leurs propres plateformes. Cette visibilité s'articule autour de deux axes complémentaires : d'une part, l'exploitation des alignements par l'écosystème Wikimédia et les
nombreux projets qui s’appuient sur ces données; d’autre part, la réappropriation par l’institution elle-même de ces correspondances pour enrichir ses propres outils de médiation et s’inscrire dans la logique du Web de données liées.

## 1. La publication et la valorisation sur Wikidata

La publication des alignements sur Wikidata permet non seulement de donner une visibilité à ces alignements sur la plateforme elle-même mais aussi dans les autres outils de la Galaxie Wikimédia qui s’appuient et réutilisent ces données<fnref n="1" />. Les données de Wikidata sont également ré-exploitées non seulement dans le domaine privé mais aussi par les chercheurs en quête de données transversales dans toutes les disciplines. Premièrement, les projets transversaux de la galaxie Wikimédia comme « Sum of all paintings » ou « Somme de toutes les peintures » qui est alimenté par les données de Wikidata et les contenus indexés sur ces données de Wikimédia Commons. Le projet a pour périmètre les règles suivantes : « La peinture est dans une collection connue d’un musée, d’une bibliothèque, d’un service d’archives (ex : peintures du Metropolitan Museum of Art) » ou « La peinture a été faite par un artiste connu (ex : peinture de Van Gogh dans une collection privée) ». Parmi ses réalisations se trouvent des reconstitutions en images des catalogues des salons et expositions artistiques importantes.

Dans le cadre du musée d'Orsay, ces alignements seront principalement signalés via la propriété « identifiant Musée d'Orsay d'un artiste ou d'une personnalité » (P2268) qui relie directement la page d'une entité du répertoire des artistes et personnalités et son ou ses équivalents sur Wikidata. Ils pourraient également bénéficier de l'existence de la propriété « dossier d'artiste détenu par »(P9493), développée pour le projet d'alignement des dossiers d'artistes de la Smithsonian<fnref n="2" />. Cette dernière ne pourra cependant pas être ajoutée de façon systématique. En effet, bien que le répertoire des artistes et personnalités sert principalement à mettre en avant les dossiers existants à la documentation du musée, il arrive que certaines personnalités considérées comme importantes pour divers critères et qui n'ont pas de dossier à la documentation soient tout de même publiés sur le répertoire. Ainsi, il faudra prendre en compte les signalements de « dossier à créer » ou « sans dossier » indiqués dans la base de données TMS si cette propriété est employée.

Le processus d'alignement du projet du musée d'Orsay prévoit également, au-delà de la publication des alignements réalisés, la création de nouveaux éléments sur Wikidata. Ces nouveaux éléments correspondent aux entités publiées sur le répertoire qui possèdent le statut « non_aligne », que ce soit par absence de candidat lors de la génération de proposition

<footnote n="1">1. Voir partie I, chapitre 3</footnote>

<footnote n="2">2. Voir partie I, chapitre 3, section II.</footnote>
d'alignement ou par refus de tous les candidats possibles. En fonction de critères qu'il faudra
déterminer, en terme de quantité et de qualité minimum des données sur l'entité, une création
est envisageable. La création de ces éléments s'appuiera également, pour le renseignement des
déclarations, sur le mapping réalisé en amont afin de savoir quelles propriétés et qualificatifs
employer pour chacun. Cela permet au musée de valoriser les ressources « uniques » ou
« niches » qu'il possède de par ses collections, son périmètre documentaire, ses missions et le
travail fourni du personnel scientifique depuis l'ouverture du musée en 1986 au cours des divers
projets de ce dernier. Par exemple, la période couverte par le musée d'Orsay (1848-1914)
présente un très grand nombre de sources permettant d'identifier et documenter l'activité
d'artistes décorateurs, de fondeurs, de ciseleurs, d'émailleurs, autrefois souvent anonymisés
au profit d'un atelier, d'un marchand ou d'un commanditaire. Dans le domaine des arts
décoratifs, il est alors fort possible que les entités recensées par le musée d'Orsay ne se
recroisent que très peu, voir aucunement, avec les ressources présentes sur Wikidata.

La publication des alignements et la création de nouveaux éléments Wikidata pourra se
faire via l'outil QuickStatements<fnref n="3" />. Tout comme Mix'n'Match, QuickStatement est un outil
développé par Magnus Manske<fnref n="4" /> qui permet l'édition ou la création en masse d'éléments
Wikidata. Si sa première version est créée en 2015⁵ l'outil en est actuellement à la deuxième
version de son interface et une troisième version semble être en développement<fnref n="6" /> depuis 2024.
Les données et instructions de modification ou de création sont transmises à l'outil sous forme
de fichier au format .TSV ou .CSV (voir figure 8.1) importé dans l'interface. Il est important
de noter que l'utilisation de Quickstatement nécessite tout de même un compte Wikidata dit
« autoconfirmé »<fnref n="7" /> ce qui implique une certaine préparation en amont de la publication.

<footnote n="3">3. Voir l'annexe I, section Inscription des alignements sur Wikidata.</footnote>

<footnote n="4">4. Aide :QuickStatements — Wikidata, URL : https : / / www . wikidata . org / wiki / Help : QuickStatements/fr (visité le 05/09/2025).</footnote>

<footnote n="5">5. Voir la déclaration de la propriété « date de fondation ou de création » (P571) sur l'élément Wikidata représentant la première version de l'outil : https://www.wikidata.org/wiki/Q20084080.</footnote>

<footnote n="6">6. *QuickStatements 3.0 - Meta-Wiki*, URL : https://meta.wikimedia.org/wiki/QuickStatements_3.0 (visité le 05/09/2025).</footnote>

<footnote n="7">7. « Les utilisateurs autoconfirmés sont des utilisateurs enregistrés qui ont passé certains seuils. Certaines actions sur Wikidata sont limitées aux comptes utilisateur ayant dépassé certains seuils d'ancienneté (temps écoulé depuis la création du compte) et du nombre d'éditions. Les comptes ayant passé ces seuils font partie du groupe “’autoconfirmed’” (“utilisateurs enregistrés”). Ce statut est vérifié à chaque fois qu’un utilisateur exécute une action limitée : elle est alors automatiquement autorisée par le logiciel. Bien que les seuils précis d’accès au statut varient selon les situations, la plupart des utilisateurs de Wikidata pré-sents depuis plus de quatre jours et ayant accompli plus de 50 modifications sont considérés comme faisant partie du groupe des utilisateurs enregistrés. » - *Wikidata : Utilisateurs autoconfirmés — Wikidata*, URL : https://www.wikidata.org/wiki/Wikidata:Autoconfirmed_users/fr (visité le 05/09/2025).</footnote>
FIGURE 8.1 – Extrait du contenu d'un fichier préformaté pour ajouter des déclarations de la propriété « identifiant Musée d'Orsay d'un artiste ou d'une personnalité » (P2268) pour un ensemble d'alignements validés.

<table><tr><td>Q365891</td><td>P2268</td><td>"208410"</td></tr><tr><td>Q726881</td><td>P2268</td><td>"205084"</td></tr><tr><td>Q16038503</td><td>P2268</td><td>"10709"</td></tr><tr><td>Q3557491</td><td>P2268</td><td>"211205"</td></tr><tr><td>Q7649381</td><td>P2268</td><td>"38007"</td></tr><tr><td>Q17021787</td><td>P2268</td><td>"37796"</td></tr><tr><td>Q32860543</td><td>P2268</td><td>"35767"</td></tr><tr><td>Q21460246</td><td>P2268</td><td>"25618"</td></tr><tr><td>Q3496830</td><td>P2268</td><td>"150673"</td></tr><tr><td>Q59690861</td><td>P2268</td><td>"38162"</td></tr></table>

Par ailleurs, la création d'entités et l'enrichissement de la base Wikidata permet aussi à l'institution de s'inscrire en tant que contributeur au sein de la galaxie Wikimédia et de mettre en valeur, par la suite, sur d'autres outils de cette galaxie, d'autres types de ressources (images, audios, archives ou autres ressources numériques). Une contribution de qualité, durable, respectant les règles de la plateforme permet d'assurer, lors de futurs projets liés à la galaxie Wikimédia, une certaine crédibilité auprès de la communauté et des administrateurs de la plateforme qui peut être utile si cela engage, par exemple, le versement d'une grande quantité d'images (et donc l'occupation d'un espace de stockage important) ou bien la création d'une nouvelle propriété.

Si la publication sur Wikidata offre une visibilité au sein de l'écosystème collaboratif et de ses réutilisateurs, les institutions peuvent également exploiter directement ces alignements sur leurs propres plateformes, créant ainsi une valorisation complémentaire qui renforce leur stratégie de diffusion numérique et leur inscription dans le Web de données.

## 2. La publication et la valorisation directement par l'institution

La publication et la valorisation du résultat des alignements peuvent également être réalisées par l'institution elle-même via sa ou ses plateformes, selon différentes modalités d'exploitation qui vont de la simple exposition des correspondances à l'enrichissement automatisé des contenus. Cette approche permet aux institutions de conserver la maîtrise de la présentation de leurs données tout en bénéficiant des apports du Web de données.

La stratégie la plus directe consiste à exposer les équivalences établies avec les éléments Wikidata sur la page de la ressource concernée sous forme de lien hypertexte. C'est le cas
des alignements réalisés avec les notices des « Personnes ou institutions de qualité » de FranceArchives ou bien des notices auteur de la plateforme data.bnf.fr (voir figure 8.3).

<caption>FIGURE 8.2 – Capture d’écran de la page consacrée à Louise Michel sur francearchives.gouv.fr</caption>

Michel, Louise (1830-1905) AUTORITÉ DE QUALITÉ

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

Les alignements peuvent aussi être exploités pour enrichir l'affichage de la ressource mise à disposition du public. C'est le cas sur data.bnf.fr avec la récupération d'images représentant la personne concernée via l'indexation des images de Wikimédia Commons basée sur les éléments Wikidata (voir figure 8.3).

D'autres, à l'image de la plateforme *Google Arts & Culture*, exploitent aussi les ponts établis entre les éléments Wikidata alignés et Wikimédia Commons pour proposer aux utilisateurs, au-delà des ressources de l'organisation, un outil d'exploration des connaissances disponibles sur le Web. Ainsi, il n'est pas rare qu'une page dédiée à une personne sur *Google Arts & Culture* présente, dans la section « Related works from the web : Artworks not sourced from our partners' collections », des œuvres répertoriées sur Wikidata, Wikipédia et Wikimédia Commons (voir figure 8.4).

L'institution peut aussi améliorer, comme cela a été expliqué précédemment<fnref n="8" />, le référencement des pages web liées aux ressources via l'insertion des triplets RDF directement

<footnote n="8">8. Voir partie I, chapitre 2</footnote>
<figure><img src="image_30.png" /><figcaption>FIGURE 8.3 – Capture d'écran de la page consacrée à Louise Michel sur data.bnf.fr</figcaption></figure>

dans le code HTML de la page (voir annexe C). Cette intégration des triplets RDF démontre aussi d'une volonté de se conformer à l'échelle créée par Tim Berners-Lee pour définir la qualité de la donnée ouverte, en exposant ces fameux liens vers d'autres ressources. La tendance vers la publication de jeux de données en « Linked Open Data », ou données liées ouvertes, est encouragée par les agrégateurs nationaux et internationaux puisque cela leur facilite le travail d'interopérabilité des différents jeux de données qu'ils mettent à disposition du public. Elle est poussée, en France, par le Ministère de la Culture et par la plateforme data.gouv.fr <fnref n="9" />. Le premier publie, par exemple, un guide pratique sur l'« Ouverture des données publiques culturelles »<fnref n="10" /> en 2019 qui explique l'importance de l'inclusion, dans les jeux de données ouverts de « données de référence » définies comme suit :

> « Les données de référence définies dans le code des relations entre le public et l'administration (CRPA) sont des données utilisées par un grand nombre d'acteurs, qui y recourent fréquemment, par exemple le code officiel géographique,

<footnote n="9">9. « data.gouv.fr est la plateforme ouverte et communautaire qui vise à centraliser et structurer les données ouvertes en France. Elle favorise la transparence et l'efficacité de l'action publique tout en facilitant la création de nouveaux services. Sur ce site, vous trouverez des informations sous forme de données numériques brutes. Elles peuvent être téléchargées et utilisées par tous de manière libre et gratuite. » - À propos de data.gouv.fr, URL : https://www.data.gouv.fr/pages/about/a-propos_data-gouv/ (visité le 07/09/2025).</footnote>

<footnote n="10">10. Ministère de la Culture, *Ouverture des données publiques culturelles : guide pratique*, 2019.</footnote>
<figure><img src="image_31.png" /><figcaption>FIGURE 8.4 – Capture d’écran de la page consacrée à Berthe Morisot sur *Google Arts & Culture*.</figcaption></figure>

le répertoire SIRENE, le cadastre, etc. Les données de référence sont des données considérées comme structurantes, par l'administration ou par l'usage, pour nommer ou identifier des produits, des entités économiques, des territoires ou des acteurs (personnes physiques et morales). Ces référentiels sont indispensables pour lier des bases de données de nature hétérogène et construire tout nouveau service intégré au Web des données (Linked Open Data). »<fnref n="11" />

L'importance de ces données « pivots » est également soulignée par la plateforme data.gouv.fr, qui met à disposition les jeux de données ouverts publics dans son guide permettant d'« Évaluer le niveau de qualité d'un jeu de données »<fnref n="12" />

Le *Rijksbureau voor Kunsthistorische Documentatie* (RKD) ou Bureau national pour la documentation relative à l'histoire de l'art présente, tout comme la BNF, un modèle de données en « LOD » (*Linked Open Data*). Leurs données sont donc, elles-aussi, interrogeables via un SPARQL endpoint et sont enrichies via des propriétés d'équivalences vers des concepts et référentiels externes. Lors d'une présentation en 2024 portant sur les objectifs de leur plateforme RKD Research<fnref n="13" />, une des diapositives indique clairement Wikidata comme un vecteur principal d'intégration de données externes dans leur propre graphe de connaissance<fnref n="14" />

<footnote n="11">11. *Ibid.*, p.15.</footnote>

<footnote n="12">12. « La présence de données et colonnes pivots pour lier les données à un référentiel (par exemple le SIRET) » - *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).</footnote>

<footnote n="13">13. Reinier van 't Zelfde et Astrid Verheusen, *RKD Research The Digital Hub for Art Historical Research*, text, juin 2024, URL : https://www.enssib.fr/bibliotheque-numerique/notices/73130-rkd-research-the-digital-hub-for-art-historical-research* (visité le 20/07/2025).</footnote>

<footnote n="14">14. *Ibid.*, p.36.</footnote>
concernant les artistes.

Ces différentes modalités d'exploitation montrent que les alignements offrent aux institutions une gamme d'outils pour enrichir leurs plateformes, depuis la simple exposition de liens vers des ressources, externes jusqu'à l'intégration automatisée de contenus multimédias. Cette approche permet de transformer les correspondances établies en véritables leviers d'amélioration de l'expérience utilisateur et de conformité aux standards du Web sémantique.

## II. Correction et enrichissement des données institutionnelles

Si l'exposition des alignements pousse l'institution à améliorer la qualité de ses données ouvertes en se rapprochant de la définition du « Linked Open Data », les alignements peuvent aussi être utilisés en interne pour l'amélioration de la qualité des données institutionnelles via leur correction ou enrichissement. Les alignements permettent une comparaison directe et efficace entre des informations sources et celles de l'institution. Dans le cadre du musée d'Orsay, plusieurs enrichissements pourraient être envisagés sur la base de données TMS en récupérant des données directement depuis les déclarations sur éléments Wikidata concernés. Par exemple, il serait envisageable d'enrichir les liens entre les entités personnes et institutions en ajoutant des qualifications qui indiqueraient la nature du lien familial ou professionnel qui existe entre elles. Ces liens seraient récupérés en se basant, une fois de plus, sur le mapping<fnref n="15" />. Au lieu d'une potentielle indication en plein texte dans la biographie, les relations identifiées seraient alors indiquées via la table « Associations », en créant de nouvelles valeurs pour la colonne « RelationshipID » afin de remplacer le simple « voir aussi » hérité des renvois entre dossiers papier de la documentation. Cela faciliterait grandement une perception efficace et plus globale des dynasties d'artistes ou de la composition des ateliers de certains créateurs par exemple. Un enrichissement par extraction des données de Wikidata, pour garantir la cohérence et l'intégrité scientifique des données institutionnelles, doit être appuyée par une méthodologie qui prend en compte les références pour chaque déclaration (soit la source de l'information) et potentiellement le rang qui leur est attribué. Wikidata ne contient pas des « données d'autorité » à proprement parler. Bien que l'autorité puisse se définir par le taux de réutilisation des ressources, elle est avant-tout considérée comme dépendante de la crédibilité du producteur de la donnée ou de la notice. Ainsi, la crédibilité des données de Wikidata repose essentiellement sur celle des sources ajoutées en référence des déclarations, c'est-à-dire le principe de « vérifiabilité ». Le rang de la donnée permet aussi de vérifier

<footnote n="15">15. Voir le *mapping*, section Relations.</footnote>
l'obsolescence d'une déclaration, même si cette dernière est appuyée par un nombre important de références. La méthodologie d'enrichissement doit donc comprendre une sélection des sources régulièrement utilisées en références et qui sont considérées comme « d'autorité » par les personnes en charge de la qualité et de la fiabilité des données, en l'occurrence, le personnel scientifique du musée. Elle doit aussi prendre en compte le rang attribué dans les cas où l'information se doit d'être à jour.

La confrontation des données institutionnelles avec celles des éléments Wikidata issus de l'alignement permet aussi de signaler ces données obsolètes ou des renseignements incomplets au sujet d'une entité de la base TMS. L'équipe du SDPN travaille actuellement sur une extension nommée « Sémiramis » destinée à être employée sur le navigateur utilisé par défaut sur les ordinateurs au musée d'Orsay. Cette extension est conçue pour enrichir le contenu des pages du répertoire des artistes et personnalités en affichant, en plus des données publiques, des informations issues des éléments Wikidata correspondants. Cette extension sert donc d'outil interne pour accompagner le travail de recherche et de documentation du personnel scientifique. Elle facilite notamment la recherche de données biographiques et de leurs sources et donne aussi un accès sous forme de liens hypertexte, à plusieurs notices considérées comme d'« autorité », des bases de données généalogiques, des bases sur le marché de l'art et tout autre ressource qui serait considérée comme utile par le personnel scientifique dans le cadre de leurs missions. Cet outil exploite pleinement le contenu des déclarations sur les éléments et particulièrement les propriétés de type « external-id » qui donnent accès à ces ressources externes au musée. L'outil permet aussi de créer des liens entre les entités du répertoire lorsque ces dernières sont déjà alignées avec Wikidata. Cette extension donne un aperçu de ce qu'il est déjà possible de faire en interne en exploitant les alignements réalisés par la communauté de Wikidata. Elle pourrait, plus tard, s'appuyer sur les alignements réalisés par le musée, qu'ils soient publiés sur Wikidata ou seulement stockés en interne sur la base TMS.

L'exploitation des alignements à des fins de correction et d'enrichissement illustre ainsi leur double nature : outils d'ouverture vers l'extérieur et instruments d'amélioration interne. Toutefois, cette démarche nécessite une approche méthodologique rigoureuse qui préserve l'intégrité scientifique des données institutionnelles en s'appuyant sur une sélection critique des sources et une validation par l'expertise du personnel scientifique. Les alignements ne remplacent pas le travail de recherche et de documentation, mais en facilitent et en enrichissent considérablement la portée.
## III. L'interopérabilité des référentiels internes et externes

Comme soulevé dans la partie I au chapitre 3, Wikidata permet de répondre en partie au besoin d'interopérabilité des référentiels entre institutions, au-delà de la nature des institutions et des disciplines couvertes. Certains ponts ou « données de référence » permettent alors de relier, non seulement des référentiels divers qui peuvent exister de façon interne à une institution (dans le cas plusieurs bases de données ou systèmes documentaires) mais aussi, de favoriser la collaboration et la création de projets communs avec d'autres institutions.

Le musée du Louvre, par exemple, a entrepris un projet, présenté en 2021 par Benoit Deshayes<fnref n="16" />, consistant en l'alignement des artistes de la base de données principale du musée du Louvre (MuseumPlus) et les artistes mentionnés dans la base de données interne « Arts Graphiques » avec Wikidata. Une fois les alignements réalisés pour les deux bases, les entités communes ont pu être identifiées et ainsi être présentées sous un seul nom dans le moteur de recherche de la plateforme collections.louvre.fr.

Dans le cadre du musée d'Orsay, le projet d'alignement pourrait aussi offrir de nouvelles possibilités pour le contenu de la plateforme qui sera proposée par le futur centre de ressources et de recherche Daniel Marchesseau, encore en cours de préfiguration. Il serait, par exemple, possible de relier les personnes et institutions aux ressources de la bibliothèque du musée dont le référentiel utilise actuellement en grande partie des entités possédant un numéro ISNI (*International Standard Name Identifier*). Ce lien se ferait via la récupération des identifiants ISNI, lorsque ces derniers sont renseignés, directement sur Wikidata en récupérant la ou les valeurs des déclarations de la propriété dédiée (P213) pour chaque entité concernée. Ces identifiants pourront, tout comme ceux des éléments Wikidata alignés, être intégrés directement dans la base de données TMS dans la table « AltNum »<fnref n="17" />. Une autre ressource du musée d'Orsay, la base « Salons »<fnref n="18" />, devrait bénéficier, dans un futur proche, d'un travail approfondi sur la qualité de ses données et une potentielle refonte de son interface. La communauté Wikidata est déjà à l'origine, via la propriété « identifiants Salons

<footnote n="16">16. Benoit Deshayes, *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).</footnote>

<footnote n="17">17. Voir section III. et annexe F.</footnote>

<footnote n="18">18. « La base "Salons et expositions, 1673-1914" donne accès à la transcription des livrets des salons artistiques organisés entre 1673 et 1914 à Paris et en région, ainsi qu'aux catalogues des principales expositions de groupes (expositions impressionnistes, Rose-Croix...), conservés à la bibliothèque du musée d'Orsay. Elle permet l'exploration des données contenues dans ces livrets. Les informations relatives aux œuvres et aux artistes sont destinées à être continuellement enrichies par les informations et données issues de la recherche en histoire de l'art. » - *Base salons*, URL : https://salons.musee-orsay.fr/ (visité le 06/09/2025).</footnote>
1673-1914 » (P6007) de trois mille deux-cent quarante-six alignements d'œuvres <fnref n="19" /> présentes sur la base. Ce travail d'alignement, s'il est poursuivi pour les créateurs et artistes, permettra de créer des liens durables avec la base TMS et ainsi, favoriser la découvrabilité des ressources du musée sur le futur portail du centre.

La présence d'identifiants externes pour les éléments Wikidata alignés avec le jeu de données institutionnel permet aussi de faciliter la mise en place de collaborations scientifiques sur des projets de recherches qu'ils soient issus de la même discipline ou transversaux. Le futur portail du centre de ressource et de recherche pourrait tout à fait renvoyer ou exploiter les données ouvertes d'autres institutions ou projets afin de favoriser le recroisement des informations. Par exemple, le projet Reg.Art<fnref n="20" />, réalisé entre 2021 et 2024, consiste principalement en la publication, sous forme de base de données publique, des « registres d'inscription des élèves de la section peinture et sculpture de l'École des beaux-arts de Paris de 1813 à 1968. Ces registres recensent environ 12 000 élèves. Ils fournissent des informations sur leur origine géographique et sociale, leur adresse à Paris, leur garant et des observations sur leur parcours. La publication numérique permet de croiser les données, de les visualiser (cartes et graphes) et de les exporter. » <fnref n="21" />. Dans ce cadre, le projet a réalisé des alignements des élèves et des garants avec les référentiels de « Wikidata puis en complément [avec] le Bénézit, afin d'identifier le plus grand nombre d'individus (au total 5154 identifiants Bénézit et 4646 identifiants Wikidata associés) » <fnref n="22" />. Les personnes et institutions citées par le projet Reg.arts se recoupent en grande partie avec celles publiées par le musée d'Orsay (dans le répertoire et sur la base « Salon »). De ce fait, les ponts créés par l'intermédiaire de Wikidata permettent d'envisager des visualisations géographiques et temporelles des déplacements des artistes ou bien encore des réseaux entre les acteurs majeurs dans le monde artistique. Des projets de recherches similaires notamment avec l'INHA dans le cadre de sa plateforme Aghora ou les Archives nationales pourraient aussi être envisagés. Ce recroisement des données devient aussi possible à l'échelle internationale dans le cadre, par exemple, d'artistes ayant eu des vies internationales de par leur naissance ou leur carrière. Les identifiants externes présents sur les éléments Wikidata pourraient faciliter la conception d'expositions collaboratives en donnant plus facilement accès aux ressources et collections d'autres institutions culturelles.

L'interopérabilité rendue possible par les alignements avec Wikidata dépasse ainsi le simple rapprochement technique entre bases de données. Elle constitue un véritable levier de collaboration scientifique qui permet de décloisonner les ressources institutionnelles et de fa-

<footnote n="19">19. Voir la requête SPARQL exposant les alignements réalisés via la propriété P6007.</footnote>

<footnote n="20">20. « Le projet a été porté entre 2021 et 2024 par trois institutions, les Beaux-Arts de Paris, l'INHA et le LIR3S (CNRS/Université de Bourgogne) » - *Reg Arts : À propos*, URL : https://regarts.huma-num.fr/a-propos (visité le 06/09/2025).</footnote>

<footnote n="21">21. *Reg-Arts*, URL : https://regarts.huma-num.fr/ (visité le 06/09/2025).</footnote>

<footnote n="22">22. Ibid.</footnote>
voriser l'émergence de projets de recherche transversaux. En servant de pivot entre différents référentiels, Wikidata transforme les silos documentaires en un réseau interconnecté où les données culturelles et scientifiques peuvent être croisées, confrontées et valorisées collectivement, ouvrant de nouvelles perspectives pour la recherche en histoire de l'art et au-delà.
# Conclusion

L'alignement des données institutionnelles avec Wikidata s'inscrit dans une transformation majeure des pratiques documentaires, où les systèmes traditionnels, souvent cloisonnés, cèdent la place à des environnements ouverts et interconnectés. Ce processus ne se réduit pas à une simple opération technique : il engage les institutions dans une réflexion sur la gouvernance de leurs données, leur interoperabilité et leur valorisation. Wikidata, en tant que graphe de connaissances collaboratif et évolutif, se positionne comme un outil central pour relier, enrichir et contextualiser les référentiels patrimoniaux. Pourtant, cette démarche soulève des enjeux complexes, notamment en matière de granularité et de correspondance des modèles de données.

Les champs en texte libre contenant du langage naturel, bien que perçus comme un frein à l'interopérabilité, pourraient jouer un rôle clé dans l'amélioration du mapping. Un travail d'extraction et d'analyse par LLM de certaines informations permettrait de pallier les limites des données structurées, en affinant les correspondances et en adaptant les alignements aux spécificités des entités ou concepts représentés par le jeu de données. Cette approche ouvre des perspectives pour des processus plus robustes, capables de s'adapter aux particularités de chaque jeu de données. Bien qu'elle ait été envisagée pour extraire certaines professions ou liens familiaux, la durée limitée du stage n'a pas permis de pousser l'expérimentation de cette méthode à un niveau satisfaisant pour les utiliser à l'échelle du processus.

L'exemple du musée d'Orsay permet aussi de mettre au jour les avantages et enjeux liés à l'inclusion du personnel scientifique dans le processus d'alignement, surtout à l'étape de la validation. L'expertise des métiers de la documentation et de la conservation prend d'autant plus son sens lorsque ces alignements sont utilisés dans le cadre du centre de ressources et de recherche. Ce mémoire démontre qu'il n'y a pas de processus d'alignement parfait qui conviendrait à tous mais des processus et des méthodologies qui permettent de valoriser des expertises, des ressources, et qui s'adaptent selon l'histoire, les objectifs, les moyens et les besoins des institutions.

Les alignements avec Wikidata, une fois réalisés, constituent un moyen efficace de créer des liens avec les données des autres institutions, projets de recherches ou ressources
ouvertes via, notamment, l'interopérabilité des référentiels. Ces alignements peuvent devenir vecteurs de collaboration et de valorisation des données institutionnelles à différentes échelles. Ils permettent également leur enrichissement, l'amélioration de leur qualité et leur re-contextualisation pour en faciliter la réutilisation.

En définitive, les alignements avec Wikidata ne constituent pas une finalité, mais une étape vers une gestion plus dynamique des données patrimoniales. Les perspectives qui en découlent sont multiples : amélioration de la découvrabilité des collections, développement de nouveaux projets scientifiques, ou encore renforcement du rôle des institutions comme acteurs clés de la connaissance partagée. Leur utilisation démontre la possibilité d'un écosystème où expertise scientifique et innovation technologique se complètent.
# Quatrième partie

## Annexes
<figure><img src="image_32.png" /></figure>
# Annexe A

## Liste des acronymes
# Acronymes

**AAF** Association des Archivistes Français

**AAM** American Association of Museums

**ABES** Agence bibliographique de l'enseignement supérieur

**ABF** Association des Bibliothécaires de France

**API** Application Programming Interface

**BNF** Bibliothèque nationale de France

**CADA** Commission d'accès aux documents administratifs

**CIDOC-CRM** Conceptual Reference Model du CIDOC

**CNC** Centre national du cinéma et de l'image animée

**CRPA** Code des Relations entre le Public et l'Administration

**CSS** Cascading Style Sheets

**EDM** Europeana Data Model

**EPMOO** Établissement public du musée d'Orsay et du musée l'Orangerie - Valéry Giscard d'Estaing

**FRBR** Functional Requirements for Bibliographic Records

**GLAM** Galleries, Libraries, Archives and Museums

**HTML** Hypertext Markup Language

**HTTP** Hypertext Transfer Protocol

**ICA** Conseil International des Archives

**ICOM** Conseil international des musées

**IFLA** International Federation of Library Associations and Institutions

**IFLA-LRM** Library Reference Model de l'IFLA

**INA** Institut national de l'audiovisuel

**INHA** Institut National d'Histoire de l'Art
**ISAD(G)** Norme Générale et Internationale de Description Archivistique

**ISBD** International Standard Bibliographic Description

**ISNI** International Standard Name Identifier

**LIDO** Lightweight Information Describing Objects

**LIDO-MC** Lightweight Information Describing Objects - Ministère de la Culture

**LLM** Large Language Model

**LOD** Linked Open Data

**MARC** Machine-Readable Cataloging

**OAI-ORE** Object Reuse and Exchange

**OAI-PMH** Open Archives Initiative - Protocol for Metadata Harvesting

**OWL** Web Ontology Language

**RDF** Resource Description Framework

**RDFS** RDF Schema

**RGPD** Règlement général sur la protection des données

**RiC-CM** Records in Contexts - Conceptual Model

**RKD** Rijksbureau voor Kunsthistorische Documentatie

**SDPN** Service des Données Patrimoniales et Numériques

**SGBDR** Système de gestion de bases de données relationnelles

**SIRENE** Système d'Identification du Répertoire des Entreprises

**SKOS** Simple Knowledge Organization System

**SPARQL** SPARQL Protocol and RDF Query Language

**SQL** Structured Query Language

**TMS** The Museum System

**ULAN** Union List of Artist Names

**URI** Uniform Resource Identifier

**URL** Uniform Resource Locator

**VIAF** Virtual International Authority File

**W3C** World Wide Web Consortium

**WER** Word Error Rate

**XML-EAD** Extensible Markup Language - Encoded Archival Description
# Annexe B

## Organigrammes concernant
l'Établissement public du musée
d'Orsay et du musée de l'Orangerie -
Valéry Giscard d'Estaing

### I. Organigramme général de l'EPMO
# Organigramme général de l'établissement public des musées d'Orsay et de l'Orangerie

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

Secteur prévention
et sécurité incendie
Major Jean-Marie Le
Nadant

Agence comptable
Daniel Le Gac

MUSÉE
HEBERT

Coordinatrice
générale
Agrès Faravel-
Cordeau

Chargée de mission
RSO
Misty Montéville
II. Organigramme de la direction de la conservation et des collections - Pôle ressources et recherches (Anonymisé)
# Direction de la conservation et des collections (DCC) 2/2

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

Retour à l'organigramme général

## Direction de la conservation et des collections

### Pôle ressources et recherches

Préfiguratrice du Centre de ressources et de recherches en charge du pôle ressources et recherches
France Nerlich

Chargée de recherches
en provenance

Service de la documentation

Chef de service

Assistante de documentation

Secrétaire de documentation

Peintures et autorisations
de reproduction

Chargés d'études documentaires

- Arts décoratifs

- Peinture

- Architecture

- Peinture

- Photographie

- Peinture

- Peinture

- Sculpture

- Dessins et pastels

Service de la bibliothèque

Chef de service

Bibliothécaires assistants spécialisés

Service des données patrimoniales
numériques

Chef de service

Benoît Deshayes

Iconographe

Chargée de projet en données culturelles
et numériques

Chargée d'édition scientifique

Responsable de l'outil de gestion
informatisée des collections

Chargée de l'outil de gestion
des collections
# Annexe C

## Extrait du code HTML de la page
https://data.bnf.fr/fr/ark:/12148/cb11907966z dédiée à Victor Hugo

```json
{
    "@context": "http://schema.org/",
    "@type": "Person",
    "@id": "https://data.bnf.fr/ark:/12148/cb11907966z",
    "name": "Victor Hugo (1802-1885)",
    "alternateName": [
        {
            "@value": "Victor-Marie Hugo",
            "@language": "fr"
        },
        {
            "@value": "Vittor Hugo",
            "@language": "fr"
        },
        {
            "@value": "Vittorio Hugo",
            "@language": "fr"
        },
    ],
```
```html
"https://imslp.org/wiki/Category:Hugo,_Victor",
"http://isni.org/isni/0000000121200982",
"http://id.loc.gov/authorities/n79091479",
"https://musicbrainz.org/artist/c0c99c8f-4779-4c35-9497-67d60a73310a",
"https://www.persee.fr/authority/30997",
"10083",
"https://francearchives.gouv.fr/agent/130963047",
"http://viaf.org/viaf/9847974",
"http://wikidata.org/entity/Q535",
"http://fr.wikipedia.org/wiki/Victor_Hugo"
]
}
</script>
```
# Annexe D

## Modèle de données IFLA-LRM

<figure><img src="image_35.png" /></figure>
# Annexe E

## Modèle de données de data.bnf.fr
Vue d'ensemble

Version février 2018

<figure><img src="image_36.png" /></figure>
<figure><img src="image_37.png" /><figcaption>Focus sur l'Auteur</figcaption></figure>
<caption>Focus sur l'Œuvre (hors Périodiques et Spectacles)</caption>

data.bnf.fr

<figure><img src="image_38.png" /></figure>
Focus sur les Périodiques et les Spectacles

data.bnf.fr

<figure><img src="image_39.png" /></figure>
<figure><img src="image_40.png" /><figcaption>Focus sur le Thème</figcaption></figure>
Focus sur le Lieu

<figure><img src="image_41.png" /></figure>
Focus sur la Date

Œuvre (FRBR)

ŒUVRE

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

MANIFESTATION

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

rdagroup1elements:
dateOfWork

rdagroup1elements:
dateOfCapture

rdagroup2elements:
dateOfPublicationManifestation

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

Littéraux

rdfs:label

foaf:page

http://data.bnf.fr/date/1956/

http://data.bnf.fr/date/1901-2000/

rdf:type>
owl-time:Instant

rdf:type>
owl-time:Interval
rdf:type>
owl-time:Instant

owl:sameAs

DBpedia

dcterms:hasPart

Date

Auteur

AUTEUR

rdf:type>
foaf:Person

rdf:type>
foaf:Organization

rdagroup2elements:
dateOfBirth
dateOfDeath

rdagroup2elements:
dateOfEstablishment
dateOfTerminaison

DATE

Spectacle

dcterms:-date
bnf-onto:-date

SPECTACLE

<figure><img src="image_45.png" /></figure>
# Préfixes utilisés dans le modèle de data.bnf.fr

## Ontologies et vocabulaires du Web sémantique

* **rdf**: http://www.w3.org/1999/02/22-rdf-syntax-ns#

* **dcterms**: http://purl.org/dc/terms/

* **foaf**: http://xmlns.com/foaf/0.1/

* **isni**: http://isni.org/ontology#

* **rdagroup1elements**: http://rdvocab.info/Elements/

* **rdagroup2elements**: http://rdvocab.info/ElementsGr2/

* **rdarelationships**: http://rdvocab.info/RDARelationshipsWEMI/

* **owl**: http://www.w3.org/2002/07/owl#

* **ore**: http://www.openarchives.org/ore/terms/

* **frbr-rda**: http://rdvocab.info/uri/schema/FRBRentitiesRDA/

* **marcrel**: http://id.loc.gov/vocabulary/relators/

* **mo**: http://purl.org/ontology/mo/

* **dcmi-box**: http://dublincore.org/documents/dcmi-box/

* **dcmitype**: http://purl.org/dc/dcmitype/

* **geo**: http://www.w3.org/2003/01/geo/wgs84_pos#

* **geonames**: http://www.geonames.org/ontology#

* **bio**: http://vocab.org/bio/0.1/

* **rdfs**: http://www.w3.org/2000/01/rdf-schema#

* **skos**: http://www.w3.org/2004/02/skos/core#

* **bibo**: http://purl.org/ontology/bibo/

* **insee**: http://rdf.insee.fr/geo/

* **schemaorg**: http://schema.org/

* **ign**: http://data.ign.fr/ontology/topo.owl#

## Ontologie et vocabulaires BnF

* **bnf-onto**: http://data.bnf.fr/ontology/bnf-onto/

* **vocabulary**: http://data.bnf.fr/vocabulary/
Légende

geo:SpatialThing

Classe

Objet lui-même

skos:Concept

Classe - Concept

Représentation du document à propos de l'objet

dcterms:subject

Propriété

Relation entre deux classes

foaf:name

Attribut

Littéraux

Alignement interne

(avec jeu de données BnF)

Gallica
Bibliothèque
 nationale
française
de la
concorde

DBpedia

Alignement externe

(avec jeu de données extérieur)

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

Page html data.bnf.fr

Vocabulary BnF
scheme

Code et vocabulaire BnF
# Annexe F

## Documentation de la base de données
The Museum System du musée
d'Orsay

I. Extrait du modèle de données concernant les liens vers la table « Constituents »
# Constituents

(with regular, non-anonymous ConXref linking - see also ConXrefs and Anonymity)

Confidential

## Tables which link to Constituents through ConXrefs.ID and ConstituentRoleTypeID (below):

Objects (1,2,5), ObjRights (19), AccessionLot (21), AccessionObjectLot (22), Exhibitions (3), ExhibitionVenues (20), Conditions (16), HistEvents (9), InsurancePolicies (15), Loans (17) incoming, 18 outgoing), MediaRenditions (18), ReferenceMaster (4), Shipments (12), ShipmentSteps (14), Sites (8), Conservation Studio (24), Projects (23)

## Tables which link to Constituents with TableID = 23 and ID=ConstituentID

AllNums, Associations, MediaCounts, MediaXrefs, PackageList, TextEntries, ThesXrefs

## SubModels and Tables which link to Constituents through ConstituentID

Circulation, BorrowerConID & LenderConID, ConDisplayBios, Conditions, ExaminerID & Examiner2ID, ExhVenueXrefs, LocApprovers, ConstituentID, LocHandlers, ConstituentID MediaRenditions, QualityConID, ObjDeaccession, RecipientConID, ObjIncoming, ShipperID, ShipConveyances, ConveyanceConID, TextEntries, AuthorConID Users, ConstituentID

Locations is included on the Constituent scheme because the Location data belongs to an Address. ConAddress ShortName is the field displayed at the top level of a Location.

## SubModels and Tables which link to Constituents through NameID:

ObjInsuranceAppraiserID, Shipments, ShipToNameID, & ShipFromNameID, ShipmenSteps, CarrierNameID

## New Confidentiality features (9.94)

Tables that received the new "IsConfidential" field:

ConAddress
ConDates
ConDisplayBios
ConPhones
ConPrimaryDates (new table)

(The Confidentiality features are different in purpose and scope than the long-standing Anonymity features.)

<figure><img src="image_47.png" /></figure>
# Annexe G

## Schéma décisionnel de validation de Mix'n'Match

<figure><img src="image_48.png" /></figure>
# Annexe H

## Schéma décisionnel de validation d'OpenRefine

<figure><img src="image_49.png" /></figure>
# Annexe I

## Documentation du processus d'alignement des entités personnes et institutions du musée d'Orsay

Voir sur le dépôt Github : https://github.com/Melina-Conter/livrables_memoire_M2_TNAH/blob/main/Processus/Documentation_Processus_Alignement.md ou https://github.com/Melina-Conter/livrables_memoire_M2_TNAH/blob/main/Processus/Documentation_Processus_Alignement.html.
# I. Schéma global du processus d'alignement des entités personnes et instituions

<figure><img src="image_50.png" /></figure>
II. Modèle logique de la base de données principale de l'application 2AMO

<figure><img src="image_51.png" /></figure>
### III. Modèle de la table dédiée à l'affichage des données des entités TMS dans l'application

<table><thead><tr><th colspan="2">tms-constituent_constituent-description</th></tr></thead><tbody><tr><td>123</td><td>constituentid</td><td>int4</td></tr><tr><td>A-Z</td><td>displayname</td><td>varchar(300)</td></tr><tr><td>{}</td><td>autres labels</td><td>json</td></tr><tr><td>①</td><td>date_naissance_historique</td><td>date</td></tr><tr><td>②</td><td>date_mort_historique</td><td>date</td></tr><tr><td>A-Z</td><td>date_naissance</td><td>varchar(50)</td></tr><tr><td>A-Z</td><td>date_mort</td><td>varchar(50)</td></tr><tr><td>{}</td><td>activites</td><td>json</td></tr><tr><td>A-Z</td><td>commune_naissance</td><td>varchar(100)</td></tr><tr><td>A-Z</td><td>departement_naissance</td><td>varchar(100)</td></tr><tr><td>A-Z</td><td>pays_naissance</td><td>varchar(100)</td></tr><tr><td>A-Z</td><td>commune_mort</td><td>varchar(100)</td></tr><tr><td>A-Z</td><td>departement_mort</td><td>varchar(100)</td></tr><tr><td>A-Z</td><td>pays_mort</td><td>varchar(100)</td></tr><tr><td>A-Z</td><td>biographie</td><td>varchar(3000)</td></tr><tr><td>{}</td><td>roles_creazione</td><td>json</td></tr><tr><td>{}</td><td>dossiers_documentation</td><td>json</td></tr><tr><td>①</td><td>db_update</td><td>timestamp</td></tr></tbody></table>
# Annexe J

## Documentation de l'application
2AMO

Voir sur le dépôt Github : https://github.com/Melina-Conter/livrables_memoire_M2_TNAH/blob/main/2AMO/Documentation_2AMO.md ou https://github.com/Melina-Conter/livrables_memoire_M2_TNAH/blob/main/2AMO/Documentation_2AMO.html.
# Annexe K

## Code source de l'application 2AMO

Voir sur le dépôt Github : https://github.com/Melina-Conter/livrables_memoire_2TNAH/tree/main/Code_source_2AMO
# Annexe L

## Requêtes SPARQL Wikidata pour l'affichage des données des candidats dans l'interface de validation de 2AMO

### I. Requête pour la récupération des données des candidats de nature « être humain » (Q5)

La requête est issue de la route « /validation » dans validation.py, lignes 516 à 636.

```
query_q5 = f""
SELECT ?item ?itemLabel
?genreLabel
(GROUP_CONCAT(DISTINCT ?altLabel; separator="; ") AS ?autresLabels)
(GROUP_CONCAT(DISTINCT ?typeLabel; separator="; ") AS ?types)
(GROUP_CONCAT(DISTINCT ?naissanceFormatee; separator="; ") AS ?datesNaissance)
(GROUP_CONCAT(DISTINCT ?mortFormatee; separator="; ") AS ?datesMort)
(GROUP_CONCAT(DISTINCT ?lieuNaissanceLabel; separator="; ") AS ?lieuxNaissance)
(GROUP_CONCAT(DISTINCT ?lieuMortLabel; separator="; ") AS ?lieuxMort)
(GROUP_CONCAT(DISTINCT ?occupationLabel; separator="; ") AS ?occupations)
(GROUP_CONCAT(DISTINCT ?nationaliteLabel; separator="; ") AS ?nationalites)
?pereLabel
?mereLabel
(GROUP_CONCAT(DISTINCT ?frereOuSoeurLabel; separator="; ") AS ?freresOuSoeurs)
```
(GROUP_CONCAT(DISTINCT ?enfantLabel; separator="; ") AS ?enfants)
(GROUP_CONCAT(DISTINCT ?conjointLabel; separator="; ") AS ?con joints)
(GROUP_CONCAT(DISTINCT ?elevesLabel; separator="; ") AS ?eleves)
(GROUP_CONCAT(DISTINCT ?eleveDeLabel; separator="; ") AS ?eleveDe)
?description
WHERE {{
VALUES ?item {{ {qid_values_q5} }}
OPTIONAL {{
?item wdt:P21 ?genre.
?genre rdfs:label ?genreLabel.
FILTER(LANG(?genreLabel) = "fr")
}}
OPTIONAL {{
?item skos:altLabel ?altLabel.
FILTER(LANG(?altLabel) = "fr")
}}
OPTIONAL {{
?item wdt:P31 ?type.
}}
OPTIONAL {{
?item p:P569 ?naissanceStatement.
?naissanceStatement psv:P569 ?naissanceNode.
?naissanceNode wikibase:timeValue ?dateNaissance.
?naissanceNode wikibase:timePrecision ?precisionNaissance.
BIND(STR(?dateNaissance) AS ?naissanceStr)
BIND(
IF(?precisionNaissance = 11,
CONCAT(SUBSTR(?naissanceStr, 9, 2), "/", SUBSTR(?naissanceStr, 6, 2), "/",
IF(?precisionNaissance = 10,
CONCAT(SUBSTR(?naissanceStr, 6, 2), "/", SUBSTR(?naissanceStr, 1, 4)),
IF(?precisionNaissance = 9,
SUBSTR(?naissanceStr, 1, 4),
"[date imprécise]"))) AS ?naissanceFormatee)
}}
OPTIONAL {{
?item p:P570 ?mortStatement.
?mortStatement psv:P570 ?mortNode.
?mortNode wikibase:timeValue ?dateMort.
?mortNode wikibase:timePrecision ?precisionMort.
BIND(STR(?dateMort) AS ?mortStr)
BIND(
    IF(?precisionMort = 11,
        CONCAT(SUBSTR(?mortStr, 9, 2), "/", SUBSTR(?mortStr, 6, 2), "/", SUBSTR(?mortStr, 1, 4)),
    IF(?precisionMort = 10,
        CONCAT(SUBSTR(?mortStr, 6, 2), "/", SUBSTR(?mortStr, 1, 4)),
    IF(?precisionMort = 9,
        SUBSTR(?mortStr, 1, 4),
        "[date imprécise]"))) AS ?mortFormatee)
}

OPTIONAL {{
    ?item wdt:P19 ?lieuNaissance.
}}

OPTIONAL {{
    ?item wdt:P20 ?lieuMort.
}}

OPTIONAL {{
    ?item wdt:P106 ?occupation.
    ?occupation rdfs:label ?occupationLabel.
    FILTER(LANG(?occupationLabel) = "fr")
}}

OPTIONAL {{
    ?item wdt:P27 ?nationalite.
    ?nationalite rdfs:label ?nationaliteLabel.
    FILTER(LANG(?nationaliteLabel) = "fr")
}}

OPTIONAL {{
    ?item wdt:P22 ?pere.
}}

OPTIONAL {{
    ?item wdt:P25 ?mere.
}}

OPTIONAL {{
```sql
?item wdt:P3373 ?frereOuSoeur.
}}

OPTIONAL {{
?item wdt:P40 ?enfant.
}}

OPTIONAL {{
?item wdt:P26 ?conjoint.
}}

OPTIONAL {{
?item wdt:P802 ?eleves.
}}

OPTIONAL {{
?item wdt:P1066 ?eleveDe.
}}

OPTIONAL {{
?item schema:description ?description.
FILTER(LANG(?description) = "fr")
}}

SERVICE wikibase:label {{
bd:serviceParam wikibase:language "fr,mul,en".
?type rdfs:label ?typeLabel.
?lieuNaissance rdfs:label ?lieuNaissanceLabel.
?lieuMort rdfs:label ?lieuMortLabel.
?pere rdfs:label ?pereLabel.
?mere rdfs:label ?mereLabel.
?frereOuSoeur rdfs:label ?frereOuSoeurLabel.
?enfant rdfs:label ?enfantLabel.
?conjoint rdfs:label ?conjointLabel.
?eleves rdfs:label ?elevesLabel.
?eleveDe rdfs:label ?eleveDeLabel.
?item rdfs:label ?itemLabel.
}}
}}

GROUP BY ?item ?itemLabel ?genreLabel ?description ?pereLabel ?mereLabel
""
```
II. Requête pour la récupération des données des candidats qui ne sont pas de nature « être humain »

La requête est issue de la route « /validation » dans validation.py, lignes 666 à 754.

```sql
query_autres = f""
SELECT ?item ?itemLabel
(GROUP_CONCAT(DISTINCT ?altLabel; separator="; ") AS ?autresLabels)
(GROUP_CONCAT(DISTINCT ?typeLabel; separator="; ") AS ?types)
(GROUP_CONCAT(DISTINCT ?entiteRemplaceeLabel; separator="; ") AS ?entitesRemplacees)
(GROUP_CONCAT(DISTINCT ?remplaceeParLabel; separator="; ") AS ?remplaceeParx)
(GROUP_CONCAT(DISTINCT ?paysLabel; separator="; ") AS ?pays)
(GROUP_CONCAT(DISTINCT ?siegeLabel; separator="; ") AS ?sieges)
(GROUP_CONCAT(DISTINCT ?fondationFormatee; separator="; ") AS ?datesFondation)
(GROUP_CONCAT(DISTINCT ?dissolutionFormatee; separator="; ") AS ?datesDissolution)
?description
WHERE {
    VALUES ?item {{ {qid_values_autres} }}

    OPTIONAL {{
        ?item skos:altLabel ?altLabel.
        FILTER(LANG(?altLabel) = "fr")
    }}

    OPTIONAL {{
        ?item wdt:P31 ?type.
        ?type rdfs:label ?typeLabel.
        FILTER(LANG(?typeLabel) = "fr")
    }}

    OPTIONAL {{
        ?item wdt:P1365 ?entiteRemplacee.
    }}

    OPTIONAL {{
        ?item wdt:P1366 ?remplaceePar.
    }}
```
OPTIONAL {{
?item wdt:P17 ?pays.
?pays rdfs:label ?paysLabel.
FILTER(LANG(?paysLabel) = "fr")
}}

OPTIONAL {{
?item wdt:P159 ?siege.
}}

OPTIONAL {{
?item p:P571 ?fondationStatement.
?fondationStatement psv:P571 ?fondationNode.
?fondationNode wikibase:timeValue ?dateFondation.
?fondationNode wikibase:timePrecision ?precisionFondation.
BIND(STR(?dateFondation) AS ?fondationStr)
BIND(
    IF(?precisionFondation = 11,
        CONCAT(SUBSTR(?fondationStr, 9, 2), "/", SUBSTR(?fondationStr, 6, 2), "/", S
    IF(?precisionFondation = 10,
        CONCAT(SUBSTR(?fondationStr, 6, 2), "/", SUBSTR(?fondationStr, 1, 4)),
    IF(?precisionFondation = 9,
        SUBSTR(?fondationStr, 1, 4),
        "[date imprécise]"))) AS ?fondationFormatee)
}}

OPTIONAL {{
?item p:P576 ?dissolutionStatement.
?dissolutionStatement psv:P576 ?dissolutionNode.
?dissolutionNode wikibase:timeValue ?dateDissolution.
?dissolutionNode wikibase:timePrecision ?precisionDissolution.
BIND(STR(?dateDissolution) AS ?dissolutionStr)
BIND(
    IF(?precisionDissolution = 11,
        CONCAT(SUBSTR(?dissolutionStr, 9, 2), "/", SUBSTR(?dissolutionStr, 6, 2), "/"
    )
)}
IF(?precisionDissolution = 10,
CONCAT(SUBSTR(?dissolutionStr, 6, 2), "/", SUBSTR(?dissolutionStr, 1, 4)),
IF(?precisionDissolution = 9,
SUBSTR(?dissolutionStr, 1, 4),
"[date imprécise]"))) AS ?dissolutionFormatee)
}}

OPTIONAL {{
?item schema description ?description.
FILTER(LANG(?description) = "fr")
}}

SERVICE wikibase:label {{
bd:serviceParam wikibase:language "fr,mul,en".
?item rdfs:label ?itemLabel.
?siege rdfs:label ?siegeLabel.
?entiteRemplacee rdfs:label ?entiteRemplaceeLabel.
?remplaceePar rdfs:label ?remplaceeParLabel.
}}

}}
GROUP BY ?item ?itemLabel ?description
"""
<figure><img src="image_52.png" /></figure>
# Table des matières

Résumé i

Remerciements iii

Bibliographies thématiques v

Introduction xiii

# I Wikidata : une concrétisation du Web de données pour les institutions patrimoniales et culturelles 1

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

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

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

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

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

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

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

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

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

### II. Une expansion massive 32
IV Annexes 119

A Liste des acronymes 121

B Organigrammes concernant l'Établissement public du musée d'Orsay et du musée de l'Orangerie - Valéry Giscard d'Estaing 125

I. Organigramme général de l'EPMO 125

II. Organigramme de la direction de la conservation et des collections - Pôle ressources et recherches (Anonymisé) 127

C Extrait du code HTML de la page https://data.bnf.fr/fr/ark:/12148/cb11907966z dédiée à Victor Hugo 129

D Modèle de données IFLA-LRM 133

E Modèle de données de data.bnf.fr 135

F Documentation de la base de données The Museum System du musée d'Orsay 145

I. Extrait du modèle de données concernant les liens vers la table « Constituents » 145

G Schéma décisionnel de validation de Mix'n'Match 147

H Schéma décisionnel de validation d'OpenRefine 149

I Documentation du processus d'alignement des entités personnes et institutions du musée d'Orsay 151

I. Schéma global du processus d'alignement des entités personnes et institutions 153

II. Modèle logique de la base de données principale de l'application 2AMO 154

III. Modèle de la table dédiée à l'affichage des données des entités TMS dans l'application 155

J Documentation de l'application 2AMO 157

K Code source de l'application 2AMO 159

L Requêtes SPARQL Wikidata l'interface de validation de 2AMO 161

I. Requête pour la récupération des données des candidats de nature « être hu-
main » (Q5) 161
<table><tr><td>II. Requête pour la récupération des données des candidats qui ne sont pas de nature « être humain »</td><td>165</td></tr></table>