yoyodesign.orgdocuments ‣ Guide d'utilisation du Dublin Core
Avertissement — Ce document est une traduction d'un document original du Dublin Core Metadata Initiative (DCMI) qui seul fait autorité. La traduction peut comporter des erreurs ou en introduire de nouvelles.
Original Traduction
  • Titre : Guide d'utilisation du Dublin Core
  • Traducteur : J.J.SOLARI
  • Date de publication : 2007-06-05
  • Adresse URL : http://yoyodesign.org/doc/dcmi/usageguide/
  • Copyright © 2007 yoyodesign.org

Guide d'utilisation du Dublin Core

Créateur : Diane Hillmann
Date de publication : 2005-11-07
Identificateur : http://dublincore.org/documents/2005/11/07/usageguide/
Remplace : http://dublincore.org/documents/2005/08/15/usageguide/
Est remplacé par : Non applicable
Dernière version : http://dublincore.org/documents/usageguide/
Traductions : http://dublincore.org/resources/translations/
Statut du document : Ressource recommandée par le DCMI (N.d.T. Ce document-ci en est une traduction.)
Description du document : Ce document sert de point d'entrée pour les utilisateurs du Dublin Core. Il aidera les non-spécialistes à créer des enregistrements descriptifs simples de ressources d'informations (par exemple, des documents électroniques). Les spécialistes y trouveront un point de référence pratique pour la documentation du Dublin Core, au fur et à mesure de ses évolutions.

Table des matières

1. Introduction

2. Les problèmes de syntaxe, de stockage et de mise à jour

3. Le contenu des éléments et les vocabulaires contrôlés
4. Les éléments
5. Les qualificatifs Dublin Core
6. Annexe (les rôles)
7. Glossaire
8. Bibliographie

1. Introduction

1.1. Les métadonnées, qu'est-ce que c'est ?

Les métadonnées nous accompagnent depuis que le premier bibliothécaire a fait la liste des éléments dans un rayon de rouleaux manuscrits. Le terme « meta » est issu d'un mot grec signifiant « à côté, avec, après, ensuite ». L'utilisation latine ou anglaise plus récente de « meta » dénoterait quelque chose de transcendental ou de par-delà la nature. On peut donc considérer les métadonnées comme des données à propos d'autres données. C'est le terme de l'ère Internet pour désigner les informations traditionnellement cataloguées par les bibliothécaires, et il désigne communément des informations descriptives au sujet de ressources Web.

Un enregistrement de métadonnées consiste en un ensemble d'attributs ou d'éléments nécessaires pour décrire la ressource en question. Par exemple, un système de métadonnées courant dans les bibliothèques (le catalogue de librairie) contient un ensemble d'enregistrements de métadonnées avec des éléments qui décrivent un livre ou un autre élément de bibliothèque : l'auteur, le titre, la date de création ou de publication, la matière et le numéro d'appel indiquant l'emplacement de l'article dans le rayon.

La liaison entre l'enregistrement de métadonnées et la ressource qu'il décrit peut prendre deux formes :

  1. Les éléments peuvent être contenus dans un enregistrement séparé de l'article comme c'est le cas pour un enregistrement de catalogue de bibliothèque, ou ;
  2. Les métadonnées peuvent être incorporées à la ressource même.

Les exemples de métadonnées intégrées emportées par la ressource en question comprennent les données de catalogage avant publication (CIP) imprimées au verso de la page de titre d'un livre, ou l'en-tête TEI dans un texte électronique. Beaucoup de standards de métadonnées couramment en usage, dont le standard Dublin Core, ne prescrivent aucun type de liaison, en laissant la décision à chaque mise en œuvre particulière.

