Archives de Tag: normes

Réflexion autour de Bibframe et la formation au Web sémantique

Publié le par

Je n’avais jamais eu le temps de me pencher véritablement sur Bibframe, ce « format » développé par la bibliothèque du congrès dans le cadre de sa transition bibliographique, avec pour objectif annoncé de « remplacer les formats MARC ». J’ai pu récemment réparer ce tort grâce à une étude d’une collègue de la BnF (merci Suzanne) suivie d’une très riche discussion avec plusieurs autres collègues (privilège des grandes maisons !)

Au départ, l’idée de Bibframe nous a laissés plutôt songeurs. Pour commencer, peut-on vraiment parler de « format » ? Naturellement, entre gens habitués depuis plusieurs années à manipuler des vocabulaires RDF et des triplets, nous avons plutôt employé le terme de « modèle ». Or, ce modèle est assez troublant. Sans se raccrocher explicitement à d’autres modèles/vocabulaires comme FRBR ou Dublin Core, il ne paraît pas non plus incompatible avec eux.
En termes d’usage, difficile également d’avoir les idées claires : Bibframe serait-il un « format » de production ? Dans ce cas il ne paraît pas assez détaillé. Un « format » d’échange ? Mais alors pourquoi n’avoir pas privilégié un vocabulaire existant et déjà bien implanté, comme le Dublin Core… Serait-il alors un « format » destiné principalement à transformer en graphe des notices MARC existantes ? Hypothèse peut-être la plus plausible, mais la souplesse du modèle est telle qu’il permettrait de le faire de mille façons différentes.
Au terme de la discussion, Bibframe ne nous semblait pas avoir vraiment de sens dans une perspective technique. Rien de ce qui est fait dans Bibframe ne semble impossible à faire en combinant des vocabulaires existants comme par exemple dans le modèle de données de data.bnf.fr. On a donc l’impression d’avoir affaire au énième standard qui vient se surajouter à tous les autres pour essayer de les réconcilier… et ne fait que créer une nouvelle couche de complexité (cf cette fameuse BD).

Cependant, en y réfléchissant en résonance avec divers événements, j’ai commencé à regarder les choses autrement.

D’abord, il y a eu Semweb.pro, le mois dernier, et la conférence de clôture de Phil Archer. Dans celle-ci, il a émis l’idée que l’important à transmettre à nos développeurs et autres professionnels n’était pas « faites du Web sémantique » car dans la plupart des cas, ils n’avaient en fait pas besoin du niveau de complexité qui est associé à cette technologie. Pour, lui il suffit dans la plupart des cas de se limiter à trois choses :
– attribuer des URI,
– penser en graphe,
– faire du JSON-LD (cette sérialisation très simple de RDF semble être la meilleure promesse d’adoption par les développeurs depuis l’invention du Web sémantique).
Alors ils feraient du Web sémantique sans y penser, comme Monsieur Jourdain faisait de la prose.

Ensuite, j’ai participé le 26 novembre à la 2e saison de la formation du CNFPT « les catalogues au défi du Web ». Au cours des différentes discussions, notamment la très intéressante table ronde de l’après-midi, je réfléchissais au fait qu’il ne serait ni possible, ni utile de former tous les catalogueurs ou tous les bibliothécaires au Web sémantique.
Je me suis souvenue qu’à l’époque où j’ai fait l’ENSSIB, nous avions des cours sur la modélisation des bases de données relationnelles et sur le requêtage SQL. A part pour les tordus dans mon genre qui ont besoin de comprendre comment fonctionnent les choses sous le capot, cela n’avait aucun intérêt. Difficile de placer le curseur de l’apprentissage technologique pour des gens qui n’auront pas à pratiquer au quotidien… C’était ce qu’on appelait dans le temps « le niveau technico-stratégique » : le niveau de base de connaissance technique qui permet de comprendre et donc de décider. Mais tout le monde n’en a pas besoin.

En effet, après avoir déployé pas mal d’énergie à essayer de former des bibliothécaires au Web sémantique (on a même écrit un bouquin, c’est dire) je suis aujourd’hui convaincue que la plupart d’entre eux peuvent vivre très confortablement sans savoir ce qu’est le Web sémantique ou comment ça marche. Par contre, ils manipuleront et pour certains, créeront de la donnée en RDF, mais façon M. Jourdain, sans en avoir conscience.
Finalement, seuls les modélisateurs de données ont vraiment besoin de connaître et comprendre en détail le Web sémantique et ils sont assez peu nombreux. D’ailleurs, cela fait peu de différence avec la situation antérieure : combien de catalogueurs savent qu’en fait de MARC, il produisent en réalité de l’ISO 2709 stocké dans les tables d’une base de données relationnelle ?
Pour revenir à Bibframe, je pense qu’on pourrait interpréter de cette façon le besoin d’avoir un « format » pour remplacer MARC.
Si on souhaite que les catalogueurs et les développeurs de SIGB (ces deux groupes en priorité) manipulent des URI et des triplets sans avoir besoin d’une formation extensive à RDF, SPARQL, OWL etc., et sans même avoir besoin de maîtriser les 5 vocabulaires de base du Web sémantique, nous avons besoin d’un outil (appelons-le « format ») qui permette d’expliquer de manière simple le nouveau modèle des données bibliographiques. Nous avons besoin qu’il soit suffisamment homogène et cohérent pour qu’on puisse expliquer ce format, uniquement ce format, et que dans la phase de transition cela permette aux catalogueurs et aux développeurs de SIGB d’acquérir une maîtrise des données suffisante pour les tâches qu’ils ont à effectuer. Enfin, nous avons besoin que ce « format » ait un nom afin de pouvoir faire passer aux managers des bibliothèques et aux décideurs un message simple : « on va remplacer MARC par X ».

Alors, pourquoi pas Bibframe ?
Bibframe est un outil qui est déjà associé à la transition bibliographique et à l’idée qu’il y aura un « après-MARC » que l’on doit commencer à construire dans les bibliothèques. Il est suffisamment souple pour être compatible avec les anciens formats (MARC aux différents parfums) et les nouveaux modèles (FRBR & Co). Bien sûr il manque encore pas mal de choses dans Bibframe (rien n’est fourni, par exemple, pour décrire les autorités) mais on pourrait le compléter ou l’étendre, l’adapter à nos besoins, en faire un profil français, voire établir ses correspondances avec d’autres vocabulaires du Web sémantique que nous utilisons par ailleurs.

