Initiative de métadonnées du Dublin Core

TABLE DES MATIÈRES

1. Introduction

• 1.1. Que sont les métadonnées?
• 1.2. Qu'est-ce que le Dublin Core?
• 1.3. But et portée de ce guide

2. Quelle syntaxe?

• 2.1. HTML
  • 2.1.1. Utilisation de la syntaxe HTML
• 2.2. RDF/XML
• 2.3. Métadonnées autonomes
• 2.4. Métadonnées contenues dans une ressource

3. Principes fondamentaux des éléments descriptifs

• 3.1. Parties d'éléments et syntaxe
• 3.2. Contenu des éléments et vocabulaire contrôlé

4. Les éléments de base

5. Qualificatifs (en anglais)

6. Exemples

• 6.1 Exemples génériques (en anglais)
• 6.2 Exemples simples en HTML (en anglais)
• 6.3 Exemples qualifiés en HTML (en anglais)
• 6.4 Exemples simples en format RDF
• 6.5 Exemples qualifiés en format RDF
• 6.6 Exemples d'autres sources
  • ALGS
  • EDnA

7. Glossaire (en anglais)

8. Lectures générales et références (en anglais)

1. Introduction

1.1. Que sont les métadonnées?

Les métadonnées décrivent une ressource d'information (NdT on parle ici de ressource d'information plutôt que de document car les métadonnées peuvent décrire des ensembles plus petits qu'un document, par exemple, des images, ou des fichiers sonores, à l'intérieur d'un document). Le terme "meta" vient du grec et dénote quelque chose de nature plus élevée ou plus fondamentale. Les métadonnées sont des données à propos d'autres données. C'est un terme "branché" pour décrire le même type d'information que les bibliothécaires mettent depuis toujours dans les catalogues. On l'utilise généralement pour parler d'information descriptive à propos de ressources du Web. Toutefois les métadonnées peuvent répondre à de nombreux objectifs, que ce soit l'identification d'une ressource satisfaisant un besoin particulier d'information, l'évaluation de sa pertinence ou enfin pour garder la trace des caractéristiques d'une ressource à des fins d'entretien ou d'utilisation à long terme. De nos jours, différentes communautés d'usagers comblent de tels besoins en utilisant une grande variété de normes de métadonnées.

Une notice contenant des métadonnées est constituée d'un ensemble d'attributs, ou éléments, nécesaires pour décrire la ressource en question. Par exemple, un système commun de métadonnées dans les bibliothèques -- le catalogue de bibliothèque -- contient un ensemble de notices de métadonnées comprenant des éléments spécifiques pour décrire un livre ou tout autre document que l'on trouve en bibliothèque: auteur, titre, date de création ou de publication, sujet et cote, permettant de le retrouver sur les tablettes.

Le lien entre une notice de métadonnées et la ressource qu'elle décrit peut être fait de deux façons.

1. Les éléments peuvent être contenus dans une notice séparée du document, comme c'est le cas pour une notice dans un catalogue de bibliothèque
2. Les métadonnées peuvent être intégrées dans la ressource elle-même

Comme exemple de métadonnées intégrées, qui sont transportées avec la ressource, on peut penser aux données de catalogage avant publication qui sont imprimées au verso des pages titres; ou bien à l'en-tête du TEI (TEI  Header) dans un texte électronique [NdT on peut consulter une version française du TEI, réalisée par François Role, au http://www.uic.edu/orgs/tei/lite/teiu5_fr.html (voir chap. 20)].

Plusieurs standards de métadonnées présentement en usage, incluant celui du Dublin Core, ne prescrivent ni l'un ni l'autre des types de liens; la décision doit être prise en tenant compte des caractéristiques et des besoins de chaque implantation particulière.

Le concept de métadonnées est antérieur à Internet et au Web. Toutefois, c'est avec l'augmentation de l'édition électronique et des bibliothèques numériques que l'intérêt mondial pour les pratiques et standards de métadonnées a véritablement explosé. La surabondance d'information -- infobésité --, résultant de vastes quantités de données numériques non différenciées disponibles en ligne, explique cet intérêt soudain. Quiconque a déjà tenté de trouver de l'information en ligne en utilisant un des nombreux et populaires moteurs de recherche du Web a probablement vécu la frustration d'obtenir des centaines, si ce n'est des milliers, de résultats sans grande possibilité de raffiner ou de faire une recherche plus précise. L'adoption à grande échelle de normes descriptives et de nouvelles pratiques pour les ressources électroniques va améliorer la possibilité de trouver des ressources pertinentes dans Internet. Comme le notaient Weibel et Lagoze, deux leaders dans le développement des métadonnées:

