Archives de Tag: métadonnées

28% de taggeurs

Publié le par

D’après ce rapport du Pew Internet Project sur le tagging, 28% des internautes américains auraient déjà utilisé les "tags" pour caractériser des ressources.

Le profil de ces taggeurs ? plutôt jeunes (moins de 40 ans), hommes et femmes, blancs et noirs… leur principal point commun c’est d’être des « early adopters », amateurs éclairés de technologies nouvelles.

Le rapport contient une interview intéressante dans laquelle sont discutés l’avenir du tagging, ses avantages et ses inconvénients.

Tout cela c’est bien joli, mais aujourd’hui, à mon avis en France on est très loin des 28% en question. La plupart des sites qui proposent des interfaces de tagging, comme del.icio.us ou flickr, n’ont pas encore traduit leurs interfaces en français et ne sont adoptés que par une frange très restreinte des internautes : des blogueurs, des geeks et autres internautes 2.0…
Alors si une bibliothèque veut lancer un tel service, elle se heurte à un mur d’incompréhension général : à quoi ça sert, quelle différence avec le bon vieux « panier » de mon SIGB préféré, etc.

Si on veut que les « tags » entrent dans les bibliothèques en France, il va donc falloir, à mon avis…

  • trouver une traduction valable pour « tag » : en français c’est affreusement connoté, on imagine tous ces jeunes des banlieues avec leurs bombes de peinture
  • mobiliser les utilisateurs : et en priorité ceux qui ont une pratique du web 2.0, donc les jeunes
  • prouver la valeur du service par une adoption massive et la réalisation d’entreprises d’indexation qui auraient été manifestement impossibles autrement.

Alors, est-ce jouable ? l’avenir nous le dira… peut-être…

Ceci est un blog sérieux

Publié le par

A tous les gens qui seraient susceptibles de débarquer ici pour la première fois, suite à un événement impromptu survenu dans ma vraie vie, je voudrais dire que ce blog a beau être rose fluo (j’ai essayé de changer, mais franchement vous seriez déçus) c’est quand même un blog vachement sérieux.

Il y est question de sujets aussi graves que les rapports de la commission européenne sur les droits d’auteurs qui impactent la numérisation, la construction de la bibliothèque numérique du monde, et la préservation des données numériques.

Y sont évoquées des tas de technologies compliquées comme le passage de MARC en RDF, l’impact de l’OAI sur l’interopérabilité, et les services de terminologie.

Ce blog se pose des tas de questions existentielles pour l’avenir de la bibliothéconomie numérique, telles que la modélisation conceptuelle des accès, les entrepôts du Web 2.0, et l’univers des données scientifiques du futur.

Enfin ce blog est truffé de références vers des sites originaux et pertinents, comme la Chronologie d’histoire de l’art du Metropolitan Museum of Art et le moteur BabyGo destiné aux enfants.

En plus, ce blog est vraiment sérieux car il cite ses sources : Resourceshelf et Catalogablog souvent, mais parfois aussi Open Access News et des collègues français comme Affordance. Alors, hein, si c’est pas sérieux tout ça !!! Le seul problème c’est qu’en ce moment je manque de temps pour bloguer aussi sérieusement que je le voudrais… Enfin, il reste toujours les figues ;-)

3 ressources sur les métadonnées

Publié le par

Un bouquin : Metadata and its impact on libraries. A lire le résumé, je ne suis pas sûre d’être d’accord avec tout dans cet ouvrage (notamment la définition des métadonnées…), mais cela semble être une synthèse correcte et assez complète.

Un article dans Dlib : Beneath the Metadata – Some Philosophical Problems with Folksonomy. Après le coup de MARCXML, voilà maintenant qu’ils nous expliquent les différences entre l’indexation bibliothéconomique et le social tagging, et que la première est le Bien et la seconde le Mal… Pourrait-on cesser un peu d’opposer ces deux modèles et de voir le monde en noir et blanc ? Donc je ne suis pas très d’accord avec ça non plus.

