Navigation – Plan du site

Une chaîne d’extraction pour l’enrichissement de bases de données archéologiques

An Information Extraction Framework to Enrich Archeological Databases
Frédérique Mélanie-Becquet, Johan Ferguth, Michel Cartereau, Katherine Gruel et Thierry Poibeau

Résumés

Cet article décrit une expérience visant à extraire des informations textuelles pour alimenter automatiquement des bases de données dans le domaine de l’archéologie. Les premières expériences ont porté sur les Cartes archéologiques de la Gaule (CAG). Elles ont permis d’observer des problèmes de transfert d’information et d’évolution des thésaurus, un même terme ne désignant pas toujours la même notion au cours du temps, ou un site archéologique pouvant avoir été catégorisé de différentes manières au cours du temps.

Haut de page

Texte intégral

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.

  • 1 EITAB est l’acronyme d’un projet PEPS CNRS-PSL et signifie « extraction automatique d’informations (...)

2Cet article est une présentation du projet EITAB1, qui vise à mettre en place une chaîne de traitement dont la finalité est l’enrichissement de bases de données à partir de documents numérisés. Pour ce faire, il a été nécessaire, dans un premier temps, de procéder à de nombreux échanges entre informaticiens, linguistes et archéologues. Cette étape a permis d’appréhender les données, d’une part les textes à scanner dont il faut extraire le lexique pertinent pour la tâche, et d’autre part les bases de données informatisées existantes, que le projet a pour finalité d’enrichir. Il en résulte la constitution d’un thésaurus qui servira de référence dans la chaîne de traitement. Les différents échanges entre acteurs du projet ont aussi montré la nécessité de créer une interface graphique permettant une utilisation optimale de l’application par l’expert, ainsi que la nécessité de standardiser les formats pour garantir une meilleure portabilité.

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.

Figure 1. Structuration des Cartes archéologiques de la Gaule (CAG)

Figure 1. Structuration des Cartes archéologiques de la Gaule (CAG)

Extrait d’une version numérisée de Carte archéologique de la Gaule. 18. Le Cher, par Michel Provost, Jean-François Chevrot et Jacques Troadec

AOROC

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.

  • 2 L’atlas propose, en complément de ces réponses ponctuelles, des cartes thématiques enrichies et com (...)

12La BaseFer alimente un atlas disponible en ligne : l’atlas de l’âge du Fer. L’atlas permet de répondre aux questions « où ? quoi ? quand ? » (figure 3)2.

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

  • 3 Nous n’aborderons pas ici la numérisation par reconnaissance de caractères (OCR). Nous nous plaçons (...)

17Le premier objectif était d’extraire les termes des CAG3. Nous avons utilisé YaTeA, outil d’extraction permettant de récupérer l’ensemble des termes du domaine. YaTeA a été développé au LIPN par Thierry Hamon et Sophie Aubin pour aider le processus d’identification des termes en corpus.

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).

Figure 4. Fichier de configuration de YaTeA

Figure 4. Fichier de configuration de YaTeA

YaTeA, Thierry Hamon et Sophie Aubin, https://perso.limsi.fr/​hamon/​YaTeA

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, 1er â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.

  • 5 La balise part of est utilisée dans la structure OBO pour indiquer qu’un concept est une partie d’u (...)

28OBO (Open Biomedical Ontologies) est un format de la famille XML à l’origine utilisé en biomédecine, comme son nom l’indique, mais dont les propriétés ont a priori semblé intéressantes au-delà de ce domaine scientifique (figure 6). Il permet d’organiser les concepts biologiques entre eux à la fois de manière hiérarchique et par synonymie, et de typer les relations. Les concepts sont organisés selon qu’ils sont père ou fils. Ainsi le terme fosse est le fils du concept structure. Cette information est portée par la balise <is_a>. Du côté du père, la valeur de la balise est father. Du côté du fils, la balise reprend l’identifiant du père ainsi que le concept lui-même5.

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.

  • 6 Nous avons testé divers formats d’import et d’export de notre ontologie avec le logiciel libre Prot (...)

