Initiatives numériques de BAC

Recherche numérique

Identification permanente

Analyse de l'environnement - Février 2008

Aujourd'hui, les ressources intellectuelles et culturelles de valeur sont de plus en plus hébergées sur des réseaux publics comme Internet. La conception de systèmes efficaces de gestion de l'information favorisera l'utilisation de ces ressources à l'avenir. Les organisations doivent toutefois mettre en place des infrastructures qui assurent un accès à long terme. La mise en œuvre d'un système d'identification permanente des ressources numériques est une composante de cette infrastructure.

Fondé sur un rapport publié par l'ancienne Bibliothèque nationale du Canada¹, le présent document passe en revue les différents schémas d'identification permanente existants ainsi que les services connexes. Il a été préparé à la suite d'une analyse de l'environnement effectuée par Bibliothèque et Archives Canada (BAC) à la fin de l'année 2007. Ce document vise à fournir des renseignements favorisant l'élaboration de pratiques exemplaires pour l'attribution de métadonnées d'identification aux ressources numériques.

Après un aperçu des principes d'adressage Internet, le document situe l'identification permanente dans le continuum des pratiques de gestion du cycle de vie. Le corps du document décrit les schémas et les services d'identification existants. Les ressources annexées au présent document incluent entre autre, un glossaire, des profils d'organisations et une bibliographie sommaire.

Contexte

Depuis la création du World Wide Web, le localisateur de ressources uniformes (URL) est utilisé pour identifier et référencer les ressources de réseau. Cependant, si on n'assure pas une maintenance constante, l'adressage par URL peut entraîner l'utilisateur dans un véritable labyrinthe truffé de cul-de-sac.

Les URL ne sont pas des identificateurs durables puisqu'ils sont fondés sur l'emplacement. Les liens sont rompus lorsque les ressources ne sont plus maintenues dans les URL référencés. À mesure que les objets numériques changent de propriétaires, que les structures de fichier sont réorganisées et que les noms de domaine sont achetés et vendus, les liens entre les objets et les URL sont rompus. C'est pourquoi les utilisateurs obtiennent souvent le message suivant : « Erreur 404 : Fichier introuvable ».