Un rapport chez HP : What next for semantic blogging. Celui-ci présente un prototype d’utilisation des blogs pour créer des réseaux sémantiques. Il mélange un peu tout, les microformats, le RSS, le RDF, FOAF… Mais il y a sans doute de bonnes idées. Au moins, il écarte la tarte à la crème 2.0.

Bon c’est pas très glorieux tout ça : la blogosphère est acide et moi avec. J’essayerai de positiver un autre jour.

Merci à Resourceshelf et Catalogablog.

Back to the future

Publié le par

J’en ai à peine cru mes yeux en lisant cet article dans Dlib : Repository Librarian and the Next Crusade – The Search for a Common Standard for Digital Repository Metadata. Ecrit par des gens du LANL, il défend une théorie époustouflante : MARCXML serait le meilleur format de métadonnées possible pour des entrepôts numériques…

C’est très étonnant car comme ils le disent eux mêmes :

Au début, MARC et MARCXML étaient perçus comme trop bibliocentriques et trop rigides. L’équipe était également préoccupée par la viabilité et le manque de popularité de ce format dans la communauté. (…) Le grand nombre de combinaisons d’étiquettes/indicateurs/sous-champs pouvaient suggérer que la complexité de ce standard serait problématique.

Ensuite ils mettent leur priorité sur 3 fonctionnalités du format : granularité, transparence, extensibilité. Là encore, on se sent assez loin de MARC et même de MARCXML. Mais c’est là que l’effet pervers des tableaux de comparaison de fonctionnalités fait son office et montre qu’on peut leur faire dire tout ce que l’on veut.

En comparant MARCXML à ONIX et PRISM (rapidement écartés) et également Dublin Core et MODS, en se limitant à des métadonnées descriptives et aux sujets les plus complexes, on réussit à "prouver" que MARCXML est meilleur que tous ses petits copains.

D’où la conclusion :

Utilisé dans le monde entier et supporté par de nombreux outils, MARC est omniprésent dans la communauté des bibliothèques (…)

Et d’autres vérités du même acabit. Nous voici en plein retour vers le futur : le format de métadonnées le plus prometteur pour l’avenir serait un format particulièrement vieilli, compliqué, rigide, non lisible par des humains (sauf s’ils ont suivi des cours de bibliothéconomie auquel cas on peut se demander s’ils sont vraiment toujours humains ;-) et limité à la communauté des bibliothèques. Et extensible pourvu qu’on tolère d’en arriver à ça :

administration metadata

Cela me fait hurler… Amis spécialistes de XML, du Web sémantique et des métadonnées, je vous en prie, dîtes-moi ce que vous en pensez : serais-je déjà encore en retard (ou en avance) sur mon temps ?

Le bon grain de l’ivraie

Publié le par

Chiche que j’aborde un sujet dont tout le monde parle : les folksonomies.

Avec les folksonomies en général, et le tagging en particulier, ce qui fait le plus peur aux bibliothécaires, c’est le problème de la qualité. Olivier Le Deuff dans son article décrit bien les problèmes que l’on rencontre en confiant à des utilisateurs inexpérimentés le soin d’indexer des documents.

Je vous suggère de voir comment Google aborde le problème. Un double problème, en fait :

  • on ne sait pas indexer des images et on n’a pas les ressources pour le faire,
  • les utilisateurs peuvent le faire mais ils sont stupides.

Comment contrôler le travail d’utilisateurs incompétents ? Il suffit de les pousser sur la pente glissante qui les entraîne vers le bas.

Pour preuve, ce nouveau service : Google image labeler.

Pour motiver sa communauté d’utilisateurs, Google présente le taguing sous forme de jeu : vous avez un partenaire tiré au hasard et un peu moins d’1 minute pour taguer un maximum d’images. Pour qu’une image soit taguée, il faut que vous et votre partenaire inconnu saisissiez le même tag. A chaque image taguée, vous gagnez 100 points.

Qu’est-ce qu’on gagne ? Rien, mais la rapidité et l’émulation rendent le jeu prenant et il est difficile de s’arrêter. Du coup, les utilisateurs vont taguer plein d’images, et avec des tags supposés plus pertinents puisque deux utilisateurs les ont choisis en même temps.

