Propositions de la TEI pour l'indexation:

Balisage et indexation

‘Markup reflects a theory of text’ (Sperberg-McQueen, 1991)

On pourrait considérer que l'acte même de balisage serait une forme d'indexation...

• en balisant, nous choissisons une partie d'un texte et nous la catégorisons d'une manière quelconque
• ces catégories pourraient très bien correspondre avec les termes d'un index

Mais c'est habituel de distinguer

• l'annotation (le surajout des catégorisations) de
• l'indexation (l'indication des locations textuelles auxquelles ces catégorisations s'appliquent)

La balise <index>

La TEI propose un élément spécifique pour faciliter la création d'un index classique

• à chaque point de répérage ciblé par l'index on met une balise <index>
• on précise par un <term> l'entrée sous lequel on souhaite indexer ce point
• les <index> peuvent s'imbriquer

... The Tangerine Dream (où officiaent deux danseuses du ventre Zazou et Asiza)...

On peut aussi specifier une hierarchie des termes :

Attention: comme ailleurs, la prise en charge de la création des indexes à partir de cette balisage n'est pas assurée par la TEI!

Indexation et représentation des expressions référentielles

• Pour construire un index des phrases démotiques ou exotiques, des passages jolis, des paragraphes controversés etc., l'usage de <index> peut tres bien suffir.
• Mais il n'est pas aussi bien adapté au cas plus typique: la construction d'un index des expressions référentielles
• Par ‘expression référentielle’ nous entendons tout mot ou phrase qui fait référence à une entité (une personne, un evenement, un lieu) dans le monde, par ex. un nom propre, un titre, etc.
• L'identification et l'annotation des expressions référentielles servent à traverser une frontière importante: des mots constitutifs d'un texte jusqu'aux entités signallées par ce texte... voire sa sémantique.

Révéler la vraie sémantique d'un document ... la rêve des indexeurs

Sommaire des propositions de la TEI pour les expressions référentielles

Quelques exemples des expressions qu'on pourrait souhaiter distinguer/annoter/indexer

• signaller la présence d'une référence : <name> et <rs>.
• distinguer plus nettement le type de référence : <persName>, <placeName>, <orgName> ...
• distinguer les composants de ces références (par ex <surname>, <location>, <addName> etc.)
• associer une référence avec un ensemble d'information concernant son référent (<person>, <place> etc.)
  • pour la désambiguïser
  • pour la sémanticiser

Grosse question : comment s'exprime la sémantique du balisage TEI ?

Encodage des références (1)

Un élément très générique est disponible en TEI : il s’agit de <rs>, qui signifie « expression référentielle » (referencing string)

Il peut contenir un nom propre, mais aussi un pronom, une périphrase, ou toute autre façon de référencer un objet identifiable

Mais ceux-ci sont peut-etre plus douteux:

<rs>: une balise qui fait tout

Attention: les valeurs de l'attribut type ne sont pas forcément contrôlés de la TEI

Un élément plus spécifique existe pour distinguer les noms propres des autres types de référence: <name>...

Des éléments plus précises...

Au lieu d'une balise <name type="xxx">, la TEI propose une balise <xxxName>

• <persName> : nom de personne
• <placeName> : nom de lieu
• <orgName> : nom d'organisation
• <geogName> : nom d'un entité geographique

Quel est l'interêt de ce type d'encodage (dite "sémantique")?

• mise en relation des textes
• traitement type TAL, cartographie, indexation...
• optimisation de recherche et moteur de recherche sémantique
• production de savoir par inférence (classification de documents par exemple)
• ... bref, utiliser un ensemble de textes comme une base de données

Composants des noms de personnes

• <forename> : prénom, nom de baptême
• <surname> : nom de famille (hérité)
• <roleName> : titre officiel, rang, position dans la société
• <nameLink> : particule
• <genName> : attribut générationnel (Pline «le Jeune», Henri «IV»)
• <addName> : nom supplémentaire, par ex surnom, épithète, alias, périphrase descriptive
• ... et bien sur d'autre types de nom propre (<placeName>, <orgName> ... )

Enrichissement progressif d'un texte

Un <persName>n'est pas un <person>!

Nous considérons que tous ces noms réfèrent à la même personne. Comment le signaller ?

De même, il arrive que nous trouvons des noms identiques qui (à notre avis) réfèrent à des personnes différentes. Comment le signaller ?

La TEI propose deux attributs, disponibles sur tous les éléments de dénomination, pour spécifier à quelle entité on réfère :

• key pour spécifier un code prédéfini associé avec l'entité dénommée, d'un format arbitraire
• ref pour pointer sur une définition de l'entité dénommée : forcément un URI

#CS est un URI: il devrait correspondre à un autre élément de notre document (a priori un <person>)

Relier les noms propres à des ontologies externes

Toutes les balises de références textuelles permettent également ce type de connexion à des referentiels (ou ontologies) externes

• @ref : pointeur vers une définition

• @key : utiliser un code quelconque

