Le W3C se penche depuis belle lurette sur l’identification pérenne des ressources numériques (dont vous devez avoir sacrément marre d’entendre parler ici à force, mais tant pis).

Il y a eu d’abord les URI (identifiants de ressources), puis les URN(noms de ressources), tous deux dès 1994.

Les URL (localisation de ressources) arrivent après, aussi bizarre que cela puisse paraître pour nous (mais du point de vue modélisation, c’est logique). Le fameux Cool URIs don’t change, document fondateur de la question de la pérennité de l’identification des ressources sur le Web, date de 1998.

Passé le tournant du siècle, on entre dans le Web sémantique et de nouveaux besoins apparaissent en termes d’identification : identifier des choses abstraites, des choses qui ne sont pas nécessairement des pages Web, et qu’elles puissent être identifiées par n’importe qui de façon unique sur le Web. Ces nouvelles réflexions donnent naissance au scheme "tag", une syntaxe simple pour permettre à n’importe qui de nommer de manière pérenne et unique une ressource (ou une personne, un concept quelconque). Les "tag URIs" ont une syntaxe simple qui permet à tout un chacun de générer des identifiants uniques :

tag:mon-nom-de-domaine.org,2005-03-01:nom

Ce genre d’identifiants est utilisé par exemple pour identifier les billets de blogs dans le format Atom.

En ce début d’année 2005, le W3C publie deux nouveaux documents :

• l’un qui est une nouvelle version des URIs
• l’autre qui concerne les IRIs (identifiants internationaux), qui ont l’air d’être des sortes d’URIs mais j’avoue que la portée de tout cela m’échappe encore.

Le 16 février 2005, le W3C a donc annoncé qu’il relançait le groupe URI, pour travailler donc sur les URIs et sur les IRIs.

Toute l’histoire est récapitulée ici.

Pour ceux qui auraient l’impression de n’avoir rien compris à ce billet : z’en faîtes pas, c’est normal.

Dans les épisodes précédents (1, 2, 3), nous avons vu :

• les objectifs de l’identification pérenne des ressources numériques
• les principales fonctionnalités des identifiants
• les caractéristiques communes aux différents systèmes existants.

Aujourd’hui, je m’attaque à deux compléments indispensables de l’identifiant : le résolveur, et les métadonnées.

Le contexte de l’identifiant pérenne doit permettre de savoir à quoi celui-ci correspond et d’accéder à la ressource elle-même. Pour reprendre une métaphore que j’ai déjà utilisée : si on a votre nom, et qu’on veut vous trouver, il y a deux possibilités. Soit on dispose d’autres informations sur vous : votre photo, votre numéro de téléphone, votre adresse, votre CV ou n’importe quoi d’autre incluant dans le meilleur des cas votre adresse : ce sont les métadonnées. Soit on consulte un annuaire qui va donner l’adresse correspondant à ce nom : c’est le résolveur.

L’un n’exclut pas l’autre évidemment. On peut avoir un identifiant associé à des métadonnées et en plus un résolveur qui va donner l’URL correspondante.

Certains systèmes d’identification pérenne vont demander ou recommander la saisie de métadonnées conjointement avec l’enregistrement de la ressource. C’est le cas par exemple de DOI et de ARK.

D’autres systèmes sont dédiés à l’échange de métadonnées, mais incluent ou nécessitent un système d’identification pérenne pour accomplir leur rôle, qui est de donner accès à la ressource elle-même. Parmi ceux-ci on peut citer le protocole OAI-PMH.

Le rôle du résolveur d’identifiants est de faire correspondre au nom de la ressource son adresse réelle. Le résolveur peut être interne à l’institution qui donne les noms, ou externe et géré par une autorité indépendante.

Pour donner un exemple : la Library of Congress dispose de son résolveur qui fonctionne pour les identifiants DOI et Handle. On dispose d’un identifiant comme : doi:10.1045/january2005-fox, et il suffit de le faire précéder par l’adresse du résolveur pour accéder à la ressource : http://hdl.loc.gov/doi:10.1045/january2005-fox. Notez qu’il s’agit d’une simple fonction de résolution ; la ressource prise en exemple n’a aucun rapport avec la Library of Congress.

