Inoxydable Dublin Core

Article rédigé en 2011, révisé en 2021

Logo du DCMI

C’est dans la petite ville de Dublin, Ohio que se déroule en 1995 une réunion initiée par des représentants de l’OCLC (Online Computer Library Center) et du NCSA (National Center for Supercomputing Applications). L’OCLC est un organisme à but non lucratif basé dans l’Ohio qui coordonne la production des ressources WorldCat pour le catalogage des revues et livres scientifiques. Le NCSA œuvre dans le déploiement aux États-Unis des infrastructure numériques. Le groupe d’environ 50 participants décide de proposer un ensemble de métadonnées capable de décrire de manière minimale et logique les pages du web alors naissant. Le jeu de métadonnées descriptives est nommé Dublin Core d’après le nom de la ville dans laquelle se déroule la réunion, et d’après le mot core qui pourrait être traduit en français par noyau, cœur ou essentiel.

Après quelque évolution des champs initialement définis, le groupe entreprend sur plusieurs années un important effort de normalisation. Le vocabulaire devient publié par l’IETF sous le nom RFC 2413 en 1998. Le NISO, organisme des standardisation américain publie en 2001 DC sous le nom Z39.85. L’International Standard Office édite Dublin Core en 2003 sous le nom ISO 15836, disponible en français de manière partiellement gratuite. Le format est actuellement mis à jour et maintenu par le Dublin Core Metadata Initiative (DCMI), un organisme à but non lucratif financé par la cotisation de ses membres et en relation avec l’ASIS&T (Association for Information Science and Technology).

Dublin Core définit un ensemble d’éléments – encore appelés selon les cas propriétés, métadonnées ou bien champs – dont l’usage est facultatif et qui peuvent être répétés autant de fois que nécessaire pour décrire un document électronique, une page ou une donnée du web. Les 15 premiers éléments constituent le Dublin Core simple. Ajoutés à partir de 2002, une version étendue nommée Dublin Core qualifié spécifie des éléments supplémentaires. Ils viennent pour certains préciser la sémantique des éléments simples et pour d’autres ajouter d’autres informations.

  • OCLC : Lien
  • NCSA : Lien
  • ASIS&T : Lien
  • Dublin Core Metadata Initiative : Lien
  • DCMI Metadata Terms : Lien
  • Using Dublin Core™ – Dublin Core™ Qualifiers : Lien
  • DCMI History : Lien
  • OCLC/NCSA Metadata Workshop Report, 1995 : Lien
  • IETF, 1998, Dublin Core Metadata for Resource Discovery, RFC 2413 : Lien
  • ANSI/NISO Z39.85-2012 The Dublin Core Metadata Element Set : Lien
  • ISO 15836-1:2017 : Lien
  1. Spécifications
  2. Cinq exemples d’encodages
  3. Alignement entre vocabulaires

1. Spécifications

Les éléments simples et affinés sont ici présentés conjointement. Certains contenus appartiennent de manière préférentielle à des dictionnaires. Ainsi, le contenu de type appartient préférentiellement à DCMI Type Terms. Ces contraintes sont ici précisées dans la description.

1.1 éléments Dublin Core simples et affinés

Les éléments affinés précisent le sens d’éléments simples particuliers. L’élément date par exemple peut être affiné en précisant created, valid, available, issued. Les éléments affinés du champs relation peuvent être spécifiés dans les deux sens. L’élément isPartOf a comme pendant hasPart. Des liens vers les exemples (ex) de la documentation officielle sont ici mentionnés :