Cette mécanisme permet la résolution des ambiguités en rendant explicite une interprétation du texte

Les entités TEI (1)

TEI propose des éléments spécifiques pour regrouper des informations concernant les entités nommées (en plus de leur noms):

• <person>, <place>, <event>
• ces éléments peuvent être regroupés en <listPerson>, <listPlace>, etc.
• des relations peuvent aussi aussi être modélisées, utilisant explicitement <relation> ou implicitement grâce au contexte

L'élément <person> (vel sim) ne contient pas une transcription, mais des annotations

Traits, états et événements

Le variéte des informations que l'on pourrait souhaiter retenir pour une entité nommée est vaste -- et donc impossible de standardiser de manière exhaustive. La TEI fournit trois éléments génériques, et quelques-uns plus spécifiques.

Les elements génériques:

• <state> : des traits : des caractéristiques qui en gros ne changent pas avec le temps
• <trait> : des états : des caractéristiques qui se maintiennent seulement pendant une durée définie
• <event> : des événements ou des incidents qui peuvent conduire à un changement d'état ou, moins fréquemment, à un changement de trait

Les éléments plus spécifiqes

Pour les personnes :

états

par ex <occupation> le métier, <residence> la résidence, <education>,l'éducation

traits

par ex <faith> la foi, <sex> le sexe, <socEcStatus>, le statut social

événements

par ex <birth> la naissance, et <death> la mort

Pour les lieux :

états

par ex <terrain>, <climate>, <location>, <population>

noms (en ordre hiérarchique)

par ex <bloc> (regroupement de pays), <country> (pays ou unité administratif pareil), <region> (sous-division administrative d'un pays), <settlement> (lieu d'habitation), <district> (sous-division de settlement)

Lieux

Pour les lieux, la TEI prévoit plusieurs types de déscription :

• le plus simple: nominatif
  <place xml:id="LYON" type="city">  <placeName xml:lang="en">Lyons</placeName>  <placeName notAfter="0056">Lugdunum</placeName>  <placeName notBefore="1400">Lyon</placeName> </place>
• ... ou bien en termes géopolitiques par rapport aux unités administratives <bloc>, <country>, <region>, <settlement>, <district> etc
  <place xml:id="LYON" type="city">  <location>   <bloc>EU</bloc>   <country>France</country>   <region notAfter="2016">Rhone-Alpes</region>  </location> </place>
• .. ou bien en termes de location physique <geo> et <offset>
  <place xml:id="LYON" type="city">  <location>   <geo>45.769559 4.834843</geo>  </location>  <location>   <offset>au confluent des</offset>   <geogName>Rhône</geogName>   <geogName>Saône</geogName>  </location> </place>

Notons que toutes ces données (même la dernière) sont des états -- elles peuvent changer avec le temps -- des attributs (notBefore etc.) sont disponibles pour associer une information avec le temps

Regroupements et responsabilités

On peut regrouper les entités dans une liste pour construire une espèce d'index :

Et pareillement on peut regrouper des <place> dans une <listPlace>, des <event> dans un <listEvent> etc.

Datation des propositions

• La plupart des informations associées avec une entité peut changer dans le temps
• par ex. occupation, adresse, mais aussi nom, affiliation réligieuse, sexe, etc.
• pour cette raison, tout élément déscriptif d'une entité est membre de la classe att.datable qui fournit plusieurs attributs utiles pour la normalisation des dates

• when : date exacte.
  <date when="2012-10-02">Deux octobre 2012</date> ou <date when="1552">M.D.LII</date>
• notBefore : indique la date la plus antérieure possible
  C’était <date notBefore="2001">un ou deux ans</date> avant sa naissance en <date when="2003">2003</date>.
• notAfter : indique la date la plus postérieure possible
  Nous partirons d’ici <date notAfter="2012-03-31">deux mois maximum</date> à partir de <date when="2012-01-31">ce jour</date>.

Autres calendriers

L'attribut calendar sert à indiquer le calendrier dans lequel une date est exprimée

Par défaut les dates sont normalisées par rapport au calendrier chrétien gregorien; l'attribut custom-when permet l'indication d'une normalisation par rapport au calendrier spécifié.

Epoques historiques

Vers le "placeography"

Par exemple: le lieu de naissance de Mayakovsky

Les éléments TEI prévus pour l'encodage des entités ressemblent plus aux notices textuelles qu'aux données structurées. Ils sont (apparemment) destinés à être lus par un humain et non pas par un automat.

Les relations entre les lieux

La TEI propose des méthodes simples pour indiquer

• des relations de synomonie
• des relations hiérarchiques

... mais comment indiquer d'autre relations, par ex ‘Vilnius est la capitale de Lietuva’ ou ‘Kaunas est loin de Vilnius’ ?

Les relations personnelles

