Dublin Core, le pouvoir de la simplicité

Suite à une suggestion de Stéphane, je voudrais faire le point sur une question souvent posée quand on parle de Dublin Core : est-ce que le fait d’utiliser Dublin Core va appauvrir mes données ?

La réponse est plus complexe que juste « oui » ou « non ».

D’abord, il n’y a pas un seul Dublin Core. Le Dublin Core, c’est un ensemble de standards dont j’avais rappelé l’articulation dans un précédent billet. Relisez-le, c’est un pré-requis pour la suite.

Maintenant si vous prenez des données dans un format richement structuré, par exemple MARC, et qu’une fois passé en XML, vous lui appliquez une conversion pour le transformer en « Dublin Core simple », oui, vous allez appauvrir vos données, et ce pour trois raisons :
le DC dit « simple » se limite aux 15 éléments « de base » et ne permet pas d’exprimer la richesse contenue dans les Dublin Core metadata terms, donc vous serez obligé de choisir pour chacun de vos éléments en MARC une cible assez générique (par exemple, tous les types de titre, titre propre, titre parallèle, titre original et que sais-je encore vont tous atterrir en « dc:title ») ;
– exprimée en XML, votre notice en DC doit respecter le schéma XML du DC simple, il est donc exclu d’introduire la moindre fantaisie et de « rajouter » quoi que ce soit qui vous permettrait d’exprimer une information plus fine.
Ce scénario, c’est typiquement ce qui va vous arriver si vous faites de l’OAI-PMH, car ce protocole impose de présenter ses données au format Dublin Core simple.

Mais ce n’est pas la seule façon d’utiliser le Dublin Core.
L’ensemble des classes et des propriétés exprimées dans le Dublin Core metadata terms (qui est donc plus large que les 15 éléments de base) peut en effet être utilisé pour exprimer des triplets en RDF.
Mais en RDF, contrairement à XML, chaque triplet est indépendant et signifiant indépendamment de tout contexte, ce qui signifie que je peux tout à fait utiliser pour décrire la même ressource des propriétés du Dublin Core et d’autres propriétés, venant d’autres vocabulaires ou ontologies.
L’utilisation de Dublin Core en RDF est donc deux fois plus riche :
– le vocabulaire lui-même est plus riche et plus détaillé
– et on n’est pas obligé de s’y limiter, on peut le combiner avec d’autres.
Pour prendre un exemple, si je veux décrire une ressource en précisant un lieu, je peux utiliser la propriété « dc:spatial » (qui est plus fine que « dc:coverage », celui-ci pouvant être utilisé pour la couverture temporelle aussi bien que géographique) mais aussi la combiner avec des propriétés d’une ontologie géographique permettant d’exprimer finement les coordonnées (latitude, longitude) du lieu.
Ainsi, pour reprendre mon exemple ci-dessus, si je passe ma notice MARC en RDF, il est probable que certaines parties de la notice pourront être exprimées en utilisant des propriétés du DC, et d’autres non, mais ce n’est pas un problème, je peux les combiner.

Et l’interopérabilité, dans tout ça, me direz-vous ?
C’est vrai, le principal atout du Dublin Core, c’est interopérabilité, et c’est pour cela que l’OAI-PMH impose le Dublin Core simple, partant du principe qu’il permet de décrire tout type de ressources.
Pourtant, l’utilisation du DC simple en XML pose de GROS problèmes d’interopérabilité : comme il appauvrit les données, il y a une infinité de façons de l’appliquer, et les résultats, à la fin, sont rarement compatibles : on a tendance à « bourrer » l’information tant bien que mal dans les 15 éléments, voire à les répéter un nombre incalculable de fois au point de ne plus savoir où on en est. Mais bon, c’est toujours mieux que rien ; donc on crée des règles, ou des profils d’application, pour s’assurer que tout le monde fait (un peu) la même chose.
En RDF, le Dublin Core est un vrai atout pour l’interopérabilité car il permet à une multitude de gens d’exprimer la même chose de la même manière, à un niveau de granularité plus fin. Au lieu que chacun réinvente la roue et crée sa propre propriété « titre », ou « auteur », on utilise le Dublin Core, qui permet au moins, pour un large ensemble de ressources décrites en RDF, de repérer assez facilement les « titres » et les « auteurs ». Ensuite, on complète avec d’autres propriétés créées exprès ou prises dans d’autres vocabulaires.
C’est la raison pour laquelle le DC joue un rôle essentiel dans le Linked Data, qui est d’ailleurs le sujet de la conférence DC 2009 à Séoul.