Éléments simples Éléments affinés Description
title (ex) / titre alternative (ex) Titre du document : il s’agit a priori du titre principal du document. Un titre alternatif peut être fourni comme un titre abrégé ou une traduction.
type (ex)   Nature ou genre du contenu : grandes catégories de document. Il est recommandé d’utiliser des termes clairement définis au sein de l’organisme. Par exemple, le Dublin Core définit différents types dans le vocabulaire DCMI Types.
format (ex) extent (ex)
medium (ex)
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 lire le document. Il est recommandé d’utiliser des termes clairement définis, par exemple le type MIME, type de média défini internationalement.
subject (ex) / sujet   Sujet, phrases de résumé, ou codes, uri. Il est préférable d’utiliser des mots-clés choisis dans le cadre d’une politique de classement. Par exemple, on peut utiliser les codages de la bibliothèque du congrès (LCSH et LCC), le vocabulaire médical (MESH), ou les notations décimales des bibliothécaires (DDC et UDC).
description (ex) abstract (ex)
tableOfContents (ex)
Description du document : résumé, table des matières, ou texte libre.
creator (ex) / créateur   Créateur du document : nom de la personne, de l’organisme ou du service à l’origine de la rédaction du document. Possiblement renseigné par un uri. Il s’agit souvent de l’auteur que celui-ci soit un individu, un service ou une organisation.
contributor (ex)   Contributeur au document : nom d’une personne, d’un organisme ou d’un service qui contribue ou a contribué à l’élaboration du document.
publisher (ex) / éditeur   Éditeur du document : nom de la personne, de l’organisme ou du service à l’origine de la publication du document.
date (ex) available (ex), created (ex), dateAccepted (ex), dateCopyrighted (ex), dateSubmitted (ex), issued (ex), modified (ex), valid (ex) 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). Une durée s’exprime avec la barre oblique (1968/2015).
coverage (ex) / couverture spatial (ex)
temporal (ex)
Relative au contenu intellectuel, la portée peut préciser un domaine géographique, un laps de temps, ou une entité géographique administrative (nom d’un pays ou d’une région). Il est recommandé d’utiliser des représentations normalisées, par exemple dictionnaire de noms de lieux, un nom administratif d’état ou de région en ISO3166, Point ou Box pour la portée spatiale, Period ou W3CDTF pour la portée temporelle.
identifier (ex) / identifiant bibliographicCitation (ex) Identifiant non ambigu : il est recommandé d’utiliser un système de référencement précis, par exemple les URI ou les numéros ISBN.
language (ex) / langue   Langue du document : il est recommandé d’utiliser un code de langue conforme à un format spécialisé. (ex : fr, ou bien fr-CA pour le français du Canada).
source (ex)   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.
relation (ex) conformsTo (ex)
isFormatOf (ex) / hasFormat (ex)
isPartOf (ex) / hasPart (ex)
isVersionOf (ex) / hasVersion (ex)
isReferencedBy (ex) / references (ex)
isReplacedBy (ex) / replaces (ex)
isRequiredBy (ex) / requires (ex)
Lien vers une ressource liée : il est recommandé d’utiliser une dénomination formelle des ressources, par exemple leur URI. Plusieurs relations comme par exemple isPartOf et hasPart peuvent être indiquées dans un sens ou dans un autre, du tout vers la partie ou l’inverse.
rights (ex) / droits accessRights (ex)
license (ex)
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 cette propriété ne présume pas que le document est libre de droits.
Tableau des 15 éléments Dublin Core simples et affinés

Les éléments simples peuvent être classés en trois groupes qui indiquent la portée des informations susceptibles d’être renseignées. L’élément particulier type définit la classe du document électronique.

ContenuPropriété intellectuelleInstanciation
titre
sujet
description
type
source
relation
couverture
créateur
éditeur
contributeur
droits
date
format
identifiant
langue
Catégorisation des éléments, d’après le RFC 2413

1.2 Le type des objets décrits

L’élément type définit la Classe du document, autrement dit sa nature physique. De manière pratique, aucun ou bien au contraire plusieurs classes peuvent être spécifiés. Les contenus de type peuvent appartenir au 12 valeurs du DCMI Type Terms, ou bien être de nature non contrôlée.

  1. Collection
  2. Dataset
  3. Event
  4. Image
  5. InteractiveResource
  6. MovingImage
  7. PhysicalObject
  8. Service
  9. Software
  10. Sound
  11. StillImage
  12. Text

Des choix éditoriaux doivent être faits en vue de garder homogène le corpus, tout en le rendant aisé à indexer. S’agit il de décrire au plus prêt de la sémantique ou bien de traiter avec une certaine souplesse un nombre important d’items ? Un important travail de conception s’avère nécessaire afin de rendre le corpus aussi cohérent que possible. Une collection de carte anciennes par exemple pourrait être décrite avec deux valeurs de type : Collection conforme au DCMI Type Terms doublé au choix de Map, Cartographic Materials, Carte, termes non contrôlés. Un tableau de données géolocalisées au format CSV serait du type Dataset.

