Introduction

1Les unités de recherche en archéologie gèrent souvent des archives volumineuses, constituées de documents hétéroclites : rapports de terrain, thèses, catalogues et ouvrages de référence. Ces archives représentent des décennies de travail, mais il est généralement difficile de les consulter et d’y accéder dans la mesure où il s’agit de documents fragiles, parfois uniques et stockés dans des laboratoires variés. Dans ce contexte, leur numérisation en texte intégral n’est pas suffisante ou, en tout cas, la numérisation est une bonne opportunité pour enrichir les documents d’index et de thésaurus structurés : pour cela, il est nécessaire de formaliser et structurer ces documents ainsi que les informations qu’ils contiennent, puis d’en faciliter l’accès grâce à des interfaces conviviales.

3Il faut noter que cet article, pour l’essentiel, ne présente pas une nouvelle application finalisée, mais plutôt le travail préparatoire pour y parvenir. Il serait évidemment plus facile de valoriser une application finie et conviviale, avec différentes fonctionnalités répondant à des besoins précis, mais nous pensons que le travail préparatoire, plus ingrat, sur les données, les termes, leur signification et leurs problèmes inhérents (ambiguïté, polysémie, changement de sens au cours du temps, etc.) sont aussi importants et assez peu mis en avant dans le domaine.

4Nous décrivons dans un premier temps les sources du projet, à savoir les systèmes d’information et les corpus utilisés afin d’enrichir les bases de données visées. Dans un second temps, nous abordons la constitution du lexique : comment nous avons sélectionné automatiquement les termes dans le corpus d’enrichissement, comment nous avons procédé pour structurer manuellement ces termes, quel format standard nous avons décidé d’utiliser afin de structurer notre thésaurus. Enfin, nous décrivons la plateforme mise en place, les extractions et manipulations qu’elle permet, les modifications et améliorations qui restent à développer.

À l’origine, le PEPS CNRS-PSL EITAB

5La coopération entre archéologues, linguistes et informaticiens vise à concevoir et à valider un traitement automatisé des corpus, de façon à réduire le temps d’intervention, à accroître la fiabilité des résultats et à faciliter le partage des données dans un contexte interdisciplinaire (traitements statistiques, historiques, thématiques) : autrement dit, améliorer l’environnement d’étude et de recherche de l’archéologue. Il s’agit de mettre en correspondance semi-automatiquement des informations extraites de textes avec des « champs » d’une base de données.

Les sources brutes

6Les documents dont disposent les archéologues sont nombreux. L’étude pilote dont il est question dans cet article a été menée à partir de deux types de documents, fortement structurés ou non. Les documents structurés nécessitent peu de traitement : il est aisé d’en extraire les informations essentielles par un jeu de simples « scripts » informatiques. Ce sont des fiches, des notices, des documents où l’information est classée, facile à repérer. Inversement, les documents peu structurés sont plus complexes à analyser. Notre propos est ici de montrer qu’il est possible d’analyser ce type de documents, d’utiliser des documents bruts en vue de l’enrichissement de données structurées. Si dans cet article nous parlons principalement du second, les deux types de documents ont cependant servi à tester la robustesse de la méthode.

7Lors de notre projet, nous avons utilisé une collection de textes couvrant des fouilles liées à la période gauloise, les Cartes archéologiques de la Gaule (CAG) (Coulon et al. 1992 ; Provost et al. 1992). La zone englobe une grande partie de la France actuelle, de l’âge du fer à la période médiévale. 128 volumes ont été publiés jusqu’à présent. Chaque volume correspond à un département français, et certains départements sont couverts par plusieurs volumes. L’étude pilote concernait trois de ces volumes, correspondant aux départements de l’Indre et du Cher. Ces textes retracent la plupart des découvertes archéologiques recensées dans les zones et les époques concernées.

8L’idée est bien sûr de numériser ces documents et de permettre leur mise en ligne, mais aussi (et surtout) d’en extraire les informations clés afin d’alimenter les différents « champs » des bases de données. L’exemple de la figure 1 est un texte restituant les découvertes faites à Moulins-sur-Yèvre, commune du Cher. Il est fait mention de trois sites archéologiques : le camp de Chou, le camp de Maubranches et le camp de Vercingétorix.

9L’ensemble des CAG est structuré de façon identique. Une CAG liste les communes d’un département. Chaque commune est un bloc textuel qui recense les découvertes archéologiques. Chaque bloc commence par un chiffre suivi d’un tiret puis du nom de la commune et enfin, entre parenthèses, son numéro INSEE. Cette information peut être modélisée au moyen d’une expression régulière simple, qui permet d’établir une relation entre un lieu et les découvertes archéologiques réalisées.