C’est très malin, mais à mon avis pas très efficace. En effet, on est plus tenté de « gagner » que d’être utile et efficace, donc au lieu de réfléchir à ce qui décrirait le mieux l’image, on essaye d’imaginer ce que le partenaire va trouver. Au final on aura plein d’images taggées « red », « people », « man », « map » ou « building ». Je ne sais pas si ça aidera beaucoup, mais Google nous le dira.

A part ça, chez Panlibus ils pensent aussi que Google abuse d’utiliser un nouveau terme, "label", alors que le monde entier dit "tag". Franchement.

Confiture bibliothéconomique

Publié le par

Allez, maintenant que j’ai un peu retrouvé la forme, il faut bien élaguer un peu le résidu des vacances. Confiturons.

Merci à toujours les mêmes (Catalogablog, 10KYBlog, etc. j’ai la flemme de mettre les liens.)

MPEG21 DIDL, en détail (3e partie)

Publié le par

Après avoir évoqué MPEG21, et quelques généralités sur MPEG21 DIDL, entrons maintenant dans le vif du sujet, en nous intéressant au modèle de données de la Déclaration d’objet numérique.

Je parlais de quatre « niveaux », il s’agit en fait bien sûr d' »entités », et il y en a bien plus de quatre. Pour que ce soit plus clair, je propose de les regrouper par fonction.

D’abord, il y a les entités de structure. Ce sont les quatre que j’ai citées : container – item – component – resource. J’y ajouterai également anchor et fragment, vous allez voir pourquoi.
Item est l’entité centrale du modèle, puisque c’est celle qui correspond au Digital Item c’est-à-dire au niveau qu’on envisage de manipuler.
Container est, comme son nom l’indique, un conteneur. Il peut contenir d’autres conteneurs et/ou un ou plusieurs items, mais il ne peut pas exister s’il n’y a pas d‘item dedans. Le conteneur est en principe constitué de manière logique (pour rassembler des items) et il est optionnel.
Les items sont constitués de components qui eux-mêmes contiennent des resources. Un composant ne peut exister sans un item. Il contient la resource et ses métadonnées associées, métadonnées qui ne doivent pas être descriptives à ce niveau (uniquement techniques ou assimilé). Les resources sont des objets numériques physiques qui disposent d’une adresse pérenne.
Enfin anchor et fragment servent à pointer sur une partie à l’intérieur d’une ressource.

Les entités de description sont les deuxièmes plus importantes du modèles, surtout descriptor. Celui-ci est une enveloppe de métadonnées qui peut être associée à un item, un component ou une ressource.
Dans ce descriptor on trouve un statement qui correspond à l’énoncé de l’information.
A ce stade, le modèle n’est pas très directif sur la façon d’utiliser ces enveloppes de métadonnées. On sait juste, comme dit plus haut, qu’il vaut mieux mettre le descriptif au niveau de l‘item et le technique au niveau des ressources.
On peut rajouter ici annotation, qui est une information sur une entité dont la particularité est de ne pas avoir d’impact sur ladite entité.

Après, il y a les entités de choix et là excusez moi, mais je ne vais pas m’étendre car c’est terriblement compliqué. En gros on peut rendre un item conditionnel en fonction de conditions et de prédicats, auxquels on attribue des sélections et des assertions.
Ce genre de trucs doit permettre de gérer des droits d’accès ou de faire de la négociation de contenu. Cela ne m’intéresse pas vraiment ici.

Pour finir, on va donc combiner ces différents éléments pour obtenir la Déclaration complète. C’est ce qui est exprimé dans la figure ci-dessus (cliquer pour agrandir). Les containers contiennent des items, qui eux-mêmes contiennent un ou plusieurs components, qui eux-mêmes contiennent une ou plusieurs ressources. Les métadonnées sont accrochées à deux niveaux : celui de l‘item et celui du component.
Cette méthode permet d’exprimer des granularités et des structures d’objets. Celles-ci sont entremêlées avec leurs descriptions, contrairement à METS qui sépare les métadonnées et l’organisation des ressources.
A mon humble avis, un tel modèle paraît assez satisfaisant conceptuellement, mais soulève de grosses difficultés d’implémentation. Je ne sais pas si j’irai jusqu’à parler de ça, parce que la semaine prochaine je suis en vacances :-)

