Retour à la page principale --> Etude préalable --> Les normes

Le Dublin Core




Le Dublin Core Metadata est un jeu de métadonnées qui a été mis au point par le Dublin Core Metadata Initiative (forum ouvert composé de personnes de disciplines variées et de toutes les régions du monde), en 1995. La norme Dublin Core définit des champs de métadonnées utilisables par les pages Web. Elle se veut facile et assez générale pour être pertinente quelque soit le domaine d’application. Elle définit les types d’informations à enregistrer pour bien définir une ressource sans toutefois préciser comment représenter ces données en pratique. Le Dublin Core a été approuvé comme norme ANSI et ISO et a été adopté entre autres par le gouvernement canadien, britannique et australien.
Les champs de métadonnées sont appelés éléments et ces deniers peuvent être approfondis à l’aide d'affinements. Un affinement restreint la signification d’un élément sans la changer fondamentalement.
De plus, les valeurs associées aux champs de métadonnées peuvent être dans un format libre ou être conforme à un format de données bien défini. Le Dublin Core référence un certain nombre de formats de données officiels.

Champs de métadonnées

Le Dublin Core est un ensemble de 15 éléments de métadonnées ayant trait au contenu, à la propriété intellectuelle et à la version.

Nous présenterons ici une liste exhaustive des champs de métadonnées du Dublin Core qui peuvent être encodés dans des balises HTML <meta>.

Liste des éléments du Dublin Core
Élément Description et liste des raffinements
title Titre du document : il s'agit a priori du titre principal du document. Pour indiquer un autre type, on peut utiliser le raffinement suivant :
  • alternative : alternative pour le titre, par exemple une abréviation ou une traduction.

creator Créateur du document : nom de la personne, de l'organisation ou du service à l'origine de la rédaction du document.
subject Sujet et mots-clefs : mots-clefs, phrases de résumé, ou codes de classement. Il est préférable d'utiliser des mots-clefs choisis dans le cadre d'une politique de classement.
description Description du document : résumé, table des matières, ou texte libre. Le type de description peut être précisé à l'aide des raffinements suivants :
  • tableOfContents : table des matières ;

  • abstract : résumé.