Les sources à enrichir

10La BaseFer (Buchenschutz et al. 2015) répertorie les gisements de l’âge du Fer, par commune, en indiquant les types de structures et les principaux mobiliers associés. Elle donne une image globale des connaissances sur l’âge du Fer. Elle n’est pas exhaustive. Le projet a été pensé pour enrichir cette base de données.

11Les tables de la BaseFer permettent de décrire les éléments ou objets découverts lors de fouille, site par site. Sur la commune de Moulins-sur-Yèvres (figure 2) sont recensés trois sites archéologiques, ce qui correspond à trois fiches dans la base (comme l’indique le compteur 3/15734). L’une d’elles recense les découvertes archéologiques du site Champ de Chou. Les champs permettent de lister les structures ou mobiliers et ecofacts de chacun des sites. Ainsi le fossé est un type de structure, parmi les habitats. En cliquant sur l’onglet mobiliers et ecofacts de ce formulaire, l’utilisateur accède au recensement de la découverte du lignite qui correspond à un type de mobilier, parmi les mobiliers de type parure.

13L’ensemble des participants du projet a étudié la BaseFer afin d’appréhender son modèle de données. Les experts du domaine – les archéologues – ont expliqué les éléments présents dans la base. Les linguistes informaticiens ont appréhendé a minima le lexique afin de comprendre le domaine d’application. Jamais cependant ces derniers n’ont prétendu en saisir toute la finesse et n’ont pu acquérir la sensibilité linguistique optimale nécessaire à la structuration du lexique. En aucun cas, ils ne se sont substitués à l’expert. Sur toute la durée du projet, un perpétuel échange entre archéologues et linguistes informaticiens a été nécessaire.

14En effet, il est difficile pour une néophyte de savoir ce qu’est une fibule (sorte d’agrafe), une armille (bracelet de bronze pour le bras), ou encore un artefact (objet résultant de l’activité humaine). À cela s’ajoute le problème de la polysémie lexicale, un même terme peut référer à différents objets. Par exemple, la fosse peut être un dépôt, un cimetière ou encore une structure en creux. Un même terme peut évoluer au fil des années, des siècles et ne plus désigner la même chose. Ainsi quand un archéologue rédige un article, un carnet de terrain, il emploie toutes les richesses de la langue. C’est pourquoi, lors de la constitution d’un thésaurus, il revient à l’expert de déterminer la signification exacte d’un terme en fonction du contexte.

15À partir de cette première analyse des sources, l’idée était d’extraire automatiquement l’ensemble des termes des CAG, de créer une liste à plat de termes, c’est-à-dire une simple liste de termes, non hiérarchisée, non structurée. Il est important que cette liste soit large, ne soit pas trop restreinte. L’outil ne doit pas écarter des termes potentiellement importants, significatifs pour le domaine. Mieux vaut une présélection large que l’utilisateur peut à souhait consulter, retravailler, restreindre.

Extraire et hiérarchiser les termes

16Le projet n’avait pas pour ambition de développer de nouveaux outils. Le travail a essentiellement consisté à choisir parmi les outils existants ceux qui étaient le mieux adaptés à la situation, puis à les paramétrer et les lier entre eux pour constituer une chaîne de traitement adaptée (Lamani 2013).

Extraire les termes

• 4 https://perso.limsi.fr/hamon/YaTeA/.

YaTeA (Yet Another Term ExtrActor) est un extracteur de termes. Il identifie et extrait des groupes nominaux pouvant être des termes, c'est-à-dire des termes candidats. Chaque terme candidat est analysé syntaxiquement pour faire apparaître sa structure sous la forme de têtes et modifieurs4.

18YaTeA offre la possibilité de redéfinir ou de modifier le processus d’extraction à travers plusieurs fichiers de configuration. On peut ainsi préciser la langue, les portions de texte qu’il faut ou non inclure (inclusion ou non des titres pour les traitements, par exemple), le type de termes à considérer (termes simples – monogramme – ou complexes), si le logiciel doit aussi extraire les termes simples inclus dans des termes complexes, etc. (figure 4).

19YaTeA est un module Perl. C’est un logiciel libre disponible en ligne. Son utilisation s’effectue en ligne de commande. Il prend en entrée un texte étiqueté morphosyntaxiquement à l’aide de TreeTagger (Schmid 1997). Il n’a pas d’interface graphique, et est de ce point de vue difficile à utiliser pour un non-informaticien.