Bibframe n’est en fait pas un format mais un « cadre » (framework, comme son nom l’indique) permettant d’accompagner la transition vers le Web sémantique pour les bibliothèques.
A l’heure où nous entamons en France notre propre transition bibliographique nationale, nous aurons dans doute également besoin d’un outil qui serve de support à la formation des producteurs de données et des développeurs, et qui soit plus simple que la machine de guerre Web sémantique : des URI, un graphe, une sérialisation simple.
Je ne sais pas si Bibframe sera cet outil mais on pourrait en tout cas s’inspirer de la démarche.

Web sémantique, FRBR et RDA en tournée dans toute la France

Publié le par

Depuis quelques mois, bien que tenue à l’écart de l’évolution des normes de catalogage par d’autres activités, j’ai eu la chance de participer au tour de France entrepris par quelques collègues sous l’égide du CNFPT pour présenter « les catalogues au défi du Web ». Nancy, Montpellier, Dunkerque, Angers, plus deux journées sur un thème similaire organisées à Reims et Strasbourg par Médial et une excursion aux journées RNBM à Marseille : on peut dire qu’on a sacrément bourlingué.

Au programme, parmi les sujets évoqués, on a parlé du projet OpenCat réalisé par la BnF et la médiathèque de Fresnes, qui ont construit un OPAC (interface d’accès de catalogue) en ligne en s’appuyant sur data.bnf.fr et d’autres données du Linked Data (le prototype est maintenant consultable en ligne).
On a discuté des nouvelles règles du Sudoc qui visent à mieux préparer la FRBRisation et le passage à RDA, ou encore de la FRBRisation des thèses.
On a abordé Bibframe, l’initiative pragmatique (trop pragmatique ?) des américains pour faire évoluer les formats MARC. On a parlé du rapport du comité stratégique bibliographique sur l’avenir des catalogues en France, et des actions menées par le groupe EURIG pour faire évoluer RDA vers un code de catalogage vraiment international et pas seulement anglo-saxon.

Bref, autant dire qu’il y a trop de sujets intéressants et d’évolutions passionnantes pour tout faire tenir en un seul billet. Et puis c’est vrai que si j’ai continué à travailler d’arrache-pied sur le Web sémantique (avec un projet de livre en préparation !) je me suis un peu éloignée de ces sujets plus strictement bibliothéconomiques et je ne me sens pas vraiment très à la page pour en parler.

Pour ceux qui auraient raté ces rencontres passionnantes, sachez qu’une session de rattrapage est organisée par le CNFPT le 19 novembre prochain à Paris. Je serai là encore au rendez-vous, pour introduire le propos en expliquant ce que change le Web…

Compte-rendu du séminaire IDPF

Publié le par

A l’occasion du Salon du Livre de Paris, j’ai eu la chance d’assister au séminaire organisé par l’IDPF (International Digital Publishing Forum) le 25 mars dernier. L’objectif de ce séminaire technique était de présenter aux éditeurs les fonctionnalités de l’ePub3 et les perspectives offertes par ce standard. Je rends compte ici de ce que j’ai pu y entendre.

L’IDPF est un organisme de normalisation dont le sujet de travail principal est la normalisation du format ePub. Le séminaire s’est ouvert sur une conférence introductive de Bill Mc Coy, directeur exécutif de l’IDPF, qui avait pour objet de démontrer entre autres que la distinction entre sites internet, applications natives et livres numériques a de moins en moins de sens aujourd’hui avec la mutualisation des moyens de développement entre ces plateformes. Il pose le constat que le modèle économique de l’application native ne fonctionne pas : elles coûtent trop cher à produire et les modalités de production ne sont pas scalables à l’ensemble du catalogue d’un éditeur qui publie plusieurs centaines ou milliers de titres par an. Il est donc nécessaire de faire évoluer ce mode de travail. Il est probable qu’à l’avenir on se dirige de plus en plus vers un format de contenus structuré qui sera réutilisable dans plusieurs contextes. L’ePub3 est appelé à jouer un rôle dans ce contexte grâce à la conjonction avec HTML5.

La présentation d’HTML5 était effectuée par Robin Berjon qui représentait le W3C (je m’excuse d’avance pour l’inexactitude probable avec laquelle je vais rapporter ses propos…) L’ePub3 était présenté par Daniel Weck du consortium Daisy (un organisme qui travaille sur l’accessibilité du livre numérique) (ses diapos en ePub dans le texte ici.)

HTML5 est plus une galaxie de normes qu’une norme unique. Il y a une centaine de spécifications liées entre elles qui incluent HTML5 proprement dit mais aussi d’autres standards tels que CSS par exemple (pour la mise en forme), Javascript, etc. L’ensemble est désigné sous le terme générique de « the Open Web Platform ».

HTML5 apporte de nouvelles fonctionnalités par rapport au HTML traditionnel :
– support natif de la vidéo et de l’audio : on n’a plus besoin d’installer un plug-in (ex. Flash) pour lire ces médias
– interactivité native grâce à « canvas », une sorte de langage qui permet de coder directement en HTML des applications interactive (jeux, 3D…) de même type que ce qu’on pouvait faire avec Flash
– de nouvelles fonctions de présentation (il semblerait qu’on puisse faire des ligatures grâce à HTML5 et CSS par ex. :-)
– le support natif de Ruby (utile pour les écritures japonaises et chinoises), MathML (pour les équations mathématiques) et SVG (images vectorielles qui permettent par exemple d’agrandir les images sans pixellisation)
l’amélioration des formulaires
– de nombreuses APIs qui permettent notamment d’interagir avec le terminal (dans le cas d’un terminal mobile cela permet de gérer par exemple l’orientation portrait/paysage, de détecter les vibrations, d’interagir avec le micro, la lumière ambiante, etc.)
– une meilleure sémantique de structuration de la page qui permet maintenant de distinguer un en-tête et pied de page, des menus de navigation, etc.

On le voit, toutes ces nouvelles fonctions de HTML5 sont extrêmement pertinentes dans le contexte d’un usage en mobilité et plus spécifiquement dans le contexte du livre numérique enrichi.
Dans la mesure où ePub3 est complètement basé sur HTML5, on dispose nativement de tout l’outillage nécessaire pour ajouter des médias, interagir avec des terminaux de lecture de type eReader / tablette, et structurer le contenu d’une manière cohérente avec les pratiques traditionnelles du livre (en séparant le texte lui-même du paratexte – titres, tables des matières, notes, etc.)