Bien que le concept de métadonnées soit antérieur à Internet et au Web, l'intérêt dans le monde pour les standards et les utilisations de métadonnées a crû avec l'accroissement de la publication électronique et des bibliothèques numériques, et la « saturation d'informations » concomitante qui résulte de l'énorme quantité de données numériques indifférentiées disponibles en ligne. Quiconque a essayé de trouver des informations en ligne en utilisant un des services de recherche populaires aujourd'hui sur le Web a vraisemblablement éprouvé la frustration de récupérer des centaines voire des milliers de « hits » avec une capacité réduite d'affiner la recherche ou de faire une recherche plus précise. L'adoption à grande échelle de standards de description et d'utilisation des ressources électroniques améliorera la consultation de ressources pertinentes dans tous les terrains où la recherche d'informations est critique. Comme le font remarquer Weibel et Lagoze, deux chefs de file dans le domaine du développement des métadonnées et des bibliothèques numériques :

« L'association de métadonnées descriptives normalisées à des objets en réseau peut améliorer considérablement les capacités de découverte en autorisant des recherches par champs (par exemple, l'auteur, le titre), en permettant l'indexation d'objets non textuels et en donnant accès à un contenu de substitution distinct du contenu de la ressource en question » (Weibel et Lagoze, 1997)

Ces dernières années, nous avons également vu une hausse de l'utilisation de métadonnées Dublin Core dans des environnements plus fermés. Il existe des mises en œuvre où les métadonnées Dublin Core servent à décrire les ressources détenues, possédées ou produites par des entreprises, des gouvernements ou des organisations internationales en support d'un portail de services ou d'une gestion interne des connaissances. Il y a aussi des mises en œuvre où les métadonnées Dublin Core servent de format d'échange commun gérant l'agrégation de collections de métadonnées, comme c'est le cas de l'initiative pour des archives ouvertes (OAI). Dans ces cas, comme dans l'environnement ouvert du Web, le concept de métadonnées descriptives normalisées offre un mécanisme puissant pour une meilleure consultation par des applications particulières et des communautés d'utilisateurs spécifiques. Le Dublin Core répond à ce besoin de « métadonnées descriptives normalisées ».

1.2. Qu'est-ce que le Dublin Core ?

Le standard de métadonnées Dublin Core est un jeu d'éléments simple mais efficace pour décrire une gamme étendue de ressources en réseau. Le standard Dublin Core inclut deux niveaux : Simple Dublin Core et Qualified Dublin Core. Le niveau Simple Dublin Core comprend 15 éléments, le niveau Qualified Dublin Core ajoute 3 éléments supplémentaires (audience, provenance et rightsHolder) ainsi qu'un groupe d'affinements d'élément (appelés aussi qualificatifs) lesquels affinent la sémantique des éléments pour faciliter la découverte des ressources. La sémantique des métadonnées Dublin Core a été établie par un groupe international et interdisciplinaire de professionnels venant de la bibliothéconomie, de l'informatique, du codage de textes, de la communauté des musées, et d'autres domaines apparentés du savoir et de la pratique.

