Dans ce dernier billet consacré au projet Sudoc21, sont abordées les solutions informatiques choisies pour tester l’implémentation du modèle de données (format pivot) conçu par les experts de la modélisation bibliographique.

1. Nom de code Sudoc21
2. Les données en diptyque
   • 2- 1 Le noyau de la cerise ou la culture du pivot
   • 2- 2 Exercice d’apagogie négative
3. Retours sur l’exploration des solutions informatiques

A partir des différentes solutions logicielles permettant de stocker, interroger et mettre à jour les données structurées selon le format pivot, il s’agissait d’évaluer l’aptitude à traduire en terme de système d’information les différents cas d’usages, et notamment d’évaluer leur complexité technique et leur facilité d’implémentation. De manière générale, le volet « expérimentation des solutions informatiques » a constitué un espace d’échanges et de réflexion entre les membres de l’équipe Sudoc21, indépendamment du domaine de compétences de chacun, ce qui a renforcé la diffusion et le partage d’expertises.

Un projet tourné vers l’avenir

L’équipe informatique du projet Sudoc21 a conservé à l’esprit le fait que le système d’information va être amené à gérer des volumes de plus en plus conséquents : si, en l’état actuel, l’éclatement des données Sudoc en entités s’évalue en milliards, l’objectif est d’atteindre une granularité plus fine encore, comme en témoigne le « en deçà » (ie. chapitres, articles, numéros et volumes) évoqué dans le précédent billet Punktokomo à ce sujet : Les données en diptyque : exercice d’apagogie négative:

“Ce modèle a mis en exergue l’importance de la notion de “granularité” : en deçà, granularité de description documentaire – livres et revues, mais aussi leurs parties composantes -chapitres, articles, numéros et volumes” 

Il s’agissait également de tenir compte des assouplissements à prévoir lors de la conception et de l’évolution des schémas de données.

Pour prendre en charge ces contraintes, l’équipe a envisagé, en complément des solutions relationnelles classiques, d’autres solutions de stockage et d’interrogation, qui intègrent des mécanismes plus flexibles. Il existe en effet différentes possibilités techniques permettant :

• soit d’«éclater» des données dans une granularité très fine (« atomique ») – chaque instance pouvant avoir des relations différentes –  et de les lier entre elles
• soit d’obtenir un compromis entre de la donnée « tabulée » – classique, relationnelle – et de la donnée « orientée » – composite et faiblement structurée-  qui bénéficie peu ou pas des avantages d’un stockage en tables

Dans le cadre du projet Sudoc21, les explorations techniques ont donc été réalisées selon trois approches : une approche relationnelle classique, une approche « graphe »  et une approche « mixte »

Ces billets sont la seconde partie d’une trilogie consacrée au projet Sudoc21. Ils reviennent sur les enjeux de la modélisation des données posés dans le premier billet, et sur la manière dont l’équipe en charge du projet s’y est confrontée.

• • 1. Nom de code Sudoc21
    2. Les données en diptyque
       • 2- 1 Le noyau de la cerise ou la culture du pivot
       • 2- 2 Exercice d’apagogie négative
    3. Retours sur l’exploration des solutions informatiques (billet technique)

Tout en cherchant à conceptualiser ce modèle cible, nous avons parallèlement exploré certaines logiques de modélisation, pour en évaluer l’intérêt, ou les écueils. Ces expérimentations nous ont conduits à des choix de modélisations parfois hétérodoxes, parfois même pas totalement cohérents, et ce volontairement. Voici quelques exemples de ces choix, des réflexions qui nous y ont menés et des leçons que nous en avons tirées.

Être ou ne pas être… un Nomen