Le service PURL d’OCLC est un autre exemple de résolveur assuré de manière externe.

La combinaison du type de résolveur et du type de métadonnées associés à chaque système d’identification vont être un facteur de choix déterminant. Ils constituent le coeur du système, qu’il faut confronter avec les fonctionnalités attendues : par exemple, la possibilité de gérer plusieurs niveaux de granularité, la simplicité des mises à jour, la gestion des versions différentes d’une même ressource, etc.

Et voilà, j’en ai terminé avec cette introduction sur la problématique des identifiants pérennes des ressources numériques. Je rends justice à Diana Dack dont le rapport pour la National Library of Australia, bien que datant de 2001, reste encore largement d’actualité et a été ma principale source d’inspiration (attention le lien ne marche pas bien avec Firefox, il faut IE).

Dans une deuxième phase, il faudrait travailler sur la description de chaque système dans une approche comparative. Je ne sais pas si le Figoblog est le lieu pour faire cela… si vous pensez que oui, exprimez-vous dans les commentaires. Sinon j’en resterai là.

Dans les épisodes précédents (1 et 2), nous avons vu que définir un système d’identification pérenne de ressources numériques passait par le choix d’un certain nombre de propriétés et de fonctionnalités du système.

Ceci étant posé, l’heure est maintenant venue de faire un choix parmi les sytèmes d’identification pérenne existants aujourd’hui sur le Web.

Si on essaye de faire une typologie des différents systèmes, on se trouve bien en peine de trouver un critère qui permette de les classer tous. En fait, il y a plusieurs critères à prendre en compte, parmi lesquels on peut citer :

• l’indépendance : il y a les systèmes où les identifiants sont donnés par le créateur de la ressource, et les systèmes où ils sont donnés par un tiers
• l’unicité : il y a des systèmes qui garantissent l’unicité seulement au sein d’un système, d’autres qui la garantissent de manière totale et mondiale à l’échelle du Web
• la structure : il y a des systèmes qui attribuent des identifiants opaques, ou aveugles, et d’autres qui donnent des identifiants signifiants
• etc.

Je pourrais continuer comme ça presque indéfiniment. En fait, ce qu’il faut retenir, c’est que la plupart des systèmes combinent ces différents aspects à différents niveaux. Le choix va être difficile car il n’existe pas de critère de différenciation clair et net. Ils ont chacun leur façon de concevoir les choses, de les organiser.

Il est donc plus constructif de partir, non de leurs différences, mais de leurs points communs.

Les systèmes d’identification pérenne utilisent généralement tous une structure en trois parties de type :

SCHEME – NAMING AUTHORITY – NAME

Le « scheme », c’est un préfixe qui permet d’identifier le système dans lequel l’identifiant est unique. Par exemple, OAI, ARK, URN:NBN…

La « naming authority » ou autorité nommante, c’est une organisation qui a reçu, de l’autorité centrale en charge de définir le système, l’autorisation et le pouvoir d’attribuer des identifiants. Cette autorité peut être désignée par son nom, par un code attribué au sein du ssytème, par un code ou un nom codé qu’elle détient par ailleurs (comme un nom de domaine), etc.

Enfin, le nom, c’est une chaîne de caractères qui identifie la ressource de manière unique, au sein de ce système et pour cette autorité. En général, l’autorité nommante peut se retrouver assez libre de la façon dont elle structure ses noms, tant qu’elle garantit leur unicité en son sein. Elle peut aussi déléguer à une sous-autorité l’attribution de noms dans un domaine plus petit.

On voit bien comment, dans un seul identifiant, les critères que j’ai cités plus haut peuvent s’imbriquer : suivant l’existence et la nature du « scheme », l’unicité est garantie à une échelle plus ou moins importante. Suivant la façon dont l’autorité nommante est codée, cela détermine son degré d’indépendance, ou de dépendance à l’égard d’un système ou d’une autorité plus haute. Enfin, la structure de l’identifiant peut varier, au sein d’un même système, en fonction de chaque autorité.