1.3 Éléments supplémentaires

Des éléments simples et affinés supplémentaires viennent compléter les spécifications de base. Ils précisent le public ciblé dans le cas de documents pédagogiques, la provenance d’un item pour des documents d’archives, le détenteur des droits ou la politique d’acquisition dans le cas d’une collection de bibliothèque.

Éléments simplesÉléments affinésDescription
audience (eg)mediator (eg),
educationLevel (eg)
Public du document : ciblé par l’auteur ou l’éditeur.
provenance (eg)Provenance : indique tout changement de propriétaire ou de détenteur du document.
rightsHolder (eg)Détenteur des droits : personne ou organisme gestionnaire ou propriétaire des droits.
instructionalMethod (eg)Méthode d’apprentissage : pour des ressources de type pédagogique.
accrualMethod (eg)Méthode d’acquisition : telle qu’un dépôt ou un achat. (Typiquement pour une collection)
accrualPeriodicity (eg)Périodicité d’acquisition : fréquence à laquelle des items sont ajoutés à une collection.
accrualPolicy (eg)Politique d’acquisition : concernant l’ajout d’items à une collection.
Tableau des 7 éléments supplémentaires

A réserver aux afficionados, un modèle abstrait vient donner un fondement théorique aux choix faits par les concepteurs : Lien

2. Cinq exemples d’encodages

Dublin Core peut selon les intentions et les contextes être encodé de différentes manières. Les espaces de nom restent constants et sont pour les éléments simples seuls http://purl.org/dc/elements/1.1/ et pour tous les éléments http://purl.org/dc/terms/ . Cinq exemples d’usages réels et fictifs sont ici proposés.

2.1 Dublin Core dans l’en-tête HTML

Localisées dans la balise head de l’en-tête HTML, les balises meta sont spécifiquement dédiées à l’affichage des métadonnées à l’adresse des robots d’indexation. L’exemple réel suivant est extrait du code source du document http://hdl.handle.net/2042/15134. Le code XHTML suivant est généré par le logiciel DSpace. Dans l’article Psychanalyse et politique in Individus et politique de la revue HERMES écrit en 1989, les auteurs Paul-Laurent Assoun et Erich Fromm étudient la correspondance entre Freud et Einstein. Les affichages de DC se retrouvent dans le code source de la page. Titre en bleu, espaces de noms en rouge, type en vert.