Nous avons ainsi beaucoup joué avec les Nomens, qui dans le modèle LRM portent les appellations des autres entités, quelles qu’elles soient : titres, noms, libellés. Nous avons pris parti de les considérer comme des entités à part entière, ils sont donc vite devenus omniprésents. Seule entorse au principe, nous n’avons pas poussé cette logique jusqu’à faire des identifiants eux-mêmes des Nomens, comme ils sont censés l’être. Excepté, à titre expérimental, pour l’ISSN-L (ISSN de lien, attribué par le Registre ISSN, commun aux différents supports de publication d’une ressource continue).
Notre retour d’expérience sur ce point, après avoir travaillé sur les cas d’usages en écrivant des requêtes au cours de nos tests des différentes solutions, est mitigé. L’intérêt du Nomen comme entité, est de pouvoir en “dire quelque chose” en plus de sa valeur via des propriétés : langue, écriture, parfois sous-éléments (comme le nom et le prénom pour les personnes), données de gestion…
A contrario, les requêtes portant bien souvent sur la valeur littérale de ces entités, leur présence en « bout de chaîne » alourdit considérablement, à la fois l’écriture de la requête et le parcours des données.
Si c’était à refaire, nous reconsidérerions ce choix : il serait plus économique et efficace de les repenser comme propriété de leur entité mère, à condition de disposer d’un mécanisme permettant de qualifier cette propriété, comme nous l’avons fait pour les affiliations.

Ces billets sont la seconde partie d’une trilogie consacrée au projet Sudoc21. Ils reviennent sur les enjeux de la modélisation des données posés dans le premier billet, et sur la manière dont l’équipe en charge du projet s’y est confrontée.

• 1. Nom de code Sudoc21
  2. Les données en diptyque
     • 2- 1 Le noyau de la cerise ou la culture du pivot
     • 2- 2 Exercice d’apagogie négative
  3. Retours sur l’exploration des solutions informatiques (billet technique)

Façonner un top-modèle…

Des silos au modèle commun

Pour rappel, les enjeux du projet Sudoc21 étaient d’expérimenter à la fois comment :

• “Désiloter” les différents types de données, aujourd’hui dispersés dans des environnements et formats qui ont du mal à se parler.
• Ouvrir la voie à leur migration vers le modèle IFLA-LRM en faisant le choix d’une instanciation commune de ce modèle à tous les types de données traitées. C’est ce modèle cible que nous évoquerons plus loin sous le raccourci “pot commun”.

Dans cette première partie consacrée aux données, il sera question des choix opérés par l’équipe pour l’instanciation du modèle et le passage par un format pivot pour leur conversion.

Pour ce faire, nous avons constitué des jeux de données représentatifs de chaque source. Puis, afin de rendre tangible l’articulation qui existe entre ces données et qui n’est aujourd’hui pas exploitable, nous avons sélectionné un sous-ensemble de ressources présentes à la fois dans le Sudoc, dans BACON et en base RDF auquel est venu s’ajouter un échantillon de métadonnées TEF pour les thèses.

Ce billet est le premier d’une trilogie consacrée au projet dit Sudoc21. Il revient sur les enjeux de la modélisation des données, et sur la manière dont l’équipe en charge du projet s’y est confrontée.

• 1. Nom de code Sudoc21
  2. Les données en diptyque
     • 2- 1 Le noyau de la cerise ou la culture du pivot
     • 2- 2 Exercice d’apagogie négative
  3. Retours sur l’exploration des solutions informatiques (billet technique)

Flash-back

Les JABES 2019, une présentation en plénière sur l’avenir du Sudoc, la refonte du SI de l’Abes, enthousiasme et anxiété de venir dire où nous voulions aller. Depuis ? Ce que nous ne pouvions pas prévoir : le monde mis sens dessus dessous les mois suivants, où le sens de la mesure allait s’inverser – jamais assez loin des autres, toujours trop proche de chez soi. Ce que nous pouvions encore moins imaginer : que Stéphane Rey, responsable informatique du projet, meure brutalement en avril 2020. Et après. Et pourtant. Et malgré. Nous voici au bout de ce projet de deux années, nom de code Sudoc21. Vingt-et-un comme XXIème siècle davantage que 2021, si c’est d’échéance qu’il s’agit. Car au risque de vous décevoir, l’irruption du nouveau système ne sera pas immédiate. Mais au moins avons-nous pu prendre le temps, dans un travail très étroit entre bibliothécaires et informaticiens, de poser correctement les questions pour mesurer le chemin qui nous reste à parcourir.