20Les informations sont extraites du corpus sous forme de listes de termes, appelés termes candidats. Chaque terme candidat de la liste est constitué d’un mot ou groupe de mots.

21En sortie, la liste des termes est importante, elle contient beaucoup de bruit, c’est-à-dire beaucoup de termes candidats qui ne sont pas pertinents pour la tâche. À titre d’exemple, la CAG du Cher est un document de 132 462 mots. YaTeA extrait de ce texte 14 000 termes candidats. La liste des termes candidats contient des monogrammes et des multigrammes, elle est ainsi composée de plus de 3 500 mots (chaque mot pouvant apparaître plusieurs fois dans la liste des termes extraits, d’où le fait qu’il y ait beaucoup moins de mots différents que de termes extraits).

22C’est principalement pour effectuer des sélections dans cette liste de termes candidats que la plateforme développée est d’une aide précieuse pour l’expert, comme nous le verrons ultérieurement.

Structurer les termes

23La liste obtenue en sortie de YaTeA est une liste plate, un fichier texte. Il s’agit maintenant non seulement de la nettoyer – enlever le bruit – mais aussi et surtout de la structurer. C’est sur ce second point, complexe, qu’un premier travail est mené.

24Dans la liste obtenue, il est plus ou moins facile de repérer différentes variantes d’un même terme. Il peut s’agir d’une simple variante graphique (âge du fer, âge du Fer, Age du Fer), d’une différence de nombre (amphore républicaine, amphores républicaines), d’écriture en chiffres ou lettres (premier âge du Fer, 1^er âge du Fer), d’écriture alternative (clef, clé) ou encore de différence terminologique (cuillère, cuilleron). Mais comment structurer ces variations ?

25Afin de structurer le vocabulaire, l’ensemble des termes extraits, nous avons utilisé un éditeur initialement développé par l’INRA. TyDI (Terminology Design Interface) est un outil collaboratif pour la validation et la structuration de termes en ontologie (figure 5). Il est intégré à AlvisAE (Alvis Annotation Editor [Papazian et al. 2012]), plateforme d’annotation en ligne. Cette plateforme permet de visualiser et d’annoter les entités, de lier et de typer les entités. TyDI permet la gestion de campagnes d’annotation. C’est un éditeur complexe, spécifique au traitement de données biologiques.

26Comme tout éditeur, TyDI permet de faciliter la classification des nombreuses données fournies en entrée. Ce travail aurait pu être fait avec un autre éditeur d’ontologie, mais TyDI (contrairement à d’autres éditeurs) permet de voir le terme en contexte, ce qui aide au travail de classification et au nettoyage de la liste. En observant parallèlement le texte et l’ontologie en devenir (c’est-à-dire en cours de construction), l’expert parvient plus aisément à structurer sa terminologie et son domaine. La contextualisation est un avantage non négligeable pour ce type de tâches.

27La structuration de la BaseFer (les champs et les tables de la figure 2) est reprise pour constituer une première ontologie des termes extraits, dégager des concepts. Comme l’illustre la figure 2, les concepts tels que ecofact, mobilier ou encore structure sont les parents des termes extraits du corpus tels que fosse, dépôt.

29Le format OBO permet de gérer les phénomènes de synonymie et variation lexicale. Ainsi dans notre ontologie, âge du Fer a pour exact synonyme l’ensemble des variations possibles de ce terme : âge du Fer ou Âge du Fer (figure 7). De même, les mentions en texte de la période protohistorique Âge du bronze ou Âge du bronze moyen sont rattachées à un seul et même concept Âge du bronze, fils du concept période protohistorique.

30Quel que soit l’éditeur d’ontologie utilisé, les variations lexicales restent les mêmes et sont au cœur de la structuration de l’ontologie. Selon le type de texte à analyser et la richesse de la structure souhaitée, le format de l’ontologie est différent. Le classement des termes est fait par le terminologue, en l’occurrence ici l’expert du domaine. Seul l’archéologue peut établir un modèle de classification en vertu de ses connaissances. L’expert doit établir un modèle, définir les critères de normalisation.

Des lignes de commande à un environnement graphique

32La seconde étape de l’étude pilote était la mise en place d’une plateforme pour l’analyse des termes par les experts (extraire les termes, comparer les termes extraits à un thésaurus existant, et permettre un travail itératif pour l’enrichissement de bases de données existantes).

Extraire, visualiser, exporter le lexique

