Le chaînon manquant entre les normes patrimoniales et les données patrimoniales

patrimoine culturell'âge a coglobal Des normes pour décrire ce que sont les choses. Ce qui a été plus difficile à obtenir, c'est comment les utiliser efficacement pour permettre aux données d'atteindre leur plein potentiel, notamment pour les trouver, y accéder et les (ré)utiliser, en particulier dans le cadre de requêtes et d'analyses automatisées. Ce qui a manqué jusqu'à présent, c'est La couche sous-jacente : celle qui permet au logiciel de vérifier un fichier réel, de le comprendre et de le transmettre. C’est ainsi que le projet HERITALISE a construit cette couche. en tirant parti de l'approche par blocs de construction OGC, c'est-à-dire la définition, le stockage et la documentation de petits éléments modulaires de spécifications, facilitant la validation, la conformité aux normes et l'évolutivité (voir ci-dessousLes résultats sont publiés. as bblocks-héritage, un registre public de 27 blocs de construction réutilisables. Tla méthode assistée par l'IALe domaine situé derrière celui-ci se transfère à n'importe quel domaine. 

Comment lire cet article ? Le texte principal s’adresse aux concepteurs et aux spécialistes des systèmes de données. Les encadrés « En termes simples » reprennent ces informations sans jargon technique, à l’intention des professionnels du patrimoine qui privilégient le résultat aux aspects techniques. Chaque approche peut être utilisée indépendamment.

Commencez par une chambre à Venaria

La Reggia di Venaria, près de Turin, est l'un des sites pilotes du projet HERITALISE et le premier à imposer un cahier des charges documentaire précis. Prenons l'exemple de la Galleria Grande, la grande galerie de Filippo Juvarra. Une équipe de documentation doit recenser la galerie, le bâtiment qui l'abrite, le site auquel appartient ce bâtiment, l'état de ses surfaces, les relevés laser et photogrammétriques effectués, ainsi que les personnes ayant réalisé ces relevés, les dates et les instruments utilisés.

Demandez quelles normes utiliser, et le domaine vous fournira une réponse pertinente et éprouvée. Décrivez les objets, les lieux, les acteurs et les événements avec CIDOC-CRM, le modèle conceptuel de référence ISO sur lequel la communauté a convergé et qui sous-tend les travaux européens actuels, tels que l'ontologie du jumeau numérique du patrimoine (Heritage Digital Twin Ontology) à l'origine du Cloud collaboratif européen pour le patrimoine culturel (European Collaborative Cloud for Cultural Heritage). Consignez qui a fait quoi, à partir de quoi et avec quel instrument, en utilisant PROV-O. Géolocalisez les données avec GeoJSON. Utilisez SOSA/SSN pour les relevés de capteurs, DCAT pour les métadonnées des jeux de données et EDM si les enregistrements sont destinés à être intégrés à Europeana. 

Ce n'est que la moitié du tableau, car la galerie est aussi un bâtiment intégré à un paysage. Dès lors que la documentation inclut les données 3D et topographiques, une seconde famille de normes s'applique : IFC pour la maquette BIM du bâtiment lui-même, CityGML LandInfra pour le contexte urbain et paysager, INSPIRE pour tout ce qui doit être aligné sur les données géospatiales européennes. La documentation patrimoniale se situe précisément à la frontière entre le monde sémantique et le monde géospatial et BIM, et c'est là que réside la plupart des difficultés pratiques. 

Chacune de ces normes apporte la réponse adéquate à la question pour laquelle elle a été conçue. Cependant, aucune ne fournit, intentionnellement, l'étape suivante : un modèle de données concret pour votre cas d'utilisation. Il faut encore définir le contenu d'une notice de cette galerie, la structure d'une évaluation de l'état du bâtiment (en termes de champs), le lien entre une pièce, le bâtiment environnant et le scan qui l'a capturée, puis associer chaque décision à la terminologie normalisée correspondante, sous une forme exploitable par un logiciel. Un modèle conceptuel de référence vous guide dans la gestion des informations patrimoniales. Il ne réalise pas délibérément cette modélisation et ne peut pas indiquer au logiciel que le lien vers le site parent est manquant.

