Archives Mensuelles: septembre 2009

Dublin Core, le pouvoir de la simplicité

Publié le par

Suite à une suggestion de Stéphane, je voudrais faire le point sur une question souvent posée quand on parle de Dublin Core : est-ce que le fait d’utiliser Dublin Core va appauvrir mes données ?

La réponse est plus complexe que juste « oui » ou « non ».

D’abord, il n’y a pas un seul Dublin Core. Le Dublin Core, c’est un ensemble de standards dont j’avais rappelé l’articulation dans un précédent billet. Relisez-le, c’est un pré-requis pour la suite.

Maintenant si vous prenez des données dans un format richement structuré, par exemple MARC, et qu’une fois passé en XML, vous lui appliquez une conversion pour le transformer en « Dublin Core simple », oui, vous allez appauvrir vos données, et ce pour trois raisons :
– le DC dit « simple » se limite aux 15 éléments « de base » et ne permet pas d’exprimer la richesse contenue dans les Dublin Core metadata terms, donc vous serez obligé de choisir pour chacun de vos éléments en MARC une cible assez générique (par exemple, tous les types de titre, titre propre, titre parallèle, titre original et que sais-je encore vont tous atterrir en « dc:title ») ;
– exprimée en XML, votre notice en DC doit respecter le schéma XML du DC simple, il est donc exclu d’introduire la moindre fantaisie et de « rajouter » quoi que ce soit qui vous permettrait d’exprimer une information plus fine.
Ce scénario, c’est typiquement ce qui va vous arriver si vous faites de l’OAI-PMH, car ce protocole impose de présenter ses données au format Dublin Core simple.

Mais ce n’est pas la seule façon d’utiliser le Dublin Core.
L’ensemble des classes et des propriétés exprimées dans le Dublin Core metadata terms (qui est donc plus large que les 15 éléments de base) peut en effet être utilisé pour exprimer des triplets en RDF.
Mais en RDF, contrairement à XML, chaque triplet est indépendant et signifiant indépendamment de tout contexte, ce qui signifie que je peux tout à fait utiliser pour décrire la même ressource des propriétés du Dublin Core et d’autres propriétés, venant d’autres vocabulaires ou ontologies.
L’utilisation de Dublin Core en RDF est donc deux fois plus riche :
– le vocabulaire lui-même est plus riche et plus détaillé
– et on n’est pas obligé de s’y limiter, on peut le combiner avec d’autres.
Pour prendre un exemple, si je veux décrire une ressource en précisant un lieu, je peux utiliser la propriété « dc:spatial » (qui est plus fine que « dc:coverage », celui-ci pouvant être utilisé pour la couverture temporelle aussi bien que géographique) mais aussi la combiner avec des propriétés d’une ontologie géographique permettant d’exprimer finement les coordonnées (latitude, longitude) du lieu.
Ainsi, pour reprendre mon exemple ci-dessus, si je passe ma notice MARC en RDF, il est probable que certaines parties de la notice pourront être exprimées en utilisant des propriétés du DC, et d’autres non, mais ce n’est pas un problème, je peux les combiner.

Et l’interopérabilité, dans tout ça, me direz-vous ?
C’est vrai, le principal atout du Dublin Core, c’est interopérabilité, et c’est pour cela que l’OAI-PMH impose le Dublin Core simple, partant du principe qu’il permet de décrire tout type de ressources.
Pourtant, l’utilisation du DC simple en XML pose de GROS problèmes d’interopérabilité : comme il appauvrit les données, il y a une infinité de façons de l’appliquer, et les résultats, à la fin, sont rarement compatibles : on a tendance à « bourrer » l’information tant bien que mal dans les 15 éléments, voire à les répéter un nombre incalculable de fois au point de ne plus savoir où on en est. Mais bon, c’est toujours mieux que rien ; donc on crée des règles, ou des profils d’application, pour s’assurer que tout le monde fait (un peu) la même chose.
En RDF, le Dublin Core est un vrai atout pour l’interopérabilité car il permet à une multitude de gens d’exprimer la même chose de la même manière, à un niveau de granularité plus fin. Au lieu que chacun réinvente la roue et crée sa propre propriété « titre », ou « auteur », on utilise le Dublin Core, qui permet au moins, pour un large ensemble de ressources décrites en RDF, de repérer assez facilement les « titres » et les « auteurs ». Ensuite, on complète avec d’autres propriétés créées exprès ou prises dans d’autres vocabulaires.
C’est la raison pour laquelle le DC joue un rôle essentiel dans le Linked Data, qui est d’ailleurs le sujet de la conférence DC 2009 à Séoul.

