Archives de Tag: identifiants

Dernier billet

Publié le par

Ceci est mon dernier billet.

Avant une semaine parce que là, je pars en vacances. (Quoi, comment ça on est plus le 1er avril ?) J’ai l’impression que ça a passé super vite depuis les dernières.

J’espère que quand je reviendrai ce sera le printemps, il fera beau, il y aura un paquet de figues sur mon bureau (ah non, ce voeu là est déjà réalisé … Merci l’Inconnu !) et plein de beaux sujets bibliothéconomiques et numériques à partager ensemble.

En attendant, je vous laisse avec cette excellente citation de Lorcan Dempsey :

L’URL est la monnaie du Web. Pour que quelque chose puisse être référencé, évoqué ou partagé dans le contexte du Web, il faut avoir une URL.

Il disait cela au sujet de Wikipedia, expliquant qu’un des succès de cette encyclopédie réside dans le fait qu’elle est une base de connaissance « adressable ». Citable. Et tant pis pour les problèmes d' »autorité ».

NISO et les identifiants

Publié le par

Dans Newsline la lettre d’information du NISO (agence de normalisation américaine), on trouve ce mois-ci un rapport sur les identifiants. Celui-ci est le fruit d’un workshop qui s’est tenu le mois dernier à la National Library of Medecine.

Il y a plein d’informations sur la compréhension qu’on peut avoir aujourd’hui du rôle des identifiants pérennes, sur le Web et ailleurs, et quelques pistes sur ce qu’il serait intéressant de normaliser dans ce domaine.

Je vous le recommande chaudement.

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 :

Retour sur les identifiants

Publié le par

Les identifiants pérennes, mes chers identifiants, semblent revenir un peu à la mode ces derniers temps – peut-être une impression due au fait que j’ai eu l’occasion de m’y replonger profondément.

Ainsi en réécoutant les interventions du DDC workshop de juin sur ce thème, j’ai pu constater que pas mal de chemin a été fait dans la réflexion sur les identifiants et que la polémique a encore de beaux jours devant elle. Des anciennes croyances ont été pulvérisées, et de nouvelles créées.

(NB : attention la plupart des liens qui suivent pointent vers des fichiers powerpoint.)

Je dirais que la première révélation de ce workshop, c’est que la pérennité des identifiants n’a rien de technique. Il a été affirmé, répété et même proclamé haut et fort qu’aucun schème d’identifiants, qu’il s’agisse de DOI, Handle, ARK, PURL ou n’importe quoi d’autre, n’aide en quoi que ce soit à la pérennité. La pérennité n’est pas une question technique, c’est une question organisationnelle et institutionnelle, ainsi qu’une question de modèle économique et de financement. Donc si votre principal problème était de savoir quel schème choisir, faites d’emblée un trait sur la pérennité comme critère.

Face à cette assertion très généralement admise, plusieurs positions apparaissent.
Il y a ceux qui ne veulent pas mettre tous leurs oeufs dans le même panier, et vont s’enregistrer dans plusieurs schèmes afin de multiplier les points d’entrée.
Il y a ceux qui pensent que la solution réside dans la normalisation, et ceux qui espèrent que l’ouverture de l’enregistrement des "URI schemes" va permettre de trouver des solutions innovantes.
Il y a ceux qui pensent qu’il faut arrêter de diaboliser les URL, que ce n’est plus vrai de nos jours de dire que les URL sont des localisations, et qu’avec HTTP et les URI, on a un super système qui marche d’enfer et que pourquoi diable irait-on en changer.

Dans les autres questions de fonds qui ont été soulevées sur les identifiants pérennes des ressources numériques, je retiendrai celle de savoir ce qu’on entend par identifiant, ce qu’on entend par pérenne, et ce qu’on entend par ressource (tout le monde est d’accord sur "numérique").
Pour prendre un exemple, un identifiant comme http://www.lemonde.fr/ est tout à fait stable en terme d’URL. Pourtant son contenu change tous les jours, voire plus. Peut-on parler d’identifiant pérenne ?
Une distinction intéressante a été faite entre des ressources « abstraites », éventuellement mouvantes, et des ressources « concrètes », stables et uniques, les deux ayant besoin d’être identifiées.

