Description fonctionnelle et technique

Je propose ici des solutions techniques qui paraissent pertinentes, mais l’implémentation apportera sans doute, là aussi son lot de modifi-cations.

Figure 6.1 – Brouillon d’interface vierge

Figure 6.3 – Brouillon d’interface pour la consultation d’annotation/de modélisation

Stockage des documents et des données

L’outil doit gérer la documentation et des données en partie extraites de la documentation, œuvrer pour améliorer l’intégrité documentaire. Je propose que les documents soient agrégés en l’état dans un lac de données (data lake), ou lac de documents pour l’utilisation que je propose. Les données quant à elles sont stockées dans un triple store formaté en RDF, mis en œuvre par SPARQL pour structurer des données sous la forme de NQUADS[CHH08]. L’utilisation de NQUADS plutôt que des triplets classiques permet la mise en place d’un mécanisme évitant la duplication des données.

Pour rapidement expliquer ici ces concepts, les triples RDF ont une forme simple :

Sujet ^prédicat! Objet

Si la relation est orientée, on distingue le sujet de l’objet. Quand la relation est symétrique, la distinction n’est que formelle.

Les N-QUADS sont apparus pour permettre de créer des graphes nom-més, identifiant des sous ensembles d’un graphe. J’en détourne ici l’usage

en leur donnant la forme la plus réduite : je recommande de créer systé-matiquement des graphes nommés ne contenant qu’un triplet.

Nom du graphe ^prédicat_!^h sujet ^prédicat_{! objet} ⁱ

Par ce procédé, on peut identifier chaque information de façon unique et y référer de façon univoque. Cela permet également d’éviter la dupli-cation des informations (dans la limite de leur hétérogénéité). Pour cela, je propose de reprendre le fonctionnement mis en place par le projet So�ware Heritage, qui archive tous les projets de développement logiciel accessibles de façon publique dans les services de gestion de dévelop-pement de logiciels (comme GitHub, GitLab, SourceForge, ...). La grande quantité d’informations qu’ils archivent et la pratique courante dans le code logiciel de copier des parties, de forker des projets leur cause un grand risque de duplication.

Travaillant seulement avec des documents textes, ils ont eu l’idée d’associer un identifiant particulier à chacun de leurs documents : un hash en anglais, une empreinte numérique, produite par le calcul d’une fonction de hachage. La fonction de hachage a le comportement sui-vant : si le contenu à hacher est identique, l’empreinte est identique, si le contenu est différent, l’empreinte sera nécessairement différente1.

Par la même approche, puisque le contenu de notre triplestore n’est que du texte, je propose de hacher le triplet et d’en faire un graphe nommé par son emprunte numérique.

0x428a2f98 ^identifie_{! [ Objet1} ^Predicat1_{! Objet2 ]} 0xd807aa98 ^identifie_{! [ Objet1} ^Predicat1_{! Objet3 ]} 0x983e5152 ^identifie_{! [ Objet1} ^Predicat2_{! Objet1 ]} ...

On gagne ainsi la capacité de faire référence à chacune des informa-tions de notre base. Par extension, on pourra tout de même créer des graphes nommés pour identifier des groupes d’informations. Il devient alors possible d’attribuer simplement et de façon fiable des méta)donnés à ces graphes nommés.

Le dépôt d’un document dans le lac de données entraine la création d’informations dans notre base de données orientées graphes : les méta-données accessibles relatives à cet ajout sont crées, et le document est

1. Une des fonctions de hachage standard SHA-2, par exemple, que nous avons utilisée, peut produire de l’ordre de grandeur de 1038empreintes avant de se répéter

indexé. On sait qu’il existe, on lui attribue une dénomination, une date d’ajout,...

Dans un second temps, s’il est consulté, chaque affichage du docu-ment est enregistré dans notre base de données.

Lorsqu’un utilisateur cherche à sélectionner une partie du document pour identification d’une donnée ou pour créer une annotation, alors un module d’import/export est sollicité : Les données sélectionnées dans le document originel sont importées dans notre base de données. (un groupe de pixels, de points ou de facettes, une zone de texte ou un extrait de tableau ou de graphe, ...).

Ces sélections documentaires distantes des documents originaux permettent ensuite :

— de lier des informations au travers des documents et des types de documents,

— d’exporter les sélections dans des documents nouveaux sans confu-sion ou altération possible avec le document original,