L'association de métadonnées descriptives standardisées avec des objets en réseau offre un potentiel d'amélioration substantiel des possibilités de découverte de ressources: en permettant des recherches basées sur des champs (e.g., auteur, titre), en permettant l'indexation d'objets non-textuels et en permettant l'accès à un contenu de substitution, ce qui est différent de l'accès au contenu de la ressource elle même" (Weibel et Lagoze, 1997).

C'est ce besoin de métadonnées descriptives standardisées que le Dublin Core veut combler.

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

La norme de métadonnées du Dublin Core est un ensemble d'éléments simples mais efficaces pour décrire une grande variété de ressources en réseau. La norme du Dublin Core comprend 15 éléments dont la sémantique a été établie par un consensus international de professionnels provenant de diverses disciplines telles que la bibliothéconomie, l'informatique, le balisage de textes, la communauté muséologique et d'autres domaines connexes.

On trouvera une description de l'ensemble des éléments du Dublin Core dans la Section 4. Chaque élément est optionnel et peut être répété. Chaque élément possède également un ensemble limité de qualificatifs, des attributs qui peuvent être utilisés afin de raffiner davantage (et non pas étendre) la signification de l'élément. L'Initiative de métadonnées du Dublin Core (IMDC) a défini, en juillet 2000, des façons normalisées de "qualifier" les éléments au moyen de différents types de qualificatifs. Un registre de qualificatifs conformes aux "meilleures pratiques" de l'IMDC est en cours de construction.

Bien que le Dublin Core favorise la description d'objets ressemblant à des documents (car la description des ressources textuelles traditionnelles est une activité bien maîtrisée), son usage pour la description des ressources ne ressemblant pas à des documents traditionnels va dépendre, jusqu'à un certain point, des similitudes entre les métadonnées de ces nouveaux documents par rapport aux métadonnées habituelles   d'un document. Il va aussi dépendre des objectifs visés par les métadonnées de ces nouveaux documents.

Dublin Core a pour objectif de concilier les caractéristiques suivantes:

Simplicité de création et de gestion

L'ensemble des élements du Dublin Core a été tenu aussi sommaire et simple que possible afin de permettre au non-spécialiste de créer des notices descriptives simples pour les ressources informationnelles, de façon facile et économique et ce, tout en permettant des recherches efficaces de ces mêmes ressources dans un environnement en réseau.

Sémantique communément comprise

La découverte d'information dans l'immensité d'Internet est gênée par des différences de terminologies et de pratiques descriptives d'un champ des connaissances à l'autre. Le Dublin Core peut aider le "touriste du numérique" -- un chercheur non spécialisé -- à trouver son chemin en supportant un ensemble commun d'éléments dont la sémantique est universellement comprise et supportée. Par exemple, les scientifiques désirant localiser les articles d'un auteur particulier et les étudiants en art intéressés par les travaux d'un artiste particulier conviendront de l'importance d'un élément "créateur". Une telle convergence sur un ensemble commun d'éléments bien que légèrement plus génériques augmente la visibilité et l'accessibilité de toutes les ressources, à la fois à l'intérieur d'une discipline et au-delà.

Envergure internationale

L'ensemble d'éléments du Dublin Core a été d'abord développé en anglais mais des versions sont créées en plusieurs autres langues. En novembre 1999, il y avait des versions en plus de 20 langues incluant 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 de travail sur le Dublin Core multilingue coordonne les efforts pour lier ces versions dans un registre distribué utilisant la technologie du Resource Description Framework actuellement en développement au Consortium World Wide Web (W3C).

Bien que les défis techniques de l'internationnalisation du World Wide Web n'ont pas été directement abordés par la communauté de développement du Dublin Core, l'implication de représentants de presque tous les continents a permis d'assurer que le développement de la norme tienne compte de la nature multilingue et multiculturelle de l'univers de l'information électronique.

Extensibilité

Tout en conservant un équilibre entre les besoins de simplicité dans la description des ressources numériques avec la nécessité d'une découverte précise, les développeurs du Dublin Core ont reconnu l'importance de prévoir un mécanisme permettant d'étendre l'ensemble des éléments du DC pour d'autres besoins de découvertes de ressources. On s'attend à ce que d'autres communautés d'experts en métadonnées créent et administrent d'autres ensembles de métadonnées. Le présent modèle permet à différentes communautés d'utiliser l'ensemble des éléments du DC pour la description primaire de l'information, qui devient alors utilisable à travers l'Internet, tout en permettant des ajouts, spécifiques à un domaine, qui soient pertinents dans une communauté particuière (e.g. éducation).

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