Nous avons donc maintenant notre identifiant, du moins sa structure. Cependant, tout seul et sorti de son contexte, il est inopérant : nous avons besoin de savoir à quoi il correspond. Pour cela, deux types d’outils sont à notre disposition :

• les résolveurs,
• les métadonnées.

Je les garde pour la prochaine fois.

On en était à définir les fonctionnalités de notre système d’identification pérenne. Faisons une petite liste de courses (librement inspirée de : RFC 1737 – Functional Requirements for Uniform Resource Names)

Unicité. Un identifiant doit bien sûr être unique pour garantir qu’il désigne une ressource et pas une autre. Mais unique à quelle échelle ? Il y a les identifiants qui sont uniques au sein d’un système, qui conviennent parfaitement pour un usage interne, bien circonscrit. Par contre, quand on se préoccupe de diffusion ouverte, d’échange, de référence, on cherche l’unicité à l’échelle du réseau, donc du monde. La même ressource, située à différents endroits, devrait avoir le même identifiant. Cela peut supposer une organisation plus ou moins centralisée à l’échelle internationale.

Pérennité. La pérennité est la clef de la stabilité de la référence et la principale problématique de l’utilisation des identifiants. Si on ne peut pas se contenter des URL, c’est qu’elles ne sont pas pérennes : si la ressource se déplace, son URL change. On peut comparer cela à une adresse postale : si on ne vous identifie que par votre adresse, et que vous déménagez, on ne peut plus vous retrouver. On identifie plus généralement les gens par leur nom, et ce nom, c’est l’identifiant. En général, la pérennité du système d’identification est garantie par la pérennité de l’institution qui donne les identifiants. Les institutions ou acteurs appelés à durer peuvent ainsi devenir des "autorités nommantes", à l’échelle d’une organisation locale, d’un pays, ou du monde.

Granularité. Les identifiants doivent être applicables à n’importe quelle échelle de la ressource : la ressource elle-même mais aussi la collection dont elle fait partie, les articles qu’elle rassemble, et pourquoi pas, le paragraphe de l’article (ou le commentaire du billet), et également différentes versions d’une même ressource. Il faut donc définir les différents niveaux de granularité de l’information qui doivent être identifiés, et comment cela va se décliner dans le système d’identification : le choix peut aller de l’attribution d’identifiants complètement indépendants à chaque niveau, jusqu’à un système hiérarchisé qui reflète l’organisation de la collection.

Adaptabilité. Les identifiants peuvent être capables d’intégrer des modèles préexistants pour le fournissur qui les utilise. Par exemple, les ISBN et ISSN, les cotes d’une bibliothèque, un système de nommage préexistant utilisé pour les URL ou les fichiers.

Extensibilité. On doit pouvoir les étendre et les adapter au fur et à mesure des évolutions du réseau, des standards du Web, des capacités des navigateurs.

Indépendance. Celui qui donne les identifiants doit pouvoir avoir une complète liberté et un complet contrôle sur ce qu’il fait de son système.

Résolution. Les identifiants doivent fonctionner, autrement dit, être compréhensibles pour un navigateur puisque c’est l’outil que nous utilisons pour parcourir le Web. A l’heure actuelle, les navigateurs ne savent pas interpréter tout seuls les URN, DOI et autres. Ils ont besoin qu’on leur fournisse, quelque part, la correspondance avec des URL : c’est le rôle du "résolveur".

Nous avons donc une autorité nommante mondialement reconnue, qui dispose de la liberté et de l’indépendance nécessaires pour attribuer à des ressources des identifiants pérennes, uniques, et capables de s’adapter à toutes sortes de situations, que les navigateurs interprètent à l’aide d’un résolveur. Il existe déjà, aujourd’hui, un certain nombre de systèmes qui répondent à ces critères. J’aborderai leurs caractéristiques dans le prochain billet.

Quand on crée des ressources numériques en ligne, qu’il s’agisse de numérisation, d’une édition ou tout simplement d’une entrée de blog, on se demande comment leur donner une identification fiable et durable sur le réseau.