On peut voir le Dublin Core comme un « langage rudimentaire pour faire un ensemble de déclarations particulières à propos de ressources ». Ce langage contient deux classes de termes, les éléments (noms) et les qualificatifs (adjectifs), qui peuvent être arrangés dans un modèle simple de déclarations. Les ressources sont elles-mêmes les sujets implicites du langage. (Pour d'autres explications de la grammaire Dublin Core, cf. Les principes grammaticaux DCMI). Au sein de la diversité du monde Internet, on peut assimiler le Dublin Core à un « pidgin de métadonnées pour touristes numériques », facilement appris mais pas forcément à la hauteur pour exprimer des relations ou des concepts complexes.

Le jeu d'éléments de base Dublin est décrit dans la section 4. Chaque élément est optionnel et répétable. La plupart des éléments possède un jeu limité de qualificatifs ou affinements, c'est-à-dire des attributs utilisables pour affiner plus (pas pour étendre) la signification de l'élément. L'initiative de métadonnées Dublin Core (DCMI) a défini des méthodes normalisées pour affiner les éléments et pour encourager l'utilisation de schémas de codages et de vocabulaires. Un jeu complet d'éléments et affinements d'éléments conformes aux « pratiques exemplaires » du DCMI est disponible, ainsi qu'un registre formel.

Trois principes Dublin Core méritent d'être mentionnés ici car ils sont essentiels pour comprendre la relation des métadonnées à la ressource sous-jacente qu'elles décrivent.

1. Le principe d'un-pour-un. En général, les métadonnées Dublin Core décrivent une seule manifestation ou version d'une ressource au lieu de supposer que les manifestations sont interchangeables. Par exemple, une image JPEG de Mona Lisa a beaucoup de choses en commun avec la peinture originale mais ce n'est pas la peinture. L'image numérique en elle-même devrait être décrite comme telle, et on devrait très probablement inclure le créateur de l'image numérique dans un champs creator ou contributor au lieu d'inclure juste le peintre de la Mona Lisa originale. La relation entre les métadonnées de l'original et celles de la reproduction fait partie de la description des métadonnées et aide l'utilisateur à déterminer s'il doit aller voir l'original au Louvre ou si la reproduction peut satisfaire à ses besoins.

2. Le principe de décrochage. La qualification des propriétés Dublin Core est guidée par la règle appelée familièrement « principe de décrochage ». Selon cette règle, un client devrait pouvoir ignorer le qualificatif et utiliser la valeur comme si celle-ci n'était pas qualifiée. Quoique cela puisse se traduire par une certaine perte de précision, la valeur d'élément qui subsiste (sans le qualificatif) doit rester généralement correcte et utile pour la découverte. La qualification est donc censée seulement affiner et non étendre la portée sémantique d'une propriété.

3. Les valeurs appropriées. Les pratiques exemplaires pour un élément ou un qualificatif particuliers peuvent varier avec le contexte mais en général le développeur ne peut pas toujours prédire si une machine interprètera les métadonnées. Cela peut imposer certaines contraintes sur la façon de construire les métadonnées mais on devrait garder à l'esprit le critère d'utilité pour la découverte.

Bien que le Dublin Core ait d'abord été développé pour décrire des objets de types documents (car les ressources textuelles traditionnelles sont assez bien comprises), les métadonnées Dublin Core peuvent aussi bien s'appliquer à d'autres ressources. Leur applicabilité à des ressources non documentaires particulières dépendra dans une certaine mesure de la plus ou moins grande ressemblance des métadonnées de ces ressources avec celles de documents typiques, et aussi de l'intention poursuivie avec ces métadonnées. (Les développeurs intéressés par l'utilisation de métadonnées Dublin Core pour des ressources variables sont encouragés à consulter les pages de projets du Dublin Core pour des suggestions d'application à leurs ressources).

Le Dublin Core vise les objectifs suivants :

La simplicité de création et de mise à jour

Le jeu d'éléments Dublin Core est tenu aussi petit que possible afin qu'un non-spécialiste puisse créer facilement et à moindre coût des enregistrements descriptifs simples de ressources d'information tout en permettant de les récupérer efficacement dans un réseau.

Une sémantique comprise par tous

La découverte d'informations à travers les immenses biens communs de l'Internet est entravée par une terminologie et des pratiques descriptives différentes d'un champs de connaissances à un autre. Le Dublin Core peut aider le « touriste numérique » (un chercheur non-spécialiste) à trouver son chemin en promouvant un jeu d'éléments commun dont la sémantique est comprise et reconnue universellement. Par exemple, les scientifiques cherchant à localiser les articles d'un certain auteur et les étudiants en arts intéressés par les travaux d'un artiste particulier pourront tomber d'accord sur l'importance d'un élément tel que creator. Une telle convergence vers un jeu d'éléments commun, même légèrement plus générique, augmente la visibilité et l'accessibilité de toutes les ressources, au sein et hors d'une discipline donnée.

Une portée internationale

Le jeu d'éléments Dublin Core a d'abord été développé en anglais mais des versions sont produites dans beaucoup d'autres langues dont le finnois, le norvégien, le thai, le japonais, le français, le portugais, l'allemand, le grec, l'indonésien et l'espagnol. Le groupe d'intérêt spécial localisation et internationalisation du DCMI coordonne les efforts afin de relier ces versions à un registre épars.

Bien que les défis techniques posés par l'internationalisation du World Wide Web n'aient pas été directement étudiés par la communauté de développement du Dublin Core, la participation de représentants issus de tous les continents fait que le développement du standard prend en compte la nature multilingue et multiculturelle du monde de l'information électronique.

La capacité d'extension

Tout en respectant un équilibre entre les critères de simplicité de description et de précision de récupération des ressources numériques, les développeurs du Dublin Core ont reconnus l'importance d'un mécanisme d'extension du jeu d'éléments Dublin Core pour des besoins supplémentaires de découverte des ressources. Il est prévu que d'autres communautés d'experts en métadonnées créent et administrent d'autres jeux de métadonnées adaptés aux besoins de leur communauté. Les éléments de ces jeux de métadonnées pourraient être utilisés conjointement aux métadonnées Dublin Core pour satisfaire au critère d'interopérabilité. Le Conseil d'usage du DCMI étudie actuellement un modèle pour y parvenir dans le contexte de « profils d'applications ».

Rachel Heery et Manjula Patel, dans leur article Application profiles: mixing and matching metadata schemas définissent un profil d'application comme :

« [...] des schémas composés d'éléments de données provenant d'un ou de plusieurs espaces de noms, combinés par les développeurs et optimisés pour une application locale particulière. »

Ce modèle permet à des communautés différentes d'utiliser les éléments Dublin Core pour des informations descriptives de base en autorisant des extensions de domaine spécifiques avec une signification dans une arène restreinte.

1.3. Le but et la portée de ce guide

Ce document sert de point d'entrée pour les utilisateurs de métadonnées Dublin Core. Il aidera les non-spécialistes à créer des enregistrements descriptifs simples de ressources d'informations (par exemple, des documents électroniques, des images JPEG, des vidéoclips). Les spécialistes y trouveront un point de référence pratique pour la documentation du Dublin Core, au fur et à mesure de ses évolutions.

Le « Guide d'utilisation du Dublin Core » montre de façon moins technique comment chacun peut utiliser les métadonnées Dublin Core pour rendre sa documentation plus accessible. Il décrit les principes, la structure et le contenu des éléments de métadonnées Dublin Core, comment les utiliser pour composer un enregistrement de métadonnées Dublin Core complet et aussi comment qualifier les éléments pour tenir compte de communautés d'utilisateurs très variées.

Un autre objectif important du document est de promouvoir les « meilleures pratiques » pour décrire les ressources avec le jeu d'éléments Dublin Core. La communauté Dublin Core reconnaît que la cohérence des métadonnées créées est un élément-clé d'une recherche optimale et d'un affichage intelligible entre des sources d'enregistrements descriptifs disparates. En réalité, des métadonnées incohérentes cachent les enregistrements désirés en produisant des résultats de recherche inégaux, imprévisibles ou incomplets.

En tant qu'introduction générale, ce document est nécessairement court et ne peut pas traiter tous les problèmes que les développeurs peuvent rencontrer dans un plan d'utilisation de métadonnées. D'autres pistes peuvent être explorées pour les questions non traitées dans le guide.

  1. À la fin du guide, on trouvera des références vers des articles pertinents et d'autres ressources, y compris des références avec une orientation plus technique pour les développeurs ;
  2. Le site Web du Dublin Core contient des références vers d'autres documents et ressources de la communauté DCMI et les développeurs y trouveront des renseignements pour s'impliquer dans le DCMI ;
  3. On peut poser des questions spécifiques à AskDCMI. Outre les questions concernant les champs, le service AskDCMI tient des archives consultables de toutes les questions déjà résolues et offre des liens vers des ressources supplémentaires.

2. Les problèmes de syntaxe

Le modèle abstrait Dublin Core fournit un modèle de référence auquel on peut comparer des directives particulières du codage Dublin Core, indépendamment de toute syntaxe de codage particulière. Un tel modèle de référence permet aux développeurs d'acquérir une meilleure compréhension des types de descriptions qu'ils essayent de coder et facilite le développement de correspondances et traductions meilleures entre des syntaxes différentes. Bien que le document s'adresse principalement aux développeurs d'applications logicielles qui prennent en charge les métadonnées Dublin Core, ceux qui envisagent une mise en œuvre Dublin Core, en particulier une extension quelconque du Dublin Core, peuvent consulter le document avec profit. Ceux impliqués dans le développement de nouvelles directives de codage syntaxique des métadonnées Dublin Core ou dans le développement de métadonnées de profils d'applications fondé sur le Dublin Core devraient également étudier le modèle abstrait Dublin Core.

Dans ce guide, nous avons choisi de représenter les exemples Dublin Core dans une forme « générique » (élément="valeur"). Les exemples dans d'autres syntaxes, dont HTML ou XHTML (le format du langage de balisage hypertexte du Web), RDF/XML (le cadre de description de ressources utilisant le langage de balisage extensible) et en XML ordinaire sont disponibles dans des documents à syntaxe propre sur le site Web du DCMI. Certains exemples sont également référencés dans ce document et dans la bibliographie de ce guide.

Les choix syntaxiques dépendent de plusieurs variables et les prescriptions à « taille unique » s'appliquent rarement. Lorsqu'on cherche une syntaxe appropriée, il est important de noter que les concepts et la sémantique Dublin Core sont conçus pour être indépendants de la syntaxe, qu'ils peuvent s'appliquer équitablement dans des contextes divers, tant que les métadonnées ont une forme propice pour une interprétation à la fois par les moteurs de recherche et par les êtres humains.

2.1. HTML et XHTML

Les langages HTML ou XHTML peuvent servir à exprimer des métadonnées Dublin Core simples ou bien qualifiées, bien qu'il existe des limitations inhérentes pour représenter les affinements dans HTML. Le document DCMI suivant contient des instructions spécifiques pour exprimer des métadonnées Dublin Core dans HTML :

  1. L'expression du Dublin Core dans les éléments HTML/XHTML meta et link

2.2. RDF/XML

Le langage RDF (Resource Description Framework) autorise la lecture de multiples schémas de métadonnées par les humains ainsi que leur analyse par les machines. Il utilise le langage XML (Extensible Markup Language) pour exprimer une structure en permettant ainsi aux communautés de métadonnées de définir la sémantique réelle. Cette approche décentralisée reconnaît qu'il n'y a pas de schéma approprié à toutes les situations et, en outre, que les schémas ont besoin d'un mécanisme de liaison indépendant d'une autorité centrale pour assister la description, l'identification, la compréhension, l'utilisation et/ou l'échange.

RDF permet de décrire plusieurs objets sans définir les détails nécessaires. Le liant sous-jacent (XML) impose simplement de définir tous les espaces de noms, ce qui permet alors de les utiliser selon les critères définis par le fournisseur des métadonnées.

Par exemple :

<rdf:RDF 
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:dc="http://purl.org/dc/elements/1.1/">

   <rdf:Description rdf:about="http://media.example.com/audio/guide.ra">

      <dc:creator>Rose Bush</dc:creator>
      <dc:title>Un guide de la culture des rosiers</dc:title>
      <dc:description>Décrit la plantation et l'élevage de différentes variétés de rosiers buissonnants.</dc:description> 
      <dc:date>2001-01-20</dc:date>

   </rdf:Description> 
</rdf:RDF>

Cet exemple simple utilise le Dublin Core pour décrire un enregistrement sonore d'un guide de la culture des rosiers buissonnants. Avec XML ou RDF/XML, le Dublin Core peut être mélangé à d'autres vocabulaires de métadonnées. Par exemple, la description Dublin Core simple précédente pourrait accompagner d'autres vocabulaires, tel que vCard capable de décrire l'affiliation et les coordonnées de l'auteur, ou bien un vocabulaire de description de roses plus spécialisé offant une description détaillée des rosiers buissonnants.

Le DCMI met à disposition plusieurs recommandations spécifiques concernant l'utilisation de ces syntaxes :

  1. Le guide de la mise en œuvre Dublin Core en XML ;
  2. L'expression du Simple Dublin Core en RDF/XML ;
  3. L'expression du Qualified Dublin Core en RDF/XML (recommandation proposée).

2.3. Les problèmes de stockage et de mise à jour des métadonnées

Certaines mises en œuvre Dublin Core ont choisi d'incorporer leurs métadonnées au sein même de la ressource. Cette approche qui est celle suivie le plus souvent pour les documents codés en HTML est parfois possible avec d'autres types de documents. Des outils simples ont été développés afin de placer très facilement des métadonnées Dublin Core au sein de pages codées en HTML. Un de ces outils (DC.dot) extrait les informations de métadonnées d'un document HTML et les formate afin de pouvoir les éditer, puis les couper et coller à nouveau dans l'en-tête HTML du document original.

Sinon on peut stocker les métadonnées dans tout type de base de données, fournir un lien vers la ressource décrite au lieu de les y incorporer. Cette approche probablement la plus pratique pour beaucoup de ressources non textuelles est de plus en plus utilisée également pour du texte, principalement pour faciliter la mise à jour et le partage des métadonnées.

Chaque approche présente des avantages et des inconvénients, et le point d'équilibre change avec l'accroissement et la variété des mises en œuvre et aussi parce que les métadonnées vieillissent.

3. Le contenu des éléments et les vocabulaires contrôlés

Chaque élément Dublin Core est optionnel et répétable, l'ordre des éléments n'est pas défini. Le classement de plusieurs apparitions du même élément (par exemple, l'élément creator) peut avoir une signification prévue par le fournisseur, mais il n'y a aucune garantie qu'il soit conservé dans tous les environnements d'utilisateurs. Le classement ou le séquencement peut dépendre de la syntaxe, par exemple, RDF/XML tient compte du classement mais pas HTML.

Le contenu de données de certains éléments peut être sélectionné dans un « vocabulaire contrôlé », qui est un ensemble restreint de termes utilisés logiquement et définis avec soin. Cela peut améliorer considérablement les résultats de recherche car les ordinateurs sont bons à comparer des mots caractère à caractère mais mauvais à comprendre comment les personnes se réfèrent à un concept avec des mots différents (synonymes). Sans un minimum de contrôle de la terminologie, la présence de métadonnées incohérentes ou incorrectes peut dégrader profondément la qualité des résultats de recherche. Par exemple, sans vocabulaire contrôlé, les mots « bonbon » et « friandise » pourraient servir à désigner le même concept. Les vocabulaires contrôlés peuvent également réduire les fautes d'orthographe risquant de se produire pendant l'enregistrement des métadonnées.

Un vocabulaire contrôlé a un coût qui est celui de la nécessité d'un corps administratif pour revoir, mettre à jour et disséminer le vocabulaire. Par exemple, le répertoire des rubriques de la Bibliothèque du Congrès des États-Unis (LCSH) et le répertoire des rubriques médicales de la Bibliothèque nationale de Médecine des États-Unis (MeSH) sont des vocabulaires formels, indispensables pour la consultation de collections rigoureusement cataloguées. Toutefois ils exigent tous deux des organisations importantes pour leur tenue. Un autre coût est celui de la formation des chercheurs et des créateurs de métadonnées, qu'ils sachent par exemple quand utiliser le répertoire MeSH pour entrer « infarctus du myocarde » au lieu du plus familier « attaque cardiaque ». Les mises en œuvre plus sophistiquées peuvent rendre cette tâche plus facile mais elles doivent disposer du vocabulaire contrôlé pour l'appliquer.

L'utilisation des vocabulaires contrôlés peut être rendue très efficace en utilisant des schémas de codage. Sans schéma de codage spécialement conçu, un sujet qui serait peut-être très soigneusement sélectionné dans un vocabulaire contrôlé particulier ne saurait se distinguer d'un simple mot-clé.

4. Les éléments

5. Les qualificatifs Dublin Core

6. Annexe (les rôles)

7. Glossaire

8. Bibliographie