Après Göteborg, Singapour : un cadre pour les Application Profiles

Publié le par

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.

Publicité

5 réactions sur “Après Göteborg, Singapour : un cadre pour les Application Profiles”

  1. Petite précision concernant les ontologies, histoire que tout le monde en profite. Il est tout à fait possible de définir une classe en OWL en précisant qu’elle doit avoir telle ou telle propriété. On utilise alors le mécanisme de restrictions de propriétés (cf. http://www.w3.org/TR/owl2-primer/#Property_Restrictions). Par ailleurs, il est vrai qu’une ontologie n’a pas le même statut qu’un schéma XML. Là où ce dernier définit et valide l’arborescence du flux XML, une ontologie définit la sémantique et la logique qui sous-tend des types de ressources et des propriétés. Néanmoins, il est tout à fait possible de valider la cohérence des données par rapport à la ou les ontologies utilisées. Ainsi, un raisonneur ne pourrait pas effectuer des inférences si les données ne respectent pas cette logique (on parle de cohérence des données dans le vocabulaire du Web sémantique). Il s’agit alors de vérifier les contraintes d’intégrité définies dans l’ontologie.

    Pour résumer, le rôle d’un schéma XML est clairement de permettre une validation structurelle d’un document XML, alors qu’il est possible avec l’ontologie de valider un ensemble de triplets par RDF par le fait qu’elle définit une sémantique et une logique. La différence semble mince, mais elle est essentielle. Maintenant, il est vrai que ce n’est pas ce qu’on met en avant. Tout d’abord, si on commence par ces aspects, on risque de renforcer la confusion avec XML, ce qui n’est pas souhaitable, deuxièmement, il y a déjà suffisamment de choses à s’approprier en comprenant les bases des technologies du Web sémantique avant d’en arriver à la définition d’une logique plus stricte et, enfin, les outils ne sont pas encore tout à fait matures pour effectuer ces contrôles sur des ensembles de données importants. Pour toutes ces raisons, il est vrai que nous avons tendance à mettre de côté ces possibilités.

    Bon, je vois qu’il serait intéressant d’écrire un billet sur OWL 2, il est commencé sur mon bureau, mais il faut que je trouve le temps de le poursuivre…

  2. Alléché, j’attends avec impatience.

    En attendant, la précision de la distinction entre schéma de validation structurelle de document et outil de validation sémantique et logique est bienvenue et mériterait à elle seule un billet…

  3. Si j’ai bien compris, le « schéma de validation structurelle » se contente de vérifier la conformité du document (par ex., un flux XML) au regard de sa syntaxe et d’un certain nombre d’attentes préalablement définies formellement. Au contraire, un « outil de validation sémantique » effectuerait les inférences et les déductions nécessaires pour valider la logique même de l’énoncé.

    Par exemple, soit l’énoncé « Socrate est un chat », exprimé en XML.
    Je peux valider que cette affirmation est structurellement correcte, par rapport à un schéma qui imposerait une phrase composée d’un sujet, d’un verbe et d’un complément. Éventuellement, je peux définir dans mon schéma XML une liste limitée de « compléments », et refuser la validation si « chat » n’en fait pas partie.

    Maintenant, soit le même énoncé, exprimé en RDF.
    Un outil de validation sémantique devrait pouvoir vérifier que Socrate est une personne, qu’un chat est un animal, qu’une personne n’est pas un animal (encore que ça se discute) donc que Socrate ne peut pas être un chat et que l’énoncé est faux.
    La condition pour que ça marche est que tous ces présupposés soient correctement décrits dans l’ontologie et dans les données (par exemple, vous, humains, avez déduit de mon énoncé que « Socrate » était un philosophe antique, mais si ça se trouve je parlais effectivement de mon chat qui s’appelle Socrate… allez savoir ;-)

Les commentaires sont fermés.