31Le format OBO a permis aux membres du projet de créer un premier thésaurus, depuis l’extraction lexicale faite par YaTeA. Si ce format s’est avéré trop spécifique au domaine de la biologie, il a cependant été facile de transformer ce format standard en un autre format davantage en adéquation avec la tâche d’application. Nous avons, par le biais de scripts, transformé le format OBO en un format SKOS6. Nous aurions pu, dans ce compte rendu d’expérience, évoquer directement SKOS et laisser de côté OBO, mais il nous semble intéressant malgré tout de montrer les tâtonnements qui ont été les nôtres. Il existe de multiples outils et de multiples standards. Il était sans doute prévisible que SKOS était plus approprié que OBO (car SKOS est plus standard, compatible avec RDF, etc.) mais la présence d’outils disponibles et efficaces autour du standard OBO nous a d’abord incités à aller voir de ce côté.

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.

  • 7 Le lemme est l’entrée dictionnairique du terme, sa forme canonique.
  • 8 Un patron syntaxique est un motif, une séquence d’une ou plusieurs étiquettes syntaxiques.

34Il est aussi possible de produire une liste enrichie. Cette liste regroupe l’ensemble des informations mises à disposition par YaTeA : non seulement les termes candidats repérés et extraits par YaTeA, mais aussi la forme lemmatisée du terme7, les patrons syntaxiques8, le nombre d’occurrences de chacun des termes ainsi que leur contexte. Autant d’informations utiles à l’expert pour observer, manipuler le résultat. Ces informations sont présentées sous forme d’un tableau (figure 9) qui peut être filtré directement sur la plateforme ou exporté.

Figure 8. Le Cher : liste terminologique

Figure 8. Le Cher : liste terminologique

Outil d’extraction automatique d’informations textuelles

AOROC, http://www.archeo.ens.fr

Figure 9. Le Cher : liste terminologique enrichie

Figure 9. Le Cher : liste terminologique enrichie

Outil d’extraction automatique d’informations textuelles

AOROC, http://www.archeo.ens.fr

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.

Figure 10. Projection de l’ontologie

Figure 10. Projection de l’ontologie

Outil d’extraction automatique d’informations textuelles

AOROC, http://www.archeo.ens.fr

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.

Figure 11. Projection de l’ontologie

Figure 11. Projection de l’ontologie

Outil d’extraction automatique d’informations textuelles

AOROC, http://www.archeo.ens.fr

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.

Haut de page

Bibliographie

Buchenschutz, Olivier, Christophe Batardy, Michel Cartereau, Katherine Gruel et Marc Levéry. 2015. « Une base pour l’élaboration de modèles de peuplement de l’Âge du fer en France ». ArcheoSciences, revue d’archéométrie 39 : 157-175. https://doi.org/10.4000/archeosciences.4457.

Coulon, Gérard, Jean Holmberg et Michel Provost, 1992. Carte archéologique de la Gaule. 36. Indre. Paris : Académie des inscriptions et belles-lettres, ministère de l’Éducation nationale et de la Culture.

Lamani, Sihem. 2013. « Extraction d’information à partir de documents en archéologie ». Rapport de stage.

Papazian, Frédéric, Robert Bossy et Claire Nédellec. 2012. « AlvisAE : a Collaborative Web Text Annotation Editor for Knowledge Acquisition ». Dans Proceedings of the 6th Linguistic Annotation Workshop. Édité par l’Association for Computational Linguistics, 149-152, Jeju Island, South Korea, https://www.aclweb.org/anthology/W12-3621.

Provost, Michel, Jean-François Chevrot et Jacques Troadec, 1992. Carte archéologique de la Gaule. 18. Le Cher. Paris : Académie des inscriptions et belles-lettres, ministère de l’Éducation nationale et de la Culture.

Schmid, Helmut. 1997. « Probabilistic Part-of-speech Tagging Using Decision Trees ». Dans New Methods in Language Processing, Studies in Computational Linguistics. Édité par Daniel Jones et Harold Somers, 154-164. Londres : UCL Press.

