Languages pour la metadonnée - une vue d'ensemble

© Jean-Marc Vanel 2002
Dernière mise à jour (Last update):

Introduction

En fonction du style de données, de l'application envisagée, et des implémentations on choisira SQL, UML, Java Bean, etc comme source première de metadonnée. En suite à partir de cette source première on pourra à l'aide de differents outils générer un autre format de metadonnée et de donnée. On pourra ainsi intégrer des outils, des implémentations, être ouvert et évolutif.
Ce choix est la clé de voute d'un système. En effet à partir de là le stockage s'en suit automatiquement; on peut également, ce qu'on ne fait pas assez, générer des IHM (application cliente, pages Web). De plus les règles de validation sont souvent (plus on moins) contenues dans la metadonnée. Pour achever un système opérationnel, il ne reste qu'à implémenter des opérations métier, et choisir des implémentation génériques: serveurs, bases de données, IHM.

Encore faut-il choisir à bon escient son format de metadonnée. Cet article veut donner une vue d'ensemble.

On s'attend à trouver de plus en plus de metadonnée réutilisable sur Internet. Un exemple est le réservoir de Schémas XML de xml.org qui contient des dizaines de vocabulaires XML classés par métiers. On peut aussi trouver dans des logiciels libres des schemas de bases de données, ou en extraire des classes métier. Cependant il faut dire que partager des conceptions réutilisables n'est pas (encore) un mode de travail répandu dans le monde du libre.

Les formats de metadonnée

Il faudrait caractériser les différentes façons de spécifier la metadonnée:
On peut introduire une relation d'ordre définie ainsi:
S1 < S2

veut dire que S2 est une spécification strictement plus détaillée que S1. Précisément tout ce qu'on peut exprimer en language S1 peut être traduit en S2 sans perte d'information. Par contre il existe des constructions en S2 qu'on ne peut traduire en S1.

Metadonnée XML

On a d'ores et déjà des inégalités :
  DTD < XML Schema
  SQL Data Definition Language < XML Schema

La première est évidente : c'est un des buts de conception de XML Schema.
La deuxième est moins évidente mais en passant en revue les possiblités de SQL on voit que tout y est dans XML Schema:

La traduction des données peut au choix faire appel à une convention de correspondance ou être "verbatim". Pour faciliter l'extraction en XML d'une ligne de SGBDR, on peut mettre dans un même élément XML toutes les lignes appelées par des clés étrangères. Mais on peut aussi être "verbatim" et traduire chaque table par un élément XML, puis chaque ligne par un élément ou par un attribut XML.
Un exemple d'une convention de correspondance est l'association 1-n entre une commande commerciale et les articles commandés. Alors la table de jointure "articles commandés" n'apparait en tant que telle dans le XML, mais à travers des sous-éléments des éléments <commande>. Cette convention est ici classique et parait naturelle, mais ce n'est sûrement pas la seule possible.

D'autre part l'inégalité est stricte car des contraintes sur la cardinalité ou sous forme d'expressions régulières en XML Schema ne peuvent pas être écrites en SQL standard. Cependant ces contraintes peuvent être garanties par des triggers. Ceci est classique dans les SGBDR, mais non standardisé. Par contre dans les bases de données natives XML, imposer à tout instant la conformité à un XML Schema est encore une fonctionalité d'avant-garde. Il vaut mieux dans ce contexte des bases de données natives XML recourir à des contraintes exprimées en XSLT, ou encore plus simplement en XPath.

Maintenant entre les langages de Schema pour XML, je pense qu'on a (presque) 

  XML Schema < Schematron
Les relations structurelles: présence, type, nombre et choix des sous-éléments sont exprimables avec XPath. Il est clair que Schematron a des fonctionalités plus avancées que XML Schema, puisqu'il est basé sur XPath, qui permet de comparer des éléments entre eux (exemple: spécifier un rapport d'aspect pour un rectangle). Cependant XML Schema a certaines fonctionalités non reproductible en Schematron:
Si on pouvait utiliser avec Schematron les extensions XSLT 1.1 pour les appels à Java, on pourrait lever ces restrictions, mais je n'ai pas trouvé comment faire.

Je n'ai pas encore étudié Relax NG, mais comme XML Schema, et peut-être mieux encore, c'est un language structurel, i.e. on spécifie l'imbrication des éléments entre eux. Schematron apparait comme un langage de spécification de contraintes supplémentaires, à utiliser en supplément de Relax NG, ou XML Schema.

Metadonnée UML Java

Maintenant pour les langages de conception, je pense qu'on a (presque) l'équivalence:
XMI (UML), diagrammes de classe seulement ~ Java Beans

Le "presque" se rapporte aux associations n-n, qui ne peuvent pas s'exprimer comme des propriétés sans une convention de correspondance. On pourra typiquement pour une association n-n entre classes A et B ajouter une propriété multi-valuée dont les valeurs seront des couples A,B .
Evidemment en dehors des diagrammes de classes, UML offre plein d'autres richesses, qui dépassent le domaine de la metadonnée: diagrammes de séquence, d'état, cas d'utilisation, déploiement, ...