Source : la norme partie 2 – DID (attention fichier PDF zippé)

Introduction à MPEG21 (1e partie)

Publié le par

L’adepte de METS que je suis (et je fais sans arrêt des émules) a enfin décidé, par honnêteté intellectuelle, de s’intéresser un peu aux autres formats qui remplissent la même fonction, à savoir décrire tous les aspects d’un objet numérique complexe. J’ai donc commencé à regarder MPEG21 DIDL. Je débute, alors si vous avez des précisions, des corrections ou des remarques, n’hésitez pas.

Avant de s’intéresser à MPEG21 DIDL, un petit aperçu de ce qu’est MPEG21 ne peut pas faire de mal. Alors allons-y, en avant, vers l’infini et au-delà !

MPEG21 est un cadre (framework) de représentation des objets numériques basé sur un ensemble de modules indépendants. Normalisé par l’ISO sous le charmant petit nom de ISO/IEC 21000, ce cadre comprend à l’heure actuelle les parties suivantes :

  • 1 – Vision, Technologies and Strategy
  • 2 – Digital Item Declaration (oui, oui, c’est celui-là qui nous intéresse)
  • 3 – Digital Item Identification (oh ! des identifiants !)
  • 5 – Rights Expression Language (oh ! des droits !)
  • 6 – Rights Data Dictionary (oh ! encore des droits !)
  • 7 – Digital Item adaptation
  • 8 – Reference software
  • 9 – File format
  • 10 – Digital Object processing
  • 11 – Evaluation Tools for Persistent Association Technologies (Technical Report)
  • 12 – Test Bed for MPEG-21 Resource Delivery (Technical Report)
  • 15 – Event Reporting
  • 16 – Binary Format

Non, je ne yoyote pas complètement, j’ai sauté des numéros mais c’est exprès. Sont en cours d’élaboration :

  • 4 – Intellectual Property Management and Protection Components
  • 14 – Conformance Testing

La partie 13 (scalable video coding) semble avoir été abandonnée.

Certaines de ces parties sont publiques et on peut les télécharger sur le site de l’ISO. Ce sont les parties 1 et 2 (ça tombe bien, la notre est dedans). Les autres peuvent être acquises auprès de l’ISO pour une modique somme comprise généralement entre 50 et 150 euros par partie, et c’est pourquoi je n’en parlerai pas dans le détail.

Toutefois, si on regarde rapidement tous ces morceaux, en particulier tels qu’ils sont décrits dans la Partie 1 (« vision etc. »), on peut quand même faire quelques observations dans les grandes lignes :

  • MPEG21 a pour objectif de donner le cadre d’un bon niveau d’interopérabilité dans la diffusion de documents multimédias. Ca inclut même une réflexion sur les types de terminaux (PC, mobile etc.), sur la différence entre une bande-annonce et un film en haute résolution… ça va assez loin.
  • logiquement, suite au point précédent, MPEG21 s’intéresse beaucoup aux droits : déclaration de droits, référentiel de droits… Malheureusement, la partie qui serait la plus intéressante, la normalisation de la gestion des droits elle-même, des DRM si vous voulez, n’est pas finie;
  • MPEG21 s’intéresse aussi pas mal aux questions techniques, avec une partie sur les logiciels de référence et une sur les formats de fichier ; au-delà des besoins immédiats (faire fonctionner correctement des formats complexes sur des plateformes appropriées), on devine qu’en terme de gestion conforme à l’OAIS sur le long terme, cela pourrait être intéressant.

La notion de Digital Item est au centre de la norme ; il s’agit de définir l’élément qui doit être géré, manipulé, décrit, échangé, etc au sein de tout système où des gens (users) entrent en interaction avec des objets numériques. Le Digital Item est donc un niveau de granularité préférentiel.
En pratique, un Digital Item se compose de trois ingrédients :

  • des ressources (c’est-à-dire, des fichiers numériques)
  • des métadonnées
  • une structure.