Haut de page

Notes

1 EITAB est l’acronyme d’un projet PEPS CNRS-PSL et signifie « extraction automatique d’informations textuelles pour alimenter des bases de données » : http://www.archeo.ens.fr/spip.php?article586.

2 L’atlas propose, en complément de ces réponses ponctuelles, des cartes thématiques enrichies et commentées par les chercheurs (www.chronocarto.eu).

3 Nous n’aborderons pas ici la numérisation par reconnaissance de caractères (OCR). Nous nous plaçons au moment où il est possible d’exploiter informatiquement les données. Les documents que nous avons traités dans cette expérience nous ont été fournis au format « texte brut » et nettoyés.

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

5 La balise part of est utilisée dans la structure OBO pour indiquer qu’un concept est une partie d’un autre concept. Il n’y a pas d’exemple d’utilisation de cette balise dans notre ontologie.

6 Nous avons testé divers formats d’import et d’export de notre ontologie avec le logiciel libre Protégé : http://protege.stanford.edu/. En effet, cet éditeur d’ontologie a l’avantage d’être un logiciel libre et d’avoir de nombreux formats d’import et d’export (RDF, OWL, OBO, etc.) disponibles.

7 Le lemme est l’entrée dictionnairique du terme, sa forme canonique.

8 Un patron syntaxique est un motif, une séquence d’une ou plusieurs étiquettes syntaxiques.

Haut de page

Table des illustrations

Titre Figure 1. Structuration des Cartes archéologiques de la Gaule (CAG)
Légende Extrait d’une version numérisée de Carte archéologique de la Gaule. 18. Le Cher, par Michel Provost, Jean-François Chevrot et Jacques Troadec
Crédits AOROC
URL http://journals.openedition.org/revuehn/docannexe/image/471/img-1.png
Fichier image/png, 246k
Titre Figure 2. La BaseFer
Crédits Base Fer, AOROC, https://www.chronocarto.eu/​spip.php?article8&lang=fr
URL http://journals.openedition.org/revuehn/docannexe/image/471/img-2.png
Fichier image/png, 383k
Titre Figure 3. Atlas de la BaseFer
Crédits Base Fer, AOROC, https://www.chronocarto.eu/​spip.php?article8&lang=fr
URL http://journals.openedition.org/revuehn/docannexe/image/471/img-3.png
Fichier image/png, 310k
Titre Figure 4. Fichier de configuration de YaTeA
Crédits YaTeA, Thierry Hamon et Sophie Aubin, https://perso.limsi.fr/​hamon/​YaTeA
URL http://journals.openedition.org/revuehn/docannexe/image/471/img-4.png
Fichier image/png, 53k
Titre Figure 5. TyDI : un éditeur d’ontologie
Crédits TyDI, INRA, http://faculty.washington.edu/​fxia/​LAWVI/​proceedings/​cdrom/​pdf/​LAWVI21.pdf
URL http://journals.openedition.org/revuehn/docannexe/image/471/img-5.png
Fichier image/png, 58k
Titre Figure 6. Le format OBO
Crédits TyDI, INRA, http://faculty.washington.edu/​fxia/​LAWVI/​proceedings/​cdrom/​pdf/​LAWVI21.pdf
URL http://journals.openedition.org/revuehn/docannexe/image/471/img-6.png
Fichier image/png, 91k
Titre Figure 7. Le format OBO : la synonymie
Crédits TyDI, INRA, http://faculty.washington.edu/​fxia/​LAWVI/​proceedings/​cdrom/​pdf/​LAWVI21.pdf
URL http://journals.openedition.org/revuehn/docannexe/image/471/img-7.png
Fichier image/png, 116k
Titre Figure 8. Le Cher : liste terminologique
Légende Outil d’extraction automatique d’informations textuelles
Crédits AOROC, http://www.archeo.ens.fr
URL http://journals.openedition.org/revuehn/docannexe/image/471/img-8.png
Fichier image/png, 404k
Titre Figure 9. Le Cher : liste terminologique enrichie
Légende Outil d’extraction automatique d’informations textuelles
Crédits AOROC, http://www.archeo.ens.fr
URL http://journals.openedition.org/revuehn/docannexe/image/471/img-9.png
Fichier image/png, 420k
Titre Figure 10. Projection de l’ontologie
Légende Outil d’extraction automatique d’informations textuelles
Crédits AOROC, http://www.archeo.ens.fr
URL http://journals.openedition.org/revuehn/docannexe/image/471/img-10.png
Fichier image/png, 337k
Titre Figure 11. Projection de l’ontologie
Légende Outil d’extraction automatique d’informations textuelles
Crédits AOROC, http://www.archeo.ens.fr
URL http://journals.openedition.org/revuehn/docannexe/image/471/img-11.png
Fichier image/png, 555k
Haut de page

