• 1 Pour le modèle conceptuel et les discussions théoriques de l’année dernière, voir P. A. Stokes, « H (...)

1Au cours de cette année, nous avons mis en pratique nos réflexions théoriques de l’année dernière sur un projet pratique : créer un modèle conceptuel pouvant être appliqué à des objets inscrits dans n’importe quelle langue ou écriture, implémenter notre modèle avec une base de données, remplir cette base avec des données existantes et créer une interface web pour interagir avec les données1. En réalisant ces tâches nous avons rencontré et discuté d’un grand nombre de questions théoriques et pratiques sur la modélisation, l’échange de données, l’implémentation, la documentation et autres, qui sont au cœur des humanités numériques.

• 2 Pour l’« archéologie » du livre, voir F. Masai, « Paléographie et codicologie », Scriptorium, 4 (19 (...)
• 3 P. Andrist, P. Canart et M. Maniaci, La Syntaxe du codex : essai de codicologie structurale, Turnho (...)

3Afin de développer notre modèle, une première étape a consisté à examiner les différentes entités et à décider lesquelles inclure, puis à leur fournir des définitions claires. Il s’agit d'une tâche particulièrement ardue. En effet, il convient de trouver des termes suffisamment concrets pour être utiles, mais en même temps assez abstraits pour pouvoir être appliqués à l’ensemble des types d’écriture et des objets. Par exemple, un point de départ évident serait Manuscrit, qui fait référence à l’objet contenant le texte manuscrit. Cependant, dans la pratique, le terme « manuscrit » tend à designer un codex ou une autre forme de document portable, mais pas une inscription sur pierre, même si cette inscription est écrite à la main. En outre, les informations que l’on enregistre normalement pour une inscription sur pierre sont généralement différentes de celles des écritures sur des feuilles de parchemin, de papier, de feuilles de palmier ou d’autres supports portatifs. Cela suggère alors le concept de Text-Bearing Object comme classe, avec des cas spécifiques tels que Codex ou Inscription comme sous-classes. Cette approche est utile, mais il est difficile de décrire l’« archéologie » de l’objet, c’est-à-dire ses différents états à différentes époques2. Les livres, les inscriptions et les autres objets sont souvent très différents aujourd’hui de ce qu’ils étaient au moment de leur production : ils peuvent être divisés en unités qui circulent séparément, ou des unités qui étaient à l’origine séparées peuvent être jointes plus tard, du texte peut être ajouté ou supprimé, etc. Heureusement, ces problèmes de terminologie ont déjà été discutés par Andrist, Canart et Maniaci. Ces derniers distinguent l’Unité de production (UniProd) et l’Unité de circulation (UniCirc)3.

• 4 Groupe de travail IFLA sur les Fonctionnalités requises des notices bibliographiques, Fonctionnali (...)
• 5 Groupe de travail IFLA, Fonctionnalités, p. 14.
• 6 Groupe de travail IFLA, Fonctionnalités, p. 19.
• 7 Bekiari et al. (éd), LRMoo (formerly FRBRoo) Object-Oriented Definition and Mapping from IFLA LRM, (...)

4Ensuite le défi est comment modéliser le texte en soi, ainsi que le contenu paléographique. Développé par la Fédération internationale des associations des bibliothécaires et des bibliothèques4, le modèle FRBR semble être le plus approprié. Ce modèle distingue entre quatre entités principales : Œuvre, « une création intellectuelle ou artistique déterminée », Expression, « la réalisation intellectuelle ou artistique d’une œuvre », Manifestation, « la matérialisation de l’une des expressions d’une œuvre », et Item, « un exemplaire isolé d’une manifestation »5. Ils donnent en exemple l’Œuvre Œ1 Playback de Ronald Hayman, qui trouve sa réalisation dans l’Expression E1 le texte de l’auteur, mis en forme pour l’édition, qui se concrétise dans la Manifestation M1 le livre édité́ en 1973 chez Davis-Poynter, qui est représentée par l’Item I1 un exemplaire avec dédicace autographe de l’auteur. Dans notre cas, l’Item correspond directement au Text Bearing Object, c’est-à-dire la combinaison de l’Unité de production et de l’Unité de circulation. Le concept d’œuvre est aussi utile, parce qu’il nous donne la possibilité de grouper tous les objets qui contiennent une telle œuvre. En revanche, l’Expression nous semblait moins pertinente et nous ne l’avons pas incorporé dans notre modèle. Enfin, le concept de Manifestation est pertinent pour notre étude, mais son introduction génère des difficultés importantes. La définition d’une Manifestation est « la matérialisation de l’expression d’une œuvre », et elle « regroupe tous les objets matériels présentant les mêmes caractéristiques, tant du point de vue du contenu intellectuel que du point de vue de l’aspect matériel »6. Cette définition fonctionne assez bien pour les livres imprimés, mais elle est moins pertinente pour les objets crées à la main, où chacun a ses propres caractéristiques matérielles. Pour cette raison, quelques versions du standard FRBRoo, fondé sur celui de FRBR, ajoute le concept de Manifestation Singleton pour mieux prendre en compte les objets faits à la main. Toutefois, cette entité a été supprimée des versions plus récentes7. Quoi qu’il en soit, la Manifestation est essentielle pour nos besoins et nous l’avons donc retenue pour notre modèle.

• 8 Andrist et al., La Syntaxe, p. 64.

6Une fois que les entités sont bien définies, il faut préciser les relations qui les unissent. La plupart des relations sont simples : par exemple, il y a une relation évidente entre une Unité de circulation et une Unité de production, ou entre une Œuvre et la Personne qui l’a écrite. Il y a également des relations moins claires. Nous avons, par exemple, ajouté une relation entre une Personne et la Manifestation pour indiquer l’auteur qui est désigné par le texte de cet objet n’est pas forcément le véritable auteur de l’œuvre. Un autre point de discussion était la relation entre l’Unité de circulation et la Manifestation. En principe, selon La syntaxe du codex, chaque ajout de contenu crée une nouvelle Unité de production, même sans addition du support matériel8. Dans ce cas, il semble clair que la Manifestation appartient à l’Unité de production et non pas à l’Unité de circulation. Cependant, ce principe implique qu’un manuscrit avec des gloses ajouté par une dizaine des personnes possèdera une dizaine d’Unités de production et donc une dizaine des Manifestations. Cela rendrait la base de données très difficile à gérer. Cette approche est aussi contraire au standard de FRBR, qui précise que :

• 10 L’installation Heurist de HumaNum est disponible à https://heurist.huma-num.fr/.

10Une fois que le modèle conceptuel est défini, il nous fallait l’implémenter dans une base de données. Un nombre énorme de logiciels sont disponibles pour créer et gérer des bases de données, mais nous avons choisi d’utiliser Heurist. Créé par une équipe de l’université de Sydney, Heurist est conçu pour les sciences humaines. Une instance de ce logiciel est disponible sur l’IR* HumaNum, l’infrastructure de recherche française pour les humanités numériques10. Un grand nombre de détails est déjà pris en compte par le logiciel, ce qui nous aide avec l’implémentation, et qui nous permet de créer la plupart de notre base de données sans besoin de programmation. Par exemple, plusieurs de nos entités sont déjà présentes dans Heurist, telles que Personne, Institution, Lieu, Œuvre, Événement historique, et Image. Nous avons facilement ajouté les autres entités, telles que l’Unité de circulation et l’Unité de production. D’autres entités sont présentes dans Heurist mais ne sont pas parfaitement adaptés à nos besoins, et donc nous les avons modifiés. Enfin, pour compléter le modèle et donc l’implémentation, il faut aussi décider quelles informations on souhaite enregistrer pour chaque entité. Par exemple, pour une Unité de production, nous avons choisi les informations suivantes :

• 11 S. Brookes et al., « The DigiPal Project for European Scripts and Decorations », dans A. Conti, O.  (...)

13À ce stade, la structure de la base de données était en place : toutes les entités sont définies, ainsi que les champs qui les décrivent et les relations qui les unissent. L’étape suivante consistait à saisir les données. Cela pourrait être fait à la main, mais nous avons décidé d’importer les données d’un projet existant, DigiPal. Le projet DigiPal est le résultat d’une « Starting Grant » de l’European Research Council qui s’est déroulée de 2010 à 2014 et qui comprenait la conception et la création d’une base de données et d’un site Web pour l’étude paléographique des écrits du xi^e siècle en langue anglaise11. Au moment de la rédaction de cet article, la base de données DigiPal contient des entrées pour 1 675 manuscrits contenant 1 477 mains de scribes et plus de 60 000 images annotées de lettres écrites par ces scribes. La base de données DigiPal est donc clairement pertinente aussi pour notre base de données dans Heurist, et cela a soulevé la question de savoir si les anciennes données pouvaient être importées dans le nouveau site.

• 12 Pour le logiciel Archetype voir https://github.com/kcl-ddh/digipal, et G. Noël et P. A. Stokes, « T (...)
• 13 P. Stokes, « Aligning Archetype: Towards a Formal Model for a Transversal Palaeography », Comparati (...)
• 14 GeoNames, https://www.geonames.org.

14DigiPal est basé sur la plateforme Archetype (qui a également été développée par l’auteur et son équipe au King’s College de Londres), et celui-ci possède une API Web qui permet à un logiciel externe de récolter le contenu de la base de données et de l’utiliser directement à d’autres fins12. Cependant, cette récolte n’est pas facile à faire dans la pratique, car le modèle de données de DigiPal est différent de celui que nous avons développé pour Heurist. Dans certains cas, les différentes entités sont suffisamment claires pour être liées directement : par exemple, un Historical Item de DigiPal correspond plus ou moins directement à une Unité de circulation de Heurist. En outre, le modèle DigiPal / Archetype a été aligné au modèle FRBRoo / CIDOC-CRM13 que nous avons déjà évoqué. Cela signifie que FRBRoo peut être utilisé comme format intermédiaire pour la conversion entre DigiPal et Heurist. Cette approche a été relativement fructueuse, malgré quelques pertes de données résultant de légères différences entre les modèles. La difficulté la plus notable était peut-être celle des lieux. Le modèle DigiPal pour les lieux comprend un simple texte sans autres détails tels que les coordonnées sur une carte. Cela présente l’avantage considérable de permettre une grande souplesse qui est essentiel pour prendre en compte l’incertitude dans la représentation des lieux historiques, avec des exemples tels que « Worcester or York », « Abingdon (or Continent?) », et « France (prob. Brittany, or South-West France?) ». Cependant, l’absence de coordonnées rend les lieux impossibles à reporter sur une carte, ce qui est l’un des objectifs de notre base de données Heurist. À cette fin, nous avons produit un script simple et plutôt naïf pour la géolocalisation, c’est-à-dire pour identifier les coordonnées de chaque lieu et insérer cette information dans la base de données. Pour ce faire, nous avons utilisé GeoNames, qui est un répertoire géographique pour les lieux14. Il permet à une personne ou à un ordinateur de rechercher le nom d’un lieu et de trouver ses coordonnées, ainsi que le nom du lieu dans un grand nombre de langues et d’autres données. Il était très facile d’écrire un court programme informatique pour parcourir les listes dans DigiPal, les consulter sur GeoNames, puis de créer des fichiers XML avec les coordonées et les importer dans Heurist.