— de nommer, classer, comparer, combiner, etc. les sélections entre elles.

Gestion des modèles de données

Une contrainte importante dans la réalisation de l’outil est sa capacité à ne pas restreindre les différents concepts manipulés.

À l’import de données depuis une source, le vocabulaire ou le méta-modèle de la source est repris, ou alors un vocabulaire de traduction permet l’import des données. Je propose qu’un système d’annuaire pilote la gestion des vocabulaires : il référence les vocabulaires à disposition et permet l’ajout de nouveaux vocabulaires. Un vocabulaire local permet de compléter et d’assurer la liberté ontologique maximale.

Modules de traitement automatique

L’interface permet le travail manuel sur les documents et les données. Le développement de modules de traitement automatique étend les ca-pacités de l’outil. À titre d’illustration, je propose ici quelques exemples de modules.

Remodéliser des données 3D

La remodélisation 3D se fait le plus souvent dans un logiciel dédié aujourd’hui : un modeleur capable d’afficher des nuages de points. En

se calant sur le nuage de points qu’il interprète, l’utilisateur remodèle les géométries et les éléments qui l’intéressent. Les formes sont seg-mentées d’après la compréhension de l’utilisateur, les géométries sont normalisées et rapportées à des primitives mathématiques simples.

Cette opération de modélisation recourt de façon standard à des catalogues de pièces et de formes, et permet ainsi d’intégrer un grand nombre d’informations : le type de pièce modélisé, la fonction qu’elle remplit, le matériau dont elle est constituée. Lorsqu’elle est voulue très complète, cette remodélisation est fastidieuse et demande à l’utilisateur de définir chaque élément et de redessiner les formes. Certains détails sont inéluctablement omis, certains imperfections témoins d’activités ou de l’état des matériaux sont lissées.

La remodélisation automatique, connait un développement net dans les dernières années [MLG17, PNNB18, TKKDV18, OVK19]. Elle non plus n’est pas exempte de simplifications et de lissage. Elle produit cependant des résultats intéressants pour des segmentations à l’échelle du bâtiment (la segmentation se fait à la dimension du mur ou du pan de mur).

Adjoindre un module de remodélisation automatique permettrait d’obtenir des segmentations des données 3D dans des échelles définies par l’utilisateur, sans que ce dernier n’ait besoin de développer des com-pétences de remodélisation, ou d’acquérir des logiciels spécialisés. Moins réalistes, ces remodélisations schématiques permettent de distinguer et désigner des éléments qui pourront être retravaillés dans un temps second.

Remodéliser les textes

De façon analogue, je propose d’intégrer des systèmes de remodéli-sation des textes permettant de faciliter ou de préparer l’encodage TEI. À partir d’outils de reconnaissance d’images, la structure du document (chapitres, paragraphes, notes de bas de page...) est automatiquement capturée afin de permettre à l’utilisateur de se concentrer sur la modé-lisation du contenu. Ces fonctionnements existent dans des outils à la maturité déjà importante [MRK03, SKB08, LNK12].

Automatiser les propositions d’informations

Une des limites aux études patrimoniales tient dans la diversité des sources d’information accessibles, permettant d’intégrer une variété d’information la plus grande possible, multipliant les points de vue, étof-fant la compréhension.

Les propositions d’informations ou de documentation se basent sur des outils de classification automatique, calculant des similarités entre différents objets. À l’échelle du document, j’ai déjà parlé d’Haruspex qui permet de faire des propositions de regroupement de textes par mo-délisation de sujet, à partir de leur contenu lexical. Pour des modèles 3D, les mêmes mécanismes et outils existent [DDK+17, NSH04, VHK11], pour des images en 2D également [SMGE11, GWL+17]. Développés dans différents contextes (médical, industriel, cartographique,...) ces outils de classification automatique me semblent des modules intéressant pour enrichir les modélisations.

Gérer la traçabilité

Je propose également d’avoir recours à une des ontologies dédiée aux questions de traçabilité des informations, des documents et pour suivre les différentes étapes de modification. PROV-O[LSM+13], ou SEPPIO[BSH16], me paraissent les plus intéressants. L’évolution et la maintenance de PROV-O, désormais entre les mains du W3C (World Wide Web Consortium), me conforte dans la pérennité de cette ontologie.