• <relation> (relationship) est concu pour décrire une relation parmi des personnes spécifiques

  name

  fournit un nom pour le type de relation dont elle est une instance.

  active

  identifie les personnes actives dans une relation non-mutuelle (par ex. le père et la mère dans la relation "ancêtre de")

  passive

  identifie les personnes ‘passives’ dans une relation non-mutuelle (par ex les enfants dans la relation "ancêtre de")

  mutual

  identifie toutes les personnes concernées par une relation réciproque (par ex les frères et les soeurs dans la relation "même-génération")

Exemples

L'élément <relation> pourrait également servir à représenter des relations entre lieux :

N'oublions pas qu'un nom peut être considéré un entité!

Pour certaines raisons (onomastique, étymologie...) les noms propres existent indépendamment de leur relation à une entité.

Les éléments <nym> et <listNym> peuvent être utilisés pour rappeler une information concernant un nom considéré comme une entité, et l'attribut nymRef peut être utilisé pour lui associer le ou les noms..

Quoi faire avec toutes ces balises?

• on peut extraire ses propres indexes : simple affaire de transformation
• on peut construire une cartographie
• on peut entrelacer ses données avec celles d'autres

Exemples : le projet ReNom ; le projet Pelagios ; le projet MoEML

Index des personnes : exemple

https://renom.univ-tours.fr/fr/index/personnes/avicenne

Comment effectuer ce balisage ?

Rappel: il nous faut des moyens ...

• d'identifier automatiquement les phrases nominatives
• de retrouver ces phrases dans des référentiels appropriés
• et ainsi de désambiguïser les références

La reconnaissance automatique des ‘entités nommées’ -- NER -- est devenu une application classique dans le domaine de TAL

Les référentiels se prolifèrent en format "linked open data" (LOD)

Outil typique de cet approche: Recogito

Voir le tutoriel Données liées et annotation de corpus de Francesca Frontini (CAHIER, Montpellier, 2018)

Quid de RDF et LOD?

• RDF (Resource Description Framework) est un standard W3C tres répandu, visant la définition de la sémantique d'une ressource numérique
• RDF dispose d'une représentation très simple (si verbose) composée de "triples"
  • un triple comporte trois URI
    • sujet : de quoi s'agit-il? (par ex "Vilnius")
    • predicat : catégorie identifiée (par ex "capital-of")
    • objet : valeur du catégorie ("par ex "Lituanie")
  • Les catégories sont d'habitude sélectionnées dans une ontologie spécifique
• LOD (Linked Open Data) est un mode d'édition de ressources numériques ouvertes, qui disposent d'une déscription exprimée en RDF
• Ces deux acronymes sont au coeur de l'évolution du web actuel (le web de documents) vers le "semantic web" (le web de données)

Comment intégrer RDF en TEI ?

La TEI partage les objectifs fédératifs et "open" de LOD. Mais sa sémantique est plus dispersée. Elle ne simplifie pas les documents : on peut la lui reprocher, mais la sémantique d'un ensemble de documents TEI est souvent dispersée dans son balisage d'une manière peu cohérente.

Par contre, la sémantique d'une page web qui fournit par ex. les prix, les détails téchniques, les couleurs disponibles, etc pour un gadget quelconque peut facilement être extraite, et en l'exprimant, on exprime toute la portée de ce page.

On peut s'imaginer plusieurs méthodes pour intégrer une description RDF dans un document TEI

• directement, en utilisant l'espace de noms RDF
• en utilisant l'element <relation>
• en utilisant les attributs RDFa
• en utilisant/abusant l'élément <graph>, ou <link>, ou <fs>

Ca se discute depuis 2013... pour une synthèse récente, voir https://github.com/TEIC/TEI/issues/1860

A la recherche d'une ontologie TEI

• Depuis longtemps, on propose de surajouter aux définitions des éléments TEI une représentation de leur sémantique
• par ex, dans l'élément <equiv>, ou en élargissant la système de classes actuelle
• et/ou en définissant une "vraie" ontologie par ex en OWL, ou d'autre formalisme à la mode

c'est bien possible... mais la TEI est conçue pour les documents, et les documents ne sont pas des ensembles de données abstraites ou objectives.

Un document doit etre interprété: il faut compléter sa modélisation avec son/ses interpretation/s...

Science de texte: science de données

... et de même pour les données!

Il ne faut pas sous-estimer l'importance du contexte de production/consommation des données, non plus.

All data is historical data: the product of a time, place, political, economic, technical, & social climate. If you are not considering why your data exists, and other data sets don’t, you are doing data science wrong”

Les données ont toujours un aspect historique - elles ressortent d'un temps, d'un endroit, ou d'un climat socio-économique spécifique. Si vous ne mettez pas en question les raisons pour lesquelles vos données à vous existent et d'autres sont disparues, alors vous pratiquez incorrectement la science de données

[Melissa Terras, Opportunities, barriers, and rewards in digitally-led analysis of history, culture and society. Turing Lecture 2019-03-03, https://www.youtube.com/watch?v=bf6DsJ7VcLI]

‘Text is not a special kind of data: data is a special kind of text’