La problématique de l’identification pérenne a des implications multiples que je vais essayer d’aborder (pas en un seul billet !).

La première question qu’on doit se poser, c’est pourquoi ? Ou plus précisément, quel objectif on cherche à atteindre. La terminologie reflète déjà deux axes possibles. Quand on dit référence stable, ou lien permanent, on se préoccupe manifestement de la capacité d’un tiers à nommer et retrouver la ressource : autrement dit, la citabilité. Quand on parle d’identifiant, ou URI , on est plutôt dans une problématique d’unicité et de pérénnité dans le cadre d’une utilisation pratique par des machines.

Déjà, dans ces deux optiques, il y a un choix à faire. Un identifiant peut être plus facilement généré par une machine. Celle-ci va tabler sur des combinaisons alphanumériques très longues pour garantir l’unicité, ce qui ne lui pose pas de problèmes particuliers, mais est ingérable pour un utilisateur humain.

La citabilité a elle aussi plusieurs dimensions. Les systèmes d’identification comme DOI par exemple ont l’avantage de constituer une référence que le lecteur peut retenir pour établir ses citations. C’est un modèle de confiance. Cependant, le lecteur doit partir à la recherche de cette référence dans la description de la ressource : elle n’apparaît pas dans la barre d’URL. Le lecteur non averti va plutôt se contenter de copier-coller l’URL, ce qui n’aura pas fait avancer beaucoup la stabilité de sa citation.

Il y a aussi une idée répandue selon laquelle une URL « citable » doit être intuitive, c’est-à-dire : signifiante, et rédigée en langage humain. En fait, si on reprend le raisonnement du copier-coller, cela ne change pas forcément grand-chose à la citabilité. Par contre, cela peut poser un certain nombre de problèmes. Si on utilise le titre, on est confronté aux caractères peu adaptés aux URL, ne serait-ce que les espaces et les accents. De plus un titre n’est pas forcément unique : il m’arrive souvent de reprendre plusieurs fois le même titre de billet. On peut utiliser un élément plus stable, par exemple un autre numéro de référence comme l’ISBN et l’ISSN. Malheureusement, la vie de ces numéros n’est pas forcément aussi pérenne et unique qu’on le voudrait : si une revue change de titre, elle change aussi d’ISSN.

Il faut donc bien réfléchir à ce qu’on attend de son système d’identification pérenne, définir ses fonctionnalités. C’est la première étape. On verra ça en détail dans la suite.

Plein de questions un peu partout en ce moment sur les identifiants, les URI (qui sont cool s’ils ne changent pas), les URL, ce qu’ils veulent dire, combien de temps ils durent et comment les utiliser.

Je trouve amusant de voir les différents points du vue sur le sujet :

• du côté des geeks blogueurs, l’identifiant de rêve c’est le mod_rewrite d’Apache, ou le permalink du blog associé à la grave question de savoir comment il va se bidouiller dans le fil RSS et survivre en cas de déménagement.
• du côté des geeks standard, la question devient tout de suite plus complexe : les URL doivent-elles avoir un sens ? d’où la question qui en découle aussitôt du rapport entre URN et URL, à savoir entre nom et adresse…
• enfin du côté des geeks bibliothéconomiques (oui oui, ça existe, un peu), l’identifiant à l’honneur est notre bon vieux ISBN mangé à la sauce URN, URI et RDF.

Et nous, les bibliothécaires ? Nous qui jonglons depuis toujours avec des identifiants pérennes locaux basés sur des adresses (les cotes) ou internationaux basés sur des noms (ISSN, ISBN…), pour nous c’est quoi un identifiant pérenne, un URI, un URN ? Comme d’habitude, cela recouvre une réalité complexe et mouvante, sur laquelle personne n’est d’accord, qui implique à la fois les problèmes des métiers du livres en général et les besoins particuliers de nos systèmes informatiques…

Un petit tour d’horizon :

• W3C : URIs, URLs, and URNs: Clarifications and Recommendations
• PURL
• Handle
• DOI
• ARK
• le système local des australiens