<?xml version="1.0" encoding="UTF-8"?>
 <!-- Déclaration du type de document -->
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html xmlns:xlink="http://www.w3.org/TR/xlink/" xmlns:mods="http://www.loc.gov/mods/v3" xmlns:dim="http://www.dspace.org/xmlns/dspace/dim" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:mets="http://www.loc.gov/METS/" xmlns:dri="http://di.tamu.edu/DRI/1.0/" xmlns:i18n="http://apache.org/cocoon/i18n/2.1">
 <head>
 <meta content="text/html; charset=UTF-8" http-equiv="Content-Type" />
 <meta name="Generator" content="DSpace 1.7.0" />
 <title>Psychanalyse et politique in Individus et politique.</title>
 <!-- Déclaration des schémas DC et DCTERMS -->
 <link rel="schema.DCTERMS" href="http://purl.org/dc/terms/" />
 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" />
 <!-- Métadonnées au format Dublin Core -->
 <meta name="DC.creator" content="ASSOUN, P.-C." xml:lang="-" />
 <meta name="DC.creator" content="FROMM, Erich" xml:lang="-" />
 <!-- L’emploi du format W3CDTF est précisé pour la date -->
 <meta name="DCTERMS.dateAccepted" content="2008-02-15T09:17:51Z" scheme="DCTERMS.W3CDTF" />
 <meta name="DCTERMS.available" content="2008-02-15T09:17:51Z" scheme="DCTERMS.W3CDTF" />
 <meta name="DCTERMS.issued" content="1989" xml:lang="en_US" scheme="DCTERMS.W3CDTF" />
 <meta name="DC.identifier" content="http://hdl.handle.net/2042/15134" scheme="DCTERMS.URI" />
 <meta name="DCTERMS.abstract" content="Recueil de 8 articles. La correspondance Freud-Einstein : &quot; Pourquoi la guerre &quot; (1933), commentée par F. FORNARI et P.-C. ASSOUN, qui est l'auteur d'autre part de &quot; Freudisme et indifférentisme politique : objet de l'idéal et objet de la démocratie &quot;. De E. FROMM : &quot; Méthode et tâche d'une psychologie analytique &quot; (1932). D'autres articles : Psychanalyse et politique sociale| Approche communicationnelle de l'inconscient| Le discours analytique et la politique" xml:lang="fr" />
 <meta name="DCTERMS.extent" content="28847 bytes" />
 <meta name="DC.format" content="application/pdf" />
 <meta name="DC.language" content="fr" xml:lang="en_US" scheme="DCTERMS.RFC1766" />
 <meta name="DC.publisher" content="CNRS Editions, Paris (FRA)" xml:lang="en_US" />
 <meta name="DC.relation" content="http://irevues.inist.fr/utilisation" xml:lang="en_US" />
 <meta name="DC.source" content="Hermès (Paris.1988) [ISSN 0767-9513], 1989, N° 5-6; p. 255-366" xml:lang="en_US" />
 <!-- L’élément subject est répété -->
 <meta name="DC.subject" content="Politique" xml:lang="fr" />
 <meta name="DC.subject" content="Psychanalyse" xml:lang="fr" />
 <meta name="DC.subject" content="Psychosociologie" xml:lang="fr" />
 <meta name="DC.subject" content="Politics" xml:lang="en" />
 <meta name="DC.subject" content="Psychoanalysis" xml:lang="en" />
 <meta name="DC.subject" content="Psychosociology" xml:lang="en" />
 <meta name="DC.title" content="Psychanalyse et politique in Individus et politique." xml:lang="fr" />
 <meta name="DC.type" content="Article" xml:lang="en_US" />
 <!-- Métadonnées non Dublin Core -->
 <meta content="CNRS Editions, Paris (FRA)" name="citation_publisher" />
 <meta content="http://documents.irevues.inist.fr/handle/2042/15134" name="citation_abstract_html_url" />
 <meta content="Psychanalyse et politique in Individus et politique." name="citation_title" />
 <meta content="Article" name="citation_keywords" />
 <meta content="ASSOUN, P.-C.; FROMM, Erich" name="citation_authors" />
 <meta content="fr" name="citation_language" />
 <meta content="http://documents.irevues.inist.fr/bitstream/2042/15134/1/HERMES_1989_5-6_255_P3.pdf" name="citation_pdf_url" />
 <meta content="1989" name="citation_date" />
 </head>
 <body>
[…]
  • Expressing Dublin Core™ metadata using HTML/XHTML meta and link elements, 2008 : Lien

2.2 Interopérabilité avec OAI-PMH

Défini à partir de 2001, le format OAI-PMH (Open Archive Initiative – Protocol for Metadata Harvesting) est dédié à l’échange de métadonnées entre un « entrepôt » et un « moissonneur de métadonnées« . Un entrepôt correspond simplement à une bibliothèque numérique compatible avec le protocole alors qu’un moissonneur est une sorte de roobot d’indexation. Le moissonneur lance une requête http à l’adresse de l’entrepôt. La réponse consiste en un fichier XML au format OAI-PMH qui inclut les métadonnées au format Dublin Core. Ainsi l’URL fonctionnelle correspond à l’article vu dans l’exemple vu précédemment : http://documents.irevues.inist.fr/dspace-oai/request?verb=GetRecord&metadataPrefix=oai_dc&identifier=oai:documents.irevues.inist.fr:2042/15134. Le code source de la réponse peut être étudié :

