Les metadonnées et le catalogage des documents numériques

Jacques Ducloy,
Ingénieur LORIA, Nancy
jacques.ducloy@loria.fr

Catherine Lupovici,
Responsable activités Bibliothèques
JOUVE Digitalisation des informations)
clupovici@jouve.fr

Elizabeth Cherhal,
Cellule MathDoc, Grenoble
Elizabeth.Cherhal@ujf-grenoble.fr




retour

Jacques Ducloy

Quelle définition pour les métadonnées. De façon simpliste, on pourrait dire c'est un nouvelle redéfinition du catalogage. Voilà une première définition officielle que j'ai trouvée sur le site web du Dublin Core, elle est très sibylline : « Metadata is data about data. » Voici la traduction française d'une autre version plus complète : « Description d'objets, de documents ou de services qui contiennent des données identifiant leur forme ou leur contenu. » Dans la version américaine (« The term refers to any data used to aid the identification, description and location of networked electronic resources. »), on trouve le terme électronique, mais c'est à peu près la même chose que du catalogage.

Pour introduire cette discussion sur les metadata, on peut réfléchir sur le passage du catalogage traditionnel aux métadonnées des documents numériques. L'objectif de base est d'améliorer la recherche d'informations sur internet. Donc le problème du bibliothécaire ou de celui qui fait des pages web va être de produire des métadonnées qui vont permettre à ces informations d'être retrouvées. Pour que ces informations soient retrouvées par une vaste communauté, deux types de problèmes se posent : l'homogénéisation des structures ou des formats d'une part et homogénéisation des contenus de l'autre.

Cet exposé va être divisé en deux parties : on va commencer par parler de la structure, et ensuite, on réfléchira sur le contenu, sachant que pour produire des metadata, on peut opérer de plusieurs façons : soit complètement à la main, soit en production totalement automatisée, soit en production assistée, c'est-à-dire en mêlant des procédés automatiques et des procédés manuels.

Pour aborder la structure, il est indispensable de parler de SGML qui est une norme générique, à partir de laquelle peuvent se décliner autant de normes que d'applications. Pour chacune, une DTD va décrire la structure des documents correspondants. Une norme extrêmement connue issue de SGML est HTML. C'est une implémentation particulière dans le cadre d'une application W3; SGML est un format plus générique qui permet d'avoir d'autres types d'applications.

Il est relativement facile de transformer un document de type notice (par exemple une notice Medline) dans un balisage SGML, qui permet d'utiliser ce type d'informations avec des moteurs, des outils, et toute une ingénierie SGML.