ePub3 est donc basé sur HTML5 mais vient également y ajouter un certain nombre d’éléments :
– l’empaquetage : en plus de l’empaquetage physique (un fichier ePub est en fait une sorte de « zip » qui contient plusieurs fichiers) il s’agit de déclarer toutes les composantes d’un paquet : navigation linéaire, table des matières, liste des pages physiques (permet des renvois depuis les références du livre imprimé)
– le paquet peut aussi contenir des métadonnées et inclure les polices spécifiques dont on a besoin pour la présentation. Cela permet à l’ePub d’être autonome et autodescriptif ;
– l’accessibilité : à l’origine le consortium Daisy travaillait sur son propre format XML pour les personnes en situation de handicap (le XML Daisy). Ils ont décidé de s’impliquer dans la normalisation d’ePub3 pour palier aux défauts d’accessibilité qui étaient ceux d’ePub2. Il est ainsi possible de synthétiser automatiquement une lecture audio à partir du texte en faisant appel à certaines fonctions de CSS (choix du type de voix, ajout d’un fichier de prononciation pour les termes ambigus par ex.)
– un système de liens performants, le système CFI (Canonical Fragment Identification) gère les notes de bas de page – qui deviennent d’ailleurs plutôt des pop-up dans ce contexte – et les tables des matières directement en HTML5 (en ePub2, il y avait un format distinct pour encoder la table des matières. Le fait qu’elle soit un simple fichier HTML permet de la présenter comme une page normale et pas seulement comme un outil de navigation)
– les méthodes de cryptage, de signature et de gestion des DRM.

A titre d’illustration de ces potentialités, un autre intervenant, Peter Meyers, nous a présenté trois exemples de livres numériques qui tirent tout le potentiel du média interactif :
– The good man, une nouvelle interactive
– Welcome to Pinepoint par Paul Shoebridge et Michael Simons (en Flash) qui fonctionne un peu comme un scrapbook multimedia
– Fish, un essai de Robin Sloan conçu pour la lecture sur smartphone.
Il s’agit ici d’inventer de nouvelles modalités d’écriture et de lecture dans un monde numérique.

Luc Audrain d’Hachette a ensuite présenté la problématique de l’industrialisation de la production de livres numériques pour les gros éditeurs.
Il a commencé son exposé en notant que contrairement à une idée reçue, transformer un livre papier en livre numérique n’est pas une opération qu’on fait une fois pour toutes. Au contraire, il faut la répéter plusieurs fois : pour corriger des erreurs, pour prendre en compte des nouvelles versions du format, etc. L’industrialisation de la production est donc d’autant plus une nécessité.

Il nous propose ensuite une grille d’analyse matricielle permettant de différencier les types d’ouvrages en fonction de leur niveau de structuration et de l’importance de la mise en page :
– peu structuré, peu maquetté (ex. romans)
– très structuré, peu maquetté (ex. dictionnaires)
– très structuré, très maquetté (ex. livres de recettes de cuisine)
– peu structuré, très maquetté (ex. livres d’art).
Cette grille permet de faire un choix entre deux stratégies de conversion : les ePub adaptables (dont la mise en page se réorganise en fonction de la taille et du format de l’écran) et les ePub fixés (qui respectent strictement la maquette d’origine).
Le ePub adaptable est très immersif et adapté à la lecture linéaire. Interopérable, il peut être produit à partir d’un flux XML. Cependant, la mise en page est limitée.
Le ePub fixé respecte la maquette du papier ce qui permet des coûts de production très bas. Toutefois, on perd en accessibilité et on ne distribue que sur un nombre limité de plateformes.
Pour Luc Audrain, si on ne fait que du texte, cela ne vaut pas la peine de passer à ePub3 qui n’est pas encore largement supporté, il vaut mieux rester à ePub2.

Plusieurs chaînes sont possibles pour produire les ePub adaptables :
– export ePub direct à partir d’InDesign : nécessite une grande vigilance de base sur la conception du fichier InDesign et de reprendre les ePub à la main ;
– deuxième possibilité, on structure un fichier Word pour obtenir de l’XML. Ce fichier XML est ensuite utilisé pour générer le PDF imprimeur et une version XML du contenu. On stocke l’ensemble dans un système de DAM (Digital Asset Management). L’ePub peut être généré en sortie. Cette chaîne fonctionne si on travaille à partir du fichier remis par l’auteur : pour le rétrospectif, on doit repartir du PDF imprimeur, voir du scan+OCR de la version papier.

Pour l’ePub fixé, on part de la maquette du papier et on produit :
– soit du HTML5+CSS (on crée un cadre dit « viewport » et ensuite on positionne les blocs de texte et d’image en absolu)
– soit une image vectorielle (SVG) ce qui revient au même principe en utilisant une technologie différente. N’importe quel PDF peut être facilement transformé en SVG, mais ce format n’est pas toujours supporté dans les logiciels de lecture d’ePub
– soit par une simple image de type JPG (méthode à l’abandon car fournit une expérience de piètre qualité notamment quand on agrandit l’image). Toutefois il peut être utile d’intégrer l’image dans le HTML5 afin qu’elle puisse servir de présentation alternative si le format n’est pas supporté.

Les contenus fortement structurés sont de plus en plus souvent stockés dans une base de données. Des équipes éditoriales les préparent alors en vue d’en faire des publications : vers du papier, des applications, des sites web, des fichiers ePub. Il existe des outils sur le marché permettant de gérer ce type de chaîne. Les auteurs n’écrivent plus uniquement pour le papier mais produisent des contenus.

Enfin il reste évidemment possible de créer un ePub ex-nihilo. L’outil Bluegriffon par exemple est un éditeur Web wysiwyg pour HTML5 et il permet également de générer des ePub2 et des ePub3.

La dernière étape réside dans le contrôle qualité. Il existe des outils de validation comme ePubcheck pour la structure des fichiers ePub. Il faut ensuite procéder à une validation visuelle grâce à un lecteur d’ePub comme Readium.

Une présentation de Marc Bide, du consortium EDItEUR a permis de rappeler que les métadonnées jouent un rôle encore plus important pour le livre numérique que pour le livre imprimé, car elles sont l’unique moyen de trouver le livre pour l’utilisateur final. Elles sont donc capitales pour la chaîne de distribution, mais aussi pour la bibliothèque personnelle de l’usager : tous les ebooks embarquent un minimum de métadonnées à cette fin. Toutefois celles-ci ne sont pas toujours suffisantes : c’est quand même énervant quand on a tous les livres d’une série d’être obligé de regarder dans wikipédia pour savoir dans quel ordre les lire !

L’ISBN est important pour faire le lien entre l’ouvrage et ses métadonnées. Marc Bide rappelle qu’il est important de fournir des ISBN différents pour la version papier et pour la version numérique. En effet, l’ISBN sert à différencier les éditions et non à les relier. On fournit un ISBN différent pour chaque format entrant (ex. PDF et ePub) ; c’est par contre optionnel si on a différents formats de sortie (ex. ePub et Mobi).

EDItEUR a sorti en 2009 une nouvelle version d’Onix, Onix 3.0, qui est beaucoup plus adaptée au livre numérique que l’ancienne version Onix 2.1. Elle permet entre autres de décrire des contraintes d’usage associées à un livre numérique.