Si les liens brisés créent une certaine hostilité chez les utilisateurs des réseaux, ils ont également des coûts quantifiables. Les organisations qui maintiennent régulièrement leurs objets numériques engagent des ressources chargées de vérifier les liens et de mettre en œuvre des processus pour augmenter la durabilité des URL (c.-à-d. des règles d'affectation des noms). Ultimement, ces stratégies ne sont pas des solutions viables à long terme (permettant d'assurer la permanence). Elles exigent beaucoup de ressources et ne permettent pas de répondre aux besoins de tous les intervenants (c.-à-d. le besoin de simplicité de l'utilisateur, le besoin d'un code durable du développeur, le besoin de commercialisation et valorisation de la marque de l'organisation). Les URL continueront néanmoins à être le principal mécanisme d'adressage Internet à court et à long terme.

S'il est clair qu'il faut identifier les ressources numériques de façon permanentes, la mise en œuvre de systèmes officiels d'identification exigera un investissement substantiel en ressources. Ce qui importe probablement le plus, c'est que pour que cette identification soit réellement permanente, il faudra un engagement continu envers la maintenance de l'infrastructure.

Comme les travaux intellectuels sont de plus en plus nombreux, les entreprises canadiennes doivent avoir un accès fiable, et ce, dans un délai raisonnable aux ressources numériques qui servent à appuyer les fonctions clés. De plus, le public canadien doit avoir accès à des renseignements qui lui permettent d'améliorer sa qualité de vie. La protection du contenu intellectuel et culturel incombe aux créateurs, aux éditeurs et aux détenteurs des ressources numériques. Dans la mesure où ces ressources représentent la diversité des connaissances et des expériences des Canadiens, il faut assurer un accès permanent et ouvert, aujourd'hui et à l'avenir.

Aperçu

Au début des années 1990, la fonctionnalité des systèmes hypertextes a été jumelée à l'infrastructure Internet existante pour créer le World Wide Web. Les hyperliens permettent de créer des connexions dynamiques entre les ressources d'information hébergées sur des réseaux distribués. Les applications Web permettent aux utilisateurs de naviguer de façon transparente dans ces pages de texte, d'images et de contenu multimédia numériques.

Le Web est fondé sur des normes officielles et des spécifications techniques formelles pour assurer l'échange d'information entre ordinateurs en réseau. La communauté informatique, coordonnée par des organisations comme l'Internet Engineering Task Force (IETF) et le Consortium W3C (W3C), est responsable de l'élaboration et du maintien de cette infrastructure. Tout le concept du Web repose sur l'attribution d'identificateurs uniques aux ressources de réseau.

Adressage sur Internet

Protocole Internet (IP)

L'Internet est un cadre mondial de réseaux informatiques interconnectés. Un ensemble de protocoles de réseau facilite les communications entre les points d'extrémité informatiques et permet la transmission de paquets de données entre ces points. Le Protocole Internet (IP) considéré comme l'épine dorsale du Web, est un mécanisme d'adressage qui supporte la transmission des données.

Les adresses IP, maintenues par l'Internet Assigned Numbers Authority (IANA), identifient les systèmes sur un réseau. Chaque entité branchée à l'Internet possède une adresse IP unique représentée par une série de nombres séparés par des points (p. ex, 137.122.6.60). L'IANA attribue des blocs d'adresses IP à des organismes tels les gestionnaires de domaines et les fournisseurs de services Internet.

Il existe aujourd'hui deux versions du protocole, IPv4 et son successeur, IPv6. Basée sur un adressage à 32 bits, IPv4 régit un peu plus de 4 milliards d'adresses uniques. Le protocole IPv6 à 128 bits, élaboré pour répondre à la demande croissante de nouvelles adresses réseau, peut fournir plus de 16 milliards de milliards d'adresses². IPv6 n'est pas encore mis en œuvre à grande échelle. L'interopérabilité entre les deux versions permet une transition continue.

Système de noms de domaine (DNS)

Bien que les ordinateurs utilisent les adresses IP pour identifier les entités sur le réseau, les humains utilisent plutôt les noms de domaine. Un domaine est une étiquette intelligible et conviviale qui identifie une adresse IP en particulier. Le système de noms de domaine (DNS) traduit ces étiquettes en adresses IP pour qu'elles puissent être manipulées par les ordinateurs.

Le système DNS utilise une forme indirecte de nommage qui exige le maintien continu du lien entre les noms de domaine et les adresses IP. Dans ce système, une hiérarchie de serveurs gère les renseignements qui font autorité au sujet des domaines et des sous-domaines. Les navigateurs et les autres applications Internet font appel aux serveurs DNS pour traduire les noms de domaine en adresses IP.

Bien que l'attribution et la résolution des adresses IP se font de façon transparente, l'omniprésence du Web et du Protocole de transfert hypertexte (HTTP) a sensibilisé le public au concept d'adressage de réseau. Les utilisateurs savent que les chaînes URL représentent l'emplacement des ressources.

URI, URL et URN

Pour normaliser l'architecture Internet, la communauté informatique a élaboré des spécifications techniques sous forme de documents d'appel de commentaires (RFC) de l'IETF. Le document RFC 3968, une spécification générique pour le système d'identificateur de ressources uniformes (URI)³, détermine la syntaxe pour l'identification et la résolution des ressources Internet. Dans les versions antérieures à cette spécification, les identificateurs étaient catégorisés. Un URI pouvait aussi bien être une adresse URL⁴, un nom de ressources uniformes (URN)⁵ ou une caractéristique de ressources uniformes (URC)⁶. À mesure que le concept d'adressage évoluait, l'attribution de catégories plus précises a été jugée inutilement complexe.

Aujourd'hui, le concept d'URI englobe à la fois les schémas URL et URN en tant que sous-ensembles. Un URI peut être un localisateur, un nom ou les deux. Les localisateurs identifient les ressources en fonction du chemin jusqu'à leur position sur un hôte donné. Le nommage est une forme d'identification indépendante de l'emplacement. Il vise à atténuer les problèmes provoqués par le fait que les ressources sont liées à l'emplacement.

Quoique le terme « URI » est reconnu officiellement, celui de l'« URL » continue de dominer dans le langage courant. L'IETF recommande que les futurs documents techniques utilisent le terme générique « URI », cependant plusieurs membres de la communauté informatique continuent d'utiliser les deux de façon interchangeable. Nonobstant les questions de terminologie, l'importance de la mise en œuvre d'identificateurs indépendants de l'emplacement fait l'objet d'un large consensus. L'identification permanente est maintenant jugée essentielle pour assurer l'accès à long terme aux ressources numériques.

Identification permanente

Gestion du cycle de vie numérique

Plusieurs domaines et communautés de pratique utilisent le concept de cycle de vie pour organiser les étapes par lesquelles une entité évolue au fil du temps. Par exemple, la communauté de gestion des dossiers utilise un modèle de cycle de vie pour comprendre les étapes de l'existence des ressources d'information, de la création des dossiers jusqu'à leur déclassement. Bien qu'il n'existe encore aucun modèle officiel pour le cycle de vie des objets numériques, l'utilisation des principes de gestion des dossiers et de l'information à cette fin a donc été recommandé⁷.

Comme d'autres types de ressources d'information, les objets numériques doivent être gérés efficacement, et ce, à toutes les étapes de leur existence. Les étapes du cycle de vie d'un objet numérique varieront selon la communauté qui gère la ressource. Cependant, tous les modèles de cycle de vie numérique comprendront les étapes reflétant la création ou l'acquisition de la ressource, sa gestion et sa conservation, aussi bien que son utilisation⁸.

Chacune de ces étapes est associée à des responsabilités clés pour la ressource numérique. Une des forces de l'approche de cycle de vie est sa capacité à mettre en évidence la diversité des intervenants qui participent à la gestion de la ressource au fil du temps⁹. Des facteurs comme l'infrastructure distribuée et les transferts successifs de propriété augmentent la nécessité de suivre les activités tout au long des différentes étapes du cycle de vie. L'utilisation de ce type de modèle met en évidence l'importance d'intégrer les intervenants pour assurer la protection de l'accès à long terme.

Les responsables des travaux effectués pour élaborer les dépôts numériques fiables (TDR)¹⁰ reconnaissent qu'il existe des interdépendances entre la création, la gestion et l'utilisation⁸ et entre les communautés responsables d'activités précises durant ces étapes. L'accès dépend de l'élaboration et de la mise en œuvre de stratégies et d'infrastructures qui appuient la gestion continue et coordonnée des ressources. Pour assurer un accès à long terme, il faut intégrer l'identification permanente aux modèles de cycle de vie.

Appuyer la permanence

Les discussions sur la permanence sont souvent axées sur l'attribution d'identificateurs uniques. Ce point de vue est toutefois limité et peut cacher le fait que la permanence est le résultat de systèmes qui fonctionnent bien. La permanence est mieux comprise comme étant le résultat final du fonctionnement systématique d'un certain nombre de composantes.

Un système d'identification permanente comprend des normes et des spécifications techniques, des services de résolution, des systèmes de registres, des autorités de nommage, etc. Les schémas d'attribution des identificateurs ne sont qu'un des éléments du système. Une fois les identificateurs attribués, la permanence dépend de l'engagement de l'organisation à adopter des politiques appropriées et à administrer régulièrement le système. Les normes techniques doivent être jumelées à un engagement ferme à maintenir l'infrastructure.

Bien que l'organisation des composantes varie selon les systèmes, ils doivent tous comprendre trois éléments génériques, soit un schéma d'identification, soit des services de résolution connexes et une infrastructure de soutien. Une compréhension élémentaire de ces principaux éléments permettra au lecteur de comparer les modèles et les systèmes décrits dans le corps de ce rapport.

Schémas et services d'identification

Les entités décrites dans le corps de ce rapport comprennent les normes communautaires non exclusives, les services de résolution distribués et les systèmes commerciaux de gestion de l'information. Certains représentent une seule composante de système, comme le modèle d'identification URN. D'autres, comme le Handle System®, comprennent plusieurs composantes.

Le choix d'un système d'identification permanente doit se faire dans le contexte d'une stratégie plus large de gestion de l'information organisationnelle. Il faut évaluer les composantes décrites dans ce rapport afin de s'assurer qu'elles sont adaptées à un usage donné.

Schémas d'identification basés sur les URN

Internet Engineering Task Force (IETF) www.ietf.org/

L'élaboration du concept d'URN découle directement des problèmes liés à l'identification basée sur l'emplacement. Un URN est un URI doté des propriétés d'un nom. Un URN ne dépend pas de l'emplacement de la ressource : « Le but ou la fonction d'un URN est de fournir un identificateur permanent unique permettant la reconnaissance et l'accès aux caractéristiques d'une ressource »¹¹. Les noms des ressources font référence à un seul objet durant toutes les étapes du cycle de vie.

Le concept d'URN offre un espace de nommage commun pour différents types d'identificateurs. Avant de définir une spécification formelle sur les URN, l'IETF a publié un document d'information énumérant les exigences fonctionnelles minimales pour les identificateurs de l'architecture URN (voir le tableau 1). Tout espace de nommage fonctionnant comme un système URN doit respecter ces exigences fonctionnelles.

Tableau 1
Exigences fonctionnelles pour les systèmes d'identification des ressources¹¹

Spécifications techniques

Le modèle des URN a été créé en 1997, au moment où l'IETF a défini officiellement sa syntaxe canonique en deux parties⁵. Un URN est composé de l'identificateur de l'espace de nommage (NID) et de la chaîne propre à l'espace de nommage (NSS).

L'élément NID contient le code d'identification pour un espace de nommage donné. En tant qu'utilisateur de l'architecture URN, l'espace de nommage répond aux exigences citées dans le tableau 1. Chaque espace de nommage est libre de définir la syntaxe de l'élément NSS. Un élément NSS est une chaîne d'identification qui pointe vers une ressource dans le contexte d'un espace de nommage donné.

Services de résolution

Le cadre URN fait la distinction entre les appellations de formats et les services de résolution. En séparant la façon dont les noms sont traduits de celle dont ils sont construits et attribués, on permet à tout service de pouvoir résoudre un URN. Cette indépendance rend toutefois nécessaire l'utilisation de mécanismes de registre pour repérer les services appropriés. Le Dynamic Delegation Discovery System (DDDS)¹² n'a pas encore été mis en œuvre à grande échelle.

Le DDDS comprend les spécifications d'un algorithme, d'une application et d'une base de données pour les services de résolution. L'application utilise l'algorithme DDDS pour récupérer de façon dynamique les documents des ressources Name Authority Pointer (NAPTR) normalisés en utilisant le DNS comme base de données distribuée. Les documents NAPTR contiennent des règles précises de transformation des chaînes que l'application applique à l'URN pour lequel des services de résolution faisant autorité sont requis¹².

La spécification DDDS ne précisant pas de protocole pour la communication entre les applications et les services de résolution, le protocole de résolution Trivial HTTP (THTTP) est la seule spécification qui existe¹³. Le THTTP est une convention simple pour les demandes de services de résolution du code qui peut aisément être mise en œuvre par les serveurs HTTP. Le tableau 2 décrit les étapes liées à la résolution des URN.

Tableau 2
Étapes de la résolution des URN

Maintenance

Tous les espaces de nommage URN sont enregistrés auprès de l'IANA avec un modèle de spécification¹⁴. Ces documents contiennent les renseignements d'enregistrement normalisés ainsi qu'une déclaration de la structure syntaxique et des renseignements sur la résolution. Les personnes responsables de l'enregistrement des espaces de nommage ont la responsabilité d'attribuer des identificateurs uniques et permanents dans leur domaine.

Mise en œuvre

Bien qu'un certain nombre d'espaces de nommage URN ont été enregistrés auprès de l'IANA, les modèles basés sur les URN n'ont pas encore été mis en œuvre à grande échelle en raison d'un manque de consensus sur un système de résolution normalisé. L'ébauche de la norme DDDS demeure au stade expérimental. La communauté Internet doit élaborer une infrastructure de résolution plus fiable et solide avant que l'on puisse mettre en œuvre des espaces de nommage basés sur les URN. La mise en œuvre des systèmes basés sur les URN est décrite à l'annexe B.

Localisateurs de ressources uniformes permanents (PURL)

OCLC Online Computer Library Center (OCLC)www.purl.oclc.org/

Les localisateurs de ressources uniformes permanents (PURL) sont une solution intérimaire pour assurer une permanence basée librement sur le concept des URN. L'élaboration du système de PURL présume que la solution idéale pour l'adressage basé sur l'emplacement réside dans la mise en œuvre de l'architecture URN de l'IETF. On reconnaît toutefois que le rythme d'élaboration des normes ne permet pas de relever les défis actuels en temps opportun¹⁵. Créés par l'OCLC, les services PURL sont compatibles avec plusieurs exigences fonctionnelles des URN. Lorsque les systèmes basés sur les URN seront mis en œuvre à plus grande échelle, les PURL seront convertis dans ce format¹⁶.

Une adresse URL identifie une ressource numérique en pointant vers son emplacement sur le réseau. Une adresse PURL est une adresse URL qui pointe directement vers un service intermédiaire de résolution. Ce service lie le PURL à un URL et retourne l'adresse de la ressource au client. L'URL associé à un PURL représente l'emplacement physique actuel de la ressource sur un hôte donné.

Spécifications techniques

Les PURL et les URL ont une relation de un à un. Comme les URN, les PURL sont des noms stables pour les ressources. L'emplacement de la ressource peut changer au fil du temps, mais le PURL attribué demeure le même. Les services PURL doivent maintenir à jour les URL des ressources sous leur contrôle.

Un PURL se compose de trois éléments : un protocole, une adresse du résolveur et un nom de ressource attribué par l'utilisateur.

L'adresse du résolveur assure l'unicité mondiale du PURL. L'espace de nommage peut être divisé hiérarchiquement en un domaine et divers sous-domaines. Il n'est pas nécessaire que la composante du nom du PURL comprenne une portion de la chaîne de l'URL connexe. Le nom de domaine et le PURL sont permanents – ni l'un ni l'autre ne peuvent être supprimés après leur création.

Service de résolution

Un résolveur de PURL fournit des services de résolution pour tous les PURL liés à l'espace de nommage de son domaine. Le système PURL utilise le protocole HTTP pour se connecter aux services de résolution et pour retourner les renseignements aux clients demandeurs. Le DNS traduit la composante d'adresse du résolveur du PURL en une adresse IP conventionnelle. Le fournisseur de services PURL à cette adresse traduit le nom de la ressource et renvoie au client l'emplacement de la ressource sous forme d'URL.

Une résolution réussie exige que le lien entre un PURL et un URL valide soit maintenu. Cette relation n'est pas mise à jour automatiquement. Si un URL devient désuet, la résolution sera un échec. Les agents de maintenance sont responsables de la mise à jour des renseignements sur leurs ressources avec le serveur PURL approprié. Le fonctionnement du système PURL dépend entièrement de l'engagement envers ce service.

Maintenance

OCLC héberge un serveur PURL sur lequel n'importe quel utilisateur peut créer de nouveaux sous-domaines et maintenir des PURL. Pour accéder à ce serveur, les utilisateurs doivent s'enregistrer auprès de l'OCLC. Les logiciels de résolution du serveur sont toutefois faciles à obtenir. Les utilisateurs peuvent télécharger un logiciel pour établir leurs propres services de résolution PURL indépendants de l'OCLC¹⁷.

Le logiciel PURL comprend des fonctionnalités permettant de créer et de maintenir les PURL dans un environnement distribué. Le maintien des URL à jour est une responsabilité partagée. Les utilitaires PURL permettent uniquement aux utilisateurs autorisés d'éditer la base de données. Le logiciel permet également de valider les liens entre les PURL et les URL. Les utilisateurs peuvent choisir de recevoir des rapports périodiques de validation qui contiennent la liste des PURL dont la résolution n'a pas fonctionné. Cette fonctionnalité facilite la maintenance des URL valides.

Mise en œuvre

Les résolveurs de PURL, offerts sur différents sites sur Internet, servent de passerelle vers les collections numériques locales. Les personnes qui veulent créer et gérer des PURL peuvent s'enregistrer comme utilisateurs sur un site de résolveur de PURL. Le principal utilisateur des PURL est le service OCLC de PURL bibliographique (voir l'annexe B). L'OCLC ne publie pas la liste exhaustive des utilisateurs enregistrés.

Handle System®

Corporation for National Research Initiatives (CNRI) www.handle.net

Élaboré par la Corporation for National Research Initiatives (CNRI), le Handle System® est composé d'un espace de nommage et d'un protocole ouvert, ainsi que de services de résolution et d'administration. Un pointeur est un nom unique attribué à une ressource d'information numérique. Les pointeurs ne dépendent pas de l'emplacement de la ressource puisqu'ils sont des identificateurs fondés sur le nom. Le Handle System® est un espace de nommage mondial et peut s'adapter aux espaces de nommage locaux existants.