Ce document est conçu comme un point d'entrée pour les utilisateurs. Il servira au non spécialiste à créer des notices descriptives simples de ressources d'information (par exemple des documents électroniques). Les spécialistes pourront trouver que ce document est une référence utile à la documentation du Dublin Core, au fur et à mesure qu'elle change et croît.

Ce guide montrera d'un façon non technique comment le Dublin Core peut être utilisé par quiconque pour rendre son matériel plus accessible. Ce guide aborde la présentation et le contenu des éléments de métadonnées du Dublin Core, comment les utiliser en composant une notice de métadonnées Dublin Core complète, de même que comment qualifier les éléments afin de permettre son utilisation par une grande variété de communautés.

Un autre objectif important de ce document est de promouvoir les "meilleures pratiques" de description des ressources en utilisant l'ensemble d'éléments du Dublin Core. La communauté du Dublin Core reconnaît que la cohérence dans la création des métadonnées est un des facteurs clés qui permettra d'atteindre un meilleur taux de rappel et un affichage intelligent parmi des sources disparates de notices descriptives. En effet, des métadonnées incohérentes cachent (silence) les notices désirées, ce qui donne des résultats de recherche inégaux, imprévisibles ou incomplets.

2. Quelle syntaxe?

Dans ce guide, nous avons choisi de représenter les exemples Dublin Core suivant différentes syntaxes, incluant HTML, le format du langage de balisage hypertexte; RDF/XML, le cadre de description des ressources utilisant le langage de balisage extensible) et dans une forme générique (élément="valeur"). Le HTML nous fournit un format facilement compréhensible pour démontrer les concepts sous-jacents du Dublin Core. Pour des applications plus complexes, utilisant des qualificatifs, on pourra trouver que l'utilisation du RDF/XML est plus pertinente. Lorsque l'on considère la syntaxe appropriée, il est important de noter que les concepts Dublin Core sont applicables également à presque tous les formats de fichiers, en autant que la métadonnée soit dans une forme qui soit propice à une interprétation à la fois par des moteurs de recherche et par des humains.

2.1. HTML

Le HTML possède deux balises pouvant être utilisées pour capturer des métadonnées. Ce sont la balise "<META>" et la balise "<LINK>". Si vous créez des métadonnées qui seront incorporées, ou qui seront liées à un document, ces balises doivent paraître à l'intérieur de la section HEAD du document HTML. Par exemple:

<HTML>
<HEAD>
<TITLE>Les habitudes d'accouplement du Wombat à nez poilu du Nord</TITLE>
<META NAME= "DC.Creator" CONTENT="Smythe, Pearl">
</HEAD>
<BODY>
<H1>Les wombats à nez poilu du Nord</H1>
<P>Le wombat à nez poilu du Nord est un animal originaire d'Australie....</P>
</BODY>
</HTML>

Les programmes d'indexation qui sont capables d'interpréter les notices comportant des métadonnées débutent leur analyse après la balise"<HEAD>" et la terminent avant la balise "</HEAD>". Ils sont ainsi capables d'extraire les métadonnées automatiquement. Les métadonnées n'apparaissent pas durant la mise en page ou l'impression d'un document normal et les navigateurs du Web capables de reconnaître les métadonnées peuvent aussi être capables de les exploiter. Un certain nombre de moteurs de recherches courants ont commencé à inclure la capacité d'utiliser la balise HTML <META> dans les documents Web.

En HTML, chaque définition d'un élément d'une notice commence avec "<META" et se termine avec ">". À l'intérieur de la balise META, deux paires d'attributs/valeurs (telles qu'on en trouve dans d'autres balises HTML) sont utilisées pour définir la métadonnées. La première est NAME et la seconde, CONTENT. Ces deux paires travaillent ensemble pour définir la métadonnée à l'intérieur de la balise META

Ce document ne couvrira pas l'utilisation de la balise LINK. Toutefois, si vous faites afficher la source du présent document, vous constaterez que la notice RDF y est liée grâce à une balise LINK).

2.1.1. Utilisation de la syntaxe HTML

Chaque définition d'élement descriptif a un attribut NAME et un atribut CONTENT comme dans:

<META NAME="DC.Creator" CONTENT="Browning, Elizabeth">

N'importe quel élément de métadonnées peut être omis ou répété. Lorsqu'on répète un élément, la  pratique recommandée est de lister chaque définition d'élément séparément comme dans:

<META NAME="DC.Creator" CONTENT="Marx, Karl">
<META NAME="DC.Creator" CONTENT="Engels, Friedrich">

Toutefois, il est aussi valide d'exprimer des éléments répétés en utilisant un seul attribut NAME avec plusieurs valeurs pour l'attribut CONTENT, séparées par des points virgules comme dans:

<META NAME="DC.Creator" CONTENT="Marx, Karl ; Engels, Friedrich">

La convention proposée ici pour inclure des métadonnées en HTML s'accorde avec une autre convention pour identifier et grouper différents schémas de métadonnées en HTML. Elle repose sur l'utilisation d'un préfixe pour indiquer que les éléments utilisés proviennent du Dublin Core ou d'un autre schéma de métadonnées. Pour faciliter la lecture, le préfixe "DC" devrait être écrit en lettres majuscules et les noms d'éléments devraient s'écrire avec une majuscule initiale. Par exemple:

META NAME="DC.Title"
META NAME="DC.Creator"

ET NON PAS

DC.CREATOR ou dc.CREATOR ou DC.creator

Si des caractères non-ASCII sont requis, utiliser le mêmes conventions que dans le corps du document. Par exemple:

<META NAME="DC.Title" CONTENT="Les biscuits &agrave; la banane">

2.2. RDF/XML

[Texte à venir ici]

Voici maintenant quelques exemples sur les façons d'utiliser la balise META de façon autonome ou intégrée au document. Notez que chaque définition de métadonnée est contenue sur une ligne mais qu'en général une définition peut s'étendre sur plusieurs lignes.

2.3. Métadonnées autonomes

Les métadonnées autonomes peuvent exister dans n'importe quelle sorte de base de données. Cet exemple décrit une photographie dans un autre fichier dont la localisation est donnée par une adresse URL.

Voici le fichier complet de la notice:

<META NAME="DC.Title" CONTENT="Kita Yama (Japon)">
<META NAME="DC.Creator" CONTENT="Kertesz, Andre">
<META NAME="DC.Date" CONTENT="1968">
<META NAME="DC.Type" CONTENT="image">
<META NAME="DC.Format" CONTENT="image/gif">
<META NAME="DC.Identifier" CONTENT="http://foo.bar.zaf/kertesz/kyama">

2.4. Métadonnées contenues dans une ressource

L'exemple suivant est une notice de métadonnées contenue dans le même fichier, avec le document qu'elle décrit. Ce document est un court poème exprimé en HTML, le langage de balisage hypertexte du Web.[3].

<HTML>
<HEAD>
<TITLE>Song of the Open Road</TITLE>
<META NAME="DC.Title" CONTENT="Song of the Open Road">
<META NAME="DC.Creator" CONTENT="Nash, Ogden">
<META NAME="DC.Type" CONTENT="text">
<META NAME="DC.Date" CONTENT="1939">
<META NAME="DC.Format" CONTENT="text/html">
<META NAME="DC.Identifier" CONTENT="http://www.poetry.com/nash/open.html">
</HEAD>
<BODY><PRE>
I think that I shall never see
A billboard lovely as a tree.
Indeed, unless the billboards fall
I'll never see a tree at all.
</PRE></BODY>
</HTML>

3. Principes fondamentaux des éléments descriptifs

3.1. Parties d'éléments et syntaxe

Chaque élément est optionnel et répétable. Les éléments de métadonnées peuvent apparaître dans n'importe quel ordre. On peut vouloir préserver l'ordre d'apparition de plusieurs occurences du même élément (e.g., Creator), toutefois cet ordonnancement  ne sera pas automatiquement conservé dans tous les environnements. Par exemple, le RDF permet  l'ordonnancement mais pas le HTML.

3.2. Contenu d'un élément et vocabulaire contrôlé