<?xml version="1.0" encoding="UTF-8" ?>
 <OAI-PMH xmlns="http://www.openarchives.org/OAI/2.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/ http://www.openarchives.org/OAI/2.0/OAI-PMH.xsd">
 <responseDate>2011-09-24T07:32:39Z</responseDate>
 <request metadataPrefix="oai_dc" verb="GetRecord" identifier="oai:documents.irevues.inist.fr:2042/15134"> http://documents.irevues.inist.fr/dspace-oai/request </request>
 <GetRecord>
 <record>
 <header>
 <identifier>oai:documents.irevues.inist.fr:2042/15134</identifier>
 <datestamp>2009-11-20T06:22:58Z</datestamp>
 <setSpec>hdl_2042_15095</setSpec>
 </header>
 <metadata>
 <oai_dc:dc xmlns:oai_dc="http://www.openarchives.org/OAI/2.0/oai_dc/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.openarchives.org/OAI/2.0/oai_dc/ http://www.openarchives.org/OAI/2.0/oai_dc.xsd">
 <dc:title> Psychanalyse et politique in Individus et politique. </dc:title>
 <dc:creator>ASSOUN, P.-C.</dc:creator>
 <dc:creator>FROMM, Erich</dc:creator>
 <dc:subject>Politique</dc:subject>
 <dc:subject>Psychanalyse</dc:subject>
 <dc:subject>Psychosociologie</dc:subject>
 <dc:subject>Démocratie</dc:subject>
 <dc:subject>Guerre</dc:subject>
 <dc:subject>Nucléaire</dc:subject>
 <dc:subject>Communication</dc:subject>
 <dc:subject>Freud, S.</dc:subject>
 <dc:subject>Einstein, A.</dc:subject>
 <dc:subject>Fromm, E.</dc:subject>
 <dc:subject>Philosophie du droit</dc:subject>
 <dc:subject>Politics</dc:subject>
 <dc:subject>Psychoanalysis</dc:subject>
 <dc:subject>Psychosociology</dc:subject>
 <dc:subject>Democracy</dc:subject>
 <dc:subject>War</dc:subject>
 <dc:subject>Nuclear</dc:subject>
 <dc:subject>Communication</dc:subject>
 <dc:subject>Freud, S.</dc:subject>
 <dc:subject>Einstein, A.</dc:subject>
 <dc:subject>Fromm, E.</dc:subject>
 <dc:subject>Philosophy of law</dc:subject>
 <dc:description> Recueil de 8 articles. La correspondance Freud-Einstein : " Pourquoi la guerre " (1933), commentée par F. FORNARI et P.-C. ASSOUN, qui est l'auteur d'autre part de " Freudisme et indifférentisme politique : objet de l'idéal et objet de la démocratie ". De E. FROMM : " Méthode et tâche d'une psychologie analytique " (1932). D'autres articles : Psychanalyse et politique sociale| Approche communicationnelle de l'inconscient| Le discours analytique et la politique </dc:description>
 <dc:publisher>CNRS Editions, Paris (FRA)</dc:publisher>
 <dc:date>2008-02-15T09:17:51Z</dc:date>
 <dc:date>2008-02-15T09:17:51Z</dc:date>
 <dc:date>1989</dc:date>
 <dc:type>Article</dc:type>
 <dc:format>28847 bytes</dc:format>
 <dc:format>application/pdf</dc:format>
 <dc:identifier>http://hdl.handle.net/2042/15134</dc:identifier>
 <dc:source> Hermès (Paris.1988) [ISSN 0767-9513], 1989, N° 5-6; p. 255-366 </dc:source>
 <dc:language>fr</dc:language>
 <dc:rights>http://irevues.inist.fr/utilisation</dc:rights>
 </oai_dc:dc>
 </metadata>
 </record>
 </GetRecord>
 </OAI-PMH>
  • Open Archives Initiative, Protocol for Metadata Harvesting : Lien

2.3 Dublin Core et Bibo en JSON-LD

Créé fin 2008, JSON-LD est devenu en 2014 un standard du W3C maitenant bien adopté. Le code JSON-LD est inséré dans une balise <script> du corps d’HTML et peut servir à optimiser le référencement des bibliothèques numériques. Dans cet exemple, le livre « La République » de « Platon » de même que son premier chapitre sont décrits à l’aide de deux ontologies différentes Dublin Core et Bibo. Les préfixes des espaces de nom sont définis dans « @context« . Bibo une ontologie largement utilisée par les bibliothèques numériques vient ajouter le type contrôlé Book non spécifié par Dublin Core. Plusieurs ontologies peuvent être mixées avec JSON-LD.