Concernant la résolution, on a soulevé la question des identifiants qu’on ne voudrait pas résoudre (lire : relier à une ressource donnée dans une forme donnée), ou en tout cas pas résoudre de la façon dont on les résoud aujourd’hui.
La question de la maintenance du lien entre l’identifiant et la ressource, et même plus encore entre l’identifiant et les métadonnées, est récurrente et non résolue.

Enfin quant à la pérennité, l’idée a été affirmée que cela ne signifie pas « pour l’éternité », mais « pour suffisamment longtemps » au regard de l’intérêt de la ressource, des missions de l’institution, de l’évolution de la technologie, etc.

Et heureusement, parce que comme dirait l’autre, l’éternité c’est long, surtout vers la fin.

Encore des numéros

Publié le par

Parce que les URIs, les ISSN, les ISBN et autres ne suffisent pas, des gens ont décidé de créer encore des numéros :

  • les ESBN pour les monographies électroniques,
  • les IBSN pour les blogs.

Le premier s’annonce comme un "DRM & copyright solution" et il est à peu près impossible, comme le remarque Catalogablog, de savoir qui est réellement derrière cette idée. Ce qui n’a pas empêché notre ami David Bigwood d’en prendre un… puisque c’est gratuit.

Le second semble émaner d’une frustration de la part de blogueurs espagnols qui n’ont pas réussi à obtenir un ISBN, et dispose d’un mode d’attribution assez original puisqu’on choisit soi-même son numéro, pourvu qu’il ne soit pas déjà attribué. L’IBSN commence à faire des émules sur quelques blogs francophones : Zaphir et Doc en Vrac.

On pourra lire ici quelques réflexions sur l’idée originale que 2006 sera l’année des identifiants uniques. C’est pas pire que celle du Web 2.0… ou d’autre chose…

Pour ma part, je vais me contenter de mes URLs et m’arranger pour qu’elles ne changent pas.

Mise à jour :

Belle synchronisation involontaire avec Vagabondages.

Des identifiants gentils avec les gens

Publié le par

J’en ai déjà parlé avec Coins, mais j’y reviens car le principe devient un peu plus clair dans ma tête. Il s’agit de rendre des identifiants (pérennes) actionnables à l’aide d’un agent, user agent disent-ils en anglais, et de HTML.

Voici le problème : en général, les identifiants pérennes ont l’avantage de transporter plein d’informations utiles avec eux, ou de sous-entendre cette information. Un Purl est un lien pérenne pour lequel on a enregistré dans une base sa correspondance avec la localisation réelle du document.
L’inconvénient de ce type d’identifiants, c’est qu’ils ne sont pas gentils-avec-les-gens (user-friendly). Ils ne s’affichent pas dans la barre d’URL du navigateur. La plupart du temps, on clique dessus sans même savoir qu’ils sont pérennes en fait.

Certains ont donc eu l’idée de développer des outils qui vont se comporter comme des grands, et savoir "quoi faire" quand ils sont confrontés à de tels liens.
C’est le cas de cette extension Firefox qui permet de reconnaître la présence l’un Purl sur une page Web et de faire en sorte que le Purl soit bookmarké à la place de l’adresse normale de la page.
Malheureusement elle ne fonctionne qu’avec Firefox 1.0, alors comme je suis passée à 1.5 j’ai pas eu la joie de la tester. C’est dommage il faudrait qu’ils remettent à jour.
Pour que cela puisse marcher, cependant, il faut encoder correctement les liens, à savoir leur ajouter une métadonnée : link rel=’purl’ href= »http://purl.org/net/linkpurl » dans l’en-tête de la page. C’est ce qui permet au « user agent », ici une extension Firefox, mais ce pourrait être un bookmarklet par exemple, de savoir que la page a un Purl et qu’il doit le prendre en compte.