La problématique est la même pour SQL: 
SQL Data Definition Language ~ Java Beans

Les trois précités sont donc équivalents, ce qui correspond aussi aux diagrammes entités-relations qui existent depuis longtemps.

Ontologies

Enfin il faut regarder du côté des "ontologies" et autres réseaux sémantiques; on a: 
RDF Schema < DAM+OIL
car DAM+OIL est basé sur RDF Schema. Mais dans ce monde-là le paradigme n'est pas celui d'un document avec des parties, sous-parties, données textuelles, et liens entre parties. Ce paradigme est commun à SQL, Java Beans et XML. Ici tout est basé sur la notion de "resource", qui dans un contexte Web est typiquement l'URL d'une page Web. Mais en fait une resource ça n'est rien d'autre qu'un identifiant unique dans un monde clos dans lequel on fait des raisonnements. Une resource peut donc être vue comme un objet, une ligne dans un SGBD, un concept, etc. Une base RDF contient les fameux triplets (resource, propriété, valeur). Mais ici on est dans un monde de connaissance, pas dans un monde SGDB où une commande DOIT avoir un client, un montant, une date, etc. Dans un réseau sémantique une propriété peut ne pas être remplie. Par example un "prospect" peut ne pas avoir de propriété "fonction dans l'entreprise".
RDF Schema permet de spécifier une hiérarchie de classes et leurs propriétés. Mais au lieu de déclarer en une seule fois (comme en Java etc) qu'une classe possède une liste (fermée) de propriétés, on déclare indépendemment des propriétés avec un domaine d'application et une plage de valeurs.

DAM+OIL est très riche et à vue de nez, il y a à peu près de quoi exprimer XML Schema :
DAM+OIL ~ XML Schema
et plus encore, voir "feature comparison of XML, RDF(S), and DAML+OIL" . Dans DAML New User Roadmap on trouvera des lectures conseillées pour chaque type de lecteur. Dans XML Schema l'accent est mis sur l'aspect structurel du document XML, dans un but de validation. Par contre dans DAM+OIL l'accent est sur une modélisation de la connaissance, qui peut se traduire en structures isomorphes à celles de XML Schema, mais qui permet en plus des inférences logiques.

Quand à Topic Maps, la dernière fois que j'ai essayé de lire la spec., j'ai renoncé par son absonceté! Je suis habitué à la prose W3C, mais là c'est un autre niveau de jargon ! Il y a cependant des didacticiels: Topic Maps (Introduction). Les concepts de base de Topic Maps sont: topic, association, scope. Par rapport à RDF et DAM+OIL, topic correspond à resource, association à propriété. "scope" n'a pas d'équivalent direct et permet de définir un sous-contexte. Apparemment Topic Maps n'a pas la richesse de structuration logique de DAM+OIL, c'est un vocabulaire métier pour la gestion documentaire .

Les ponts entre formats de metadonnée

Castor est un outil de choix pour échanger entre:
On peut l'utiliser pour des projets centrés XML, ou centrés Java. On peut générer des classes à partir de XML Schema, mais pas l'inverse. Donc dans le cas d'un projet centré Java, on ne pourra pas valider le format d'échange XML.

ArgoUML ( http://argouml.tigris.org/ ) est un éditeur UML libre. Il permet d'importer des classes Java et de sortir du format XMI. Ensuite ce format XMI pourra être transformé via XSLT en :

2002-08-30    J'ai vu dans freshmeat.net plein de projets donc plusieurs nouveaux, que je vais tester pour vous ...
En gros on peut faire pas mal de choses avec un XML Schema, mais comment créer / éditer un XML Schema sans passer par l'outil propriétaire XML Spy ? Il faut vraiment explorer butterflycode .

DTD to XML Schema translator
CyberNeko DTD Converter : un petit nouveau apparu cet été, qui fait la même chose : convertir une DTD en XML Schema.

 JaxMe 1.44  a une bonne notoriété ...
 by Jochen Wiedmann - Thursday, August 29th 2002 16:32 EDT

About: JaxMe is a Java/XML binding framework based on SAX2. It consists of a set of code generators that read an XML schema and generate code for parsing conformant XML documents into corresponding Java objects, saving those objects into a database or, vice versa, reading such Java objects from a database and converting them into XML. JaxMe supports namespaces, relational databases, and Tamino. JaxMe comes with an integrated application framework and a generator for EJB entity beans with BMP (bean managed persistence).

oil2xsd
Some XSLT stylesheets converting an OIL ontology to XML Schema.

SchemoX
Generates dynamic XML input forms from underlying XML schemas.

XJay
An XMLSchema to Java object mapper.

xsbrowser
Navigates a DTD or XML schema using a Web browser

References

http://www.w3.org/RDF/
http://www.w3.org/TR/rdf-schema/
Resource Description Framework (RDF)

http://www.xml.com/pub/a/2001/12/12/schemacompare.html
Comparing XML Schema Languages
by Eric van der Vlist
December 12, 2001

Métadonnées: une initiation
Dublin Core, IPTC, EXIF, RDF, XMP, etc.