La journée du non-patrimoine

Publié le par

Et si aujourd’hui, justement, c’était le jour où je ne me préoccupais pas de l’accès de tous à la culture, de la conservation et de la transmission du patrimoine, de la médiation et de l’accès du grand public aux œuvres, de la diversité et de la richesse des contenus, de la trouvabilité de l’aiguille dans la botte de foin, de l’usager et de ses usages multiples, de l’élaboration de la connaissance et du savoir, de l’émulation culturelle des communautés, du positionnement de la collection dans l’espace et le temps, de la qualité de la donnée qui fait la qualité de l’expérience utilisateur, de la découverte et de la sérendipité, de l’exception qui rend la règle encore plus magnifique, des siècles qui nous contemplent, du grand, du beau, et de l’ancien.

Aujourd’hui, c’est ma journée du non-patrimoine.

Modéliser le Linked Data

Publié le par

Quand on se lance dans la modélisation, je suppose qu’à un moment on atteint un degré de complaisance (ou peut-être de folie furieuse) qui amène à tout théoriser, et pour que le modèle tienne la route, on finit par être obligé de créer des modèles qui expliquent comment on modélise les modèles.

Ça va vous paraître fou, mais en fait, c’est utile.

En juin j’ai visiblement raté une bonne occasion d’aller à Madrid pour la conférence Linked data on the Web 2009.
A noter dans les papiers de cette conférence, deux propositions intéressantes pour aider à modéliser le Linked Data.

La première, c’est IRW : Information Resources on the Web Ontology, par Harry Halpin et Valentina Presucci.
Pour les puristes, l’ontologie elle-même est ici.
Cette ontologie s’attaque à des notions sur lesquelles on peut gloser pendant des jours : les ressources informationnelles et non informationnelles, les représentations, les réalisations Web d’une ressource, et leurs URI respectives. La seule question qu’elle ne pose pas (probablement par pudeur ;-) c’est… la notion de document.

L’autre c’est un vocabulaire pour gérer la provenance dans le Linked Data, par Olaf Hartig de l’Université Humboldt de Berlin.
La spécification est ici pour les puristes, et pour ceux qui aiment plutôt les petits dessins, le powerpoint est là.
Il s’agit de contribuer à l’établissement de la confiance dans le Linked Data en modélisant les informations de provenance qu’on peut associer à un ensemble de données.

Il y a plein d’autres trucs intéressants dans cette conférence. C’est juste que j’ai pas encore eu le temps de regarder.

IFLA (4) – User generated content, tagging sémantique et Web 2.0

Publié le par

Mieux vaut tard que jamais ;-) je poursuis ma série de comptes-rendus de l’IFLA (ce qui me rassure c’est qu’en regardant les autres blogs la plupart n’ont pas eu beaucoup plus de temps que moi pour bloguer pendant le congrès… C’est que ça occupe, un congrès de l’IFLA…)

Un autre thème sur lequel je voudrais revenir, c’est celui des contenus générés par les utilisateurs (UGC de leur petit nom).

