Pour clore cette série de billets sur mon voyage à l’IFLA, je voulais revenir sur quelques idées fortes qui se sont avérées récurrentes quand il a été question de Web sémantique et de Linked Data.

Le premier point portait sur les licences et de l’open data. Ce sujet avait été inscrit à l’agenda de la session des bibliothèques nationales, et il a surgi également lors de nos deux événements sur le Web sémantique (la table ronde OCLC et la session du SWSIG). On commence à voir les « gros » se poser réellement la question pour une partie de leurs données de l’ouverture complète, sans la moindre contrainte, façon CC0 : la British Library, la Deutsche Nationalbibliothek, la BnF. De même, OCLC a récemment ouvert les données de WorldCat en Schema.org sous licence ouverte. Les données sont fournies dans les pages en RDFa, mais on peut aussi télécharger un « dump » (gros fichier avec plein de données dedans) partiel contenant 1,2 millions de ressources. Ce choix de licence montre qu’OCLC reste attaché au principe de la citation de la source, allant jusqu’à fournir des guidelines sur la meilleure façon de citer ses sources s’agissant de données. Je trouve ce document très intéressant en ceci qu’il aborde les différents cas possibles, depuis l’attribution sous la forme d’une mention globale (genre, « ce site/service/article utilise des données de Worldcat sous licence ODC-by ») jusqu’au simple fait d’utiliser les URIs de WorldCat dans le jeu de données, qui est considéré comme une forme d’attribution en soi ! L’intermédiaire entre les deux consiste à ajouter dans la description de son dataset un triplet avec un « DC:source » vers WorldCat. On pourra lire avec grand bénéfice quelques commentaires sur la stratégie d’OCLC sur le blog CC. Bien que je sois globalement d’accord, je les trouve un peu sévères sur les guidelines et la question de leur applicabilité dans le contexte du Linked Data. Il me semble au contraire que le fait de considérer la simple utilisation des URI comme une forme d’attribution contribue à intégrer juridiquement le principe qui est au cœur du Linked Data (« follow your nose », naviguer dans les données en suivant les liens). Et justement, cela fait plusieurs années qu’on proclame, nous les Linked Data évangélistes, que vos données – même réutilisées – ramèneront toujours de la valeur et de la visibilité à votre institution ne serait-ce qu’à travers les URI. C’est donc réconfortant de lire cela dans les guidelines d’OCLC… Sans vouloir m’étendre davantage sur OCLC, je trouve pour finir que ces quelques pas qu’ils font en direction du Linked Open Data sont significatifs d’une tendance beaucoup plus importante : le modèle économique de la vente des données, c’est fini. Et tous les acteurs qui reposaient là-dessus uniquement vont devoir se creuser la cervelle pour trouver autre chose. Quant à ceux, comme les bibliothèques nationales, qui y voyaient un sympathique à-côté fournissant quelques petits revenus quand même, ils vont pouvoir libérer leurs données avec la conscience tout à fait tranquille… bonne nouvelle non ? (A lire absolument pour se détendre sur le sujet : pourquoi les bibliothèques ne sont pas en open data, par Mace Ojala sur Cyc4libs.) Une fois les données ouvertes, c’est bien joli mais on aimerait bien pouvoir savoir qui va les utiliser et comment. Et là c’est le trou noir, le black out. Les données libérées sont désespérément muettes quant à leur usage, tout au plus dispose-t-on de logs sur un serveur qui semblent témoigner d’une activité, mais laquelle… Or la communauté ayant maintenant bien intégré l’idée que nous ne pouvons pas aller plus loin sans démontrer la valeur ajoutée de l’open/linked data en termes de réutilisations, cette question est devenue cruciale. C’était d’ailleurs le sujet de ma keynote à DC2011. A l’époque c’était presque révolutionnaire, et j’avais lancé ce slogan : « we need to stop citing the BBC », parce qu’il me semblait impensable que nous puissions tenir encore plusieurs années sans avoir un autre exemple digne de ce nom à présenter. Quand je dis « digne de ce nom », ce n’est pas que les autres applications sont indignes, mais je voulais parler d’exemples démontrant l’usage des données du Linked Data en production, et pas seulement de manière expérimentale, cet usage étant assorti d’une vraie réflexion et d’un discours sur ce que cela apporte à l’institution. Quand on discute avec les collègues de la BBC (on peut aussi lire leur use case sur le site du W3C) ils expliquent que l’approche Linked Data est complètement intégrée à la conception de leur système d’information, dont une partie est considérée comme « externalisée » sur le Web (en gros, ils corrigent les notices de Wikipédia au lieu d’éditorialiser leur propre site) et dont la clef de voûte réside dans l’attribution des URI qui permettent d’unifier le système. En fait, ils ont eu avant la lettre cette vision du Linked Enterprise Data (minute copinage : vous trouverez une très bonne explication du LED en français ici), c’est-à-dire l’utilisation des principes et des technologies du Linked Data à l’intérieur du système d’information pour unifier les données entre les différentes applications. C’est d’ailleurs cet aspect que j’ai choisi d’approfondir quand j’ai présenté le Centre Pompidou virtuel pendant la table ronde OCLC (comme quoi je ne raconte pas toujours la même chose !) J’ai comparé le principe à celui d’un intranet, qui utilise les technologies du Web mais au bénéfice interne de l’institution, sans parler de publication. Eh bien là c’est la même chose, une première étape où on fait en quelque sorte du Linked Data en interne – avant, je l’espère, d’envisager d’ouvrir les données. Ainsi, le premier argument pour convaincre une institution de faire du Linked Data pourrait être la perspective d’améliorer les processus internes. Mais si on parle d’open data, il faut aussi être capable de démontrer la valeur ajoutée de l’ouverture, en terme de réutilisation. Martin Malmsten suggérait de partir d’un principe simple : contribuez ce qui est unique chez vous, et bénéficiez de l’ensemble. A mon avis, il reste cependant nécessaire de démontrer *comment* on bénéficie de l’ensemble, et pour cela il nous faut connaître les utilisateurs du service et les cas d’usage. D’où la question : comment faire pour connaître les utilisateurs de nos données ouvertes ? On a failli repartir tous avec des tee-shirts « if you build it, they will come ; if you break it, they will complain » (l’idée étant de casser le service pour que les utilisateurs se manifestent ;-) Mais plus sérieusement, l’approche proposée par Neil Wilson (BL) m’a semblé très sensée : c’est à nous de construire la communauté, en contribuant éventuellement dans un premier temps à la mise en place de services tiers, pour montrer l’exemple. Enfin, le troisième défi souligné par mes camarades de la British Library et de la bibliothèque royale de Suède est celui de la mise à jour des données. Il est aussi lié au point précédent, en ceci qu’on constate que les consommateurs actuels de Linked Data ont tendance à faire porter leur préférence sur un dump plutôt que d’utiliser les données liées en temps réel, pour diverses raisons notamment techniques sur lesquelles je ne vais pas m’étendre ici. Au temps pour le graphe global : ce qu’on utilise aujourd’hui en réalité, c’est bien souvent une photographie des données à un instant T, et suivant la fréquence de mise à jour du dump source et de l’application cliente, la fraîcheur du service est inégale. Du coup, côté OCLC et Libris, on privilégie une approche où la version RDF de chaque notice fait partie intégrante du service, dans un esprit très Linked Data. Ils voudraient inciter leurs utilisateurs à utiliser directement ces données plutôt que des dumps qui vont se périmer très vite. Côté British Library et BnF, on rafraîchit tous les mois, et on voudrait passer à un rythme hebdomadaire. Et moi, je suis bien placée pour savoir que rafraîchir quotidiennement est un défi, mais que dans certains cas c’est aussi une nécessité. Donc, on voudrait que notre Linked Data soit plus intégré aux processus de production des données, et pas seulement en bout de chaîne (cf. ce que je disais plus haut sur le LED). On voudrait des applications qui « suivent leur flair » (follow your nose, donc) en temps réel au lieu d’avaler des gros fichiers une fois de temps en temps. Et enfin, on voudrait un processus de notification qui permette aux consommateurs de données de savoir quand un dataset ou une ressource a été mis à jour (c’est là que Martin s’est mis à parler d’Atom et de PubSubHubbub, le protocole au nom marrant). Cette problématique renvoie à la question de la provenance, sur laquelle travaille le DCMI, en lien avec le W3C qui avait fait un groupe d’incubation sur le sujet. Mais ce n’est pas tout ; dans le Linked Data on exprime les triplets sous la forme d’un document, un fichier qui contient les données sous une forme RDF/XML ou autre. La question est donc de savoir comment utiliser ce document pour transmettre aussi des informations de notifications concernant les mises à jour. Mince, je m’étais dit que j’allais faire un petit billet pas trop long et voilà le résultat… En tout cas, nous allons aborder tous ces sujets, Got et moi, dans notre présentation au séminaire INRIA en octobre. Pour ceux qui n’ont pas pu s’inscrire, les actes seront publiés, en français dans le texte. Ces questions seront également au cœur de la présentation que je vais faire en keynote de la 2e journée de la conférence SWIB 2012, à Cologne, le 27 et 28 novembre prochains (je me permets de l’annoncer en avant-première, le programme devrait être publié très prochainement). Alors venez nombreux ! Commentaires bienvenus par mail, sur Twitter @figoblog et sur Facebook pour ceux qui y sont.