Ainsi , chaque projet effectue sa propre modélisation, et chaque projet le fait différemment. C'est ainsi que l'on se retrouve avec des ensembles de données qui prétendent tous respecter les mêmes normes, mais qui restent inutilisables ensemble. Cet article traite justement de la réalisation de cette modélisation une fois pour toutes, en accès libre, et de sa publication dans un format exploitable par les logiciels.

En clair, dans le domaine du patrimoine, on s'accorde globalement sur la manière d' appréhender l'information. Il existe des modèles éprouvés et internationalement reconnus pour les objets, les lieux, les personnes, les événements, les bâtiments et les données 3D. Cependant, aucun de ces modèles ne fournit d'informations pratiques : que faut-il exactement inclure dans une fiche descriptive d'une pièce, dans un format exploitable par un ordinateur ? Chaque projet doit trouver sa propre solution, ce qui explique pourquoi deux équipes peuvent respecter scrupuleusement les mêmes normes et pourtant être incapables de lire les fichiers de l'autre. Nous avons déjà réalisé ce travail, pour le patrimoine, et l'avons mis à disposition de tous.

Qu'est-ce qu'un élément de base ?

Un bloc de construction OGC est une petite spécification autonome, ou une partie réutilisable d'une telle spécification. Chaque bloc est un modèle de données pour un type d'élément, et il regroupe, dans un seul paquet sous un nom stable comme ogc.heritage.building :

• a schéma: les champs exacts que possède un enregistrement valide, sous une forme que le logiciel vérifie automatiquement ; 

• a cartographie sémantique: pour chaque champ, le terme standard qu'il désigne, qu'il s'agisse de « fait partie de » selon CIDOC-CRM. site parent Le champ ou le « a été généré par » de PROV-O derrière l'analyse qui a produit un modèle, ce qui permet de transformer un simple fichier de données en un graphe de connaissances ; 

• règles de validation pour ce graphique, détecter les erreurs qu'une vérification champ par champ ne peut pas voir ; 

• Documentation en langage courant ; 

• exemples concrets, testé automatiquement à chaque modification du bloc ; 

• lorsque cela est utile, conversions prêtes à l'emploi à d'autres spécifications. 

Un registre est une collection publiée et mise à jour de tels blocs. OGC Blocks constitue le cadre de leur construction, et des registres publics existent déjà pour de nombreux domaines à usage général.

Les blocs se composent, et c'est sur ce mécanisme que repose tout le reste. La forme la plus évidente est le profilage : on prend un autre bloc tel quel, puis on le contraint ou on l'étend, sans le redéfinir ni le dupliquer. La forme moins évidente est plus importante. Un bloc n'est pas limité à un seul parent. Il peut hériter de plusieurs simultanément, composer des parties d'autres blocs, restreindre son héritage et proposer un choix entre différents parents, le tout dans une seule définition. Les profils sont construits en combinant ces techniques, et non en se spécialisant dans une seule lignée de descendance.

C’est ce qui permet de maintenir un modèle de données à la taille adéquate. Les normes générales sont conçues pour une large applicabilité ; les adopter telles quelles a donc tendance à vous laisser à la fois sur-spécifié et sous-spécifié : elles contiennent des termes et des options sans rapport avec vos données, sans pour autant exprimer la distinction cruciale pour votre cas d’utilisation. De plus, aucune norme, prise isolément, n’est suffisamment complète, quelles que soient les modifications apportées. La combinaison de normes vous permet d’éliminer ce qui ne s’applique pas, d’ajouter les détails précis et de vous appuyer sur une deuxième, voire une troisième spécification là où la première s’arrête. Les données écrites avec l’un de nos blocs restent valides pour tous les blocs sur lesquels il s’appuie, et ainsi de suite. La section suivante illustre ce principe dans un contexte réel. 

Ensemble, cela couvre les trois choses dont les pilotes avaient réellement besoin : 

• Décrire. Tous les intervenants, du conservateur qui saisit les données au développeur qui conçoit des outils à partir de celles-ci, travaillent à partir d'une définition précise des données. 