Pour l’IDPF, la problématique majeure aujourd’hui est de faciliter l’adoption de l’ePub3 qui n’est pas encore très largement supporté, et même quand il l’est c’est souvent de manière incomplète.
Le BISG (Book Industry Study Group) maintient un outil qui permet de savoir quelle plateforme supporte ou non quelle fonctionnalité d’ePub3 : le ePub3 support grid.

Pour pallier à cette problématique, les tenants de l’HTML5 et de l’ePub3 encouragent le développement en « fallback design » : c’est-à-dire un design qui s’adapte aux capacités des différentes plateformes.
Il en existe deux sortes :
– « graceful degradation » : le développement est effectué en visant les plateformes les plus performantes, mais si une fonctionnalité n’est pas supportée, des formats alternatifs sont proposés
– « progressive enhancement » : la version présentée par défaut est la plus basique, ensuite on teste en javascript l’environnement de l’utilisateur et on fournit progressivement les contenus plus avancés si la plateforme le permet.

L’IDPF s’implique également dans le développement de Readium, qui est considéré comme le logiciel de lecture d’ePub3 de référence. Le jour du séminaire, l’IDPF annonçait la création de la Readium Foundation, dont l’objectif est de fournir des briques logicielles pour accélérer l’adoption d’ePub3. L’un des moyens utilisés sera la création d’un Readium SDK que les développeurs pourront utiliser pour intégrer les fonctions de Readium dans leurs propres applications.

Et au fait, le LLD XG ?

Publié le par

Il y a quelques mois, j’annonçais ici la naissance d’un groupe au W3C sur les bibliothèques et le Web de données. Depuis, silence radio… et pour cause ! C’est un peu prenant, comme activité. D’ailleurs, ceux d’entre vous qui auraient essayé de suivre via la liste de discussion se seront rendu compte qu’il s’y passe tellement de choses que c’est parfois difficile de suivre. Même pour les membres du groupe, et même pour les co-chairs, alors ;-)

Du coup je me suis dit qu’un petit point d’étape à mi-parcours, et en français dans le texte, ne serait pas inutile. Oui à mi-parcours, on a déjà passé la moitié de l’espérance de vie normale de ce groupe…

Depuis le mois de mai, le groupe se réunit chaque semaine pendant une heure au téléphone. Vous me direz, comment on fait pour tenir une réunion d’une heure, avec en général entre 10 et 20 personnes en ligne, par téléphone et dans une langue étrangère pour la la plupart des membres du groupe ? Et ben, on y arrive grâce à l’infrastructure géniale du W3C (et un peu d’organisation).
Sur le wiki vous trouverez le running agenda, qui contient toutes les actions en cours et les sujets de travail actifs. Chaque semaine, celui qui préside la réunion le met à jour et envoie un sous-ensemble, les points qui seront traités, sur la mailing list.
Pendant la réunion, on est au téléphone et en même temps sur un canal IRC qui permet aux robots du W3C (Zakim et ses amis) de nous rejoindre et de gérer les aspects « logistiques » de la réunion : passer à la parole à ceux qui la demandent, couper les micros qui font trop de bruit, et prendre des notes. Enfin, c’est le scribe (une fonction tournante) qui écrit directement dans le canal IRC tout ce qui se passe : comme ça les minutes sont prêtes, ou presque, dès que la réunion est finie.

Je ne vous recommande pas la lecture des minutes de réunion, qui sont un peu dures à comprendre quand on n’a pas participé, mais il existe une page où sont récapitulés tous les sujets qui ont été traités pendant les réunions, ce qui permet de voir un peu l’avancement du groupe.

En octobre, nous nous sommes rencontrés à Pittsburgh pour le « face to face », seule et unique réunion présentielle dans la vie du groupe. Cette réunion a duré 1 jour et demi, et était elle aussi assistée par Zakim, avec des minutes extensives.
Mais bon, pour que cela soit compréhensible pour le reste du monde, nous avons produit un résumé des résultats de cette réunion.
Principalement, ce que nous avons fait c’est que nous avons regroupé les 42 (et plus) « use cases » que nous avions reçu en plusieurs « paquets » thématiques, les use case clusters, sur lesquels nous travaillons actuellement (voir ci-dessous).
Nous avons aussi travaillé sur la liste des sujets intéressants (« topics ») que nous avions identifié en lançant le groupe, pour essayer d’évaluer ce qui serait faisable dans le groupe d’incubation lui-même, et ce qui devrait faire l’objet de recommandations pour des actions ultérieures.

Depuis, nous bossons dur sur les use case clusters. L’objectif est, en partant de cas réels identifiés dans les use cases, d’essayer de couvrir plus ou moins tout le spectre des problématiques du Web de données en bibliothèque… pas une mince affaire !

Le cluster Bibliographic Data s’intéresse au cœur de cible des données de bibliothèques : la notice bibliographique. Il aborde des sujets tels que l’évolution des modèles et des formats, les problématiques de duplication et d’échanges de notices, et bien sûr, une discussion qui fait rage sur la liste en ce moment : dans un contexte de Web de données, peut-on encore parler de « notice » ?

Le cluster Authority data (la page est encore vide, mais ça va venir ;-), qui porte sur les données d’autorité, touche des problématiques assez différentes. Il fait l’objet d’une discussion pour savoir si quand on parle d’autorités, il est question des « choses » elles-mêmes ou juste des « noms » des choses. En fait, une discussion intensive autour de VIAF sur la liste a conduit à une sorte de consensus sur un modèle qui, à partir d’une notice d’autorité (par ex. une personne), produit un ensemble d’assertions reliées entre elles, dont certaines portent sur la personne en tant qu’entité, et d’autres sur son « label » (sa forme, on dirait en français) et les caractéristiques de cette forme.

Le cluster Vocabulary alignment porte sur l’utilisation de vocabulaires reliés entre eux pour améliorer l’interopérabilité entre des données qui sont décrites suivant des standards différents.
En fait, il s’avère que ce terme de « vocabulaire » était sujet à ambiguïté, ce qui a conduit, là encore, à tout un tas de discussions sur la liste, et débouché sur cette définition, dont nous ne prétendons pas qu’elle est globalement parfaite, mais plutôt qu’elle est suffisamment claire pour servir les besoins de notre groupe, à savoir, produire un rapport à peu près compréhensible pour des bibliothécaires ;-)
Au-delà de ça, il s’agit d’identifier la façon dont l’utilisation des technologies du Web sémantique pour aligner des vocabulaires va permettre d’améliorer l’expérience de l’utilisateur en terme de recherche et de navigation (search and browse). Bien sûr, cela ouvre aussi des perspectives pour améliorer ces vocabulaires eux-mêmes.