Comme nous avons beaucoup parlé de Web 2.0, la question du « tagging » s’est posée à différentes reprises, avec un constat un peu déprimant : les utilisateurs ne vont pas tagguer dans les catalogues de bibliothèque. Faire des listes, oui, tagguer ailleurs, peut-être, mais dans les catalogues ? peu de chances.
Un jour autour d’un verre, nous avons échangé quelques idées amusantes pour essayer d’envisager une méthode pour contrebalancer cette tendance… Par exemple un système similaire à Booking.com : quelques jours après la fin de votre séjour, on vous envoie un mail avec un questionnaire pour évaluer l’hôtel. Et si on faisait de même quand un lecteur emprunte un livre à la bibliothèque ?
Une autre idée consistait à proposer une étagère de retour de prêt qui serait compartimentée en fonction de l’intérêt du bouquin (intéressant – ennuyeux – etc.) : apparemment ça a déjà été testé, si vous avez vu ça quelque part je serais curieuse d’en avoir la référence.
Blague à part, ce qu’il faut en retenir comme toujours, c’est que si on veut générer des contributions des utilisateurs, il faut que ce soit 1. facile, 2. pertinent par rapport à leur pratique, et 3. que cela fasse partie d’un dispositif d’incitation.
Ces trois critères sont semble-t-il parfaitement remplis par l’application de correction de l’OCR de la numérisation de la presse à la Bibliothèque nationale d’Australie (voir la présentation de Pam Gatenby à l’IFLA – voir le site – voir les informations sur le projet). Et ça marche : comme quoi, on peut arriver à mobiliser les utilisateurs sur des tâches pénibles et en plus ils adorent ça ;-) Noter qu’ils diffusent le code de leur application en open source.

Face aux possibilités du Web 2.0, la question critique de l’indexation sujet a été posée (pendant la table ronde de la conférence satellite Emerging trends… à Florence) : devrait-on arrêter d’indexer de façon aussi complexe que nous le faisons aujourd’hui ? L’indexation sujet, jugée à la fois coûteuse à produire et trop complexe à utiliser, était en question.
A mon avis à l’heure actuelle prendre une décision aussi radicale est impossible, d’autant qu’on sait pertinemment que les utilisateurs veulent des accès sujets, et qu’ils ne veulent pas les créer eux-mêmes (puisqu’ils ne veulent pas tagguer dans les catalogues).
Une solution envisageable pourrait résider dans le « tagging sémantique » par des bibliothécaires : c’est-à-dire, en fait, exploiter la richesse des vocabulaires contrôlés, mais sans la contrainte de la syntaxe, et en utilisant la puissance des ontologies pour les relier et les augmenter.
C’est intéressant, mais il va falloir du temps pour mesurer toutes les implications d’une telle évolution. Elle mériterait d’être organisée, évaluée, préparée au niveau international, pour permettre une évolution concertée des données bibliographiques dans le monde, vers le Web sémantique. L’IFLA peut sûrement jouer un rôle dans ce type de changements.
Et puis, mon petit doigt me dit qu’on a pas encore imaginé toutes les possibilités qu’ouvre une initiative comme Rameau en skos en termes d’exploitation sémantique des données…

Au final, et pour en finir avec le Web 2.0 dans les bibliothèques à l’IFLA, je voudrais noter une idée que j’ai retenue des différents événements qui ont abordé cette question, en particulier la conférence satellite, la session « Social computing tools for learning and knowledge sharing » (dans laquelle j’ai particulièrement apprécié l’intervention de Moira Fraser), et la rencontre du SIG « Libraries and the Web 2.0 ». Cette idée c’est que la bibliothèque 2.0 commence avec des petites choses toutes simples : avoir un compte Twitter, un blog, communiquer par l’image et la vidéo et pas seulement par du texte, sortir du paradigme de la présentation magistrale avec powerpoint. Être 2.0, c’est un peu comme se brosser les dents après chaque repas, ou manger cinq fruits et légumes par jour : quelque chose qui doit rapidement devenir un réflexe naturel du quotidien, pas une contrainte. Sinon, c’est voué à l’échec.