CLI d'indexation Elasticsearch pour la suite DoTS

[vicpsl]

DoTS CLI d'indexation Elasticsearch (backend)

Dans le cadre de la conception d'un outil de recherche de données documentaires décrit ici : chartes/dots-vue#11, l'objet de cette issue consiste en la création d'un CLI d'indexation et de gestion des indexes, basé sur Elasticsearch.

Objectifs spécifiques

Indexation des collections et sous-collections

1. Pouvoir (re)indexer les collections et sous-collections servies par une API DoTS-DTS (réponses JSON) :

• collection racine du endpoint : https://dev.chartes.psl.eu/dots/api/dts/collection
• projet (collection de niveau 1) : https://dev.chartes.psl.eu/dots/api/dts/collection?id=theater
• sous-collections (collection descendantes d'un projet - ex : la collection moliere est enfant directe du projet - collection de niveau 1 - theater - : https://dev.chartes.psl.eu/dots/api/dts/collection?id=moliere

2. Pouvoir (re)indexer une ou plusieurs (sous-)collections en incluant on non leurs documents
3. Pouvoir supprimer une ou plusieurs (sous-)collections en incluant on non leurs documents (des documents pouvant avoir plusieurs collections parentes : prévoir la suppression de la seule (sous-)collection concernée)
4. S'assurer de la cohérence entre d'éventuelles listes de sous-collections dans les collections versus la(les) collection(s) parent(es) listé(es) dans ces sous-collections
5. Possibilité d'incorporer des paramètres de réglages (comme l'exclusion éventuelle de (sous-)collections)) en provenance des dossiers de configuration (DoTS-vue-settings) des déploiements des front-end (Dots-vue)
6. Réponse appropriée pour liage de ces résultats de recherche à leurs URLs dans le front-end :
   Le front-end DoTS-vue prévoit d'éventuellement ne pas avoir de page dédiée pour une sous-collection.
   Dans ce cas la seule page dédiée - et l'URL correspondante - ne reflète que la collection de niveau 1 (aussi appelée "projet") à laquelle appartient la sous-collection.
   Il est nécessaire de stocker a minima l'id de cette collection de niveau 1 - "projet", voire le chemin ou path d'une sous-collection vers la collection racine.

Indexation des documents

1. Pouvoir (re)indexer un ou plusieurs documents, diverses approches à évaluer : par id (liste d'ids), par collection parente / par range d'ids / par range de dates, etc.
2. Pourvoir supprimer un ou plusieurs documents, diverses approches à évaluer : par id (liste d'ids), par collection parente / par range d'ids / par range de dates, etc.
3. S'assurer de la cohérence entre d'éventuelles listes de documents dans les collections versus la(les) collection(s) parent(es) listé(es) dans ces documents

Source des métadonnées des documents (notamment pour les filtres / facettes, comptages buckets ES)

1. Pouvoir (re)indexer les métadonnées de documents servies par une API DoTS-DTS (réponses JSON), disponibles également sur le endpoint collection de l'API : https://dev.chartes.psl.eu/dots/api/dts/collection?id=document_id, par ex.: https://dev.chartes.psl.eu/dots/api/dts/collection?id=moliere_avare

Source du contenu des documents (pour la recherche plein texte et réponse contenant les concordances highlight ES)

1. Pouvoir (re)indexer le contenu de documents servies par une API DoTS-DTS (réponses HTML ou XML TEI), disponibles sur le endpoint document de l'API : https://dev.chartes.psl.eu/dots/api/dts/document?resource=document_id, par ex.:

• réponse XML TEI : https://dev.chartes.psl.eu/dots/api/dts/document?resource=moliere_avare
• réponse HTML : https://dev.chartes.psl.eu/dots/api/dts/document?resource=moliere_avare&mediaType=html

2. Réponse appropriée pour liage de ces résultats de recherche à leurs URLs dans le front-end :
   La méthode d'indexation doit permettre de connaître dans quel passage (au sens DTS) du texte ont été trouvés les résultats d'une recherche. Les passages d'un texte sont disponibles dans la clé member du endpoint navigation de l'API : https://dev.chartes.psl.eu/dots/api/dts/navigation?resource=document_id&down=-1 (par ex : member de https://dev.chartes.psl.eu/dots/api/dts/navigation?resource=moliere_avare&down=-1)

• pour la réponse du endpoint document en XML TEI, ces passages sont les éléments XML disposant d'un xml:id correspondant à l'un de ces member
• pour la réponse du endpoint document en HTML, ces passages sont les éléments HTML disposant d'un id correspondant à l'un de ces member
  Un passage peut correspondre à une page web ou à une ancre dans une page dans le front-end, en fonction du niveau de découpage du document choisi par l'éditeur. Afin de pouvoir lier un résultat de recherche à son URL de présentation dans le front-end, il sera nécessaire de permettre à ES d'inclure dans sa réponse, pour chaque concordance, l'identifiant du passage (identifier), son niveau de prodondeur (level), son type (citeType), ses "ancestors" (parent successifs)

ES settings, analysers, mappings d'indexes

1. Définition des mappings (textes, métadonnées, analyzers) permettant autant que possible l'indexation de ressources de typologies variées et une évolution des mappings aisée
2. S'assurer de la cohérence des schémas avec les données DoTS et la documentation de l'API DoTS-DTS
3. Commandes de diagnostic (statistiques, santé des index, etc.)
4. Articulation du service avec plusieurs implémentations de DoTS-vue et leurs dossiers de configuration correspondants DoTS-vue-settings

Livrables attendus (backend)

1. Outil CLI d’indexation et d'administration (création, mise à jour, suppression d'index et/ou de documents dans les index)
2. Schémas d’index configurables (analyzers, mappings)
3. Documentation technique de l’indexation

Critères d’évaluation

1. Cohérence avec le modèle de données DoTS
2. Capacité à exploiter correctement la structure documentaire des sources (métadonnées, contenu subdivisé en passages identifiés)
3. Maintenabilité et lisibilité du pipeline d’indexation
4. Performances et scalabilité
5. Facilité d’évolution des schémas Elasticsearch et des analyzers
6. Alignement avec les usages front-end et l’API de recherche ES

Nota bene : contraintes structurantes des données

Variabilité linguistique et diachronique

1. Données en plein texte multilingues : français, allemand, latin, etc.
2. États de langue variés selon les périodes (français médiéval, moderne, contemporain)

Implications :

1. analyzers Elasticsearch configurables ou combinables
2. absence d’hypothèse forte sur l’uniformité linguistique des corpus

Variabilité des métadonnées

1. Métadonnées dépendantes des collections :
   • auteurs présents ou non
   • dates précises, imprécises, intervalles ou absentes
   • champs spécifiques par corpus

Implications :

1. schémas d’index configurables ou tolérants à l’absence de données sources
2. capacité à activer ou désactiver certaines fonctionnalités par projet / collection

Documentation

1. Documentation DTS et DoTS
2. Front-end : dots-vue et exemples de dossiers de configuration dots-vue-elec-settings et dots-vue-demo-settings
3. Besoins front-end en termes de formulaires de recherche (filtres, tris, paginations, recherche plein texte etc) : voir Composants de recherche Vue pour le front-end DoTS-vue dots-vue#23
4. Considérations sur l'architecture globale du service de recherche DoTS: voir issue Architecture du service de recherche et fonctionnalités attendues pour la suite DoTS #2