Le cluster Archives and heterogeneous data est un ensemble de cas qui touchent à la convergence entre des données au-delà des bibliothèques (archives, musées, etc.) en particulier dans des contextes où on essaye d’agréger ou de fédérer des grosses quantités de données.
C’est celui sur lequel j’ai travaillé donc je ne suis peut-être pas tout à fait objective… Mais à mon avis, son intérêt principal est de faire émerger le besoin, pour ce type de données, d’utiliser ce que les archives appellent le contexte (ou les bibliothèques, les autorités), bref un réseau d’informations sémantiques, pour relier des données qui sont différentes, qui décrivent des ressources différentes, mais qu’on voudrait pouvoir connecter quand même pour offrir une dimension de navigation à l’utilisateur.
Dans ce cluster, on touche aussi à l’intérêt du Linked Data pour des données non bibliographiques et à des fins professionnelles (l’utilisateur est le bibliothécaire ou l’archiviste).

Le cluster Citations travaille sur la notion de référence bibliographique. Après avoir posé une définition à plusieurs niveaux, il s’est attaché à imaginer ce que le Linked Data pourrait apporter comme enrichissements à la notion de citation telle que nous la connaissons actuellement : notamment en permettant l’accès direct à la ressource citée, ou en ajoutant des liens typés permettant d’être plus précis sur la relation entre le document citant et le document cité. La problématique des formats de citation est à rapprocher de celle des données bibliographiques.

Le cluster Digital Objects fait le tour des besoins liés à la publication d’objets numériques en ligne, l’accent étant mis sur la nécessité de pouvoir regrouper des objets, les enrichir, les parcourir et les réutiliser. Derrière la notion de regroupement on retrouve celle de structuration des objets complexes, avec notamment la mention d’OAI-ORE.

Ces 6 clusters étaient ceux qui avaient émergé de la réunion « face to face », mais par la suite nous avons été amenés à en créer deux autres : Collections qui traite des collections de bibliothèques et aussi de la problématique de la localisation des objets physiques, et Social Uses qui vient juste de lancer un appel à contributions.

Voilà, nous en sommes là ! Le travail sur les clusters est en train de se terminer, et je suppose qu’ensuite, nous commencerons à l’intégrer dans l’embryon de ce qui sera notre rapport final.

Petite visite guidée de RDA

Publié le par

Pour ceux qui n’auraient pas encore eu l’occasion de jeter un oeil au RDA Toolkit, voici un petit guide de ce que l’on peut y trouver (NB : j’avais pris ces quelques notes à l’époque où il était encore en accès libre…)

Si on le déroule dans l’ordre (ce qui n’a peut-être pas de sens, vu qu’il y a des liens dans tous les sens, c’est un hypertexte ;-) mais bon il faut bien commencer quelque part), on rencontre d’abord une introduction qui présente les objectifs de RDA, le lien avec les FRBR et autres standards, et une liste des « core elements ».

Viennent ensuite les sections 1 à 4, consacrées à l’enregistrement des attributs des
– manifestations et items,
– œuvres et expressions,
– personnes, familles et organisations,
– et concepts, lieux et événements (cette section n’est pas encore développée sauf pour les lieux).
Dans RDA, les attributs jouent un rôle essentiel puisque ce sont les éléments qui constituent la description elle-même, et donc qui permettent d’identifier les entités. Chaque entité est ainsi décrite avec des « core elements », qui sont plus ou moins obligatoires, et des éléments additionnels qui ne doivent être utilisés que s’ils sont nécessaires pour identifier l’entité.
Pour tout ce qui peut servir de point d’accès, au sens bibliographique du terme (ce par quoi l’utilisateur cherche), donc les œuvres, expressions, personnes etc., on construit également un « point d’accès autorisé » avec un titre ou nom préféré, et des variantes.

Viennent ensuite les sections consacrées aux relations entre entités.
La section 5 est consacrée à l’enregistrement des « relations primaires » c’est-à-dire les relations structurelles entre entités du groupe 1 : Œuvre, Expression, Manifestation et Item. Elles sont supposées être exprimées dans cet ordre, sauf qu’on peut sauter l’Expression si on veut.
Les sections 6 et 7 sont consacrées aux relations entre les entités du groupe 1 et celles des groupes 2 et 3 (celles du groupe 3 ne sont pas encore développées).
Les sections 8, 9 et 10 sont pour les relations internes à chaque groupe d’entité (le groupe 3, vous l’avez deviné, n’est pas encore développé).
L’expression de toutes ces relations fait appel à des « relationships designators » dont les listes sont enregistrées en annexe :
– annexe I pour les relations entre une entité du groupe 1 et une entité du groupe 2 (ce qu’on pourrait appeler les « rôles »);
– annexe J pour les relations internes entre les entités du groupe 1;
– annexe K et L pour les relations internes aux groupes d’entités 2 et 3.

Ces relations constituent une sorte de spécialisation ou d’interprétation de FRBR, au sens où des choix assez radicaux ont été effectués.
Par exemple, s’agissant des « rôles », le « creator » ne s’applique qu’à l’œuvre, alors que l’expression, elle, a un « contributor ». La manifestation peut avoir un publisher, un distributor, et un manufacturer ; quant à l’item, il peut avoir un owner et un custodian.

Les règles elles-mêmes peuvent porter sur les sources d’informations à consulter (même si « take this information from any source » est probablement la phrase qui revient le plus souvent dans RDA, surtout quand il s’agit des œuvres et ce genre de trucs…), et sur la façon de transcrire les informations. Il y a un certain nombre de règles particulières pour les manuscrits, les documents et œuvres audiovisuel(le)s, ou encore les documents électroniques (y compris des informations techniques et des informations sur les restrictions d’accès).

Enfin pour certains éléments, on dispose de référentiels qui permettent de prédéterminer une liste de valeurs à utiliser.
Noter ainsi que le support se décline en trois éléments :
– le type de média, qui indique le type de matériel à utiliser pour accéder au contenu, dans une liste qui inclut « unmediated: Media used to store content designed to be perceived directly through one or more of the human senses without the aid of an intermediating device » (j’adore…)
– le type de support, à préciser pour chaque média (par exemple si le média est « computer », le support peut être « computer disc », computer tape », etc.)
– et enfin l’étendue (? « extent ») qui indique le nombre d’unités (et éventuellement de sous-unités) qui constituent la ressource : par ex. 3 microfiches, 2 computer discs etc.

