Un réservoir de données liées…

En farfouillant dans les archives du Figoblog pour produire un document, je retombe sur cet article d’avril 2006 dans lequel je suggérais :

Moi je verrais bien l’évolution du catalogue vers un statut de base « pivot », contenant des données en XML qu’on pourrait réutiliser à volonté, dans des applications adaptées aux différents types d’usagers.

5 ans après, je ne sais pas si je suis complètement monomaniaque ou franchement visionnaire, mais j’ai toujours la même vision. A quelques détails près.

Je pensais XML, parce que je n’avais pas encore réalisé qu’il n’était pas vraisemblable de vouloir faire entrer toutes les données du catalogue, dans leur diversité, dans un même modèle documentaire.
Il a fallu s’extraire des carcans de la pensée documentaire pour considérer que ce dont nous avons besoin, ce n’est pas un format unique, mais un modèle générique capable d’intégrer de façon souple et auto-descriptive différents formats.

J’avais aussi pressenti que le problème n’était pas d’imaginer les nouveaux usages, mais d’imaginer un réservoir de données capable de s’adapter à tous les usages possibles :

Il y a des usages, multiples, différents, et aucun outil miracle ne saura tous les contenter. Il faut des données fiables et souples, qu’on peut sortir, transformer, adapter, réutiliser. Pour moi c’est ça le futur du catalogue.

En fait, j’envisageais déjà le catalogue comme un système métastable, c’est à dire capable d’intégrer les évolutions de façon naturelle, et pas uniquement comme des facteurs de remise en cause et d’instabilité.

En fait, il fallait pousser le raisonnement jusqu’au bout : ce qui m’inspirait ces réflexions c’était le modèle du Web. Or, le Web, en tant qu’espace global d’information (un espace où on peut naviguer d’une page à l’autre sans rupture, ni technologique, ni dans l’expérience utilisateur : il suffit de « cliquer »), nous apprend précisément ceci : si on veut que de larges quantités d’informations puissent interopérer, il faut accepter qu’elles soient produites de façon hétérogène, et n’imposer que le niveau minimal de normalisation permettant à toutes ces informations de cohabiter dans le même espace.

Les systèmes d’information actuels (dont les catalogues) posent exactement ce type de problème : ils sont instables au sens où leur équilibre est sans arrêt remis en cause par quelque chose de nouveau (un nouveau format, un nouveau besoin, une nouvelle fonctionnalité), et ils sont hétérogènes parce qu’à chaque nouveau besoin, on donne une réponse spécifique.

Le Linking Enterprise Data correspond à l’application des principes du Linked Data au domaine de l’entreprise. Je ne vous parle même pas d’exposer les données sur le Web. L’enjeu est seulement d’utiliser le Web (ou le Web sémantique) comme modèle pour la conception du système d’information. On adopte un niveau de normalisation minimal pour toutes les applications, de façon à ce que les données soient interopérables et reliées (avec des URI). A partir de là, le système devient métastable, capable de maintenir une certaine stabilité dans un contexte en évolution. Quand un nouvel usage émerge, la donnée est déjà disponible, il suffit de l’agréger pour la retraiter.

La masse des données manipulée dans les catalogues (surtout les gros) rend illusoire l’adoption d’une base unique, d’un format unique. Techniquement, les problèmes de performance et de cohérence sont exponentiels. Du point de vue de l’utilisateur, le modèle est rigide, inadapté aux évolutions.
Il faut adopter un modèle qui est prévu, de façon inhérente, pour être permissif aux évolutions. RDF par exemple.
Dès lors le catalogue, plutôt qu’un réservoir unique, est une plate-forme, un environnement cohérent au niveau local (à l’intérieur de la bibliothèque) dont le rôle majeur est de relier les données et de les rendre disponibles.

Merci à Got d’avoir partagé ses lumières avec moi sur ce sujet.

Publicité

2 réactions sur “Un réservoir de données liées…

  1. Je ne suis pas sûr de comprendre. L’idée c’est de gérer un réservoir de données RDF et d’en extraire des sous-ensembles pour constituer des bases ad hoc pour telle ou telle occasion ?

  2. Pas vraiment. En fait, le format de stockage n’a qu’une importance limitée ici. Ce qui compte, c’est la modélisation RDF avec 3 principales qualités : le modèle de triplet et de graphe, le fait que le modèle soit autodescriptif (on exprime le modèle de données sous la même forme que les données), et le système global d’identifiants (les URI).

    A partir du moment où toutes les données du SI partagent ces caractéristiques, peu importe si on les stocke ensemble ou non. Elles sont reliées et exprimées dans un modèle commun. On peut utiliser divers outils pour les traiter, ensemble ou séparément, en constituant ou non des bases ad-hoc.

Les commentaires sont fermés.