C’est pour décrire toutes ces choses de manière formelle qu’on a créé le DID et le DIDL. La Déclaration d’Objet Numérique (DID) est une description d’un objet à travers ces trois composantes. Elle est représentée sous la forme d’un fichier XML, grâce à DIDL. Ce qui confirme une intuition que j’avais au départ : tout cela n’a rien à voir avec les souris !

A suivre…

Source : MPEG21 part 1 (fichier PDF zippé).

Introduction à MPEG21 : DIDL, en gros (2e partie)

Publié le par

Après avoir étudié la place de DIDL dans MPEG21, nous allons pouvoir nous intéresser à la partie 2 de MPEG21 : la Déclaration d’objet numérique (DID).

Cette déclaration se compose de trois parties :

  • le modèle (DID, en conceptuel)
  • la représentation (DIDL, expliqué de façon pratique, élément par élément)
  • le schéma (le schéma XML de DIDL lui-même).

Avant d’entrer dans le détail, je voudrais énoncer quelques caractéristiques de MPEG21 DIDL (par rapport à METS – pour un update rapide sur METS voir là et là):

  • Il dispose d’un modèle de données abstrait. Ca veut dire qu’ils ont modélisé avant d’implémenter, ce qui est plutôt rassurant à priori. Ca veut aussi dire qu’il sera plus facile de changer la méthode de représentation du modèle si nécessaire (par exemple pour passer de XML à RDF). Pour l’instant, le modèle abstrait s’exprime sous la forme d’un schéma XML ; c’est ce schéma qui s’appelle DIDL.
  • Il ne propose pas une carte de structure pour décrire un objet, la structure est inhérente au fichier de métadonnées. En fait, le modèle décrit 4 niveaux : container – item – component – resource, et à chacun on peut associer des métadonnées (descriptor). Ces niveaux peuvent tous être combinés et imbriqués. La façon dont on imbrique ces niveaux correspond à la carte de structure.
  • Il met l’accent sur des machins qui sont particulièrement utiles dans le domaine de l’industrie multimedia (pour laquelle il a été conçu) : la gestion des droits et l’association d’exécutables. Pour cela, il peut utiliser d’autres modules définis dans MPEG21, comme REL.
  • Il définit un système d’identifiants complexe, qui est lui-même un module de MPEG21 nommé DII. Ces identifiants permettent notamment de faire des liens entre les métadonnées et les entités d’une instance DIDL, mais pas seulement. Alors que dans METS, l’identification des différentes parties est souple bien qu’obligatoire, ici elle est plus précisément définie. Ce mécanisme est explicitement destiné à reexploiter les identifiants de l’industrie de l’audiovisuel (ISRC, ISMN pour ceux à qui ça parle).

Quand même, quelques points communs avec METS :

  • On peut mettre les ressources dans DIDL « par valeur » ou « par référence », c’est à dire soit directement dans les métadonnées en XML ou en base 64, soit sous forme d’un lien vers un objet qui est stocké ailleurs.
  • Les métadonnées ça ne se fait pas tout seul ; il faut compléter le modèle avec des schémas de métadonnées spécifiques. Ceux qui existent sous forme de modules de MPEG21 sont prévus. Ceux qu’on voudrait ajouter en plus, on peut le faire en utilisant les espaces de nom.

Dans le monde des bibliothèques numériques, les principaux adeptes de MPEG21 DIDL sont Herbert Van de Sompel et ses amis du LANL. Ils se sont amusés à le rendre OAIS compliant et pour cela, ils ont un peu plié le modèle… en particulier pour la partie qui concerne l’association d’exécutables.
Ils ont notamment rajouté un moyen d’exprimer des relations en RDF dans les métadonnées descriptor, de façon à ce qu’on sache précisément ce qui est une partie de quoi (isPartOf) ou encore ce qui décrit quoi (isMetadataOf).

Voilà pour DIDL en gros. Si vous vouliez juste une vue d’ensemble, cela devrait suffire ; si vous voulez en savoir plus, je vous propose de continuer avec moi et étudier DIDL en détail, dans un autre billet.

Mes principales sources pour ce billet :