Au final, après le rapide tour d’horizon de RDA que j’ai effectué, voici quelques impressions personnelles :
– beaucoup de souplesse : les règles ne sont pas très directives ; elles proposent souvent des alternatives, des exceptions, ou laissent la porte ouverte à l’interprétation…
– du flou, parfois : il faut la plupart du temps décortiquer les exemples pour réussir à comprendre où les règles veulent nous emmener…
– et pas mal d’implicite : il faut connaître ses FRBR sur le bout des doigts. Les RDA ne vous donneront pas de clés pour décider comment dépatouiller les cas complexes et limites d’identification des œuvres. Si vous cherchez à déterminer quelle est précisément la relation à utiliser pour raccrocher le dernier livre de bain que vous avez offert à votre tout-petit et qui s’intitule « la petite sirène » à l’œuvre d’Andersen, autant vous le dire tout de suite, la réponse ne se trouve pas dans les RDA.
Bref, les RDA ne sont pas du prêt à consommer. Il me semble qu’il y a un gros travail d’accompagnement et de documentation à effectuer avant de mettre cela entre les mains d’un catalogueur…

Enfin, sachez que même si vous n’avez pas accès au Toolkit dans sa version payante, vous pouvez télécharger tous les schémas qui représentent les différentes entités, leurs attributs et relations, et incluent les principales définitions.

Après Göteborg, Singapour : un cadre pour les Application Profiles

Publié le par

Après avoir entendu parler (ou reparler ?) à plusieurs reprises des « profils d’application » (application profiles ou AP) du Dublin Core, que ce soit dans le LLDXG ou à l’IFLA, j’ai éprouvé le besoin de me replonger dans tout cela. Force est de constater que je ne m’y étais pas intéressée de près depuis plusieurs années, alors que le développement de RDF et du Web de données a conduit le DCMI à revoir complètement son modèle abstrait (le DCAM, Dublin Core Abstract Model) et cette notion d’Application Profile, vers 2007.

Il n’est pas dans mon propos d’entrer dans les détails du DCAM aujourd’hui. Ce modèle est surtout utile en tant que référent pour le vocabulaire un peu particulier utilisé dans le monde Dublin Core.
Plus intéressant, à mon avis, est le Singapore framework for Application Profiles, un autre document du DCMI qui a le statut de « recommended resource » (autrement dit, ce n’est pas un standard, mais il est important quand même).

Ce document, le cadre de Singapour, a été proposé à la conférence DC en 2007 (décidément une année cruciale). Il définit les différents éléments constitutifs d’un Application Profile.
Quand on applique un standard de métadonnées, il existe différents niveaux qui doivent être pris en compte pour favoriser l’interopérabilité : bien sûr il faut respecter la syntaxe, le nom des éléments, la façon adéquate de les utiliser selon qu’ils sont obligatoires ou pas, répétables ou pas, etc. Mais pour aller plus loin, il faut aussi définir précisément les valeurs de ce qu’on met dans ces éléments, et éventuellement la façon de construire ces valeurs.

Je vais faire une comparaison pas du tout triviale avec le monde des bibliothèques.
Nous avons des standards qui sont des formats de métadonnées (MARC par exemple, et ses « différents parfums » comme dirait l’autre).
Nous avons d’autres standards qui sont des règles de catalogage et expliquent comment, à partir d’un document qu’on a entre les mains, on va déterminer quel est le titre, l’auteur principal, l’éditeur, etc. et comment il faut les transcrire dans la notice. Cette deuxième famille de norme comprend AACR2 pour les anglo-saxons, ISBD pour le reste du monde, et RDA pour l’avenir (peut-être).
Nous avons également des standards qui décrivent le modèle sous-jacent de toute cette information et à quoi elle sert : ce sont les FRBR et leurs petits frères FRAD (vient de sortir en français) et FRSAD.
Construire un Application Profile, cela revient à embrasser toute la palette de ces normes pour une communauté définie, et à formaliser le résultat.

Le Singapore framework définit ainsi les éléments suivants comme constitutifs d’un AP :
– les spécifications fonctionnelles (functional requirement ou FR – ça vous rappelle quelque chose ?) et le modèle du domaine : ce sont les représentations abstraites qui définissent l’objectif de notre AP, et elles sont obligatoires ;
– le Description Set Profile, sur lequel je vais revenir dans un instant ;
– et les guides d’utilisation (guidelines) pour le contenu et pour l’encodage, tous deux optionnels. Ce sont les équivalents de nos règles de catalogage mais aussi, guides et outils du catalogueur divers.

Je ne reviens pas sur les modèles et sur les guides.
Le Description Set Profile (DSP) fait l’objet d’un document normatif DCMI encore au stade de « working draft ».
Le DSP est un document XML qui permet de décrire les différentes propriétés qu’on utilise dans notre AP, et jusqu’à un certain point, la façon dont on les utilise.
Le DSP prend complètement acte de RDF, au sens où il ne se restreint absolument pas aux propriétés du DC (voir ici pour un rappel). On peut donc construire un Application Profile en piochant dans les différents vocabulaires qu’on veut, FOAF, DC, etc. du moment que les propriétés qu’on utilise sont identifiées par une URI. Jusqu’ici, on est bien dans l’esprit de RDF.
Le DSP permet aussi de préciser un certain nombre de choses sur la façon dont on utilise ces propriétés. On peut préciser si l’objet doit être une ressource (identifiée par une URI) ou un littéral (une chaîne de caractères), ou si la propriété doit être obligatoirement une sous-propriété d’une propriété plus générique. On peut également définir qu’une propriété est obligatoire ou non, répétable ou non.

Bref, le DSP est conçu pour permettre de « valider » un ensemble de triplets RDF en fonction de règles prédéfinies (on parlerait d’un « pattern » en anglais, et ce sera compliqué à traduire). Le but étant d’obtenir des descriptions, ou si vous voulez des notices, le plus homogènes possibles. Il existe un document du DCMI qui définit les différents niveaux d’interopérabilité que l’on peut atteindre. Le DSP permet d’atteindre un niveau d’interopérabilité optimal !
Cette notion de validation, en réalité, est un non-sens en RDF. Les ontologies ne servent pas à valider les données. Elles se contentent de décrire les choses et leurs qualités, mais elles ne sont pas prescriptives. Ce n’est pas parce qu’il y a une propriété foaf:geekCode que tous les gens qu’on décrit en utilisant foaf sont nécessairement des geeks (ou doivent le devenir ;-) A l’inverse, en RDF, chaque triplet est indépendant ; il n’y a pas de notion de « notice », donc aucun moyen de dire que si on veut décrire une personne, il est obligatoire de mentionner son nom de famille – par ex.
Pour autant, si on veut pouvoir vérifier que certaines règles sont respectées pour produire certains types de données, on aura besoin de ce genre de mécanisme. Cela peut être le Description Set Profile tel qu’il se présente actuellement, mais on pourrait imaginer (et les gens du DCMI y réfléchissent) d’autres formalismes, des schémas XML, des schématrons, ou même des requêtes-type pour exprimer cette notion de validation.

