Le cadre de Singapour pour les profils d'application Dublin Core

Table des matières

1. Introduction
2. Contexte
3. Le cadre de Singapour
4. Exemples
5. Références

1. Introduction

Le cadre de Singapour pour les profils d'application Dublin Core est une structure (framework) pour concevoir des applications de métadonnées qui soient au maximum interopérables et pour les documenter afin d'être au maximum réutilisables. Le cadre définit un ensemble de composantes descriptives, nécessaires ou utiles pour la documentation d'un profil d'application, et décrit comment ces standards documentaires sont liés aux modèles de domaine normalisés et aux standards établissant le Web sémantique. Le cadre constitue une base pour évaluer l'exhaustivité documentaire et la conformité aux principes architecturaux du Web des profils d'application.

Ce document est un résumé du cadre. D'autres documents sont prévus pour aider à la création de la documentation nécessaire.

2. Contexte

Le terme profil est largement employé pour désigner un document qui décrit la façon dont des normes ou des spécifications sont mises en œuvre pour soutenir les exigences d'une application, d'une fonction, d'une communauté ou d'un contexte particuliers. Dans le métier des métadonnées, on emploie le terme profil d'application pour décrire l'adaptation des normes aux applications spécifiques.

Le modèle abstrait DCMI, publié comme recommandation du DCMI en mars 2005, fournit un modèle de métadonnées adéquat pour formaliser la notion des profils d'application interprétables par une machine. En septembre 2007, Mikael Nilsson présentait une structure pour la définition de profils d'application Dublin Core à la Conférence internationale sur le Dublin Core et les applications de métadonnées à Singapour — d'où le nom de « cadre de Singapour » (Singapore Framework).

3. Le cadre de Singapour

3.1 La notion de profil d'application Dublin Core

Le processus de « profilage » d'un standard introduit une possibilité de tension entre, d'une part, la satisfaction des exigences d'efficacité, de spécificité et de localisation dans le cadre d'une communauté ou d'un service et, d'autre part, le maintien de l'interopérabilité entre les communautés et les services. Des standards de métadonnées différents peuvent offrir des niveaux de flexibilité différents : certains standards seront plus prescriptifs et laisseront relativement peu d'options de personnalisation, tandis que d'autres présenteront une large gamme de caractéristiques optionnelles qui demanderont un degré de sélection et une adaptation considérables pour la mise en œuvre.

Il est souhaitable de pouvoir utiliser les standards de métadonnées spécifiques d'une communauté ou d'un domaine, ou des composantes de ces standards, en les combinant. Les implémenteurs de standards de métadonnées devraient pouvoir assembler les composantes dont ils ont besoin pour un ensemble particulier de fonctions. Et si cela signifie de faire appel à des composantes définies dans des standards de métadonnées différents, cette possibilité serait idéale. Ils devraient aussi avoir l'assurance que cet assemblage global sera interprété correctement par des applications conçues indépendamment l'une de l'autre. Ce processus est décrit par la métaphore du jeu de Lego : le concepteur d'une application devrait être capable d'enficher des « blocs de construction » tirés de « kits » fournis par des standards de métadonnées différents pour assembler la construction qui satisfera ses exigences, même si les kits qui fournissent ces blocs ont été créés de façon très indépendante.

Dans un profil d'application Dublin Core, les termes référencés appartiennent bien entendu aux types décrits par le modèle abstrait DCIM, c'est-à-dire qu'un profil d'application Dublin Core décrit, pour une certaine classe de descriptions de métadonnées, quelles propriétés sont référencées dans les déclarations et comment contraindre l'utilisation de ces propriétés, par exemple, en spécifiant des schémas de codage de vocabulaire et des schémas de codage de syntaxe. La notion Dublin Core du profil d'application n'impose aucune limitation pour ces propriétés ou schémas de codage, que ceux-ci soient définis ou gérés par le DCMI ou par une autre agence : la condition première est que les propriétés citées dans un profil d'application Dublin Core soient compatibles avec la notion de propriété du cadre de description de ressource (RDF).

Le modèle abstrait impose que toutes les références aux termes dans une description de métadonnées Dublin Core soient réalisées avec des adresses URI. Une fois les termes identifiés par des adresses URI, on peut les extraitre de n'importe quelle source et les référencer sans ambiguïté. Cet ensemble de termes peut être vu comme le « vocabulaire » de l'application ou de la communauté, pour le soutien desquelles le profil d'application est conçu. On peut également déployer les termes de ce vocabulaire dans les vocabulaires d'autres profils d'application Dublin Core.

Il importe de réaliser que la sémantique des termes utilisés dans les profils d'application est portée par leurs définitions, qui sont indépendantes de tout profil d'application. L'interopérabilité sémantique se traite hors du domaine (realm) des profils d'application et agit donc d'un profil d'application à l'autre. Un profil d'application décrit l'ensemble des directives, des règles de description et des contraintes utilisées pour créer un jeu d'enregistrements de métadonnées (set of metadata records) spécifique. Puisque l'interopérabilité sémantique dépend de l'emploi correct des termes définis dans un ou plusieurs vocabulaires, il s'agit pour les profils d'application de fournir une interopérabilité syntaxique et structurelle de haut niveau, en plus de l'interopérabilité sémantique.