Le Handle System® fonctionne sur l'Internet, mais ne dépend pas du DNS pour fournir des services de nommage des ressources. En raison de l'importance du DNS pour le routage du réseau, ce système permet d'éviter de le surcharger avec les fonctions générales de nommage des ressources¹⁸. Un protocole, un modèle de service et des fonctions de sécurité distincts permettent plutôt aux administrateurs de gérer le nommage des ressources sur le réseau public. Comme l'espace de nommage du système est défini séparément, l'application peut traiter les pointeurs sans préfixe URI. Les utilisateurs enregistrés avec un espace de nommage URN peuvent toutefois utiliser la technologie des pointeurs pour fournir les services de nommage et de résolution sous-jacents.

Le système utilise une architecture hiérarchique. Le CNRI gère le Registre mondial Handle (GHR), qui chapeaute divers services locaux Handle (LHS). Le LHS est responsable de la gestion des pointeurs associés à plusieurs autorités de nommage, chacune ayant défini un espace de nommage local. Ces autorités de nommage supervisent la création et l'attribution des identificateurs des ressources locales.

Spécifications techniques

L'espace de nommage du Handle System® est composé de deux éléments¹⁹. Le préfixe de l'espace de nommage représente une autorité de nommage donnée, tandis que le suffixe est un nom local attribué par cette autorité.

Les autorités de nommage dans le Handle System® sont uniques au monde et les noms locaux des pointeurs doivent être uniques dans leurs espaces de nommage respectifs. Les autorités de nommage peuvent être organisées de façon hiérarchique, avec les autorités enfants existant sous un espace de nommage parent. Les segments des autorités de nommage sont séparés par un point (« . »).

Service de résolution

Les services de résolution sont fournis par un système mondial de serveurs qui conserve les renseignements sur les pointeurs et les registres dans lesquels les ressources sont enregistrées. Les applications clientes interrogent le GHR pour identifier et repérer le LHS associé à l'autorité de nommage du pointeur. Le client peut ensuite communiquer avec le LHS où le pointeur est traduit. Afin d'améliorer le rendement de résolution, un LHS conserve souvent en antémémoire les résultats des interrogations du GHR. Ainsi, les recherches subséquentes sur le même pointeur peuvent être faites localement, ce qui réduit le trafic entre le client et le serveur.

Lorsqu'elles accèdent au système pour exécuter des processus de résolution et des processus administratifs, les applications clientes utilisent le protocole Handle System®²⁰. Ce protocole permet aux serveurs de pointeurs d'authentifier les clients en tant qu'administrateurs valides. Le système permet également aux serveurs mandataires de traiter les demandes de résolution à l'aide d'autres protocoles. Le serveur mandataire HTTP du Handle System® permet la résolution des pointeurs avec les navigateurs Web standard. Le serveur mandataire interroge le Handle System® pour obtenir des renseignements sur un pointeur et répond au client par HTTP.

Maintenance

Les administrateurs du Handle System® peuvent obtenir différents niveaux de contrôle. Les utilisateurs autorisés peuvent ajouter et supprimer des pointeurs, puis modifier leur valeur. Il est également possible de définir des responsabilités administratives pour chaque pointeur et de les exécuter à partir de n'importe quel point du réseau. Le système offre des services comme l'authentification et la confidentialité des données, mais la sécurité finale dépend des pratiques du client et du serveur. Par exemple, si la mise en antémémoire par les LHS accélère le traitement, elle présente cependant des risques puisque l'étape d'authentification est éliminée.

Mise en œuvre

Les services et le logiciel du Handle System® sont offerts par le CNRI qui supervise également la gestion des autorités de nommage du GHR²¹ et maintient le système des serveurs mandataires qui répondent aux demandes avec des protocoles différents²².

Le logiciel HANDLE.NET est offert en vertu d'une entente de licence publique et peut être téléchargé sans frais²³. Cependant, pour créer ou traduire des pointeurs, les utilisateurs doivent conclure une entente de service avec le CNRI. Pour s'inscrire en tant que fournisseur de services de résolution (RSP), il faut verser un montant unique de 50 $US qui couvre l'affectation et l'enregistrement d'une nouvelle autorité de nom dans le GHR. Des frais de service additionnels de 50 $US par année sont également requis. Ces frais sont réduits lorsqu'ils sont prépayés. Le CNRI se réserve le droit de les augmenter au besoin, pour assurer le fonctionnement du système.

Si plusieurs organisations utilisent les pointeurs à des fins d'identification permanente (voir l'annexe B), le principal utilisateur du Handle System® est l'International Digital Object Identifier Foundation (IDF).

Système DOI®

International Digital Object Identifier Foundation (IDF) www.doi.org

Le système d'identificateur des objets numérique (DOI) est une infrastructure, développée à titre de projet de collaboration entre le CNRI et l'Association of American Publishers (AAP), qui permet de gérer le contenu numérique. Géré par l'IDF, le système DOI® est un cadre général pour l'identification permanente des ressources numériques. Des fonctionnalités additionnelles permettent aux responsables de la mise en œuvre de personnaliser les services pour répondre à des exigences commerciales précises. Le système DOI® comprend des services de description des ressources et de résolution ainsi que des politiques conçues pour appuyer l'accès permanent²⁴. Le système DOI® est en cours de normalisation par l'Organisation internationale de normalisation (ISO)²⁵.

Le système DOI® est composé de quatre éléments. Une syntaxe formelle et des règles d'attribution pour le nommage des entités sont normalisés dans la norme ANSI/NISO Z39.84²⁶. Les services de résolution sont assurés par le Handle System®. Le système DOI® comprend également un modèle de données et un dictionnaire de données pour la description des ressources et un cadre politique obligatoire régit le fonctionnement du système²⁷.

Spécifications techniques

Les DOI sont des identificateurs permanents et actifs, dotés d'une syntaxe en deux parties. Le préfixe est composé du code de répertoire (DIR) et du code d'utilisateur enregistré (REG). Une barre oblique (« / ») marque le suffixe, qui contient la chaîne de suffixe DOI (DSS).

Pour différencier le système DOI® des autres utilisateurs du Handle System®, la valeur DIR demeure constante à 10. L'IDF attribue un REG aux organisations qui enregistrent des noms DOI. Le suffixe est une chaîne unique attribuée aux ressources par les utilisateurs enregistrés. Le DSS peut s'adapter aux schémas d'identification existants. Il incombe aux utilisateurs enregistrés de s'assurer de l'unicité du DSS dans chaque préfixe.

Les autorités d'enregistrement (RA) offrent des services pour le compte de certaines communautés d'utilisateurs. Les RA obtiennent des blocs de préfixes DOI à attribuer aux utilisateurs enregistrés. Elles sont également responsables du maintien de l'infrastructure qui permet aux utilisateurs enregistrés de déclarer et de gérer les DOI. Tous les utilisateurs enregistrés doivent maintenir à jour les renseignements sur les DOI de leurs préfixes. La permanence dépend de la maintenance continue des renseignements sur les valeurs en fonction desquelles les DOI peuvent être convertis. La déclaration sur le noyau des métadonnées DOI (KMD) assure l'interopérabilité des métadonnées descriptives. Le tableau 3 présente un résumé des éléments qui composent ce noyau de métadonnées.

Tableau 3
Métadonnées descriptives pour les ressources d'information dans le système DOI^®

Élément de métadonnée	Définition
DOI	Nom DOI attribué à la ressource
Identificateur de ressource	Identificateur dans un ou plusieurs autres systèmes d'identification
Nom de ressource	Nom commun de la ressource
Agent principal, rôle de l'agent	Renseignements sur la création de la ressource, sa publication, etc.
Type de structure	Structure de la ressource (c.-à-d. l'emplacement physique, l'emplacement numérique, le rendement ou les travaux abstraits)
Mode	Mode de perception (c.-à-d. audio, visuel, audiovisuel ou abstrait)
Type de ressource	Description du type de ressource (p. ex., fichier audio, article en série, PDF, etc.)

Les métadonnées sont échangées entre les RA à l'aide de déclarations de ressources de métadonnées (RMD) propres à chaque type de ressource (p. ex., publication en série, livre électronique, enregistrement sonore, etc.). Les KMD et les RMD sont toutes deux définies par des schémas XML (Langage de balisage extensible)²⁸.

Le dictionnaire de données <indecs> (iDD) décrit tous les éléments de métadonnées valides et leurs relations²⁹. Il sert également de registre pour le mappage des métadonnées DOI vers d'autres schémas. Toutes les déclarations de métadonnées sont validées en fonction des valeurs dans l'iDD.

Service de résolution

Le système DOI® utilise la technologie du Handle System® pour offrir des services de résolution³⁰. Les noms DOI peuvent être convertis en une ou plusieurs valeurs. Dans la résolution simple, un DOI se traduit par l'emplacement de la ressource (p. ex., une adresse URL)²⁴. Dans la résolution multiple, un DOI se traduit par une ou plusieurs entités reliées entre elles.

Pour exploiter les métadonnées saisies par le système DOI®, une application doit fournir des services allant au-delà de la simple résolution. Pour gérer les services, les DOI ayant des caractéristiques communes sont organisés en profils d'application (AP). Tous les DOI appartiennent à l'AP de base, qui comprend les services permettant d'identifier la RA d'attribution, la KMD et l'URL primaire pour la ressource.

Le CNRI a élaboré un module d'extension de résolveur offert gratuitement³¹ pouvant être intégré aux navigateurs standard et supporter la résolution des DOI en format d'origine (p. ex., doi:10.123/456). L'IDF maintient toutefois un serveur mandataire HTTP pour les demandes faites avec la syntaxe URL³². Bien qu'il est préférable d'utiliser la résolution directe plutôt que les serveurs mandataires, le CNRI et l'IDF reconnaissent que ce serveur est essentiel afin d'assurer l'intégrité des noms DOI sur Internet²⁴.

Maintenance

Le fonctionnement efficace du système DOI® dépend du succès des technologies sous-jacentes (p. ex., technologie du Handle System, iDD, etc.). Les risques associés à cette architecture sont en partie atténués par l'utilisation de normes reconnues. Le système se conforme également aux spécifications URI et URN.

Le système DOI® voit la permanence comme une fonction des organisations plutôt que comme des technologies purement informatiques. Des politiques détaillées de l'IDF régissent la participation au système, en définissant des pratiques uniformes faisant la promotion de la permanence³³.

Mise en œuvre

Pour attribuer les noms DOI, les responsables des ressources doivent payer des frais à la RA pour leur communauté d'utilisateurs. Les RA sont libres d'établir les frais en fonction de la nature des services qu'elles offrent. Bien que l'IDF n'est pas un organisme à but lucratif, les RA peuvent l'être.

L'IDF utilise un modèle de recouvrement des coûts où les frais sont utilisés pour financer et améliorer le système. Les demandeurs d'un statut de RA doivent être membres de l'IDF et payer des frais annuels de 35 000 $US²⁴. Les RA paient également des droits de franchise par nom DOI. En 2006, il en coûtait 0,04 $US par nom enregistré, avec un montant minimal de 20 000 $US annuellement²⁴. L'IDF demande également des frais de maintenance.