• Valider. Le schéma détecte les erreurs structurelles ; les règles du graphe détectent les erreurs significatives, comme une relation manquante ou un objet typé incorrectement. 

• Transformer. À deux niveaux. Les correspondances sémantiques d'un bloc (les siennes propres, ainsi que celles héritées des blocs sur lesquels il s'appuie) transforment un enregistrement brut provenant du système d'un partenaire en un graphe interrogeable et lié, prêt pour l'agrégation de type Europeana. De plus, les blocs peuvent publier des tables de correspondance : des conversions prêtes à l'emploi vers d'autres blocs et spécifications, fournies avec le bloc afin d'éviter toute réimplémentation ultérieure. 

En clair, un bloc de construction est une spécification succincte définissant un type d'information : le contenu obligatoire d'un enregistrement concernant un bâtiment, une pièce ou un relevé, la signification de chaque élément et les critères permettant de distinguer un enregistrement correct d'un enregistrement erroné. Ce bloc est accessible à une adresse web fixe, ce qui permet à un logiciel d'agir directement sur chaque partie, évitant ainsi à un humain de le lire et de l'interpréter. Les blocs s'empilent les uns sur les autres, et peuvent être combinés : un bâtiment historique est un élément du patrimoine auquel on a ajouté des éléments, et un enregistrement issu d'une numérisation 3D peut satisfaire simultanément aux normes patrimoniales, de provenance et de cartographie, vous évitant ainsi d'avoir à choisir.

La réponse pour la Galleria Grande

Avec cela en main, la question « comment structurer cela ? » trouve une réponse concrète : 

