Après avoir entendu parler (ou reparler ?) à plusieurs reprises des "profils d'application" (application profiles ou AP) du Dublin Core, que ce soit dans le LLDXG ou à l'IFLA, j'ai éprouvé le besoin de me replonger dans tout cela. Force est de constater que je ne m'y étais pas intéressée de près depuis plusieurs années, alors que le développement de RDF et du Web de données a conduit le DCMI à revoir complètement son modèle abstrait (le DCAM, Dublin Core Abstract Model) et cette notion d'Application Profile, vers 2007.
Il n'est pas dans mon propos d'entrer dans les détails du DCAM aujourd'hui. Ce modèle est surtout utile en tant que référent pour le vocabulaire un peu particulier utilisé dans le monde Dublin Core.
Plus intéressant, à mon avis, est le Singapore framework for Application Profiles, un autre document du DCMI qui a le statut de "recommended resource" (autrement dit, ce n'est pas un standard, mais il est important quand même).
Ce document, le cadre de Singapour, a été proposé à la conférence DC en 2007 (décidément une année cruciale). Il définit les différents éléments constitutifs d'un Application Profile.
Quand on applique un standard de métadonnées, il existe différents niveaux qui doivent être pris en compte pour favoriser l'interopérabilité : bien sûr il faut respecter la syntaxe, le nom des éléments, la façon adéquate de les utiliser selon qu'ils sont obligatoires ou pas, répétables ou pas, etc. Mais pour aller plus loin, il faut aussi définir précisément les valeurs de ce qu'on met dans ces éléments, et éventuellement la façon de construire ces valeurs.
Je vais faire une comparaison pas du tout triviale avec le monde des bibliothèques.
Nous avons des standards qui sont des formats de métadonnées (MARC par exemple, et ses "différents parfums" comme dirait l'autre).
Nous avons d'autres standards qui sont des règles de catalogage et expliquent comment, à partir d'un document qu'on a entre les mains, on va déterminer quel est le titre, l'auteur principal, l'éditeur, etc. et comment il faut les transcrire dans la notice. Cette deuxième famille de norme comprend AACR2 pour les anglo-saxons, ISBD pour le reste du monde, et RDA pour l'avenir (peut-être).
Nous avons également des standards qui décrivent le modèle sous-jacent de toute cette information et à quoi elle sert : ce sont les FRBR et leurs petits frères FRAD (vient de sortir en français) et FRSAD.
Construire un Application Profile, cela revient à embrasser toute la palette de ces normes pour une communauté définie, et à formaliser le résultat.
Le Singapore framework définit ainsi les éléments suivants comme constitutifs d'un AP :
- les spécifications fonctionnelles (functional requirement ou FR - ça vous rappelle quelque chose ?) et le modèle du domaine : ce sont les représentations abstraites qui définissent l'objectif de notre AP, et elles sont obligatoires ;
- le Description Set Profile, sur lequel je vais revenir dans un instant ;
- et les guides d'utilisation (guidelines) pour le contenu et pour l'encodage, tous deux optionnels. Ce sont les équivalents de nos règles de catalogage mais aussi, guides et outils du catalogueur divers.
Je ne reviens pas sur les modèles et sur les guides.
Le Description Set Profile (DSP) fait l'objet d'un document normatif DCMI encore au stade de "working draft".
Le DSP est un document XML qui permet de décrire les différentes propriétés qu'on utilise dans notre AP, et jusqu'à un certain point, la façon dont on les utilise.
Le DSP prend complètement acte de RDF, au sens où il ne se restreint absolument pas aux propriétés du DC (voir ici pour un rappel). On peut donc construire un Application Profile en piochant dans les différents vocabulaires qu'on veut, FOAF, DC, etc. du moment que les propriétés qu'on utilise sont identifiées par une URI. Jusqu'ici, on est bien dans l'esprit de RDF.
Le DSP permet aussi de préciser un certain nombre de choses sur la façon dont on utilise ces propriétés. On peut préciser si l'objet doit être une ressource (identifiée par une URI) ou un littéral (une chaîne de caractères), ou si la propriété doit être obligatoirement une sous-propriété d'une propriété plus générique. On peut également définir qu'une propriété est obligatoire ou non, répétable ou non.
Bref, le DSP est conçu pour permettre de "valider" un ensemble de triplets RDF en fonction de règles prédéfinies (on parlerait d'un "pattern" en anglais, et ce sera compliqué à traduire). Le but étant d'obtenir des descriptions, ou si vous voulez des notices, le plus homogènes possibles. Il existe un document du DCMI qui définit les différents niveaux d'interopérabilité que l'on peut atteindre. Le DSP permet d'atteindre un niveau d'interopérabilité optimal !
Cette notion de validation, en réalité, est un non-sens en RDF. Les ontologies ne servent pas à valider les données. Elles se contentent de décrire les choses et leurs qualités, mais elles ne sont pas prescriptives. Ce n'est pas parce qu'il y a une propriété foaf:geekCode que tous les gens qu'on décrit en utilisant foaf sont nécessairement des geeks (ou doivent le devenir ;-) A l'inverse, en RDF, chaque triplet est indépendant ; il n'y a pas de notion de "notice", donc aucun moyen de dire que si on veut décrire une personne, il est obligatoire de mentionner son nom de famille - par ex.
Pour autant, si on veut pouvoir vérifier que certaines règles sont respectées pour produire certains types de données, on aura besoin de ce genre de mécanisme. Cela peut être le Description Set Profile tel qu'il se présente actuellement, mais on pourrait imaginer (et les gens du DCMI y réfléchissent) d'autres formalismes, des schémas XML, des schématrons, ou même des requêtes-type pour exprimer cette notion de validation.
Le Singapore framework for Application Profiles et le Description Set Profile sont donc des documents qui à mon sens méritent toute notre attention, car ils font le pont entre le monde du Linked Data et celui des bibliothèques où tout est encore articulé autour du paradigme de la notice. Il me paraît clair que nous aurons besoin de ce type de formalisme - je ne dis pas celui-là en particulier, mais quelque chose de ce genre - si on veut porter toute la complexité des données des bibliothèques dans le Linked Data. Ou ne serait-ce qu'une partie.