C’est le même principe avec Coins. Un lien OpenUrl est comme une valise dans laquelle on transporte des métadonnées pour aller d’un endroit (la référence bibliographique) à un autre (le texte). L’idée est d’encoder ce lien en HTML, de façon à ce qu’un « user agent », comme le bookmarklet d’openWorldcat que je signalais, le reconnaisse et fasse ce qu’il a à faire, dans ce cas créer un lien vers WorldCat.

Donc on a un site où on code des informations particulières, invisibles pour les gens, pour procéder à certaines actions. L’utilisateur se munit des « user agents » qui lui conviennent et les actionne au cours de sa navigation. Les agents en question actionnent alors d’autres services pour lui.

J’espère que c’est un peu plus clair… (en fait non, mais c’est pas grave, j’y arriverai un jour).

Deux autres ressources sur les identifiants, juste comme ça en passant :

Agrégateur en panne

Publié le par

Depuis vendredi, il nous arrive un truc vachement bizarre et pour tout dire horrible : on n’a plus accès à Bloglines (ni à aucun service de Askjeeves) chez nous. Un problème de routage ou je sais pas quoi, enfin, un problème de Web qui est cassé.
Conséquence directe : je n’ai pas accès à mes fils et encore moins à mes « clippings », ces trucs qu’on peut mettre de côté dans mon agrégateur préféré. Donc pas de veille, donc pas de billet, et en particulier pas de confiture de liens.

Pour me faire pardonner, je poste une autre photo d’un truc que j’ai fait. Lequel est une pâle et imparfaite copie de ça qui est au Louvre. Au fait vous me direz je pourrais mettre un lien vers le Louvre mais qui a envie de mettre un lien pareil sur son blog. Vos identifiants pérennes, les gars !!!

En attendant je me suis rabattue sur litefeeds qui récupère automatiquement les souscriptions de Bloglines, mais c’est pas vraiment génial. Donc si quelqu’un a une idée d’agrégateur en ligne super bien avec import OPML et qui marche, merci de me passer le tuyau !!!

Confiture de « pff j’ai pas eu le temps de bloguer cette semaine »

Publié le par

J’ai lu un article très intéressant d’Alain Giffard sur les bibliothèques numériques en général et celle de Google en particulier.

Des gens ont parlé d’identifiants pérennes : sur catalogablog et chez Lorcan Dempsey.

Ca a bougé côté DLF : au sujet du DLF Framework qui a pour objectif de modéliser l’activité des bibliothèques si je comprends ce qu’en dit Lorcan, avec la publication des présentations d’une conférence intitulée Managing Digital Assets, et aussi avec la publication d’un document à réviser sur l’utilisation de MODS pour le patrimoine (via Digitization Blog celui-là).

Ca a bougé côté OCLC : avec la publication du rapport annuel 2005, et celle d’un autre rapport intitulé Perceptions of Libraries and Information Resources, sur les usages et les pratiques, et qui s’inscrit en continuité du 2003 OCLC Environmental Scan: Pattern Recognition vraiment à lire si vous ne l’aviez pas fait à l’époque.

Moi, pendant ce temps, j’étais occupée à aller au ciné, faire une conférence, et rencontrer des vrais gens dans la vraie vie. C’était bien aussi.

Voitures et identifiants pérennes

Publié le par

Je me disais il y a peu que si on considère les différents systèmes de nommage unique et pérenne que l’on fréquente dans la vraie vie (lire : pas sur le Web), un des plus impressionnants est l’immatriculation des voitures.

Actif depuis plus de cinquante ans, ce système a bien des avantages : son extensibilité (passage de deux lettre à trois), sa citabilité (facile à retenir). Pourtant, ce système a vécu et on nous annonce qu’on va en changer. Petite analyse.