Ce qui est valable pour un format simple est également valable pour un format plus complexe comme des formats de type MARC (exemple de notice CCF) ou ISO 2709. Pour des informaticiens entraînés, il faut environ trois jours à une semaine pour faire ce type de filtre, (d'un format traditionnel vers un format SGML), et une fois qu'on a fait la conversion sur la norme de base, on sait récupérer n'importe quel type de documents en format MARC ou ISO 2709.
En résumé, si un document a une structure initiale stable et cohérente, on peut utiliser des métadonnées anciennes dans le monde SGML. On peut donc continuer à travailler en MARC tel qu'on avait l'habitude de le faire et en même temps bénéficier de l'environnement SGML.

Par exemple, si l'on veut créer des fichiers inverses «auteur» dans une base contenant des documents venant de Medline et de Pascal, il suffit de dire dans quel chemin SGML est l'information qu'on a envie de mettre dans le fichier inverse pour réaliser des fichiers inverses multibases. On n'a pas besoin de reformater complètement les notices.

Cela dit, un reformatage de bases de données traditionnelles en SGML est relativement simple. De plus, on sait faire des applications multibases en SGML sans forcément s'imposer un reformatage systématique de toutes les données. Je crois que ce sont des points très importants quand on aborde un passage en SGML. Ça permet aussi d'imaginer de nombreuses stratégies progressives entre un fonctionnement de type MARC et un fonctionnement de type SGML.

Il y a trois types d'approches sur la recherche des documents sur le web :

L'idée du Dublin Core, qui est la forme la plus avancée de normalisation des métadonnées sur le web, est que les gens qui travaillent sur le web puissent indexer facilement des documents en limitant simplement à quinze éléments les zones de catalogage. Après de nombreuses discussions du groupe de travail Dublin Core pour savoir s'il fallait en rajouter un seizième ou en enlever un quinzième, on a finalement tranché: on n'aura jamais plus de quinze éléments de catalogage.

Parmi les sponsors du dernier meeting Dublin Core à Helsinki, on retrouve l'OCLC (Online Computer Library Center), la NSF (National Science Foundation), le CNI (Coalition for Networked Information - un consortium d'organismes américains), et la National Library of Finland (qui était l'organisateur local). Sur les participants, il est intéressant de voir que les pays nordiques étaient très influents, d'une part parce qu'ils étaient organisateurs locaux, mais aussi parce que les pays nordiques ont fortement investi sur le Dublin Core de manière coopérative. Le reste du monde est surtout représenté par le Commonwealth, trois asiatiques, un représentant de la DG XVIII, et deux français qui étaient tous les deux de l'INRIA. Une telle concentration donne à réfléchir quand on parle de la démocratisation d'Internet.

Catherine Lupovici
Les formats de métadonnées

Le terme métadonnées du point de vue des formats électroniques peut avoir deux significations :

Ces données qui servent à identifier les documents et à rechercher des informations peuvent être soit créées en tant que telles a priori en accompagnement de la ressource électronique ou elles peuvent être retrouvées et combinées a posteriori par des systèmes de recherche. La création de cette information secondaire obéit actuellement à différentes approches :

Autour de ces différentes approchent se mettent en place différents formats de métadonnées qui sont plus complémentaires que concurrents car ils ne rendent pas exactement les mêmes services. Ils correspondent à une gestion différente de la ressource électronique

  1. Le lien du catalogue vers le document

    La création d'un lien actif à partir du catalogue classique vers la ressource électronique est prise en compte dans une extension du format MARC. USMARC et UNIMARC offrent un nouveau champ 856 qui, via un certain nombre de sous-champs, permet de donner des informations techniques sur la ressource électronique et de coder un lien vers le document, par exemple un URL. Les informations sur le champ 856 du format UNIMARC sont disponibles sur le site Web de l'IFLA à l'URL : http://ifla.inist.fr./VI/3/p1996-1/856.htm. Cette approche est plutôt associée à la possession de la ressource par l'organisme qui la signale dans son catalogue.

  2. Les métadonnées du Web

    Les métadonnées des pages Web se codent en utilisant la syntaxe meta dans le format HTML. Sur la base de cette syntaxe un format de métadonnées particulier a été développé : le Dublin Core (DC). La normalisation du DC s'est faite à la fois sur les éléments qui doivent y figurer et sur la syntaxe à utiliser. Cette syntaxe dans sa forme complexe permet de mettre des liens vers les fichiers d'autorité pour les formes de point d'accès. Les éléments définis dans le DC sont le minimum qui peut être fourni par l'auteur de la ressource électronique et qui peut être éventuellement complété par une bibliothèque ou un centre de documentation qui va gérer la mise à disposition ou signaler la ressource dans le cadre de ses services d'accès à l'information. Dans le cadre des évolutions techniques du Web et du passage du codage HTML vers le codage XML, le remplacement de la syntaxe meta est en cours de définition dans le cadre de RDF (Resource Description Framework). Les éléments définis pour le DC pourront être exprimés dans la nouvelle syntaxe qui offrira non seulement la possibilité d'inclure des métadonnées dans la ressource mais aussi celle d'utiliser des attributs pour qualifier des données de base en tant que métadonnées.

  3. Les métadonnées des ressources codées en SGML

    Deux formats de métadonnées s'appuyant sur SGML/XML sont en cours d'expérimentation dans plusieurs projets coopératifs de bibliothèques électroniques dans le continent Nord américain et en particulier à la Bibliothèque du Congrès.

    • Projets d'encodage de documents textuels selon la structure SGML TEI (Text Encoding Initiative). La structure TEI a été définie par la communauté des chercheurs anglo-saxons en sciences humaines et en linguistique. Elle permet de gérer le texte à l'unité et requiert dans l'en-tête du document un champ obligatoire de description qui constitue, avec les informations sur l'encodage, les métadonnées. Cette description peut prendre la forme d'un catalogage complet et être liée aux fichiers d'autorité traditionnels. Les métadonnées TEI peuvent être créées automatiquement à partir du format MARC ou au contraire le format MARC est généré à partir de l'en-tête TEI.

    • Projets d'encodage des instruments de recherches (inventaires, répertoires, guides etcŠ) et des documents qu'ils décrivent selon la structure SGML EAD (Encoding Archival Description). Ce format a été défini en partenariat entre les bibliothèques pour leurs collections spécialisées et les archives. Il est également testé par des musées. Ce format permet la gestion des métadonnées et des ressources électroniques en tant que collections en suivant l'organisation des pièces dans la collection. Tous les niveaux de la hiérarchie d'organisation des pièces peuvent être décrits. A chacun des niveaux on peut poser des liens avec les fichiers d'autorité classiques.

  4. Les identifiants de documents

    Une des composantes très importante de métadonnées est l'identifiant unique et permanent de chaque ressource. Ces identifiants qui s'appuient lorsque cela est possible sur les identifiants classiques passifs (ISSN, ISBN) doivent permettre un accès à plus long terme sur le réseau que les seuls URL actuels. Un ensemble d'identifiants sur Internet est étudié par le W3 consortium permettant de donner un numéro unique l'URN (Uniform Resource Name) qui est enregistré dans des organismes de résolution du nom chargés de donner les URLs qui permettent d'accéder aux ressources. Les organismes assurent les changements d'URL en cas de changement d'adresse des ressources. Ils offrent également éventuellement des informations sur les conditions d'accès aux ressources via des URC (Uniform Resource Characteristics)

Elizabeth Cherhal

Je vais essayer de donner deux exemples d'utilisation concrète du Dublin Core dont a parlé Jacques Ducloy.

  1. Le premier exemple concerne les index des thèses et des prépublications de mathématiques en France. On est parti de la situation suivante : un auteur est en train d'écrire son article et veut le mettre en ligne. Comme il écrit des mathématiques, il va utiliser le logiciel TeX. Son document va subir un certain nombre de transformations : à partir du fichier TeX, on obtiendra différents formats de fichiers: dvi, PostScript ou éventuellement pdf. Un résumé en HTML sera souvent créé pour faciliter l'accès via le web. Ce document, avec son résumé sera ensuite mis sur un serveur web, et parallèlement soumis pour être publié dans un journal.

    Partant de cette situation, la mission de la Cellule MathDoc (http://www-mathdoc.ujf-grenoble.fr/) a été de voir comment on pourrait retrouver cette information autrement qu'en parcourant les quelques quarante et plus serveurs web des départements de maths.

    On avait entendu parler de l'initiative qui consistait à utiliser les métadonnées selon la définition du Dublin Core, et la méthode avait l'air relativement simple. On a affaire à des producteurs d'informations qui sont des mathématiciens, des gestionnaires d'informations qui sont parfois des informaticiens, des bibliothécaires, ou simplement des bonnes volontés. Donc on a voulu mettre en place un projet utilisable par cet ensemble de gens. Le but de notre projet était de pouvoir retrouver plus facilement l'information, en constituant un catalogue dynamique de ces documents.

    Pour chaque document en texte intégral, par exemple une pré-publication ou une thèse, quel que soit son format, PDF ou autre, il existe un résumé en HTML., dans lequel il y a des données bibliographiques (métadonnées). Ce sont ces métadonnées qui sont utilisées pour l'indexation et l'interrogation. On a essayé de suivre les recommandations des groupes de travail du Dublin Core, mais il faut avouer que ce sont des choses qui changent encore beaucoup aujourd'hui, donc on va être certainement amenés à faire des modifications dans ces propositions. En fait, une fois qu'on a mis en place quelque chose, c'est extrêmement simple de changer : si on s'est trompé dans le nom d'un champ et qu'on n'a pas mis exactement ce qu'il fallait, le changement, par un outil automatique, est simple à faire.

    Sur les serveurs de pré-publications, les gestionnaires ou auteurs ne remplissent jamais manuellement les résumés des fichiers HTML. Dans la plupart des cas, ils sont générés directement par un programme à partir d'autres formats. Dans les bibliothèques de Math, on utilise souvent Texto ou BibTeX, Les fichiers crées avec ces outils seront ensuite moulinés par un programme qui va générer la hiérarchie de fichiers HTML avec des métadonnées. Il arrive aussi que ce soit les auteurs qui créent leur fichier résumé à l'aide d'un formulaire en ligne.

    Notre projet utilise un outil gratuit qui s'appelle Harvest, qui sert à la fois de moteur de recherche, d'analyseur et d'indexeur (http://www.tardis.ed.ac.uk/harvest/ pour le télécharger). Harvest est capable de ramasser, puis d'analyser les résumés des documents en format HTML, ou des fichiers en Postscript, et d'autres formats de documents différents. Mais dans notre projet, nous ne ramassons que les fichiers en HTML et qui contiennent des métadonnées. Le ramassage prend donc relativement peu de temps par rapport à un moteur de recherche ordinaire qui va passer des nuits à parcourir le web, à ramasser les documents et à les indexer.

    Harvest contient aussi un analyseur (summarizer) qui est basé sur les DTD de SGML et qui permet d'analyser les différents documents ramassés, et d'en extraire les champs utiles pour l'indexation. L'indexeur de HARVEST va indexer les données puis exporter l'index pour permettre son interrogation sur le web

    Il y a beaucoup d'autres moteurs qui marchent. Harvest est un moteur un peu plus compliqué que certains autres parce qu'il y a ces trois étapes (moteur de recherche, analyseur, indexeur). Cela permet de construire un système réparti. Grâce à ce système et à l'utilisation du Dublin Core, donc d'un noyau minimum de catalogage de documents, on peut interroger les index de différents pays.

    Notre projet a donc permis de faire des recherches sur les pré-publications (http://www-mathdoc.ujf-grenoble.fr/prepub.html) et thèses de maths (http://www-mathdoc.ujf-grenoble.fr/these.html) en France à partir de l'indexation de métadonnées.

  2. La Cellule MathDoc participe à un projet européen, le projet EULER (http://www-mathdoc.ujf-grenoble.fr/euler/) qui vise à proposer un "one-stop shopping site", un site commun de ressources en mathématiques. Ce projet a pris comme base l'utilisation massive du Dublin Core. Quand l'utilisateur, le mathématicien européen, veut chercher une information, il faut qu'il aille chercher dans les différents catalogues de bibliothèques, dans des bases de données online comme le Zentralblatt-MATH ou les Math Reviews, dans les serveurs de preprints, dans les journaux électroniques, dans différents serveurs web, etc. Donc il perd beaucoup de temps.

    L'idée est de pouvoir utiliser une colle intermédiaire (les gens qui travaillent sur le projet utilisent le terme de glue.) La colle intermédiaire entre toutes ces ressources documentaires, c'est le Dublin Core, un peu plus, un peu moins que les quinze éléments de base. Des bases de métadonnées ³ Dublin Core ² seront constituées sur le serveur de chaque partenaire du projet. Ces bases de données seront rendues accessibles via des serveurs Z39.50. Un profil spécial est en train d'être écrit pour Z 39.50 et Dublin Core.

    L'intérêt du protocole Z 39.50 est de pouvoir interroger simultanément plusieurs bases. Il n'est pas raisonnable de penser pouvoir passer des moteurs de recherche sur plusieurs ressources et de les ramasser. Voilà pourquoi le choix de Z 3950 a été fait pour le projet EULER. Participent à ce projet, pour la France, la Cellule MathDoc associée à deux bibliothèques de mathématiques, celles d'Orsay (UMS J Hadamard 1796) et de Strasbourg (UMR 7501).

Jacques Ducloy

Parlons maintenant du contenu : comment indexer des pages W3 avec un vocabulaire spécifique, de manière à ce que ces pages soient retrouvées en bonne place, (si possible les premières), par des non spécialistes et ne parlant pas forcément français !

A Nancy, nous menons une expérience dans le cadre de la médecine. Elle nous a donné quelques pistes sur comment rechercher et filtrer des documents sur internet, en utilisant des bases bibliographiques classiques. Plus précisément, pour trouver du bon vocabulaire sur internet ou pour classifier de l'information, il peut être intéressant d'utiliser ce que nous produisons, c'est-à-dire des bases de données structurées dans lesquelles on trouve une association entre des descripteurs contrôlés et du vocabulaire. C'est cette ressource terminologique que nous allons utiliser à la fois pour interroger internet de manière un peu plus structurée, et pour produire du contenu ou des metadata.

Dans un projet en cours, MedExplore, l'utilisateur va naviguer de manière homogène entre des documents locaux, en utilisant comme ressources terminologiques d'une part Medline pour l'information internationale, et, d'autre part, Pascal pour avoir une ouverture multilingue et multidisciplinaire.

Sur un domaine spécialisé, on va prendre des informations venant d'une part de Medline, d'autre part de Pascal, et essayer de manière semi-automatique de créer un vocabulaire coeur qui va être l'identifiant de ce domaine spécialisé. Une fois que ce vocabulaire coeur est défini, on va réindexer les documents venant d'une base et de l'autre avec un vocabulaire commun, ce qui va nous permettre de naviguer de manière homogène, à la fois dans des éléments, des notices venant de Medline, de Pascal, et éventuellement de les mettre à disposition sur internet.

Le style de navigation de MedExplore est tout à fait classique de ce qu'on sait faire avec des méthodes de type clusterisation : l'utilisateur peut choisir, dans une navigation multibases, de partir avec les titres, les auteurs, les mots clés français, les mots clés anglais : puis interroger de manière indifférente Medline ou Pascal. Ce type de navigation repose sur les associations entre descripteurs. Ce principe d'association va être utilisé pour retrouver du vocabulaire.

Un exemple : en partant d'un mot clé français comme coronographie, par des traitements statistiques à la fois dans Medline (si on cherche du vocabulaire anglais), ou dans Pascal (si on cherche du vocabulaire français), on va obtenir des termes extraits des résumés qui identifient le concept de manière courante. Le résultat ainsi obtenu va être envoyé vers un moteur de recherche sur Internet.

Maintenant, si nous voulons vraiment savoir comment indexer sur internet, il faut aller encore un petit peu plus loin dans le traitement. Sur un sujet donné, il faut lancer une recherche du même type, puis récupérer les pages W3, et enfin, les analyser pour regarder quel est le vocabulaire effectivement utilisé.

Il reste un peu de temps pour donner un peu plus d'information sur la suite du Dublin Core dans le cadre du mouvement normatif autour de SGML. Jusqu'à maintenant, la philosophie SGML favorisait une différenciation assez forte entre le contenu et la présentation : on décrit le contenu en SGML et on obtient une présentation par un programme de conversion. La norme DSSSL, est censée décrire de manière normalisée cette transformation.

Quelle va être l'évolution telle qu'elle se dessine au sein du consortium du W3 ? Elle tourne fortement autour d'une suite à SGML qui s'appelle XML (Extensible Markup Language). Elle a pour but de simplifier SGML (à titre indicatif, la spécification SGML fait 500 pages, la spécification XML fait 26 pages).

Concernant l'évolution des métadatas et des contenus, les nouveaux navigateurs vont être capables d'intégrer les feuilles de style dans une autre norme qui s'appelle CSS (Cascading Style Sheet), donc l'idée est d'associer ces feuilles de style à un document XML. Un document dont on aura eu une structure essentiellement basée sur le contenu, sans trop penser à l'implantation, sera rendu présentables sur le web par l'utilisation des feuilles de style. Le résultat ne sera pas le même qu'avec une transformation de type DSSSL, mais cela permet d'avoir une première présentation relativement propre d'un document.

Nous avons donc une transition entre l'utilisation exclusive de documents HTML sur le web vers celle de n'importe quel type de document auquel on aura associé à des feuilles de style. Cette évolution va aussi concerner les métadata. Jusqu'à présent, les métadatas, telles qu'elles apparaissent dans le Dublin Core, sont assez catastrophiques d'un point de vue syntaxique: on a pris la syntaxe la plus restrictive possible, celle des attributs, pour essayer de décrire quelque chose qui peut être relativement complexe. On était très limité par le carcan HTML dont la DTD relativement pauvre n'utilise que très peu la puissance de SGML. Cette contrainte est levée avec XML et nous allons pouvoir bénéficier de descriptions bibliographiques beaucoup plus structurée (et décrivant des notions plus complexes) que dans des documents W3 classiques.

On va progressivement évoluer vers de nouvelles syntaxes, de nouveaux concepts ou un ré-habillage des anciens, et une extension probable des possibilités.

Moralité, si vous cataloguez en MARC, vous pourrez générer du Dublin Core, et vous pouvez espérer aussi pouvoir générer automatiquement du RDF!

Contributions au débat

Intervention de la salle

Au sujet de ces métadatas, j'ai entendu dire que les chercheurs et les auteurs devraient peut-être faire une partie du travail, classer déjà ces données sur les données dans leurs travaux dès le départ. Est-ce à dire qu'ils doivent maintenant acquérir aussi des aptitudes catalographiques ? Que se passe-t-il au niveau de la formation ?

Catherine Lupovici

Les métadonnées peuvent être créées à différents niveaux, mais il n'y a pas de règles. On veut simplement que les auteurs mettent les bonnes notions dans les bonnes cases, donc on leur demande de savoir ce qu'est un titre, leur nom en tant qu'auteur, créateur, la date de leur publication, etc.

Cela n'empêche pas qu'un travail complémentaire puisse être fait par des professionnels de l'information qui peuvent rajouter des métadonnées plus élaborées en utilisant des fichiers d'autorité. On n'est pas obligé de demander aux auteurs de faire un travail de catalogueur. La confusion de ces deux niveaux explique l'échec du début de l'édition électronique. A cette époque on pensait pouvoir demander aux auteurs d'écrire directement en SGML.

On a en fait appliqué à SGML la démarche d'utilisation qui avait présidé à la création de Tex par les mathématiciens pour les formules de maths. Tex a précédé SGML avec une philosophie proche permettant de qualifier les éléments de données composant les formules de mathématiques afin de les présenter correctement.

On a donc pensé que l'on pourrait demander à tous les auteurs qui publiaient, la même chose que ce que les mathématiciens font avec Tex. Cela a été un échec total. Dans les chaînes d'édition qui utilisent en entrée les fichiers des auteurs, on a généralement du Word ou des fichiers beaucoup plus simples. Le travail éditorial consiste à mettre de la forme, mais au sens logique de l'organisation du document, avec des outils plus puissants tels que SGML. Mais il est utopique de vouloir demander aux auteurs de faire ce travail.

Jacques Ducloy

Il y a quand même des revues qui imposent aux auteurs de mettre des mots clés relativement précis lorsqu'ils rédigent des articles.

Catherine Lupovici

C'est en termes de contenu mais pas nécessairement en termes de format. En fait, le Dublin Core est un format. Donc c'est là que les choses peuvent se jouer. Évidemment, les recommandations aux auteurs subsistent mais elles ne sont pas nécessairement sur le format utilisé.

Intervention de la salle

N'est-il pas dangereux de mettre ce genre d'outils dans les mains de réseaux d'éditeurs qui sont déjà particulièrement puissants ? N'est-ce pas leur donner un outil pour complètement verrouiller aussi bien l'information secondaire que l'information primaire ? Quand ils auront la possibilité de manipuler les métadonnées, ils peuvent aussi se mettre à créer des outils qui vont nous diriger vers certains sites qu'ils contrôlent déjà.

Catherine Lupovici

Non seulement ils peuvent mais ils le font en distribuant non pas les versions SGML de production mais des formats de présentation non révisables comme l'était l'imprimé. Le Dublin Core quant à lui correspond vraiment à l'environnement du web où l'on a des publications de type « à compte d'auteur », venant de communautés qui décident de publier. Si on distribue des documents codés en SGML, un utilisateur peut en faire une version personnelle, il peut rajouter des métadonnées pour son propre usage. Il peut également le faire en HTML mais avec des fonctionnalités beaucoup plus réduites.

A partir d'informations préparées et proposées dans un format universel et révisable on peut toujours rajouter ses propres données dans le même format. C'est l'objectif de l'initiative TEI de faire un format qui soit un format d'édition, de proposition de mise en forme logique de l'information que les chercheurs peuvent utiliser eux-mêmes pour éventuellement ajouter leur propre code pour une exploitation par leur propre logiciel pour du traitement linguistique.

Dominique Lahary, Bibliothèque départementale du Val-d'Oise

Y a-t-il des applications réelles de l'URL à part le DOI (Digital Object Identifier)?

Catherine Lupovici

La normalisation des URN est en cours au sein de l'IETF (Internet Engineering Task Force). Donc, pour l'instant, il n'y a pas à proprement parler d'applications, sauf des essais de mise en oeuvre ou de période intermédiaire pour résoudre les URL (trouver un URL correspondant à un numéro identifiant à un numéro URN) et faire en sorte qu'on ait une permanence sur les réseaux. C'est ce qu'a fait OCLC avec les PURL (Permanent URL).

Les éditeurs traditionnels ont joué le jeu immédiatement pour la numérotation. L'initiative Digital Object Identifier, qui permet de faire un numéro identifiant pour percevoir les droits d'usage sur le réseau, a été mise en place et commence à fonctionner. Un certain nombre de documents sont déjà pourvus d'un numéro DOI, qui est numéro URN, géré par le domaine d'associations d'éditeurs au niveau international pour enregistrer les numéros et faire la résolution des URL à l'endroit où les documents sont stockés chez les éditeurs. Ces éditeurs sont eux-mêmes, à l'occasion, serveurs de documents.


retour

Dernière mise à jour : 15 janvier 1999
Contact : Jacques Ducloy, Catherine Lupovici et Elizabeth Cherhal