XML et RDF sont deux modèles différents d'encodage de l'information et, pourtant, ils sont souvent confondus. Le dernier exemple en date est la mise à disposition par la British Library de 14 millions de notices bibliographiques au format, je cite, « RDF/DC ». La confusion est patente de par l'absence d'URI pour identifier les ressources décrites. Or, en tant que lecteur régulier de ce blog, vous savez que l'URI est un des fondements du modèle RDF.
Il est vrai que la distinction n'est pas forcément évidente à appréhender au premier abord et la syntaxe RDF/XML n'arrange pas les choses. J'ai à plusieurs reprises sur ce blog expliqué ce qui différencie les deux modèles : le modèle de l'arbre ou de l'arborescence pour l'un et le modèle de graphes pour l'autre. Mais, ainsi dit, cela n'est peut-être pas clair. Je vous propose donc d'aborder la distinction sous l'angle de la validation des informations pour faire suite à un commentaire sur le Figoblog et la réponse de Manue.
On dit d'un flux XML qu'il est bien-formé s'il respecte la logique d'imbrication des balises (à la « poupée russe »), qu'il possède un élément racine et quelques règles primitives de XML. Ce même flux est valide s'il respecte un schéma (définie selon différentes syntaxes : DTD, XML schema ou Relax NG), c'est-à-dire que les noms des éléments et des attributs et leurs imbrications respectent les règles déterminées par le schéma. Dans ce cas, il s'agit de valider la structure d'un ensemble fini dont les bornes sont déterminées par l'élément racine. Ainsi, XML permet d'encoder des portions d'informations selon une logique contextuelle à un ensemble fini.
Reprenons l'exemple donnée par Manue, soit la phrase : « Socrate est un chat ». Si j'encode cette phrase en XHTML, cela donnera :
<html>
<head>
<title>Description de Socrate</title>
</head>
<body>
<p>Socrate est un chat</p>
</body>
</html>
Cet exemple est valide du point de vue du schéma XHTML, mais je n'ai pas validé l'assertion « Socrate est un chat », simplement le fait que, dans le contexte de mon exemple en XHTML, l'assertion forme un paragraphe. Même si je change l'encodage XML voire que j'utilise un autre schéma, je continuerai de valider la logique structurelle de l'ensemble du flux et non la logique des données, par exemple, en TEI :
<TEI xmlns="http://www.tei-c.org/ns/1.0">
<teiHeader>
<fileDesc>
<titleStmt>
<title>Description de Socrate</title>
</titleStmt>
<publicationStmt>
<p>Manue, 2010.</p>
</publicationStmt>
<sourceDesc>
<p>Exemple tiré du Figoblog</p>
</sourceDesc>
</fileDesc>
</teiHeader>
<text>
<body>
<p>
<s>
<phr type="sujet">Socrate</phr>
<phr type="verbe">est</phr>
<phr type="attributDuSujet">un chat</phr>
<pc type="point">.</pc>
</s>
</p>
</body>
</text>
</TEI>
Dans ce cas, le schéma me permet de valider que je peux avoir un élément XML « s » dans un élément « p » et qu'il peut lui-même contenir des éléments « phr » ou « pc ».
En RDF, la logique structurelle est toujours la même, puisqu'elle est intrinsèque au modèle : <Sujet> <Prédicat> <Objet>. La validation « structurelle » de RDF se situe donc au niveau de l'assertion ou de la donnée à la différence de XML dont la validation est documentaire. En réalité, RDF ne s'intéresse pas à l'encodage d'une structure, mais plutôt à celui de la logique des données. C'est là que rentrent en jeu les ontologies.
Une ontologie, décrite en OWL ou en RDFS, ne permet pas à proprement parler de valider les données encodées en RDF comme c'est le cas avec un schéma XML. En premier lieu, une ontologie définit un cadre logique et sémantique d'un domaine de connaissances. Par exemple, FOAF permet de décrire, en premier lieu, des personnes, Dublin Core les métadonnées d'un document, SKOS un vocabulaire contrôlé, Good relations des produits...
Pour ce faire, une ontologie décrit :
- des classes, c'est-à-dire la nature des choses, un type : une personne, un document, un concept, un produit, une société...
- des propriétés, c'est-à-dire les caractéristiques des classes : le nom d'une personne, les différentes relations qui unissent différentes personnes, les relations entre des concepts, le fait qu'un produit est créé par une société...
- des contraintes, c'est-à-dire la logique associée aux classes et/ou aux propriétés : une personne est différent d'un chien ou d'un chat, une relation "connaît" qui unit deux personnes est symétrique, une personne a forcément une propriété "nom"...
Reprenons notre exemple et voyons dans quelle circonstance cette assertion est vraie et dans quelle circonstance elle est fausse. Pour ce faire, je vais définir une ontologie :
- les classes :
- Personne ;
- Philosophe ;
- Chat ;
- les propriétés :
- nom d'une personne ;
- le propriétaire d'un chat ;
- les contraintes :
- une même ressource ne peut être à la fois une personne et un chat, on dit alors de ces deux classes qu'elles sont disjointes ;
- La classe philosophe est une sous-classe de personne, donc une ressource de type "Philosophe" est aussi de type "personne" de par les mécanismes d'héritage définis par OWL et RDFS ;
- une personne se définit forcément par le fait qu'elle a un nom ;
- un chat se définit forcément par le fait qu'il a un propriétaire ;
A présent, instancions l'ontologie pour deux ressources Socrate 1 et Socrate 2 :
- Socrate 1 est un philosophe ;
- Socrate 1 a pour nom de personne "Socrate" ;
- Socrate 2 a pour propriétaire John Doe ;
Maintenant, évaluons l'assertion « Socrate 1 est un chat » :
- Puisque Socrate 1 est philosophe et qu'un triplet utilise la propriété "Nom de personne", Socrate 1 est un homme ;
- Or, la classe homme est disjointe de la classe chat ;
- Par conséquent, Socrate 1 ne peut pas être un chat, cette assertion n'est pas valide par rapport à l'ontologie, on dit que l'assertion est incohérente ;
Puis, évaluons l'assertion « Socrate 2 est un chat » :
- Puisque Socrate 2 a un propriétaire, Socrate 2 ne peut être qu'un chat suivant mon ontologie ;
- Aucune autre assertion ne vient compléter voire contredire cette déduction, on parle aussi d'inférence ;
- Par conséquent, cette assertion est valide ou cohérente ;
Si vous déclarez correctement votre ontologie de manière formelle avec un langage comme OWL ou RDFS, l'évaluation que nous avons menée ici peut être effectuée automatiquement par la machine avec un logiciel qu'on appelle "raisonneur". A partir d'un ensemble d'assertions, celui-ci peut non seulement déduire de nouvelles assertions par inférence mais aussi valider les assertions elles-même (ce qui revient en fait à effectuer des inférences). Dans ce cas, vous conviendrez que c'est bien la logique même de la donnée que nous avons validée grâce à l'ontologie.
La distinction entre XML et RDF, entre Schéma XML et ontologie RDF est-elle ainsi plus claire ? Si c'est le cas, rendez-vous au prochain numéro pour étudier en détail le langage d'ontologie OWL 2...
Commentaires
Merci, très clair et à mon avis utile.
Une remarque, cependant, la contrainte de l'ontologie sur les chats dotés de propriétaires est éminemment contestable, probablement liée à l'abus de langage qui autorise les "personnes" à se proclamer "propriétaires" de leur chat, de manière passablement contrefactuelle… :-)
Cf. http://www.simonscat.com/films.html
De rien, avec plaisir.
Ah ! oui, j'étais moi-même un peu dubitatif pour la contrainte avec cette propriété ;-)
C'est clair; je note simplement que tu omets le fait que l'expression en XML elle aussi peut apporter un semantique. Par exemple, un <pc> n'est pas le meme espece d'objet qu'un <phr>, meme qu'ils ont les meme propretes structurales. Ca remonte a l'ancienne distinction entre "document type definition" et "document type declaration" -- TEI augmente la structuration XML avec une semantique, voire une ontologie -- moins elaboree que permettrait RDF peut-etre, mais une ontologie quand meme.
Si je peux me permettre, la conceptualisation TEI, même si elle est partagée, n'est pas explicite pour autant (au sens de Gruber), et sauf erreur de ma part, la seule expression en est le texte des Guidelines. Il me semble que les travaux actuels sur la calculabilité de ses constructions portent essentiellement sur des mappings locaux avec des ontologies de domaine, comme CIDOC/CRM. Est-il envisageable (ou même seulement pertinent) que la TEI au sens large puisse un jour alimenter un raisonneur?
Je me décide enfin à te répondre (j'avoue que la timidité m'a envahi...). La portée pédagogique de ce billet m'a effectivement amené à faire quelques raccourcis et tu m'as pris la main dans le sac (ravi que cela vienne de toi ;-) ). Dans la mesure où il désigne le rôle joué par la portion d'informations encodée, un élément XML porte effectivement une sémantique. Mais cette dernière n'est effective et valable que dans le contexte du document encodé. Bref, c'est la logique du document qu'on encode avec la TEI et non la logique des données qui le composent.
Concernant la TEI, je ne souscris qu'à moitié à la première remarque de JM Destabaux. La structure même de la TEI (je parle bien de l'organisation des éléments et des attributs et leur description et non leur instantiation) dépasse de très loin n'importe quel schéma XML de par l'utilisation de ODD. Nous ne sommes effectivement pas dans l'ontologie (expression de l'ensemble du sens dans une logique formelle), mais nous n'en sommes pas loin. D'ailleurs, je ne fais pas une croix sur l'idée d'exprimer la structure de la TEI en RDF, comme je te l'avais déjà dit, je pense que cela pourrait ouvrir des voies dans l'exploitation du cadre que constitue la TEI et dans l'interopérabilité entre certaines données exprimées avec la TEI et des données équivalentes exprimées en RDF.
Si la TEI permet d'encoder la logique du texte, on pourrait finalement exprimer cette logique en RDF (et là je parle de l'instanciation de la TEI) et la TEI serait alors une ontologie du texte (et non une ontologie des données du texte), je partage l'interrogation de JM Destabaux quant à la pertinence de telles expériences. Est-ce-que cela permettrait de mieux appréhender la logique mise en œuvre dans certains types de textes ? Je ne sais pas. En revanche, une chose est sûre pour moi, j'ai toujours été très dubitatif quant aux expériences d'expressions du CIDOC/CRM avec la TEI auxquelles fait allusion JM Destabaux, car, pour le coup, ce n'est pas le but de XML et les outils ne sont pas adaptés. De même (et tu le sais, cher Lou, car nous en avons plusieurs fois débattu), je continue de penser que la TEI ne doit pas servir à la structuration des métadonnées ou de toutes autres données structurées. La TEI est un cadre pour encoder la structure des textes dans toutes leurs dimensions certes (même dans leur logique), mais pas la logique des données du texte.