33Une fois l’analyse terminologique terminée, l’interface permet de voir le texte support et les termes extraits. La figure 8 illustre la liste obtenue en sortie de traitement de YaTeA. YaTeA est utilisé avec ses paramétrages par défaut (comme expliqué ultérieurement), la liste des termes obtenue contient les monogrammes même quand ceux-ci appartiennent à une chaîne plus longue, autrement dit la liste comprend des termes enchâssés, comme voie par rapport à voie antique.

35L’ensemble de ces informations peut aider l’expert à traiter ses données. Tout d’abord, travailler les termes selon leur nombre d’occurrences permet de les classer du plus fréquent au moins fréquent (ou inversement). Après export au format CSV, il est alors facile de sélectionner une fréquence précise, de rechercher et isoler les hapax. Ensuite travailler la liste selon les patrons extraits permet de regrouper les termes selon leur schéma syntaxique. L’utilisateur peut lister, quantifier les patrons récurrents, et sélectionner si besoin un type de patron ou un patron contenant une étiquette donnée (par exemple ceux ne comptant que des noms propres). Les étiquettes syntaxiques sont celles de TreeTagger (voir plus haut).

36L’expérience montre qu’il est souvent intéressant de travailler motif par motif : certains motifs sont globalement pertinents et d’autres non, mais il est souvent difficile de le prédire sans regarder les exemples associés. Par exemple, sont souvent pertinentes les séquences composées de deux noms propres (étiquetage Npropre du Npropre pour Domaine du Colombier), nom commun déterminé par un autre nom commun (étiquetage Nom de Nom : enceinte de terre, cachette de fondeur…), etc.

37L’export de ce tableau au format CSV permet à l’expert d’avoir accès à l’ensemble des informations disponibles hors de l’outil, d’observer et de retravailler la liste à souhait.

Projeter une ontologie

38L’utilisateur a la possibilité d’associer à son extraction terminologique une ontologie, à condition qu’elle soit au format SKOS.

39Comme l’illustre la figure 10, lorsqu’une ontologie est associée à l’extraction, dans le texte analysé affiché dans la partie droite de la plateforme certains termes sont mis en évidence soit en vert, soit en pourpre. Les termes extraits présents dans l’ontologie sont en vert, les termes extraits absents de l’ontologie sont en pourpre.

40Les mêmes couleurs sont utilisées à droite dans l’ontologie pour symboliser en vert les termes présents dans l’ontologie et retrouvés par YaTeA dans le texte, en pourpre les termes ou concepts présents dans l’ontologie mais absents du texte affiché.

41L’utilisateur peut proposer s’il le souhaite un découpage du texte. Ce découpage permet une projection de l’ontologie sur le texte, c’est-à-dire une contextualisation de l’ontologie, sans que cette projection concerne tout le texte, ce qui rendrait l’application inutilisable (les temps de traitement seraient trop longs). L’interface propose deux découpages possibles, sur la base des paragraphes ou des communes, suivant en cela la structure du document. On rappelle que toutes les CAG sont structurées par commune, identifiées par un numéro INSEE.

42Comme l’illustre la figure 11, il s’agit pour chacune des parties du texte analysé de mettre en évidence dans l’ontologie le terme extrait par YaTeA et de lui associer l’arborescence correspondante. L’utilisateur a alors un accès direct à l’information, il sait quel chemin parcourir dans l’ontologie pour atteindre le terme en question. Il est donc obligatoire qu’il y ait découpage du texte pour qu’il y ait ontologie contextuelle.

Bilan et perspectives

43Cette collaboration a permis de développer une solution pratique au problème de la gestion des connaissances dans le domaine de l’archéologie. Bien qu’aucune des technologies utilisées ne soit très novatrice en elle-même, on voit que la mise au point d’une application particulière nécessite de rassembler des personnes d’horizons divers, maîtrisant d’un côté le domaine à traiter et de l’autres les technologies d’extraction et de structuration des connaissances. Les outils actuels sont issus de travaux de recherche, encore délicats à maîtriser en l’absence de véritable documentation et d’assistance, et ils nécessitent des compétences informatiques parfois pointues.

44L’application visée répondant à un besoin relativement classique, il serait souhaitable que des outils et des solutions plus génériques apparaissent. Il s’agit d’un effort indispensable pour valoriser les connaissances engrangées dans les laboratoires depuis des décennies, qui ne demandent qu’à être utilisées plus largement. Nous n’avons pas montré ici l’application finale, qui reste à déployer. Il s’agit in fine, rappelons-le, d’offrir une plateforme d’accès à une littérature difficilement disponible à l’heure actuelle. C’est un enjeu particulièrement important en archéologie, mais aussi dans de nombreux autres domaines des lettres et sciences humaines.