Le Singapore framework for Application Profiles et le Description Set Profile sont donc des documents qui à mon sens méritent toute notre attention, car ils font le pont entre le monde du Linked Data et celui des bibliothèques où tout est encore articulé autour du paradigme de la notice. Il me paraît clair que nous aurons besoin de ce type de formalisme – je ne dis pas celui-là en particulier, mais quelque chose de ce genre – si on veut porter toute la complexité des données des bibliothèques dans le Linked Data. Ou ne serait-ce qu’une partie.

Vacances d’été en RDA

Publié le par

Ah ah, ils sont impayables nos amis du JSC (Joint steering Committee – sous entendu : for the development of RDA).

Souvenez-vous : la dernière fois qu’il a fallu relire les RDA (resource description and access), ce nouveau code de catalogage, c’était presque Noël.

Maintenant qu’il paraît en version définitive, c’est juste avant les deux mois d’été. Et devinez jusqu’à quand vous avez accès gratuitement au RDA toolkit, ce site web qui deviendra le livre (enfin, le site Web) de chevet des bibliothécaires de demain ?

Jusqu’au 31 août.
Alors, pas de risque que les bibliothécaires s’ennuient pendant les vacances.
Et vive l’amitié France RDA !

Un groupe « Bibliothèques et Web de données » au sein du W3C

Publié le par

Le W3C vient d’annoncer le lancement d’un groupe d’incubation « Bibliothèques et Web de données » (Library linked data).
Pour moi, c’est l’aboutissement de plusieurs mois de réflexions, prises de contact, argumentation, maturation, explications, bref pas mal de travail pour aboutir à ce résultat, même si ce n’est qu’un début ! Je suis donc extrêmement heureuse de pouvoir vous en dire plus sur cette initiative.

Pourquoi le W3C ?
Le W3C est le principal organisme de normalisation du Web.
Traditionnellement, les bibliothèques font un important travail de normalisation, soit au sein d’organismes propres à leur communauté (IFLA) soit au sein d’organismes de normalisation traditionnels (ISO, AFNOR). La normalisation est d’ailleurs perçue comme un réel atout de notre communauté.
Aujourd’hui, la tendance est à la recherche de convergence, c’est-à-dire à ne plus faire des normes spécifiques à une communauté, mais des normes valables dans un environnement plus global. S’agissant de technologies de l’information, cet environnement global s’appelle le Web. Il est donc vital que les bibliothèques, aujourd’hui presque totalement absentes de la normalisation au W3C, se mobilisent et se coordonnent pour y participer.
La participation à tous les groupes de normalisation qui travaillent sur des standards potentiellement applicables en bibliothèque est inenvisageable. Ces groupes sont trop nombreux, leur propos est souvent très technique et requerrait de mobiliser fortement les informaticiens des bibliothèques, ce qui est impossible.
L’autre solution était donc de créer une structure, au sein du W3C, correspondant au domaine des bibliothèques, qui leur permettrait de s’exprimer en tant que communauté sur leurs besoins et leurs usages des normes du W3C. C’est le rôle de ce groupe.

Pourquoi un « groupe d’incubation » ?
Un « incubator group » (qui s’abrège en « XG ») a vocation à faire des propositions au W3C sur de nouveaux travaux à démarrer. C’est donc le préalable à toute action plus durable qui pourrait être entreprise au sein du W3C.
Autre avantage, c’est une structure légère à créer : il suffit que 3 organisations membres le soutiennent pour le lancer.
Le Library Linked Data XG va donc travailler pendant un an (jusqu’à fin mai 2011) pour élaborer un rapport dans lequel on trouvera des préconisations pour d’autres actions à conduire sur le plus long terme.

Pourquoi les bibliothèques ?
Du côté des bibliothèques c’était vraiment le bon moment : les formats de demain (RDA notamment) et les projets internationaux majeurs (VIAF par exemple) s’appuient fortement sur les technologies du Web sémantique. Ces actions sont encore expérimentales, jeunes, il est donc temps de les utiliser comme un tremplin pour préparer l’environnement normatif de demain.
Le W3C a été sensible à cette tendance de convergence recherchée par les bibliothèques, et l’intérêt d’un tel groupe n’a fait aucun doute de leur côté.
Cela ne veut pas dire que les autres acteurs « proches », c’est-à-dire principalement du monde patrimonial (archives, musées, etc.) ou de l’édition (éditeurs, libraires…) sont exclus de notre réflexion, bien au contraire. Simplement il fallait se fixer un objectif raisonnable et atteignable, d’où le choix des bibliothèques comme point de départ. Le rapport du groupe devra contenir des recommandations sur les modalités de rapprochement avec ces autres communautés.

Pourquoi le Web de données (Linked Data) ?
Nous avons hésité à focaliser le groupe sur le Web sémantique, mais nous avons finalement préféré le Web de données pour deux raisons.
Déjà, le Web sémantique est un terme dont l’ambiguïté pose problème, même dans les communautés supposées connaître ces technologies. C’est un fait qui est même reconnu au sein du W3C.
Mais surtout, le choix de faire référence au Web de données implique que la problématique du groupe sera l’interopérabilité globale des données de bibliothèques sur le Web, et pas seulement le Web sémantique. Le Web de données inclut la réflexion sur des standards du Web qui ne font pas uniquement partie de la sphère du Web sémantique (comme HTTP ou les URI).
Tout ceci est expliqué dans la charte du groupe.

Qui fera partie de ce groupe ?
Ce groupe a été initié par des acteurs majeurs du monde des bibliothèques, comme la Library of Congress, OCLC, et Talis, et du domaine du Web sémantique comme le DERI, l’Université libre d’Amsterdam, l’Université Aalto à Helsinki, etc.
Tous ces acteurs, ainsi que tous les membres du W3C, peuvent de droit nommer des représentants dans le groupe. De plus, les présidents du groupe peuvent faire appel à des experts invités, même si ceux-ci n’appartiennent pas à une organisation membre du W3C. Le W3C devrait publier bientôt un appel à contributions pour enclencher ce processus de nominations.
Le groupe a trois co-présidents, Tom Baker, Antoine Isaac et moi-même. Nous espérons être rejoints par une vingtaine de participants actifs (qui assisteront aux téléconférences hebdomadaires et rédigeront les documents). Mais la communauté qui va se créer autour du groupe sera beaucoup plus importante : tout le monde pourra suivre la progression de ses travaux, via le wiki et la liste de diffusion publique.