Pour citer cet article

Référence électronique

Frédérique Mélanie-Becquet, Johan Ferguth, Michel Cartereau, Katherine Gruel et Thierry Poibeau, « Une chaîne d’extraction pour l’enrichissement de bases de données archéologiques »Humanités numériques [En ligne], 2 | 2020, mis en ligne le 01 juin 2020, consulté le 04 août 2020. URL : http://journals.openedition.org/revuehn/471

Haut de page

Auteurs

Frédérique Mélanie-Becquet

UMR 8094 Lattice, CNRS, Montrouge, France
Frédérique Mélanie-Becquet est ingénieure d’études au Lattice (UMR 8094 Langues, textes, traitements informatiques, cognition, CNRS, ENS, PSL, université Sorbonne nouvelle et USPC). Elle travaille au traitement et à l’analyse de données. Elle a plus particulièrement en charge l’élaboration de bases de données linguistiques.
frederique.melanie@ens.fr

Johan Ferguth

Konverso, Ville-d’Avray, France
Johan Ferguth est développeur informatique. Il a été ingénieur d’études au Lattice (UMR 8094 Langues, textes, traitements informatiques, cognition, CNRS, ENS, PSL, université Sorbonne nouvelle et USPC) et au LLF (Laboratoire de linguistique formelle, CNRS) de 2014 à 2017. Il est actuellement ingénieur devops/NLP chez Konverso, société d’édition de chatbots et assistants virtuels.
jferguth@gmail.com

Michel Cartereau

UMR 8546 AOROC, AgroParisTech, Paris, France
Michel Cartereau est maître de conférences en informatique à AgroParisTech et au laboratoire AOROC (Archéologie et philologie d’Orient et d’Occident, UMR 8546, CNRS, ENS-PSL), docteur de l’université Pierre et Marie Curie (Paris).
michel.cartereau@agroparistech.fr

Katherine Gruel

AOROC, CNRS, Paris, France
Katherine Gruel est directrice de recherche au CNRS (AOROC, Archéologie et philologie d’Orient et d’Occident, UMR 8546, CNRS, ENS-PSL). Archéologue spécialiste en protohistoire celtique et en numismatique, elle participe au développement d’outils d’exploitation numérique des données. Elle est responsable de la BaseFer et du portail Chronocarto.
katherine.gruel@ens.fr

Thierry Poibeau

UMR 8094 Lattice, CNRS, Montrouge, France
Thierry Poibeau est directeur de recherche au CNRS et directeur adjoint du laboratoire Lattice (UMR 8094 Langues, textes, traitements informatiques, cognition, CNRS, ENS, PSL, université Sorbonne nouvelle et USPC). Il est spécialiste de traitement automatique des langues, un domaine de recherche à la frontière de la linguistique et de l’informatique.
thierry.poibeau@ens.fr

Haut de page

Droits d’auteur

Licence Creative Commons
Les contenus de la revue Humanités numériques sont mis à disposition selon les termes de la Licence Creative Commons Attribution 4.0 International.

Haut de page
  • Logo Humanistica, l’association francophone des humanités numériques
  • Logo Maison des sciences de l'homme en Bretagne
  • Logo Institut des sciences humaines et sociales du CNRS
  • Logo Alliance of Digital Humanities Organizations
  • OpenEdition Journals