<script type="application/ld+json">
{
   "@context":
   {
     "dct": "http://purl.org/dc/terms/",
     "bibo": "http://purl.org/ontology/bibo/"
   },
   "@id": "http://example.org/library/the-republic",
   "@type": "bibo:Book",
   "dct:creator": "Plato",
   "dct:title": "The Republic",
   "dct:hasPart":
   {
     "@id": "http://example.org/library/the-republic#introduction",
     "@type": "bibo:Chapter",
     "dct:title": "The Introduction",
     "dct:description": "An introductory chapter on The Republic."
   }
 }
</script>
  • Bibliographic Ontology (Bibo) Specification, 2009 : Lien

2.4 Dublin Core en XML / RDF

RDF constitue le langage pilier du web sémantique et les métadonnées au format DC peuvent être échangées encodées en XML / RDF. Une description fictive de la page d’accueil du site http://dublincore.org/ est ici proposée. Cette description pourrait prendre sens dans le cadre de l’élaboration d’un répertoire de sites du web par exemple.

<?xml version="1.0"?>
<!DOCTYPE 
rdf:RDF PUBLIC "-//DUBLIN CORE//DCMES DTD 2002/07/31//EN"
"http://dublincore.org/documents/2002/07/31/dcmes-xml/dcmes-xml-dtd.dtd">
<!-- Déclaration des espaces de nom RDF et DC -->  
<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://dublincore.org/">
 <!-- Métadonnées Dublin Core --> 
 <dc:title>Dublin Core Metadata Initiative - Home Page</dc:title>
 <dc:description>The Dublin Core Metadata Initiative Web site.</dc:description>
 <dc:date>2001-01-16</dc:date>
 <dc:format>text/html</dc:format>
 <dc:language>en</dc:language>
 <dc:contributor>The Dublin Core Metadata Initiative</dc:contributor>
 <dc:title xml:lang="fr">L'Initiative de métadonnées du Dublin Core</dc:title>
 <dc:title xml:lang="de">Der Dublin-Core Metadata-Diskussionen</dc:title>
 </rdf:Description>
</rdf:RDF>

D’autres exemples d’encodages se trouvent dans la doc DCMI sous le titre Serialization Examples. Ils incluent les formats Microdata / Microdonnées, RDFA, JSON-LD.

  • Serialization Examples of LRMI/Schema.org Markup : Lien

2.5 Dublin Core dans le Data Catalog Vocabulary (DCAT)

Le mouvement d’ouverture des données est légiféré en France et promu en Europe depuis les années 2010 environ. Les données ouvertes correspondent en général aux données statistiques des états, des territoires et des villes. Les administrations de l’Etat doivent ainsi rendre public des données concernant les élections, le cadastre, la démographie, la mobilité, l’éducation. Les sciences sont également concernées et en particulier la médecine, la géologie, l’environnement et les sciences humaines. Le mouvement Open Data s’intéresse particulièrement aux données géolocalisées et produit de nombreuses cartes et informations statistiques.

Les données ouvertes correspondent essentiellement à des jeux de données (Datasets) aisés à échanger et éventuellement mis à jour régulièrement. Ceux-ci sont fournis aux formats CSV, XML, RDF ou JSON-LD et munis d’une licence adaptée. Comme le montre la figure 1, trois types d’acteurs se distinguent en terme d’organisation : 1/ Les portails de données et métadonnées (les entrepôts), 2/ Les intermédiaires de métadonnées (les moissonneurs), 3/ les consommateurs de données (le public). L’architecture informatique se montre comparable à celle d’OAI-PMH.

Le vocabulaire Data Catalog Vocabulary (DCAT) est dédié à la documentation des jeux de données. Il est publié sous forme de brouillon par le W3C en 2012 et accède en avril 2020 au statut de recommandation. Un vocabulaire concurrent de celui-ci est DataCite. DCAT intègre Dublin Core comme le montre la figure 2 de ce billet.

Fig 1 : Les acteurs des données ouvertes : Lien
Fig. 2 : Le modèle de données DCAT, dct pour Dublin Core Terms : Lien
  • Data Catalog Vocabulary (DCAT) – Version 2, W3C, 2020 : Lien
  • Portail OpenData du Gand Nancy : Lien
  • DataCite : Lien

3 Alignement entre vocabulaires

Les vocabulaires se sont multipliés à partir de 2010 et la nécessité est apparue de formaliser des alignements. Le W3C propose l’alignement de certains termes communs à PROV et Dublin Core étendu. L’ontologie PROV créé fin 2012 vise à décrire la provenance de toute donnée numérique (document, illustration, jeu de données, liste de termes).

  • PROV Model Primer, 2013, W3C : Lien
  • Dublin Core to PROV Mapping, 2013, W3C : Lien