L'industrie de la publication électronique utilise le système DOI® à grande échelle, CrossRef étant la principale RA (voir l'annexe B). Une des obligations clés de cette communauté est de fournir des services de renvoi bibliographique efficaces. Le cadre OpenURL (voir l'annexe A) offre des services de liens vers des références sensibles au contexte qui acceptent les identificateurs DOI.

Clé de ressource archivistique (ARK)

California Digital Library (CDL)www.cdlib.org/inside/diglib/ark/

La conception et la création de la clé de ressource archivistique (ARK) sont fondées sur les conclusions d'une évaluation mondiale des systèmes d'identification permanente entreprise par John Kunze à la US National Library of Medicine (NLM). Les identificateurs ARK sont des adresses URL uniques au monde, qui offrent des liens actifs vers trois types d'objets d'information : les objets numériques, les métadonnées descriptives et les énoncés d'engagement des fournisseurs de service.

Le principe fondamental des ARK est que la permanence est en fait un engagement par les détenteurs des ressources numériques à fournir différents services. La permanence n'est pas le résultat d'un schéma ou d'un processus d'attribution de nom, elle n'est pas inhérente à un objet et ne lui est pas conférée par une syntaxe de nommage donnée³⁴. Même s'il est évident qu'il exige beaucoup de ressources, le fonctionnement efficace des systèmes d'identification est la responsabilité des détenteurs qui doivent maintenir un mécanisme pour l'indirection des noms. La permanence est le résultat de la gestion réussie des objets numériques et des identificateurs.

Le but de l'ARK est de tirer avantage de l'infrastructure Web existante pour mettre en œuvre un processus simple d'attribution de nom. L'accent n'est plus mis sur les schémas d'identification, mais sur l'engagement à maintenir des services qui assurent la permanence.

Spécifications techniques

En janvier 2008, la spécification ARK n'avait pas encore été approuvée officiellement en tant que norme IETF³⁴. Dans la syntaxe, les identificateurs commencent par l'étiquette ARK (ark:), qui est suivie du numéro de l'autorité de nommage (NAAN) et du nom, avec un qualificatif facultatif. Les identificateurs peuvent être précédés d'une adresse URL sous forme d'un port hôte de l'autorité de correspondance des noms (NMAH). La syntaxe est représentée de la façon suivante :

La composante NMAH est l'adresse Web remplaçable à laquelle les demandes de service ARK sont envoyées. Les ARK avec un NMAH sont des URL actifs. Le fait de séparer la portion NMAH de l'identificateur assure la longévité des ARK. Par exemple, à mesure que l'infrastructure Web évoluera, il sera possible d'annexer des chaînes d'identification d'ARK à un protocole d'extraction autre que le HTTP³⁴.

Le NAAN est un code numérique à 5 ou 9 chiffres qui représente l'autorité de nommage (NAA) responsable de nommer les ressources. Tout comme les URN, les NAAN sont enregistrés auprès de l'IANA et représentent l'espace de nommage du niveau supérieur dans le schéma ARK. Le nom de la ressource est une chaîne d'identification composée principalement de chiffres et de caractères alphabétiques autres que les voyelles, avec un crochet facultatif. Le schéma ARK peut s'adapter aux composantes hiérarchiques des ressources numériques. Une chaîne qualificative optionnelle peut être utilisée pour créer des points d'entrée dans une hiérarchie.

Une ARK est un lien actif vers différents types d'information : les objets numériques, les métadonnées et les énoncés d'engagement. Le protocole de mappage HTTP URL (THUMP)³⁵ permet aux clients de demander des renseignements pour une ARK en annexant une chaîne de recherche à l'identificateur. Les interrogations, qui commencent par un ou plusieurs points d'interrogation (« ? »), incitent les serveurs Web fonctionnant avec le THUMP à répondre aux demandes HTTP GET ou HTTP POST du client (voir le tableau 4).

Tableau 4
Interrogations sur les identificateurs ARK

Demande	Exemple de syntaxe	Réponse
ARK seulement	http://example.foo.com/object123	Le client est redirigé vers la ressource
ARK et un seul point d'interrogation (« ? »)	http://example.foo.com/object123?	Le client reçoit les métadonnées de la ressource
ARK et deux points d'interrogation (« ?? »)	http://example.foo.com/object123??	Le client reçoit l'énoncé d'engagement envers la permanence

Les enregistrements des citations électroniques de ressource (ERC) sont utilisés pour répondre aux demandes de métadonnées sur les ressources et d'énoncés sur la permanence³⁶. Les enregistrements ERC décrivent les objets numériques avec un minimum de métadonnées. Quatre éléments de noyau de métadonnées représentent une version simplifiée du Dublin Core³⁷. De même, les métadonnées ERC peuvent être augmentées par des éléments non noyau provenant d'autres vocabulaires.

Le noyau contient « l'historique » d'une ressource – qui, quoi, quand et où (voir le tableau 5).

Tableau 5
Éléments des noyaux de métadonnées ERC

Les enregistrements ERC sont organisés en segments, chacun contenant une histoire. Le type d'information contenu dans une histoire est précisé par l'étiquette du segment (voir le tableau 6).

Tableau 6
Étiquettes des segments ERC

Service de résolution

Les services ARK sont fournis par un système élaboré en collaboration avec la California Digital Library (CDL). L'utilitaire noid (identificateur opaque)³⁸ crée des générateurs qui créent les identificateurs permanents, les suivent et les lient aux ressources numériques. En fait, cet utilitaire est une base de données servant à gérer la composante Nom de la syntaxe ARK. noid utilise des modèles pour générer des identificateurs selon des spécifications prédéfinies. Il offre également des services de résolution des identificateurs d'ARK.

Lorsqu'elles doivent résoudre une ARK, les applications des utilisateurs analysent la chaîne pour repérer la chaîne NMAH facultative. La présence de cette composante renvoie le client vers un fournisseur de services ARK actif. La base de données noid fonctionne en arrière plan du serveur Web de ce fournisseur. Lorsque le serveur demande l'activation d'un URL, le résolveur noid doit renvoyer les enregistrements de la base de données qui correspondent à l'ARK.

S'il n'y a pas de composante NMAH, l'URL n'est pas actif. Dans ce cas, les applications clientes utilisent la composante NAAN pour repérer les NMAH, qui desservent les ARK de cet espace de nommage. Ces NMAH peuvent être repérés à l'aide d'un tableau d'autorité de nom disponible auprès de la CDL et qui peut être téléchargé dans les systèmes locaux³⁹. Il contient la liste de tous les NAAN attribués et l'emplacement des services pour chacun d'eux. Les clients peuvent également repérer les NMAH à l'aide du DNS. Basée sur la résolution des URN, cette méthode fait appel aux documents des ressources NAPTR ainsi qu'à un algorithme simplifié pour repérer les services appropriés.

Maintenance

La permanence dépend de la gestion efficace des liens entre les identificateurs et les ressources d'information. Un NAA est libre d'attribuer des identificateurs conformément à ses propres politiques, mais celles-ci doivent être publiques. Un NAA doit également avoir une stratégie documentée de la gestion des espaces de nommage.

Mise en œuvre

Les développeurs d'ARK reconnaissent que le schéma ARK ne convient pas à toutes les organisations³⁴. Les services qui appuient la permanence des identificateurs utilisent beaucoup de ressources. La CDL ne publie pas explicitement une liste des réalisateurs d'ARK, mais les organisations participantes et les projets sont publiés dans des tableaux NAAN accessibles publiquement³⁹. L'élaboration du schéma ARK se poursuit. L'annexe B décrit les mises en œuvre au CDL et à la Bibliothèque nationale de France (BnF).

Sommaire

Le présent rapport est un aperçu des différents schémas et systèmes permettant l'identification permanente des ressources numériques. Si les problèmes liés à l'identification des ressources fondée sur l'emplacement sont bien connus, chaque système les aborde d'un angle légèrement différent. Le rapport décrit une gamme de stratégies, s'étendant des spécifications techniques de la syntaxe des identificateurs à des cadres de politique complexes visant à créer un engagement commun envers les ressources numériques.

Une évaluation des schémas et des systèmes d'identification devrait faire suite à un examen approfondi des pratiques d'identification organisationnelle existantes. Si les systèmes d'identification existants sont rarement conçus en fonction de la permanence, ils reflètent les processus de travail organisationnels et les tendances dans les communautés de pratique existantes. L'interopérabilité et le partage des ressources d'information sont le but de tous les développements de l'architecture réseau. Lorsqu'elles évaluent la capacité d'identification permanente des systèmes, il est important que les organisations tiennent compte des technologies disponibles ainsi que des ressources requises pour la maintenance continue du système.

Annexe A : Cadre OpenURL

OCLC Online Computer Library Center (OCLC) www.oclc.org/research/projects/openurl/

Le cadre OpenURL établit des renvois bibliographiques ouverts et sensibles au contexte pour les ressources savantes⁴⁰. Ce cadre est essentiellement un protocole de transport des métadonnées sur les ressources d'information. OpenURL a été élaboré grâce à une subvention à l'Université Ghent, en Belgique, et a été acquis plus tard par le groupe Ex Libris Group, vendeur du résolveur SFX OpenURL⁴¹. OpenURL a été normalisé rapidement et a été homologué, en 2004, par la norme ANSI/NISO Z39.88⁴². En 2006, OCLC a été choisie comme agence de maintenance.

La sensibilité au contexte permet à OpenURL d'aborder la question « d'exemplaire approprié »⁴³. De plus en plus, les articles sont publiés dans diverses collections et relèvent d'une grande variété de détenteurs. Lorsqu'il existe plusieurs exemplaires d'une même ressource, l'accès est souvent régi par plus d'une politique. OpenURL s'assure que les demandes de ressources par les utilisateurs sont envoyées à des exemplaires conformes à leurs privilèges. Les OpenURL comportent des métadonnées bibliographiques sur la ressource référencée, des renseignements sur le contexte de réseau dans lequel se situe la référence ainsi que des renseignements sur le contexte dans lequel la demande de service a été faite. Un OpenURL transporte des paquets formés d'un identificateur de la ressource et des métadonnées connexes. Ces paquets, appelés représentations ContextObject, sont des structures de données composées qui lient les métadonnées sur la ressource, le résolveur et le demandeur. La syntaxe OpenURL est définie par les spécifications génériques des URI³. Le ContextObject est défini par le format ContextObject Clef/valeur codée (Key/Encoded-Value), une spécification qui utilise les demandes HTTP GET ou HTTP POST pour la transmission et le traitement des données.

La syntaxe OpenURL comprend deux composantes séparées par un point d'interrogation (« ? "). L'URL de base (BASE-URL) est un releveur de coordonnées pour le service traitant les OpenURL et la composante d'interrogation (QUERY) décrit les métadonnées transportées par le paquet.

Les OpenURL sont traités par les applications OpenURL. La résolution se produit lorsque le processus de l'URL de base agit sur la composante d'interrogation précisée.

En plus de servir d'agence de maintenance pour OpenURL, l'OCLC fournit également les services de résolution. Un élément du registre WorldCat Registry, le registre OpenURL Resolver Registry⁴⁴, maintient les renseignements sur les services de résolution disponibles pour les OpenURL. Les chaînes reçues par le registre sont redirigées vers les résolveurs locaux en fonction de l'adresse IP de l'entité qui présente la demande. Les nouvelles organisations qui veulent mettre ce cadre en œuvre doivent présenter une demande à OCLC et télécharger le logiciel OpenURL 1.0⁴⁵.

Annexe B : Profils d'organisations ayant mis en œuvre les différents systèmes

Schémas d'identification basés sur les URN

Bibliothèque nationale de Finlande

La communauté des bibliothèques est considérée comme étant l'utilisateur le plus visible des URN. La Bibliothèque nationale de Finlande (www.nationallibrary.fi/) attribue des URN sous forme de numéros bibliographiques nationaux (NBN) à ses collections numériques qui n'ont pas d'identificateur attribué par l'éditeur (p. ex., les ISBN)⁴⁶. Un NBN sert à identifier les ressources qui ne sont pas publiées par les moyens conventionnels.

L'objectif du projet de bibliothèque de dépôt européenne en réseau (NEDLIB)⁴⁷ est d'élaborer une infrastructure pour soutenir la saisie de publications électroniques, conforme aux lignes directrices sur le dépôt légal des différentes bibliothèques nationales. Dans le cadre de ce projet, la Bibliothèque nationale de Finlande a élaboré un générateur d'URN pour créer les NBN que les auteurs, les éditeurs et autres attribueront aux ressources numériques acquises durant la collecte sur le Web. Les services de résolution ont été élaborés et mis en œuvre à l'interne, avec la collaboration de l'Université de Helsinki.

Organization for the Advancement of Structured Information Standards (OASIS)

L'Organization for the Advancement of Structured Information Standards (OASIS) (www.oasis-open.org/home/index.php) est un consortium axé sur l'élaboration et l'adoption de normes ouvertes pour la société de l'information. Dans le cadre de ses fonctions, l'OASIS produit divers documents, y compris des normes, des ébauches fonctionnelles, des schémas, etc. Un espace de nommage OASIS basé sur les URN est défini par la RFC 3121⁴⁸. L'OASIS utilise cet espace de nommage pour générer des identificateurs permanents pour ses ressources électroniques.

Localisateur de ressources uniformes permanent (PURL)

Services OCLC de PURL bibliographiques

Le Program for Cooperative Cataloging (PCC) est un programme coopératif international coordonné par la Bibliothèque du Congrès (LC), dans lequel les participants contribuent aux programmes Cooperative Online Serials (CONSER) et Monographic Bibliographic Record (BIBCO). Le service OCLC de PURL bibliographique (http://bibpurl.oclc.org/) permet aux participants de CONSER et de BIBCO de maintenir en collaboration les PURL situés dans la zone 856 (Emplacement et adresse électroniques) du format MARC 21 pour les données bibliographiques. Le service permet aux participants de partager la responsabilité de maintenir à jour les liens dans le catalogue national.

Le serveur PURL hébergé par OCLC est disponible gratuitement. La mise en œuvre du service OCLC faisait suite à un important projet-pilote mené par CONSER en 2001 et en 2002⁴⁹. En collaboration avec Zepheira, OCLC a annoncé ses plans pour réorganiser le service⁵⁰. Les services PURL de OCLC seront mis à jour pour refléter les changements associés au Web sémantique.

Bibliothèque nationale de l'Australie (NLA)

La bibliothèque nationale de l'Australie (NLA) et un certain nombre d'autres organisations patrimoniales collaborent à l'élaboration et à la maintenance de PANDORA, les archives Web de l'Australie (http://pandora.nla.gov.au/). L'objectif de PANDORA est d'assurer un accès à long terme à d'importantes publications australiennes en ligne.

La NLA gère présentement le service de résolveur de PURL australien, qui permet aux éditeurs d'attribuer des identificateurs permanents aux publications numériques et aux sites Web (http://purl.nla.gov.au/). À l'origine, ce service était utilisé pour supporter l'accès aux ressources dans PANDORA. Plus tard, la NLA a créé son propre schéma pour attribuer des URL permanents aux ressources de ses collections. Ces identificateurs sont attribués automatiquement par le système intégré d'archivage numérique PANDAS de PANDORA, élaboré à l'interne et mis en œuvre en 2001. Si PANDORA a abandonné les identificateurs PURL, la NLA continue d'offrir des services de résolution PURL pour les éditeurs sur son site Web.

Handle System®

Library of Congress National Digital Library Program (NDLP)

Le programme de bibliothèque numérique nationale (NDLP) est une initiative de la LC American Memory (http://memory.loc.gov/ammem/index.html), qui porte sur la conversion de documents historiques en format numérique afin de les rendre accessibles en ligne. Le NDLP utilise le Handle System® pour fournir des identificateurs uniques au monde aux ressources d'information numériques⁵¹.

Comme elle est inscrite au Handle System®, la LC maintient des services de pointeurs locaux qui gèrent les associations entre les identificateurs permanents et les renseignements sur les ressources numériques. Le serveur de la LC résout les pointeurs pour les clients demandeurs. Le NDLP a établi une politique interne pour l'attribution des pointeurs ainsi que des lignes directrices sur l'utilisation des pointeurs avec des sources référencées externes à la LC.

Defense Virtual Information Architecture (DVIA)

Le Defense Technical Information Center (DTIC), la Defense Advanced Research Projects Agency (DARPA) et le CNRI collaborent au projet de Defense Virtual Information Architecture (DVIA) (www.cnri.reston.va.us/dtic.html). L'objectif du projet est de poursuivre le développement de l'architecture des objets numériques, conçue avec le Handle System®, tout en créant une bibliothèque numérique des données du DTIC.

Dans le cadre de ce projet, le CRNI élaborera un registre distribué pour les objets numériques qui utilisent des pointeurs pour repérer les objets dans le service. Le Handle System® assurera les services de résolution pour les ressources sur le réseau. Le projet incorporera également un système existant d'extraction des renseignements ainsi qu'une interface utilisateur, afin de démontrer comment les composantes du CNRI pourraient être utilisées dans une situation réelle. Le registre utilise la technologie OpenURL pour établir des liens sensibles au contexte vers les ressources d'information. Les recherches et le développement du projet DVIA se poursuivent.

Advanced Distributed Learning (ADL) Initiative

L'initiative Advanced Distributed Learning (ADL) (www.adlnet.gov/index.aspx) élabore et met en œuvre des technologies d'apprentissage au sein du Department of Defense (DoD) des États-Unis. ADL élabore des normes, des outils et un contenu d'apprentissage qui seront utilisés dans un environnement d'information distribuée. Le Sharable Content Object Reference Model (SCORM) est une spécification technique servant à l'élaboration et au déploiement d'objets de contenu numérique dans un réseau. Cette initiative fait appel à la Content Object Repository Discovery and Resolution Architecture (CORDRA), une infrastructure de recherche, d'identification, de résolution et de livraison de ces objets.

L'initiative ADL a choisi la technologie Handle System® pour générer et résoudre les identificateurs permanents attribués aux objets de contenu partageable. Le CNRI participe également à la conception du registre ADL (ADL-R) qui facilitera la recherche et la réutilisation du contenu en servant de registre local des objets numériques disponibles au sein du DoD.

Système DOI®

CrossRef

CrossRef (www.crossref.org/index.html) permet aux utilisateurs de publications savantes de relier les références aux ressources d'information citées et fonctionne sur une base inter-éditeur, où les éditeurs acceptent que leur contenu soit relié, par des liens entrants et des liens sortants, au contenu d'autres participants. Tout éditeur de publication savante peut devenir membre de CrossRef. L'établissement de liens réciproques est la clé qui assure le passage entre les ressources d'information détenues par les différents éditeurs.

CrossRef utilise le système DOI® pour identifier de façon unique les ressources numériques. CrossRef est une RA dans le contexte du système DOI®⁵² et, à ce titre, doit fournir une infrastructure permettant aux éditeurs de déclarer et de maintenir les métadonnées pour leurs ressources d'information. En déposant les DOI et les métadonnées descriptives dans le système CrossRef, les éditeurs permettent l'établissement de liens entrants vers les ressources dans leurs collections. Les liens sortants sont traités en interrogeant la base de données CrossRef, afin d'identifier les DOI. CrossRef permet aux éditeurs de contrôler l'accès en texte intégral à leurs ressources. Pour pouvoir intégrer leur contenu à celui du système conventionnel des bibliothèques, les éditeurs qui utilisent CrossRef doivent utiliser les OpenURL.

Presses scientifiques du Conseil national de recherches du Canada (CNRC)⁵³

Les Presses scientifiques du Conseil national de recherches du Canada (http://pubs.nrc-cnrc.gc.ca/) publient plusieurs revues, monographies et comptes rendus de conférence. Elles ont également le mandat d'appuyer la communauté scientifique, en fournissant des services aux éditeurs scientifiques. En tant qu'éditeur de publications savantes, le CNRC est membre de CrossRef et utilise les DOI pour identifier ses ressources scientifiques. Le CNRC a un préfixe DOI qui lui a été attribué par CrossRef. En attribuant des DOI et des métadonnées à ses ressources, le CNRC permet l'établissement de liens entrants vers son contenu. Les liens sortants depuis les références du CNRC sont établis en interrogeant CrossRef pour obtenir les DOI des ressources gérées par d'autres éditeurs.

Clé de ressource archivistique (ARK)

California Digital Library (CDL)

L'objectif de la California Digital Library (CDL) (www.cdlib.org/) de l'Université de la Californie a pour but de servir de leader dans l'utilisation novatrice de la technologie pour l'élaboration de collections et de services bibliographiques numériques.

Bien que la CDL participe au développement de l'ARK, elle est également la principale utilisatrice du système. En 2003, la CDL avait attribué 80 000 ARK à des ressources de ses propres collections⁵⁴. Un engagement ferme à maintenir les services est essentiel pour assurer la permanence dans le système ARK. C'est pourquoi la CDL attribue des PURL aux ressources qui sont hors de son contrôle.

Le NAAN de la CDL est 13030⁵⁵. Les ARK générés par la CDL utilisent des crochets terminaux et sont limités aux chiffres et aux caractères alphabétiques autres que des voyelles. Cette stratégie vise à atténuer les risques liés à l'utilisation d'un seul caractère et les erreurs de transposition⁵⁴. Pour générer les ARK et lier les métadonnées connexes, la CDL utilise l'application de source ouverte noid.

La CDL continue d'honorer son engagement envers la permanence des ARK, dont elle est responsable, même si l'énoncé d'engagement officiel de l'organisation n'est pas entièrement stable. Le document continuera d'être modifié et révisé pour que la CDL continue de respecter les exigences en matière de permanence, à mesure qu'elles évolueront au fil du temps.

Bibliothèque nationale de France (BnF)

La Bibliothèque nationale de France (BnF) (www.bnf.fr/) a mis en œuvre un système basé sur les ARK pour l'identification permanente des ressources numériques de ses collections. Le principal argument justifiant l'adoption des ARK concernait l'harmonisation de l'identification des ressources avec la préservation à long terme dans le contexte d'un registre numérique fondé sur l'OAIS⁵⁶.

En tant que bibliothèque nationale, la BnF possède des collections composées de toute une gamme de ressources d'information – des publications en série et des livres au contenu numérique. La BnF utilise les identificateurs d'ARK pour les objets avec différents schémas d'identification existants (p. ex., ISSN, ISBN, DOI, etc.). Le système ARK a été choisi en partie parce qu'il pouvait s'adapter aux schémas d'identification existants associés aux processus de développement et de numérisation des différentes collections de la BnF. Les ARK permettent également à la BnF de référencer les ressources avec des éléments hiérarchiques (p. ex., les pages d'un livre numérisé). La BnF espère que, dans le contexte d'un seul registre numérique, l'utilisation des identificateurs d'ARK simplifiera la gestion des ressources au fil du temps.

Annexe C : Glossaire

Annexe D : Liste d'acronymes

Le tableau suivant contient les acronymes utilisés dans le corps de ce rapport. Les acronymes sont présentés dans l'ordre alphabétique anglais et ne sont pas liés à leur schéma ou système.

ACRONYME	NOM
AAP	Association of American Publishers
ANSI	American National Standards Institute
AP	Profil d’application
ARIN	American Registry for Internet Numbers
ARK	Clé de ressource archivistique
CDL	California Digital Library
CNRI	Corporation for National Research Initiatives
DCMI	Dublin Core Metadata Initiative
DDDS	Dynamic Delegation Discovery System
DIR	Code de répertoire
DNS	Système de noms de domaine
DOI	Identificateur des objets numériques ou Système DOI
DSS	Chaîne de suffixe DOI
ERC	Citation de ressource électronique
GHR	Registre mondial Handle
HTTP	Protocole de transfert hypertexte
IANA	Internet Assigned Numbers Authority
iDD	Dictionnaire de données <indecs>
IDF	International Digital Object Identifier Foundation
IETF	Internet Engineering Task Force
IP	Protocole Internet
IPv4 / v6	Protocole Internet version 4 / version 6
ISO	Organisation internationale de normalisation
KMD	Déclaration sur le noyau des métadonnées
LC	Bibliothèque du Congrès
LHS	Services locaux Handle
NAAN	Numéro d’autorité de nommage
NAPTR	Documents des ressources Name Authority Pointer
NBN	Numéros bibliographiques nationaux
NID	Identificateur d’espace de nommage
NMAH	Port hôte de l’autorité de correspondance des noms
noid	Identificateur opaque
NSS	Chaîne propre à l’espace de nommage
OAIS	Open Archival Information System
OCLC	Online Computer Library Center
PURL	Localisateur de ressources uniformes permanent
RA	Autorités d’enregistrement
REG	Code d’utilisateur enregistré
RFC	Demande de commentaires
RLG	Research Libraries Group
RMD	Déclarations de ressources de métadonnées
RSP	Fournisseur de services de résolution
TDR	Dépôt numérique fiable
THTTP	Protocole de résolution Trivial HTTP
THUMP	Protocole de mappage HTTP URL
URC	Caractéristique de ressources uniformes
URI	Identificateur de ressources uniformes
URL	Localisateur de ressources uniformes
URN	Nom de ressources uniformes
W3C	Consortium W3C
XML	Langage de balisage extensible

Annexe E : Bibliographie sommaire

Ressources générales

Beagrie, N. et D. Greenstein. « A strategic framework for creating and preserving digital collections ». Arts and Humanities Data Service, Juillet 2001, http://ahds.ac.uk/strategic.pdf. Consulté le 3 janvier 2008.

Causton, L. « Identifying and describing web resources ». European Commission DGXIII/E-4, www.iua.upf.es/~jblat/material/doctorat/web_resources.pdf. Consulté le 16 juillet 2007.

Electronic Resource Preservation and Access Network. « Final report : Persistent Identifiers ». erpaSeminar. Cork, Irlande. les 17 et 18 juin 2004, www.erpanet.org/events/2004/cork/Cork%20Report.pdf. Consulté le 9 août 2007.

Gilliand-Swetland, A.J. « Enduring paradigm, new opportunities: The value of the archival perspective in the digital environment ». Washington, D.C. : Council on Library and Information Resources, Février 2000, http://clir.org/pubs/reports/pub89/pub89.pdf. Consulté le 22 janvier 2008.

Hilse, H-W. et J. Kothe. « Implementing persistent identifiers: Overview of concepts, guidelines and recommendations ». Londres: Consortium of European Research Libraries, 2006, http://bibpurl.oclc.org/web/16923. Consulté le 26 juillet 2007.

Online Computer Library Center (OCLC), É.-U. « Trustworthy repositories audit and certification: Criteria and Checklist ». Février 2007, www.crl.edu/PDF/trac.pdf. Consulté le 22 janvier 2008.

Research Libraries Group. « Trusted Digital Repositories: Attributes and Responsibility ». Mai 2002, www.oclc.org/programs/ourwork/past/trustedrep/repositories.pdf. Consulté le 22 janvier 2008.

Watson, J. « The LIFE Project research review: Mapping the landscape, riding a life cycle ». Lifecycle Information for E-Literature (LIFE), Novembre 2005, http://eprints.ucl.ac.uk/1856/1/review.pdf. Consulté le 3 février 2008.

Ressources sur les schémas d'identification et les services connexes

Nom de ressource uniforme (URN)

Daniel, R. « A trivial convention for using HTTP in URN resolution ». RFC 2169. Internet Engineering Task Force, Juin 1997, http://tools.ietf.org/html/rfc2169. Consulté le 26 juillet 2007.

Hoffman, P.E. et R. Daniel, Jr. « URN resolution overview. Internet-Draft ». Expires October 21, 1995, International Federation of Library Associations, www.ifla.org.sg/documents/libraries/cataloging/metadata/urn3.txt. Consulté le 26 juillet 2007.

Mealling, M. « Dynamic Delegation Discovery System (DDDS) Part one: The comprehensive DDDS ». RFC 3401. Internet Engineering Task Force, Octobre 2001, http://tools.ietf.org/html/rfc3401. Consulté le 26 juillet 2007.

----------. « Dynamic Delegation Discovery System (DDDS) Part two: The algorithm ». RFC 3402. Internet Engineering Task Force, Octobre 2002, http://tools.ietf.org/html/rfc3402. Consulté le 26 juillet 2007.

----------. « Dynamic Delegation Discovery System (DDDS) Part three: The Domain Name System (DNS) database ». RFC 3403. Internet Engineering Task Force, October 2002, http://tools.ietf.org/html/rfc3403. Consulté le 26 juillet 2007.

----------. « Dynamic Delegation Discovery System (DDDS) Part four: The Uniform Resource Identifiers (URI) resolution application ». RFC 3404. Internet Engineering Task Force, Octobre 2002, http://tools.ietf.org/html/rfc3404. Consulté le 26 juillet 2007.

----------. « Dynamic Delegation Discovery System (DDDS) Part five: URI.ARPA assignment procedures ». RFC 3405. Internet Engineering Task Force, Octobre 2002, http://tools.ietf.org/html/rfc3405. Consulté le 26 juillet 2007.

Moats, R. « URN syntax ». RFC 2141. Internet Engineering Task Force, Mai 1997, http://tools.ietf.org/html/rfc2141. Consulté le 26 juillet 2007.

Sollins, K. et L. Masinter. « Functional requirements for Uniform Resource Names ». RFC 1737. Internet Engineering Task Force, Décembre 1994, http://tools.ietf.org/html/rfc1737. Consulté le 26 juillet 2007.

Localisateur de ressources uniformes permanent (PURL)

Shafer, K., S. Weibel, E. Jul et J. Fausey. « Introduction to Persistent Uniform Resource Locators ».http://purl.oclc.org/docs/inet96.html. Consulté le 26 juillet 2007.

Weibel, S., E. Jul et K. Shafer. « PURLs: Persistent Uniform Resource Locators ».http://purl.oclc.org/docs/new_purl_summary.html. Consulté le 22 janvier 2008.

Handle System®

Corporation for National Research Initiatives (CNRI). « HANDLE.NET services: Global Handle Registry® ». Handle System, www.handle.net/introduction.html. Consulté le 27 juillet 2007.

----------. « Proxy server system. Handle System ». www.handle.net/proxy.html. Consulté le 27 juillet 2007.

Sun, S., L. Lannom et B. Boesch. « Handle System overview ». RFC 3650. Internet Engineering Task Force, Novembre 2003, http://tools.ietf.org/html/rfc3650. Consulté le 27 juillet 2007.

----------. « Handle System namespace and service definition ». RFC 3651. Internet Engineering Task Force, Novembre 2003, http://tools.ietf.org/html/rfc3651. Consulté le 27 juillet 2007.

Sun, S., S. Reilly, L. Lannom et J. Petrone. « Handle System protocol (ver 2.1) specification ». RFC 3652. Internet Engineering Task Force, Novembre 2003, http://tools.ietf.org/html/rfc3652. Consulté le 27 juillet 2007.

Système DOI®

International DOI Foundation (IDF). DOI® handbook. Version 4.4.1. Le 5 octobre 2006, www.doi.org/hb.html. Consulté le 30 juillet 2007.

----------. « The DOI System: Introductory overview ». www.doi.org/overview/sys_overview_021601.html. Consulté le 30 juillet 2007.

National Information Standards Organization (NISO). « ANSI/NISO Z39.84-2005: Syntax for the Digital Object Identifier ». le 30 septembre 2005, www.niso.org/standards/ressources/Z39-84-2005.pdf. Consulté le 30 juillet 2007.

Clé de ressource archivistique (ARK)

Dublin Core Metadata Initiative (DCMI) Metadata Community. « The DC kernel application profile. Draft 1 ». DCMI, le 7 août 2007, http://dublincore.org/kernelwiki/KernelApplicationProfileDraft. Consulté le 16 août 2007.

Gamiel, K., J. Kunze and N. Nassar. « THUMP – The HTTP URL Mapping Protocol. Internet-Draft ». le 24 février 2007, http://tools.ietf.org/html/draft-kunze-thump-02. Consulté le 28 janvier 2008.

Kunze, J.A. « A metadata kernel for electronic permanence ». Le 5 octobre 2001, http://jodi.tamu.edu/Articles/v02/i02/Kunze/kunze-final.pdf. Consulté le 2 août 2007.

----------. « Towards Electronic Persistence Using ARK Identifiers ». Juillet 2003, www.cdlib.org/inside/diglib/ark/arkcdl.pdf. Consulté le 2 août 2007.

Kunze, J.A., et R.P.C. Rodgers. « The ARK persistent identifier scheme ». Ébauche de la CDL. Le 24 juillet 2007, www.cdlib.org/inside/diglib/ark/arkspec.pdf. Consulté le 16 août 2007.

Kunze, J.A., et M.A. Russell. « [noid (Nice Opaque Identifier) minting and binding tool] ». Le 19 avril 2006, www.cdlib.org/inside/diglib/ark/noid.pdf. Consulté le 2 août 2007.

Kunze, J., et A. Turner. « Kernel metadata and Electronic Resource Citations (ERCs) ». Draft. Dublin Core Metadata Initiative (DCMI) Kernel Metadata Task Group, le 11 août 2007, http://dot.ucop.edu/home/jak/erc.html. Consulté le 16 août 2007.

OpenURL

Apps, A., et R. MacIntyre. « Why OpenURL? » D-Lib Magazine, Mai 2006, www.dlib.org/dlib/may06/apps/05apps.html. Consulté le 7 juin 2007.

National Information Standards Organization (NISO). « ANSI/NISO Z39.88-2004. The OpenURL framework for context-sensitive services ». Le 15 avril 2007, www.niso.org/standards/ressources/Z39_88_2004.pdf. Consulté le 1^er août 2007.

Van de Sompel, H., et O. Beit-Arie. « Open linking in the scholarly information environment using the OpenURL framework ». D-Lib Magazine, Mars 2001, www.dlib.org/dlib/march01/vandesompel/03vandesompel.html. Consulté le 28 janvier 2008

Ressources sur la communauté de développement des normes et des spécifications techniques pour Internet

American National Standards Institute (ANSI)
www.ansi.org/

Organisation internationale de normalisation (ISO)
www.iso.org/iso/fr/home.htm

Internet Assigned Numbers Authority (IANA)
www.iana.org/

Internet Corporation for Assigned Names and Numbers (ICANN)
www.icann.org

Internet Engineering Task Force (IETF)
www.ietf.org/home.html

National Information Standards Organization (NISO)
www.niso.org/

National Library of Australia Preserving Access to Digital Information
www.nla.gov.au/padi/

World Wide Web Consortium (W3C)
www.w3.org/

Documents de demande de commentaires (RFC)

L'index des documents de demande de commentaires de l'IETF est disponible au http://tools.ietf.org/rfc/

N° de RFC	Article
RFC 1737	Sollins, K. et L. Masinter. « Functional requirements for Uniform Resource Names ». RFC 1737. Internet Engineering Task Force, Décembre 1994, http://tools.ietf.org/html/rfc1737. Consulté le 26 juillet 2007.
RFC 1738	Berners-Lee, T., L. Masinter et M. McCahill. « Uniform Resource Locators (URL) ». RFC 1738. Internet Engineering Task Force, Décembre 1994, http://tools.ietf.org/html/rfc1738. Consulté le 26 juillet 2007.
RFC 2141	Moats, R. « URN syntax ». RFC 2141. Internet Engineering Task Force, Mai 1997, http://tools.ietf.org/html/rfc2141. Consulté le 26 juillet 2007.
RFC 2169	Daniel, R. « A trivial convention for using HTTP in URN resolution ». RFC 2169. Internet Engineering Task Force, Juin 1997, http://tools.ietf.org/html/rfc2169. Consulté le 26 juillet 2007.
RFC 3121	Best, K. « A URN namespace for OASIS ». RFC 3121. Internet Engineering Task Force, Juin 2001, http://tools.ietf.org/html/rfc3121. Consulté le 26 juillet 2007.
RFC 3188	Hakala, J. « Using National Bibliography Numbers as Uniform Resource Names ». RFC 3188. Internet Engineering Task Force, Octobre 2001, http://tools.ietf.org/html/rfc3188. Consulté le 26 juillet 2007.
RFC 3305	Mealling, M. et R. Denenberg. « Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and recommendations ». RFC 3305. Internet Engineering Task Force, Août 2002, http://tools.ietf.org/html/rfc3305. Consulté le 26 juillet 2007.
RFC 3401	Mealling, M. « Dynamic Delegation Discovery System (DDDS) Part one: The comprehensive DDDS ». RFC 3401. Internet Engineering Task Force, Octobre 2002, http://tools.ietf.org/html/rfc3401. Consulté le 26 juillet 2007.
RFC 3402	Mealling, M. « Dynamic Delegation Discovery System (DDDS) Part two: The algorithm ». RFC 3402. Internet Engineering Task Force, Octobre 2002, http://tools.ietf.org/html/rfc3402. Consulté le 26 juillet 2007.
RFC 3403	Mealling, M. « Dynamic Delegation Discovery System (DDDS) Part three: The Domain Name System (DNS) database ». RFC 3403. Internet Engineering Task Force, Octobre 2002, http://tools.ietf.org/html/rfc3403. Consulté le 26 juillet 2007.
RFC 3404	Mealling, M. « Dynamic Delegation Discovery System (DDDS) Part four: The Uniform Resource Identifiers (URI) resolution application ». RFC 3404. Internet Engineering Task Force, Octobre 2002, http://tools.ietf.org/html/rfc3404. Consulté le 26 juillet 2007.
RFC 3405	Mealling, M. « Dynamic Delegation Discovery System (DDDS) Part five: URI.ARPA assignment procedures ». RFC 3405. Internet Engineering Task Force, Octobre 2002, http://tools.ietf.org/html/rfc3405. Consulté le 26 juillet 2007.
RFC 3650	Sun, S., L. Lannom et B. Boesch. « Handle System overview ». RFC 3650. Internet Engineering Task Force, Novembre 2003, http://tools.ietf.org/html/rfc3650. Consulté le 27 juillet 2007.
RFC 3651	Sun, S., L. Lannom et B. Boesch. « Handle System namespace and service definition ». RFC 3651. Internet Engineering Task Force, Novembre 2003, http://tools.ietf.org/html/rfc3651. Consulté le 27 juillet 2007.
RFC 3652	Sun, S., S. Reilly, L. Lannom et J. Petrone. « Handle System protocol (ver 2.1) specification ». RFC 3652. Internet Engineering Task Force, Novembre 2003, http://tools.ietf.org/html/rfc3652. Consulté le 27 juillet 2007.
RFC 3986	Berners-Lee, T., R. Fielding et L. Masinter. « Uniform Resource Identifier (URI): Generic syntax ». RFC 3986. Internet Engineering Task Force, Janvier 2005, http://tools.ietf.org/html/rfc3986. Consulté le 26 juillet 2007.
RFC 5013	Kunze, J. et T. Baker. « The Dublin Core metadata element set ». RFC 5013. Internet Engineering Task Force, Août 2007, http://tools.ietf.org/html/rfc5013. Consulté le 4 février 2008.

---

¹ M. Dickison, « Localisateurs permanents pour les publications du gouvernement fédéral canadien  : Résumé d’une étude menée pour le compte du Programme des services de dépôt et de la Bibliothèque nationale du Canada, » Ottawa, Bibliothèque nationale du Canada, 2002, www.collectionscanada.ca/obj/r4/f2/r4-500.1-f.pdf Consulté le 22 janvier 2008.

² American Registry for Internet Numbers (ARIN), « IPv4 and IPv6, » ARIN, www.arin.net/about_us/media/fact_sheets/IPv4_IPv6.pdf Consulté le 22 janvier 2008.

³ T. Berners-Lee, R. Fielding et L. Masinter, « Uniform Resource Identifier (URI): Generic syntax, » RFC 3986, Internet Engineering Task Force (IETF), Janvier 2005, http://tools.ietf.org/html/rfc3986 Consulté le 22 janvier 2008.

⁴ T. Berners-Lee, L. Masinter et M. McCahill, « Uniform Resource Locators (URL), » RFC 1738, IETF, Décembre 1994, http://tools.ietf.org/html/rfc1738 Consulté le 22 janvier 2008.

⁵ R. Moats, « URN syntax, » RFC 2141, IETF, Mai 1997, http://tools.ietf.org/html/rfc2141 Consulté le 28  janvier 2008.

⁶ Pour une explication détaillée des catégories, voir M. Mealling et R. Denenberg, « Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and recommendations, » RFC 3305, IETF, Août 2002, http://tools.ietf.org/html/rfc3305 Consulté le 22 janvier 2008.

⁷ J. Watson, « The LIFE Project research review: Mapping the landscape, riding a life cycle, » Lifecycle Information for E-Literature (LIFE), Novembre 2005, http://eprints.ucl.ac.uk/1856/1/review.pdf Consulté le 3 février 2008.

⁸N. Beagrie et D. Greenstein, « A strategic framework for creating and preserving digital collections, » Arts and Humanities Data Service, Juillet 2001, http://ahds.ac.uk/strategic.pdf Consulté le 22 janvier 2008.

⁹ A.J. Gilliland-Swetland, « Enduring paradigm, new opportunities: The value of the archival perspective in the digital environment, » Washington: Council on Library and Information Resources, Février 2000, http://clir.org/pubs/reports/pub89/pub89.pdf Consulté le 22 janvier 2008.

¹⁰ Pour des renseignements sur les dépôts numériques de confiance, voir Research Libraries Group (RLG), « Trusted Digital Repositories: Attributes and responsibilities, » Mai 2002, www.oclc.org/programs/ourwork/past/trustedrep/repositories.pdf Consulté le 22 janvier 2008 et Online Computer Library Center (OCLC), « Trustworthy repositories audit and certification: Criteria and checklist,» Février 2007, www.crl.edu/PDF/trac.pdf Consulté le 22 janvier 2008. Le concept des dépôts numériques fiable (TDR) est fondé sur le modèle de référence pour un Open Archival Information System (OAIS). Voir Organisation internationale de normalisation (ISO), ISO 14721: 2003: Space data and information transfer systems – Open archival information system – Reference model, Genève, Suisse : ISO, 2003.

¹¹ K. Sollins et L. Masinter, « Functional requirements for Uniform Resource Names, » RFC 1737 IETF, Décembre 1994, http://tools.ietf.org/html/rfc1737 Consulté le 22 janvier 2008.

¹² M. Mealling, « Dynamic Delegation Discovery System (DDDS) Part one: The comprehensive DDDS, » RFC 3401 Internet Engineering Task Force, Octobre 2002, http://tools.ietf.org/html/rfc3401; « Dynamic Delegation Discovery System (DDDS) Part two: The algorithm, » RFC 3402 IETF, Octobre 2002, http://tools.ietf.org/html/rfc3402; « Dynamic Delegation Discovery System (DDDS) Part three: The Domain Name System (DNS) database, » RFC 3403 IETF, Octobre 2002, http://tools.ietf.org/html/rfc3403; « Delegation Discovery System (DDDS) Part four: The Uniform Resource Identifiers (URI) resolution application, » RFC 3404, IETF, Octobre 2002, http://tools.ietf.org/html/rfc3404; et « Dynamic Delegation Discovery System (DDDS) Part five: URI.ARPA assignment procedures, » RFC 3405, IETF, Octobre 2002, http://tools.ietf.org/html/rfc3405 Consulté le 22 janvier 2008.

¹³ R. Daniel, « A trivial convention for using HTTP in URN resolution, » RFC 2169, IETF, Juin 1997, http://tools.ietf.org/html/rfc2169 Consulté le 28 janvier 2008.

¹⁴ Le registre de l’Internet Assigned Numbers Authority (IANA) peut être consulté au http://iana.org/assignments/urn-namespaces. Consulté le 22 janvier 2008.

¹⁵ S. Weibel, E. Jul et K. Shafer, « PURLs: Persistent Uniform Resource Locators, » http://purl.oclc.org/docs/new_purl_summary.html Consulté le 22 janvier 2008.

¹⁶ K. Shafer, S. Weibel, E. Jul et J. Fausey, « Introduction to Persistent Uniform Resource Locators, » http://purl.oclc.org/docs/inet96.html Consulté le 22 janvier 2008.

¹⁷ Le logiciel du résolveur de PURL de l’OCLC est disponible au www.oclc.org/research/projects/purl/download.htm. Consulté le 22 janvier 2008.

¹⁸ S. Sun, L. Lannom et B. Boesch, « Handle System overview, » RFC 3650 IETF, Novembre 2003, http://tools.ietf.org/html/rfc3650 Consulté le 22 janvier 2008.

¹⁹ S. Sun, S. Reilly et L. Lannom, « Handle System namespace and service definition, » RFC 3651, IETF, Novembre 2003, http://tools.ietf.org/html/rfc3651 Consulté le 22 janvier 2008.

²⁰ S. Sun, S. Reilly, L. Lannom et J. Petrone, « Handle System protocol (ver 2.1) specification, » RFC 3652, IETF, Novembre 2003, http://tools.ietf.org/html/rfc3652 Consulté le 22 janvier 2008.

²¹ Corporation for National Research Initiatives (CNRI), « HANDLE.NET Services: Global Handle Registry^®, » Handle System, www.handle.net/introduction.html Consulté le 22 janvier 2008.

²² CNRI, « Proxy server system, » Handle System, www.handle.net/proxy.html Consulté le 22  janvier 2008.

²³ Le logiciel HANDLE.NET peut être téléchargé depuis le www.handle.net/download.html. Consulté le 22 janvier 2008.

²⁴ International DOI Foundation (IDF), DOI^® handbook, Version 4.4.1, le 5 octobre 2006, www.doi.org/hb.html Consulté le 22 janvier 2008.

²⁵ Le document est publié aux fins de commentaires comme le « Committee Draft ISO/CD 26324, Information et documentation – Identificateur des objets numérique (DOI), » disponible au www.doi.org/ISO_Standard/sc9n475.pdf Consulté le 3 février 2008.

²⁶ National Information Standards Organization (NISO), « ANSI/NISO Z39.84-2005: Syntax for the Digital Object Identifier, » le 30 septembre 2005, www.niso.org/standards/ressources/Z39-84-2005.pdf Consulté le 22 janvier 2008.

²⁷ Pour une description des liens entre les systèmes, voir IDF, « Value added by the DOI system, » Version 2, www.doi.org/factsheets/0607ValueAdded.pdf Consulté le 22 janvier 2008.

²⁸ Voir « Appendix 5 DOI Resource Metadata Declaration » et « Appendix 6 DOI Kernel Metadata Declaration: XML schema » dans IDF, DOI^® handbook,  Version 4.4.1, le 5 octobre 2006, www.doi.org/hb.html Consulté le 22 janvier 2008.

²⁹ Voir « Appendix 4 indecs Data Dictionary » dans IDF, DOI^® handbook, Version 4.4.1, le 5 octobre 2006, www.doi.org/hb.html Consulté le 22 janvier 2008.

³⁰ Pour une description des liens entre les systèmes, voir IDF, « DOI^® System and the Handle System^®,  » Version 4.1, www.doi.org/factsheets/0607DOIHandle4-1.pdf Consulté le 22 janvier 2008.

³¹ On peut obtenir le module d'extension au  : www.handle.net/other_software.html. Consulté le 22 janvier 2008.

³² Le serveur mandataire est disponible au http://dx.doi.org/. Consulté le 22 janvier 2008.

³³ Pour une description des politiques liées au système, voir « Chapter 6 Policy » dans IDF, DOI^® handbook,  Version 4.4.1, le 5 octobre 2006, www.doi.org/hb.html Consulté le 22 janvier 2008.

³⁴ J.A. Kunze et R.P.C. Rodgers, « The ARK persistent identifier scheme CDL-Draft, » le 24 juillet 2007, www.cdlib.org/inside/diglib/ark/arkspec.pdf Consulté le 22 janvier 2008.

³⁵ K. Gamiel, J. Kunze et N. Nassar, « THUMP – The HTTP URL Mapping Protocol, Internet-Draft, » le 24  février 2007, http://tools.ietf.org/html/draft-kunze-thump-02 Consulté le 28 janvier 2008.

³⁶ See J.A. Kunze, « A metadata kernel for electronic permanence, » le 5  octobre 2001, http://jodi.tamu.edu/Articles/v02/i02/Kunze/kunze-final.pdf Consulté le 22 janvier 2008; et J. Kunze et A. Turner, « Kernel metadata and Electronic Resource Citations (ERCs), » Draft, Dublin Core Metadata Initiative (DCMI) Kernel Metadata Task Group, le 11 août 2007, http://dot.ucop.edu/home/jak/erc.html Consulté le 22 janvier 2008.

³⁷ J. Kunze et T. Baker, « The Dublin Core metadata element set, » RFC 5013, IETF, août 2007,http://tools.ietf.org/html/rfc5013 Consulté le 4 février 2008.

³⁸ J.A. Kunze et M.A. Russell, « [noid (Nice Opaque Identifier) minting and binding tool], » le 19 avril 2006, www.cdlib.org/inside/diglib/ark/noid.pdf Consulté le 22 janvier 2008.

³⁹ Les tableaux de recherche des NAAN/ NAMH sont disponibles au www.cdlib.org/inside/diglib/ark/natab. Consulté le 22 janvier 2008.

⁴⁰ Herbert Van de Sompel et Oren Beit-Arie, « Open linking in the scholarly information environment using the OpenURL framework,  » D-Lib Magazine (Mars 2001), www.dlib.org/dlib/march01/vandesompel/03vandesompel.html Consulté le 28 janvier 2008.

⁴¹ Ex Libris SFX www.exlibrisgroup.com/sfx.htm. Consulté le 28 janvier 2008.

⁴² NISO, ANSI/NISO Z39.88-2004, « The OpenURL framework for context-sensitive services, » le 15 avril 2007, www.niso.org/standards/ressources/Z39_88_2004.pdf Consulté le 28 janvier 2008.

⁴³ A. Apps, « Why OpenURL?  » D-Lib Magazine (Mai 2006), www.dlib.org/dlib/may06/apps/05apps.html Consulté le 28 janvier 2008.

⁴⁴ Pour plus de renseignements sur le OCLC OpenURL Resolver Registry, voir  : www.oclc.org/productworks/urlresolver.htm. Consulté le 29 janvier 2008.

⁴⁵ OCLC OpenURL 1.0 est disponible à l'adresse suivante : www.oclc.org/research/software/openurl/default.htm.

⁴⁶ Voir J. Hakala, « Using National Bibliography Numbers as Uniform Resource Names, » RFC 3188, IETF, Octobre 2001, http://tools.ietf.org/html/rfc3188 Consulté le 28 janvier 2008.

⁴⁷ Networked European Deposit Library, http://nedlib.kb.nl/index.html, Consulté le 29 janvier 2008.

⁴⁸ K. Best, « A URN namespace for OASIS, » RFC 3121, IETF, Juin 2001, http://tools.ietf.org/html/rfc3121 Consulté le 28 janvier 2008.

⁴⁹ Ce rapport est disponible comme un Cooperative Online Serials (CONSER), « Report – CONSER PURL pilot, » www.loc.gov/acq/conser/purl/purlrept.pdf Consulté le 28 janvier 2008.

⁵⁰ OCLC News Release, le 22 juillet 2007, www.oclc.org/news/releases/200669.htm Consulté le 29 janvier 2008.

⁵¹ Library of Congress (LC), « Handle Server, » le 4 mai 1998, http://lcweb2.loc.gov/ammem/award/docs/handle-server.html Consulté le 29 janvier 2008.

⁵² Pour plus de renseignements sur CrossRef et le système DOI, voir A. Brand, « ALPSP Advice Note 37: CrossRef, » janvier 2007, www.crossref.org/01company/pr/ALPSP%20Advice%20Note%2037.pdf Consulté le 28 janvier 2008; et « CrossRef, DOI name information and guidelines, » le 11 juin 2007 www.crossref.org/02publishers/doi-guidelines.pdf Consulté le 28 janvier 2008.

⁵³ C. Brown, Gestionnaire, Programme des revues, Presses scientifiques du Conseil national de recherches du Canada (CNRC), conversation téléphonique, le 21 septembre 2007.

⁵⁴ J.A. Kuntz, « Towards electronic persistence using ARK identifiers, » Juillet 2003, www.cdlib.org/inside/diglib/ark/arkcdl.pdf Consulté le 28 janvier 2008.

⁵⁵ California Digital Library (CDL), Archival Resource Key (ARK) www.cdlib.org/inside/diglib/ark/ Consulté le 28 janvier 2008.

⁵⁶ E. Bermès, « Persistent identifiers for digital resources: The experience of the National Library of France, » International Preservation News (IPN) 40 (Décembre 2006): 22-34, www.ifla.org.sg/VI/4/news/ipnn40.pdf Consulté le 3 février 2008.