publisher Publicateur du document : nom de la personne, de l'organisation ou du service à l'origine de la publication du document.
contributor Contributeur au document : nom d'une personne, d'une organisation ou d'un service qui contribue ou a contribué à l'élaboration du document.
date Date d'un évènement dans le cycle de vie du document : il peut s'agir par exemple de la date de création ou de la date de mise à disposition. Il est recommandé de spécifier la date au format W3CDTF(AAAA-MM-JJ). Pour préciser de quelle date il s'agit, on utilise les raffinements suivants :
  • created : date de création ;

  • valid : date ou période de validité ;

  • available : date ou période de mise à disposition ;

  • issued : date de publication ;

  • modified : date de modification ;

  • dateAccepted : date d'acceptation (par exemple, acceptation d'une thèse par une université, d'un article par un journal, etc.) ;

  • dateCopyrighted : date du copyright ;

  • dateSubmitted : date où le document a été soumis (par exemple, soumis à un comité de lecture s'il s'agit d'un article).

type Nature ou genre du contenu : grandes catégories de document. Il est recommandé d'utiliser des termes clairement définis au sein de son organisation.
format Format du document : format physique ou électronique du document. Par exemple, type de média ou dimensions (taille, durée). On peut spécifier le matériel et le logiciel nécessaires pour accéder au document. Il est recommandé d'utiliser des termes clairement définis, par exemple le type MIME(Multi Purpose Mail Extension : standard permettant d’étendre les possibilités du courrier électronique. Les raffinements suivants sont disponibles :
  • extent : taille ou durée ;

  • medium : support physique.

identifier Identificateur non ambigu : il est recommandé d'utiliser un système de référencement précis, par exemple les URI (Uniform Resource Identifier) ou les numéros ISBN.
source Ressource dont dérive le document : le document peut découler en totalité ou en partie de la ressource en question. Il est recommandé d'utiliser une dénomination formelle des ressources, par exemple leur URI.
language Langue du document : il est recommandé d'utiliser un code de langue conforme au format RFC3066 (qui définit la syntaxe des étiquettes linguistiques à utiliser sur Internet).
relation Lien vers une ressource liée : il est recommandé d'utiliser une dénomination formelle des ressources, par exemple leur URI. On précise le type de lien avec des raffinements :
  • isVersionOf : on a affaire à une nouvelle version, une modification ou une adaptation du document lié. Les changements concernent le contenu et pas seulement la forme ;

  • hasVersion : réciproque d'isVersionOf. Le document lié est une version modifiée du présent document ;

  • isReplacedBy : le présent document a été remplacé par le document lié ;

  • replaces : réciproque de replaces. Le présent document remplace le document lié ;

  • isRequiredBy : on a besoin du présent document pour interpréter correctement le document lié ;

  • requires : réciproque d'isRequiredBy. Le présent document a besoin du document lié pour être correctement présenté, transmis, ou pour assurer sa cohérence ;

  • isPartOf : le document est une partie (physique ou logique) d'un autre document ;

  • hasPart : réciproque d'isPartOf : le document inclut le document lié, physiquement ou logiquement ;

  • isReferencedBy : le document courant est référencé, cité, ou lié par le document indiqué ;

  • references : réciproque d'isReferencedBy : le document courant référence, cite ou pointe vers le document indiqué ;

  • isFormatOf : le présent document a le même fond que le document indiqué, mais présenté sous une forme différente ;

  • hasFormat : réciproque d'isFormatOf : le présent document possède une variante sous une forme différente ;

  • conformsTo : référence à un standard établi auquel se conforme le présent document.

coverage Portée du document : la portée inclut un domaine géographique, un laps de temps, ou une juridiction (nom d'une entité administrative). Il est recommandé d'utiliser des représentations normalisées de ces types de données. Le type de couverture peut être précisé :
  • spatial : couverture spatiale. On peut utiliser les codages Point (point géographique), ISO3166(codes de pays à deux lettres), Box (régions géographiques), ou TGN(dictionnaire de noms de lieux) ;

  • temporal : couverture temporelle. On peut utiliser les codages Period (intervalle de temps) ou W3CDTF(dates).

rights Droits relatifs à la ressource : permet de donner des informations sur le statut des droits du document, par exemple la présence d'un copyright, ou un lien vers le détenteur des droits. L'absence de cet élément ne présume pas que le document est libre de droits.
audience Audience du document : l'audience représente le groupe de personnes à qui le document est destiné. L'audience est déterminée par l'auteur, le publicateur, ou un tiers. On peut utiliser les raffinements suivants :

Exemple

Voici en pratique un extrait d'un exemple de document dans lequel on a inséré des métadonnées.

  • <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    
    <html>
      <head>
        <title>Un document en HTML</title>
        <meta http-equiv="Content-type"
          content="text/html; charset=iso-8859-1" />
        <link rel="schema.DC"
          href="http://purl.org/dc/elements/1.1/" />
        <meta name="DC.Title" lang="fr" content="Un document en HTML" />
        <meta name="DC.Date.created" scheme="W3CDTF" content="2003-04-03" />
        <meta name="DC.Date.modified" scheme="W3CDTF" content="2003-04-27" />  
        <meta name="DC.Subject" lang="fr" content="HTML, document, Dublin Core" />
        <meta name="DC.Language" scheme="RFC3066" content="fr-FR" />
        <meta name="DC.Description" lang="fr"
          content="Mon premier document HTML avec métadonnées" />
      </head>
      <body>
        …
      </body>
    </html>
    

La balise <link …> référence la liste officielle des éléments et des affinements du Dublin Core. Elle permet aux logiciels de savoir à quoi exactement correspond le préfixe DC, en spécifiant son schéma. Pour faire référence à un élément du Dublin Core, il est conseillé d’utiliser le PURL (Persistent Uniform Resource Locator) défini pour le Dublin Core afin d’avoir une meilleure stabilité référentielle. Un PURL est un URL réputé persistant et qui est redirigé vers un service de résolutions de noms.
Ainsi, l’élément « Creator » du Dublin Core selon la version 1.1, fait référence univoquement à http://purl.org/dc/elements/1.1/creator, redirigé par le système PURL vers http://purl.org/2003/03/24/dces#creator (pourrait être redirigé vers un autre URL dans le futur).


Commentaires

Les terminologies du Dublin Core peuvent être déroutantes car certains champs peuvent être très généralisés : le Dublin Core parle de créateur (Creator) d’une ressource et non pas d’Auteur.
Le Dublin est très utile lors de la description de ressources peu complexes. Cependant, cet ensemble de métadonnées ne couvre pas les besoins potentiels de tous les utilisateurs et s’avère insuffisant pour des applications qui vont au-delà de recherches simples de ressources.
Le Dublin Core est un point de départ utilisable comme un noyau auquel viendront se rajouter des extensions en fonction des besoins de différentes disciplines ou des utilisateurs. Néanmoins, en pratique, les choses se font souvent dans l’autre sens :
Un musée peut utiliser une norme propre à une discipline pour documenter et gérer ses collections. Puis il extrait un sous-ensemble de ses enregistrements qui correspond aux éléments de la norme Dublin Core. Ces enregistrements conformes à la norme Dublin Core peuvent servir à des fins d'échange de données et de recherches simples. Cela est particulièrement important dans des projets conjoints ou lorsqu'il s'agit de partager des données de plusieurs disciplines.
Dans le cas de la gestion d’images, des champs additionnels ou des schémas complémentaires sont nécessaires pour définir des structures comme : la gestion administrative, les droits associés….