Dans l’ancien système, on combinait un élément signifiant (le département) avec un préfixe non signifiant composé de deux ou trois lettres, et une numérotation incrémentale à quatre chiffres. Il y a donc plusieurs autorités nommantes : les préfectures, ce qui a pour conséquence de lier l’identification à un lieu. Si la ressource (pardon, la voiture) change de propriétaire mais pas de lieu, elle garde son identifiant. Si elle change de lieu (même avec le même propriétaire) elle change d’identifiant.
Ces identifiants basés sur les lieux ou les adresses, ça vous rappelle rien ? Les URL par exemple… Qui n’est jamais tombé sur une erreur 404 (cette voiture a déménagé) ou pire, en suivant un lien qu’il avait duement enregistré dans ses favoris, sur un site porno (cette voiture a changé de propriétaire).
Dans le cas d’un changement d’identifiant, seules les métadonnées (les archives de la préfecture) permettent de tracer le changement et de retrouver la ressource-voiture.

Dans le nouveau système, le nommage est composé de trois séries de caractères non signifiants : deux lettres, trois chiffres, deux lettres. Le nommage est incrémental et centralisé : une seule autorité nommante, qui attribue les identifiants dans l’ordre, de AA 11 AA à ZZ 999 ZZ.
L’identifiant reste attaché à la ressource-voiture quel que soit l’emplacement-adresse de celle-ci : ce n’est plus une URL mais une URI.

Le nouveau système vise à la fois à simplifier les démarches administratives des automobilistes (plus de changements de plaques en cas de session des véhicules), à alléger la gestion du système pour l’administration et à lutter contre la délinquance automobile en améliorant l’efficacité des contrôles grâce à une «meilleure traçabilité»

A voir. On passe d’un système semi hiérarchique réparti à un système hypercentralisé et hypercontrôlé (quoi, ça vous surprend ? Qui a eu cette idée d’abord ?). Un seul système, ça veut dire aussi que si le système tombe, on n’a plus rien. Complètement non signifiant, ça veut dire moins citable (Police ! Arrêtez cette voiture !) encore que le limiter à 7 caractères est de ce point de vue une bonne initiative. Par contre quand on sera au bout de cette attribution dans l’ordre, que fera-t-on (si les voitures n’ont pas encore eu définitivement raison de la planète d’ici là) ? Dernière question, comment se fera la transition d’un système à l’autre et la récupération des anciens identifiants ?

Enfin on est bien dans un système centralisé à la française, si on considère que chez nos amis anglais on peut faire immatriculer sa voiture à ses initales si on a envie (le libéralisme, toujours lui). Mais à ma connaissance, à part ça, nous serions le premier pays européen à abandonner le nommage basé sur des lieux ? Non ?

Quand même, un avantage : on ne se fera plus traiter de sales parigots quand on ira en vacances à Marseille !

Ce billet est spécialement dédicacé à Thierry Stoehr …

PURL + OAI = POI

Publié le par

Les identifiants pérennes, retour de la vengeance.

Je viens de découvrir, via Catalogablog lui même via Lorcan Dempsey un système d’identifiants pérenne que je ne connaissais pas mais qui en combine deux que je connaissais :

Le système s’appelle POI pour PURL-based Object Identifier.

Les particularités de ce système : on n’a pas besoin d’enregistrer les POI pour chaque ressource, il suffit d’avoir un entrepôt OAI dans lequel les ressources ont des identifiants. On peut ensuite transformer de manière implicite les identifiants OAI en identifiants POI de la manière suivante :

un document qui porte l’identifiant :

oai:mon-nom-de-domaine.org:123456

a l’identifiant POI suivant :

http://purl.org/poi/mon-nom-de-domaine.org/1233456

Evidemment la conséquence de cette petite transformation est que le nouvel identifiant POI est compréhensible par un navigateur grâce au protocole HTTP. Et ensuite on utilise le résolveur PURL pour résoudre les POI et pointer vers les ressources elles-mêmes.