4 réflexions sur “Dublin Core, le pouvoir de la simplicité

  1. Pour répondre aussi à Stéphane (commentaire du précédent billet sur DC) et apporter de l’eau au moulin de l’intérêt de Dublin Core dans un environnement RDF et Web de données … depuis le temps que j’apprécie Figoblog en silence …

    Dublin Core est, dès aujourd’hui (hier, même) reconnu comme une « ontologie » (voir le moteur Swoogle par exemple) et utilisé « naturellement » par les communautés pour décrire des ressources numériques, avec, et en compléments d’autres standards (ou de microformats « moins standard » pour l’instant), portant sur des personnes, des connaissances, des lieux, des événements (FOAF, ontologies en owl, , espace de nom « geo », hCalendar … etc, etc). Tester par exemple Sindice en recherche avancée avec une propriété dc:title et une valeur « harry potter » , ou directement DBpedia pour qui manipule SPARQL : DC ou autre, ça devient impressionnant, cette affaire !

    Ces triplets indépendants et réutilisables ailleurs sont effectivement intéressants et opérationnels comme « ingrédients » libres pour créer de « nouveaux plats » (selon les termes de Yann Nicolas à la journée ADBU 2009, plus que les éléments « méta » du (X)HTML, et certainement même que des descriptions « captives » en DC-XML, simple ou qualifié.

    Il faut signaler aussi, et quand même, que ces balises « meta » renseignées en DC sont « parfois » utilisées. Un exemple : Zotero, sympathique plug-in Firefox Web 2 de gestion de « références bibliographiques » (y compris sur pages web ou images, interopérabilité avec Flick’r notamment), les reconnait, les analyse et les intègre automatiquement à sa base de données, laquelle visiblement les utilise tels quels avec d’autres, FOAF encore, etc… voir l’export « RDF Zotero » (NB : Zotero reconnait aussi COINS, métadonnées intégrées à la page via RDFa).

    … Information destinée à alimenter aussi le sujet « le Web de données au secours du Web 2 » qui se développe depuis quelques mois.

    Bref, à suivre, encore et toujours …

  2. J’ai l’impression de trouver dans ce billet LA solution à mon problème : je gère une base de données centralisée qui doivent être structurées au format non pas DC mais LOM (mais c’est le même « combat ») pour garantir leur interopérabilité mais je voudrais leur rajouter un tout petit nb de données spécifiques à ma collection (de vidéos), sans mettre en péril l’interopérabilité.
    Seul hic : je ne sais pas ce que sont des triplets, ni RDF.
    Je pensais utiliser XML.
    Pourriez-vous m’éclairer ?

  3. La description de votre problème est sommaire, mais voici quelques pistes :
    – LOM est un vocabulaire XML ;
    – l’utilisation des espaces de nom XML peut être une solution à votre problème ; en effet, vous pouvez créer votre propre vocabulaire XML intégrant vos données spécifiques, puis utiliser ce vocabulaire sous forme d’espace de nom dans vos fichier LOM, ce qui vous permet de rajouter les métadonnées dans votre fichier LOM tout en ayant la sémantique de votre vocabulaire ;
    – l’interopérabilité est maintenue puisque les outils travaillant sur le LOM de base l’ont toujours à leur disposition, et ceux comprenant votre vocabulaire supplémentaire pourront également l’utilisation. L’équivalent du ‘dumb-down principle’ des qualificateurs Dublin Core.

    Maintenant, savoir si cela est possible dépend de la solution logicielle employée.

    Emmanuel Di Pretoro

Les commentaires sont fermés.