3.2 Composantes d'un profil d'application Dublin Core

Selon le cadre de Singapour, un profil d'application Dublin Core est un paquet de documentation avec les composantes suivantes :

Exigences fonctionnelles (obligatoire)

Les exigences fonctionnelles (functional requirements) d'un profil d'application Dublin Core décrivent les fonctions pour le soutien desquelles le profil d'application est conçu, ainsi que les fonctions hors champ (out of scope).

Les exigences fonctionnelles forment la base d'évaluation du profil d'application pour la cohérence interne et pour fournir une indication sur l'adéquation du profil d'application à une utilisation donnée.

Modèle de domaine (obligatoire)

Le modèle de domaine (domain model) définit les entités de base décrites par le profil d'application et leurs relations fondamentales. Le but du modèle de domaine est de définir la portée de base du profil d'application.

Le modèle de domaine peut s'exprimer avec juste du texte ou en utilisant une approche plus formelle telle que UML.

Profil de l'ensemble de description (obligatoire)

Le profil de l'ensemble de description (description set profile) (cf. [DSP]) défini un jeu d'enregistrements de métadonnées qui sont des instances valides d'un profil d'application. Le modèle du profil de l'ensemble de description est en cours de développement au sein du forum d'architecture du Dublin Core et en attente d'avancement au stade de version préliminaire du DCMI.

Le modèle du profil d'ensemble de description Dublin Core est conçu pour offrir un langage de contrainte simple pour les métadonnées Dublin Core, fondé sur le modèle abstrait DCMI. Un profil d'ensemble de description contraint les ressources descriptibles dans un ensemble de description conforme au profil d'application, les propriétés qui sont utilisables et les manières de référencer une valeur.

Guide d'utilisation (optionnel)

Le guide d'utilisation (usage guidelines) optionnel décrit comment utiliser le profil d'application, comment les propriétés sont censées être utilisées dans le contexte de l'application, etc.

Guide de la syntaxe de codage (optionnel)

Le guide de la syntaxe de codage (encoding syntax guidelines) optionnel décrit les syntaxes spécifiques du profil d'application ou le guide de la syntaxe, le cas échéant.

Ce modèle est illustré dans la figure suivante :

3.3 Standards de domaine et standards de fondation

La figure montre aussi de quelle façon les composantes d'un profil d'application Dublin Core se rapportent aux « standards du domaine » — les modèles et spécifications largement utilisés par les communautés — et au cadre de description de ressource (RDF) normalisé du W3C, le socle implicite de la sémantique interprétable par une machine de notre temps.

Les profils d'ensemble de description sont fondés sur le modèle abstrait DCMI, au point de spécifier comment utiliser les entités du modèle abstrait DCMI dans un jeu de métadonnées spécifiques. Dans ce sens, le modèle abstrait DCMI constitue un modèle reconnu des composantes structurelles des enregistrements de métadonnées. Le modèle abstrait DCMI trouve à son tour un ancrage dans RDF.

Les profils d'ensemble de description utilisent typiquement les propriétés et les classes définies dans des vocabulaires de métadonnées tels que les termes de métadonnées DCMI. Les vocabulaires de métadonnées s'expriment à leur tour en fonction du langage de description de vocabulaire RDF (appelé également RDF Schema ou RDFS).

Le modèle de domaine utilisé dans une application est souvent fondé sur un modèle de domaine largement répandu ; par exemple, le modèle générique FRBR (Functional Requirements for Bibliographic Records) est un point de référence important pour la description de ressources dans le monde des bibliothèques.

Les directives pour exprimer un profil d'ensemble de description spécifique dans un format de données spécifique peuvent se fonder sur l'une des spécifications publiées par le DCMI, qui donnent des conseils pour exprimer les métadonnées Dublin Core en utilisant des syntaxes de données courantes telles que HTML, XML et RDF/XML.

4. Exemples

Le cadre de Singapour est encore neuf, et aucun exemple stable de profil d'application complet conforme à ces directives n'est publié. Toutefois, lors de la conférence internationale sur le Dublin Core et les applications de métadonnées à Singapour, des travaux en cours cherchant à aligner le profil d'application ePrints sur le cadre de Singapour ont été présentés ; une présentation de diapositives est disponible. Un modèle expérimental dans un wiki spécialisé est également disponible pour le profil d'application ePrints.

Références

DCAM

Powell, Andy, Mikael Nilsson, Ambjörn Naeve, Pete Johnston et Thomas Baker. Modèle abstrait DCMI. Recommandation du DCMI, juin 2007.
<http://dublincore.org/documents/2007/06/04/abstract-model/>

DSP

Mikael Nilsson. Modèle de profil d'ensemble de description DCMI. Version préliminaire, décembre 2007.
<http://dublincore.org/architecturewiki/DescriptionSetProfile>

Errata :
2008-11-03. Ajouté une ligne de statut à l'en-tête.