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.