Et maintenant ?
Et maintenant, au travail. Nous avons un an pour faire un bilan de l’état des technologies du Web de données appliquées dans le domaine des bibliothèques, identifier des acquis et des pistes de travail, mettre les acteurs en présence, construire une vision qui fasse l’objet d’un consensus. Je crois que cette année va passer très vite. Si mon blog reste un peu trop silencieux, rendez-vous sur le site du W3C…

Vers l’epub 3.0

Publié le par

Lu dans une dépêche du GFII, l’International Digital Publishing Forum (IDPF pour les intimes) annonce qu’ils vont lancer un travail pour refondre le format « epub », l’un des formats les plus en vogue du « livre numérique ».

(En écrivant cela, je me rends compte que je n’ai encore jamais parlé de livres numériques sur mon blog, ce qui prouve à quel point j’ai laissé se creuser le fossé entre ce que j’absorbe dans ma veille et ce que j’en restitue. Mais bon, tout est là, dans TeXtes… Et puis j’ai pris des bonnes résolutions, comme vous pouvez le constater).

Bref, on peut consulter en ligne le projet de charte du groupe de travail qui va se pencher là-dessus. Il identifie 13 axes d’amélioration pour le format epub :
1. permettre d’embarquer des contenus « riches » (multimédia)
2. meilleur support des langues et des caractères non latins
3. support du niveau « article » pour les journaux et revues
4. support amélioré des métadonnées (ONIX, RDFa)
5. meilleure gestion de la présentation au niveau de la page
6. amélioration de la navigation (table des matières…)
7. alignement avec les standards du Web
8. mécanismes d’annotation
9. représentations mathématiques
10. éléments spécifiques à la structure des livres (glossaires, références)
11. accessibilité (avec DAISY)
12. possibilité d’ajouter des extensions spécifiques à un domaine métier
13. enfin, élaborer une feuille de route pour mettre epub en relation avec les normes officielles au niveau national et international.

Les changements seraient suffisamment importants pour justifier une version « 3.0 » d’epub (tiens, ça manquait de 3.0 ce billet justement ;-) et d’ores et déjà, une convergence avec HTML5 est envisagée.

Si vous pensez que cette liste n’est pas complète, vous avez jusqu’au 20 avril pour répondre à l’appel à commentaires public lancé par l’IDPF.

ISWC 2008 (6) – les enjeux de la normalisation

Publié le par

Si tout le monde s’accorde à dire que la normalisation est une des grandes forces du Web sémantique, celle-ci est loin d’être un long fleuve tranquille. Le « panel » ou table ronde sur OWL 2 en était un bon exemple. J’ai entendu certains se lamenter que le fait de faire étalage des doutes, mésententes et contradictions qui existent dans la communauté autour de l’évolution normative risquait de la discréditer, mais je dois dire que je ne partage pas tout à fait cet avis. De mon point de vue, l’existence de forces contradictoires, voire de lobbys, dans un domaine normatif sont inévitables, sauf à considérer un domaine dont l’envergure est limitée et où le consensus s’impose de lui même. Il n’y a qu’à voir comment cela se passe à l’ISO TC46 où se discutent les normes du domaine de l’information. Bref, si ces normes font débat, c’est que beaucoup de gens s’y intéressent, ce qui est plutôt bon signe.

Après, en ce qui concerne la normalisation d’OWL 2, je ne suis pas sûre d’avoir perçu tous les enjeux mais en gros on peut les résumer comme cela : pour certains (notamment ceux qui ont une approche pragmatique du SemWeb dans l’esprit du Linked data), OWL est un formalisme beaucoup trop complexe et détaillé. Pour d’autres (en particulier les logiciens et tous ceux qui font des recherches sur l’aspect « raisonnement » du SemWeb), il est insuffisant et limité. Dans OWL 2, on propose un système de « profils » qui vont permettre de n’utiliser qu’un sous-ensemble de OWL tout en restant interopérable…. mais ce n’est pas simple de trouver un consensus.
L’enjeu est d’autant plus important que la tendance à l’ubiquité du Web pousse vers une utilisation très large d’OWL pour toutes sortes de besoins, alors que ce formalisme n’a jamais été conçu pour remplacer tous les modes de représentation des connaissances, pour certains prééxistants, qui peuvent être utiles dans leur diversité.

Si cela vous intéresse, je vous invite à lire les notes prises avec exhaustivité ici et l’analyse développée là.

J’ai aussi participé à une intéressante discussion de couloir sur la différence entre Powder et OAI-ORE.
C’est vrai que si on s’en tient à la définition de Powder :

« a mechanism through which structured metadata (« Description Resources ») can be authenticated and applied to groups of Web resources. »

et qu’on la compare à celle d’ORE :

« Open Archives Initiative Object Reusae and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. »

on pourrait se poser des questions.
Alors pour résumer, Powder permet de qualifier en masse des triples en s’appuyant sur des expressions régulières dans les URI. L’assertion Powder porte sur chacun des triples sélectionnés (ex. tous ces triples ont pour langue le français). Au Powder est associé un mécanisme d’authentification qui permet de prouver l’origine des assertions. Powder intègre un protocole qui permet de demander en http des infos sur une seule URI. Usage prévu : par ex., demander la taille et le type de contenu avant d’afficher un site sur un mobile.
Au contraire Oai-ore est basé sur le principe des « named graph » (graphes nommés) c’est à dire que l’assertion associée à un ensemble de triples regroupés dans une « resource map » porte uniquement sur cette « resource map » et pas sur les triples eux-mêmes (voir mon explication d’Ore ici mais c’était pas très clair et il n’était pas encore en version 1.0, il faudrait que je me replonge dedans…) En plus dans Ore il n’y a pas de protocole.
Enfin, si j’ai bien compris, la principale différence entre les deux est que Powder sert à associer des métadonnées à des URIs à posteriori (ce n’est pas le créateur de la ressource qui le fait mais un tiers). Alors que dans Ore, on structure la description de la ressource en fonction des métadonnées qu’on veut lui associer (c’est le créateur de la ressource qui associe les métadonnées). Bon ça n’a l’air de rien, mais ça change tout.
Pardon pour cette petite digression. Donc il s’agit bien de deux choses complètement différentes, et chacun va pouvoir continuer à normaliser tranquillement dans son coin. Au fait, à quand un groupe de travail pour les bibliothèques dans le Web sémantique ?

Ce billet clôt la série ISWC 2008. J’en ai fini avec mon compte-rendu, vous pouvez reprendre une activité normale, c’est-à-dire, si vous êtes un geek, retourner lire d’autres blogs plus intéressants, et si vous êtes un bibliothécaire, c’est fini, tout va bien, vous pouvez revenir ;-)