Des termes décrivant le contenu de quelques éléments peuvent être sélectionnés à partir d'un "vocabulaire contrôlé". Le vocabulaire contrôlé est un ensemble limité de termes soigneusement définis et utilisés de façon cohérente. Ceci peut améliorer de façon importante les résultats de la recherche  parce que si les ordinateurs sont efficaces dans l'appariement de mots, caractère par caractère, ils sont faibles pour comprendre comment  les gens réfèrent à un concept en utilisant différents mots, i.e. des synonymes. Sans un contrôle terminologique de base, des métadonnées incohérentes ou incorrectes peuvent  dégrader de façon importante la qualité des résultats d'une recherche. Par exemple, sans un vocabulaire contrôlé, "bonbon" et "sucreries" pourraient être utilisés pour référer au même concept. Les vocabulaires contrôlés peuvent également réduire la possibilité d'erreurs d'épellation lors de la saisie des métadonnées.

Un des obstacles (coût) à l'utilisation d'un vocabulaire contrôlé est qu'il y a nécessité d'un organe administratif pour réviser, mettre à jour et disséminer ce vocabulaire. Par exemple, le "Library of Congress Subject Headings" (LCSH) et le "US National Library of Medicine Medical Subject Headings" (MeSH) sont des vocabulaires formels, indispensables pour chercher des collections rigoureusement cataloguées. Toutefois, ces deux vocabulaires nécessitent un support important de la part de ces organismes. Un autre coût important est d'avoir à entraîner des chercheurs et des créateurs de métadonnées afin qu'ils comprennent  que lorsqu'ils utilisent le MeSH, par exemple, ils doivent employer "myocardial infarction" au lieu de l'expression plus familière "heart attack" (NdT ou "crise cardiaque"!).

La façon la plus efficace de faire usage d'un vocabulaire contrôlé est par l'intermédiaire des qualificatifs. (en anglais)

4. Les éléments de base (core elements)

[NdT les lecteurs auront avantage à compléter la lecture de cette partie du guide par la consultation de la traduction française: " Eléments de métadonnées du Dublin Core, Version 1.1: Description de Réference" effectuée par Anne-Marie Vercoustre, de l'INRIA ]

Cette section donne la liste de chacun des éléments de base par son nom complet et son identifiant. Pour chaque élément on donnera une description de référence (tirée du document RFC) et des directives pour aider à la création du contenu des métadonnées, qu'il soit fait à partir de rien ou en convertissant une notice existant dans un autre format. Des liens vers des exemples et vers les qualificatifs Dublin Core recommandés pour chaque élément seront également fournis.

Les éléments sont énumérés dans l'ordre où ils ont été développés mais il y a d'autres façons utiles de les regrouper. Dans le tableau suivant vous pouvez constater que certains des éléments sont liés au contenu de la ressource décrite, d'autres sont liés à cette ressource par la propriété intellectuelle et d'autres enfin, à l'instance particulière de la ressource.

5. Qualificatifs

En juillet 2000, l'initiative de métadonnées du Dublin Core (IMDC) a émis sa liste de qualificatifs Dublin Core (en anglais) recommandés. Actuellement l'IMDC reconnaît deux grandes catégories de qualificatifs.

• Le raffinement d'éléments. Ces qualificatifs permettent de préciser le sens d'un élément pour qu'il soit plus circonscrit ou plus précis. Un élément raffiné partage le même sens que l'élément non qualifié mais avec une portée plus restreinte. Un client qui ne peut interpréter le terme raffinant un élément spécifique devrait être capable d'ignorer le qualificatif et de traiter la valeur de la métadonnée comme s'il s'agissait d'un élément non qualifié (plus large). Les définitions des termes de raffinement d'éléments pour les qualificatifs doivent être publiquement disponibles.

• Le schéma d'encodage. Ces qualificatifs identifient des schémas qui aident à l'interprétation de la valeur d'un élément. Ces schémas comprennent des vocabulaires contrôlés et des notations formelles ou des règles d'interprétation. Une valeur exprimée en utilisant un schéma d'encodage pourra donc être une expression sélectionnée à partir d'un vocabulaire contrôlé (e.g. un terme d'un système de classification ou un ensemble de vedettes matières) ou une chaîne de caractères formattée en accord avec une notation formelle (e.g. "2000-01-01" comme expression normalisée d'une date). Si un schéma d'encodage ne peut être interprété par un client ou un agent, la valeur peut toujours être utile à un lecteur humain. La description de référence d'un schéma d'encodage utilisé avec des qualificatifs doit être clairement identifiée et disponible pour usage public.

7. Glossaire (en anglais)

8. Lectures générales et références (en anglais)

Retour à la page d'accueil officielle Dublin Core : http://dublincore.org/                     © 2000 DCMI 

Retour à la page d'accueil de la Bibliothèque de l'Université Laval : http://www.bibl.ulaval.ca/