Dans cet autre exemple d’alignement, nous nous intéresserons spécifiquement au DCMI Type Vocabulary conseillé pour renseigner l’élément type. Les termes sont comparés et alignés avec les termes des ontologies schema.org et Wikidata. L’ontologie schema.org proposée initiallement par les moteurs de recherche se trouve actuellement promue par le DCMI. Wikidata est l’une des ontologies étroitement associée à Wikipédia. Il est à noter que ce qui est considéré comme une classe par DC ou schema.org ne l’est pas forcément par Wikidata dont la portée s’avère plus large.

DCMI Type Termsschema.orgWikidata
Collection
Dataset
Event
Image
InteractiveResource
MovingImage
PhysicalObject
Service
Software
Sound
StillImage
Text
Collection
Dataset
Event
ImageObject

VideoObject
Product
Service
SoftwareApplication
AudioObject
Photograph, Drawing, Painting, Map
Text
collection, Q2668072
data set, Q1172284
significant event, P793
image, P18

video, P10
physical object, Q223557
service, Q7406919
software, Q7397
sound, Q11461
photograph, drawing, painting, map
text, Q324460
Tab. 1 : Alignement des Classes « DCMI Type Terms » avec « schema.org » et « Wikidata »

Conclusion

Dublin Core constitue un des piliers de l’interopérabilité sur le web car relativement simple d’usage et largement utilisé depuis les années 90 pour décrire tout document électronique. Ce vocabulaire n’a pas pour objectif de remplacer dans les bibliothèques, archives, centres d’édition des vocabulaires métiers tels qu’EAD, MARC, BIBFRAME, FRBR, MODS et d’autres encore, mais de produire un résumé bref et structuré, susceptible d’être lu par un vaste public y compris les moteurs de recherche. De nombreux logiciels traditionnels et du web comme par exemple Zotero, DSpace, Omeka, Lodel, basent une part de leur logique descriptive sur DC. Un logiciel particulier NumaHop, développé par la Bibliothèque Ste Geneviève, s’avère conçu pour générer à partir de MARC ou EAD du Dublin Core simple et étendu.

Le DCMI s’est rapproché depuis 2008 de schema.org, le vocabulaire créé par Google, Microsoft, Pinterest, Yandex afin de poursuivre ses travaux en direction d’une ontologie de haut niveau. Le format Dublin Core lui-même ne devrait plus connaitre d’évolution notable. Il reste largement utilisé conjointement avec d’autres ontologies simples telles que par exemple Bibo – The Bibliographic Ontology – dédiée au monde des bibliothèques, Foaf (Friends of a friend) – dédié à une description sommaire des personnes, organisations et réseaux sociaux. La description de choses complexes à l’aide de plusieurs vocabulaires choisis de manière adéquate devient alors relativement aisée.

Preuve de l’intérêt soutenu de DC, des alignements existent également avec MODS (Metadata Object Description Schema) un schéma de métadonnées récemment adapté en RDF et utilisé comme format pivot, notamment par des gestionnaire de référence bibliographique comme JabRef ou Zotero et fréquemment utilisé conjointement avec MADS (Metadata Authority Description Schema) pour décrire les personnes, collectivités, lieux et sujets.

Fig. 3 : Un exemple de modèle de données « Linked Archives » spécifiquement dédié au monde des archives : Lien
  • International Conference on Dublin Core and Metadata Applications, DCMI, 2001 – 2019 : Lien
  • Termes de métadonnées DCMI, 2008, traduction officielle en français, yoyodesign : Lien
  • Métadonnées et Dublin Core, sur Openweb.eu.org : Lien
  • Dublin Core Metadata Gen: Generator of metadata using Dublin Core : Lien
  • NumaHop, Bibliothèque Ste Geneviève : Lien
  • Foaf : Lien
  • BIO : Lien
  • Data Catalog Vocabulary : Lien
  • MODS : Lien
  • MADS : Lien
  • Dublin core : théorie et applications, Catherine Morel-Pair, 2010, PDF : Lien

Un commentaire

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s