lieu (CIDOC-CRM E53 Lieu, décrit le bloc d'entités géospatiales standard)
  └── site patrimonial (Site CIDOC-CRM E27) → la Reggia di Venaria
        └── bâtiment (CIDOC-CRM E22 Objet fabriqué par l'homme, alignement IFC)
              └── espace architectural (CIDOC-CRM E22, IFC IfcSpace) → la Galleria Grande 

Chaque niveau ajoute uniquement les éléments nouveaux à ce niveau et hérite du reste. Le niveau « bâtiment » ajoute un lien vers son site parent et hérite de tout le reste, jusqu'au champ URL mappé à l'URL d'accès DCAT, du bloc « objet patrimonial » situé au-dessus. Les alignements IFC véhiculés par les niveaux « bâtiment » et « espace architectural » permettent à une fiche de cette chaîne de circuler entre le catalogue patrimonial et la maquette BIM de la même pièce sans nécessiter de traduction spécifique à chaque fois.

Ajoutons maintenant la numérisation laser d'une travée de cette galerie, et la combinaison de plusieurs normes prend tout son sens. Une numérisation est à la fois trois choses : un historique de provenance, une localisation spatiale et une valeur patrimoniale. Aucune norme ne couvre ces trois aspects simultanément ; c'est pourquoi la représentation numérique les combine. Elle hérite de l'entité PROV-O pour la provenance. Pour la localisation, elle propose le choix entre une entité GeoJSON (JSON-FG) et une entité topographique , selon que l'enregistrement possède sa propre géométrie ou pointe vers celle d'un tiers. Son ancrage CIDOC-CRM se situe dans la couche sémantique. Elle ajoute ensuite ses propres propriétés et restreint l'identifiant hérité pour exiger un URI valide. Un seul enregistrement, trois spécifications satisfaites simultanément, aucune duplication, et l'enregistrement reste une instance valide de chacune d'elles.

Ce choix géométrique est particulièrement intéressant. Le relevé de la baie couvre exactement la zone cartographiée ; ainsi, au lieu de répéter le polygone dans le document, celui-ci pointe vers la géométrie propre à l’espace architectural par référence. Les deux ne peuvent diverger ultérieurement, puisqu’il n’existe qu’une seule copie. Il s’agit de liens explicites et lisibles par machine entre les modèles de données, et non d’une simple déclaration de compatibilité dans un document. 

La même chaîne décrit la Villa Portelli, une résidence du XIXe siècle à Malte et l'autre site pilote du projet : mêmes quatre niveaux, un bâtiment différent dans un autre pays, aucun nouveau schéma requis. Une seule définition, deux projets pilotes, deux exemples concrets. Cette réutilisation sur des sites sans lien apparent est l'avantage pratique d'ancrer les blocs aux classes CIDOC-CRM plutôt qu'au vocabulaire utilisé localement par chaque site. 

En clair. Quatre spécifications imbriquées : un lieu, un site patrimonial, un bâtiment sur ce site et une pièce à l’intérieur de ce bâtiment. Décrivez la pièce et vous obtenez automatiquement toutes les informations déjà convenues concernant le bâtiment, le site et le lieu où il se trouve. Ces mêmes quatre spécifications s’appliquent aussi bien à un palais royal baroque en Italie qu’à une maison du XIXe siècle à Malte, ce qui correspond exactement à l’objectif : deux équipes documentant des éléments très différents, de manière à ce qu’un tiers puisse les interpréter. Et comme chaque enregistrement est également un objet géospatial à part entière, le relevé d’une pièce peut simplement pointer vers son contour, évitant ainsi de conserver une seconde copie qu’il faudrait ensuite mettre à jour.

L'audit qui a précédé toute rédaction

La première véritable décision a porté sur ce qu'il ne fallait pas écrire. Des registres publiés et maintenus existent déjà pour la plupart des couches génériques :

Ce que personne ne publie, c'est la couche où le patrimoine est véritablement spécifique : CIDOC-CRM et EDM appliqués aux objets, lieux, acteurs et événements patrimoniaux physiques, ainsi qu'à leurs représentations numériques, en complément des normes géospatiales et BIM, au lieu de les ignorer. C'est là que réside la véritable contribution du registre. Tout élément créé dans bblocks-heritage est ancré à une classe CIDOC-CRM, CRMdig, CRMsci ou EDM et compose les importations ci-dessus au lieu de les dupliquer. La représentation numérique est construite en composant le bloc de provenance importé, et non en réinventant les champs de provenance.

Cet audit comparant l'existant aux lacunes existantes et les véritables manques mérite d'être mené avec soin et consigné par écrit. Il fait toute la différence entre un registre qui enrichit la couverture et un autre qui ne fait qu'alourdir un paysage normatif déjà saturé. 

L'audit a même court-circuité un cas d'utilisation entier. Un cas d'utilisation d'HERITALISE concerne les observations et les mesures sur les sites patrimoniaux : des relevés de capteurs, tout simplement. Lorsque ses exigences ont été soumises à la même recherche croisée entre registres, chacune d'elles a abouti aux blocs SOSA/SensorThings existants, et le nombre correct de nouveaux blocs à créer s'est avéré être zéro. Une méthode capable de vous dire avec certitude « vous n'avez besoin de rien de nouveau ici » remplit parfaitement son rôle. Le mode d'échec coûteux dans ce domaine est le registre qui réinvente les observations de capteurs en y ajoutant un vocabulaire patrimonial. 

En clair. Avant toute chose, nous avons vérifié l'existant. La provenance, les vocabulaires, les catalogues de jeux de données et les relevés de capteurs sont autant de problèmes résolus, avec des solutions publiées et mises à jour. Nous les avons donc réutilisés plutôt que de créer une nouvelle variante obsolète. Pour l'un des cas d'utilisation du projet, la conclusion a été sans appel : rien de nouveau n'était nécessaire. Savoir s'abstenir est aussi précieux que d'inventer.

Quatre mouvements, répétés par pilote

La méthode elle-même est suffisamment courte pour être résumée en détail : 

1. Consignez les exigences dans un format tabulaire cohérent. Les besoins de chaque pilote étaient consignés dans un tableau, une ligne par besoin de données. Ce format permettait de les recenser et de les suivre, même si le contenu de chaque cellule était principalement constitué de textes libres rédigés par des experts du domaine plutôt que par des auteurs de schémas.
2. Commencez par définir les normes, puis rédigez les schémas. Avant l'existence d'un schéma unique, chaque exigence était associée, sous forme de document, à l'élément correspondant : une propriété CIDOC-CRM, une relation PROV, une classe d'observation de capteur ou un concept IFC. Cette association, sous forme de texte argumentatif, est indépendante de tout identifiant de bloc et constitue toujours le document de référence. why Chaque bloc conserve sa structure. Les exigences déjà couvertes par un bloc existant ou un registre importé ne nécessitaient qu'un exemple, et non un nouveau schéma. Plusieurs exigences de Venaria relatives au jardinage ont ainsi été résolues.
3. Rédigez un bloc à la fois, en suivant une liste de contrôle fixe. Vérifiez si l'élément existe déjà et peut être réutilisé ; rédigez le schéma ; associez chaque champ à son terme CIDOC-CRM, PROV, EDM ou IFC ; définissez les règles de validation du graphe ; rédigez une description en langage clair ; et fournissez au moins deux exemples basés sur des données pilotes réelles, l'un adapté à Venaria et l'autre à Malte si possible. Deux exemples par bloc ne sont pas superflus. Les exemples basés sur des données pilotes constituent la preuve concrète qu'un bloc répond bien à l'exigence annoncée.
4. Vérifiez avant de passer à l'étape suivante. Chaque exemple est vérifié automatiquement de trois manières : par rapport au schéma, lors de la conversion en graphe, puis par rapport aux règles du graphe une fois la conversion effectuée. Un bloc n'est considéré comme validé que lorsque toutes ces vérifications sont réussies. Nous avons délibérément évité de générer un lot de blocs en masse pour ensuite les valider a posteriori. Plusieurs problèmes non évidents n'ont été détectés qu'au moment de la validation, et les corriger bloc par bloc s'est avéré bien plus économique que de les résoudre simultanément sur un grand nombre de blocs.

Cette dernière règle s'est avérée indispensable dès le départ. Une analyse de normes antérieure, dont nous avons hérité, comportait des règles de validation écrites manuellement par un autre assistant IA et qui n'ont jamais été exécutées. Nous l'avons considérée comme un point de départ, et non comme une vérité absolue, et nous n'avons rien conservé sans l'avoir soumise à de véritables vérifications. « Généré par IA » et « Généré et vérifié par IA » sont deux choses différentes. 

En clair : notez vos besoins, ligne par ligne. Avant toute conception, identifiez la norme existante qui couvre chaque élément. Développez ensuite chaque composant un par un et prouvez son bon fonctionnement sur des exemples concrets issus d'un site réel avant de passer au suivant. Rien n'est accepté simplement parce que cela paraît plausible, y compris les solutions générées par une IA.

La partie où l'IA justifie sa place

Nous avons utilisé Claude Code pour la création du code : lecture des exigences, écriture des schémas et des correspondances sémantiques, validation et itérations en cas d’erreur. Son efficacité et son autonomie sont dues au fait que l’assistant ne partait pas de zéro. Il a pu s’appuyer sur un ensemble conséquent de ressources, d’outils et de services dédiés à ce type d’assistant IA. Une grande partie de ces ressources existait déjà avant HERITALISE. La création de ce registre a permis de l’améliorer et de combler les lacunes qui n’apparaissent qu’une fois la méthode déployée de bout en bout dans un domaine réel. Ce registre est donc un aboutissement de cette démarche, au même titre que le registre lui-même.

Des compétences, pas des suppositions. Une compétence d'agent est un ensemble d'instructions et de documents de référence qu'un assistant IA charge lorsqu'il rencontre une tâche d'un type donné : en d'autres termes, l'expertise écrite d'une personne ayant déjà réalisé la tâche, sous une forme que l'assistant peut utiliser à la demande. Nous créons et maintenons OGC LLM Skills , un référentiel public de compétences pour les travaux sur les blocs OGC. Une compétence concerne la création de blocs ; une autre couvre le traitement en aval, la validation des données par rapport aux blocs publiés et leur conversion en graphe. Parallèlement, un service de recherche permet à l'assistant de parcourir tous les registres publiés, par mot-clé et par signification, avant toute nouvelle rédaction. C'est ce qui a permis de transformer des jugements tels que « ne pas réinventer la provenance » et « le cas d'utilisation des observations ne nécessite aucune nouveauté » en vérifications rapides et fiables, plutôt qu'en recherches manuelles de spécifications.

Une mémoire de travail qui perdure au-delà de la session. Un fichier de planification dynamique conserve la trace de la portée, de l'état, de l'ordre de création, des dépendances entre les blocs et, surtout, un journal d'activité recensant les leçons apprises lors de la validation. Prises individuellement, ces leçons sont anecdotiques. Collectivement, elles font toute la différence : le vingt-cinquième bloc passe la validation sans encombre, tandis que chaque bloc reproduit la même erreur que le premier. Chaque leçon a été apprise en effectuant les vérifications nécessaires et en analysant les erreurs réelles, puis consignée à l'endroit où la session suivante pourrait la retrouver. Ce sont les compétences acquises et le fichier de planification qui permettent à ce savoir de s'accumuler dans tout le système, au lieu de disparaître à la fin de chaque session.

En clair, l'assistant IA n'a pas été invité à improviser. Il a reçu une expertise écrite détaillée sur ce type de travail, un service de recherche pour vérifier l'existant avant toute proposition, et un carnet de notes mis à jour régulièrement afin que les enseignements tirés le lundi soient encore pertinents le vendredi. C'est grâce à cette combinaison que le travail est suffisamment fiable pour être publié, et qu'il est entièrement public, permettant ainsi au prochain projet de ne pas repartir de zéro.

Que contient le registre aujourd'hui ?

Tout ce qui est publié et validé, sous la ogc.patrimoine. préfixe. objet patrimonial, endroit et acteur transporter les entités principales. site patrimonial, bâtiment et espace architectural sont la chaîne que ce message a suivie. ensemble de données d'enquête et évaluation de l'état couvrir les travaux effectués sur un site, histoire orale et déclaration historique Les informations les concernant, ainsi que les enveloppes des caractéristiques, font de chacun d'eux un objet géospatial de premier ordre. Le reste, de seuil de surveillance à route, sont inscrits au registre. 

Chaque bloc est ancré dans les normes sur lesquelles il s'appuie, le plus souvent CIDOC-CRM, CRMdig, CRMsci, PROV-O ou EDM, et souvent dans plusieurs simultanément. Chaque bloc possède un schéma validé, un mappage sémantique, des règles de validation de graphe où il introduit ses propres contraintes, et au moins deux exemples, la plupart directement issus des données pilotes de Venaria ou de Malte. Découvrez-les tous sur ogcincubator.github.io/bblocks-heritage.

Ce n'est pas une recette réservée aux traditions.

Si votre problème se formule ainsi : « J’ai un cas d’utilisation et des données, et je dois les modéliser, les valider, les mapper à quelque chose (notamment sémantiquement), et éventuellement les transformer », le même chemin s’applique quel que soit le domaine : 

• Un exemple fonctionnel à l'échelle réelle: bblocks-héritage (source), chaînes de profils, règles de validation, exemples et tout le reste. 

• Les compétences, prêtes à être installées: Compétences OGC LLM (sourceCe module met à disposition les compétences de création et de consommation, prêtes à être installées par vous ou votre assistant. Il est compatible avec claude.ai, Claude Code et l'API Claude. 

• Le cadre: la Documentation des blocs OGC explique la démarche et comment créer son propre registre. 

La méthode en résumé : auditer l’existant avant toute modélisation, aligner les exigences sur les normes avant de les associer aux schémas, modéliser et valider chaque élément un par un à l’aide de données réelles, et consigner chaque leçon, même non évidente, afin de ne la reproduire qu’une seule fois. Il s’agit d’un processus itératif, et non d’une spécification figée. Un assistant IA doté des compétences métiers adéquates accélère ce processus, ce qui rend possible une itération à ce niveau de détail. Il ne remplace cependant pas le processus itératif. 

Pour HERITALISE, ce processus a permis de transformer les exigences textuelles de sites patrimoniaux réels en un modèle de données public : 27 blocs, chacun ancré à des normes reconnues par la communauté, intégrant sa propre validation et sa propre sémantique, et conçu pour répondre aux besoins géospatiaux et BIM, au lieu de les ignorer. Les ressources, outils et services qui ont rendu cela possible (les compétences, le service de recherche, la méthode elle-même) sont publiés, testés sur un terrain réel et prêts pour le prochain projet.