FLASH INFORMATIQUE FI



Formaliser et organiser des données diverses : un enjeu stratégique majeur et immédiat




Francis LAPIQUE


Cet article est une introduction au processus de classification et de description de données au sein d’un système d’information et plus précisément une introduction à la conception et l’utilisation d’ontologies (une ontologie est une spécification explicite d’une conceptualisation).
Pour les enjeux, songez à la NASA qui a égaré les bandes-son et vidéo du premier pas de l’homme sur la Lune. La quantité de données disponibles augmentant de façon exponentielle, pour échanger et partager ces données, il est nécessaire de les décrire afin de savoir au minimum de quoi on parle !

Des données compréhensibles par des machines

Quel(s) moyen(s) faut-il mettre en place pour rendre l’ensemble des données scientifiques (textes, images, sons, vidéos, résultats expérimentaux, résultats de simulation,...) que nous produisons par an, ici à l’EPFL, compréhensible par des machines ? Certes, nous avons des moteurs de recherche, mais vont-ils faire face à des demandes du genre derniers résultats expérimentaux sur l’observation physique de l’effet Casimir ?
Comment rendre le partage de ressources, entre différentes communautés scientifiques, aussi pertinent que possible ? (voir par exemple www.connotea.org) et les deux références suivantes (la première étant d’accès plus facile que la seconde) :

  • A Semantic Web Primer (Cooperative Information Systems), Grigoris Antoniou, Frank van Harmelen
  • Spinning the Semantic Web : Bringing the World Wide Web to Its Full Potential, Dieter Fensel, Wolfgang Wahlster, Henry Lieberman, James Hendler. L’exemple plus loin des oeuvres dans un musée est tiré du site www.openrdf.org. Il a l’avantage de mettre en jeu un vocabulaire et des relations simples. Une extrapolation à votre domaine d’expertise ou jargon peut se faire par analogie.

Avant de passer à cette mise en pratique, précisons le décor avec RDF et RDF-S, OWL (Web Ontology Language) fera l’objet d’un prochain article.

RDF

XML, RDF et OWL constituent les trois couches de base du Web sémantique : XML est le support de sérialisation sur lequel s’appuient RDF et OWL pour définir des structures de données et les relations logiques qui les lient.
RDF (Ressource Description Framework - Cadre de Description des Ressources) est de manière très générale, un modèle d’annotation de ressources (sous forme d’URI ou Uniform Resource Identifiers) sur la base d’un vocabulaire (schéma) partagé.
La syntaxe de base se présente sous la forme d’un triplet : sujet (Ressource) - prédicat (Property )- objet (Literal).
Pour reprendre un exemple célèbre, on va exprimer la sentence : The creator of http://www.w3.org/Home/Lassila is Ora Lassila, sous la forme d’un fichier RDF :

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns# "
 xmlns:s="http://monsite/schema.rdf#">
 <rdf:Description about=&#8221;http://www.w3.org/Home/Lassila&#8221;>
  <s:Creator>Ora Lassila</s:Creator>
 </rdf:Description>
</rdf:RDF>

Le sujet-ressource est http://www.w3.org/Home/Lassila, le prédicat Creator et l’objet Ora Lassila.
Pour introduire cette ressource, ce prédicat et cet objet, on fait appel à deux espaces de noms (déclarations xmlns). Le premier est obligatoire pour toute utilisation de RDF, l’autre est une extension qui précise l’élément .
L’élément compte ici l’attribut rdf:about pour introduire la ressource, mais il peut en contenir d’autres comme rdf:ID pour identifier une déclaration, rdf:type pour identifier un type prédéfini dans un schéma, rdf:bag, rdf:seq, rdf:alt pour gérer des containers de ressources. C’est presque l’essentiel de ce qu’il faut savoir sur RDF.

RDF-S ou RDF Schéma

Avec RDF-S vous définissez un modèle ou schéma de votre domaine d’expertise à savoir :

  • définir des hiérarchies de classes et de propriétés
  • formuler des contraintes.

Comment déclarer une classe de ressource ? Vous pouvez le faire de deux manières différentes :

  • en utilisant l’attribut rdf:type en vous référant au type Class
<rdf:Description rdf:about="#Artist">
<rdf:type>
        <rdf:Description rdf:about="http://www.w3.org/2000/01/rdf-schema#Class"/>
</rdf:type>
</rdf:Description>
<rdfs:Class rdf:ID=»Artist»>
</rdfs:Class>

Vous pouvez ajouter des contraintes. Ainsi dans l’exemple ci-dessous, la propriété last_name ne s’applique qu’à des ressources Artist ( attribut rdfs:domain) et ne peut être qu’une chaîne de caractères ( attribut rdfs:range).

<rdf:Description rdf:about="#last_name">
<rdf:type>
<rdf:Description rdf:about="http://www.w3.org/1999/02/22-rdf-syntaxns#Property"/>
</rdf:type>
<rdfs:domain>
<rdf:Description rdf:about="#Artist"/>
</rdfs:domain>
<rdfs:range>
<rdf:Description rdf:about=&#8221;http://www.w3.org/2000/01/rdfschema#Literal&#8221;/>
</rdfs:range>
</rdf:Description>

On peut sous-classer des types de ressources, ainsi une classe Compositeur et une classe Réalisateur peuvent être des sous-classes d’une classe Créateur, qui elle-même peut être une sous-classe d’une classe Personne. On utilisera pour cela la propriété rdfs:subClassOf. C’est presque l’essentiel de ce qu’il faut savoir sur RDF-S.

Schéma de l’exemple

L’exemple choisi propose la gestion de ressources que l’on peut trouver dans un musée. C’est un exemple qui contient un vocabulaire compréhensible par tous, mais les « vraies » applications sont évidemment beaucoup plus spécifiques : analyses et classement d’images cérébrales, données issus de la biologie, ...

GIF - 2.1 ko
fig. 1

La figure 1 montre le schéma de l’exemple. Insistons sur le fait qu’il s’agit bien d’un schéma, car vous n’avez aucune référence à des instances. Vous pouvez noter la hiérarchie des classes (flèches pleines), des propriétés (flèches pointillées) et des deux espaces de noms (ns1 et ns2).
Ce vocabulaire (Artist, Painter, creates....) contrôlé, organisé et la formalisation des relations entre les différents termes du vocabulaire porte un nom, c’est une ontologie.
Le support d’un bon éditeur graphique RDF/OWL va être d’un grand secours pour construire l’ontologie. Dans le cadre de cet article nous avons choisi un produit commercial Altova SemanticWorks 2006, il est facile d’approche et dispose d’une bonne documentation. D’autres comme Protégé http://protege.stanford.edu/ ou Isaviz du W3C font plus que l’affaire.
Commençons par définir les classes Artist et Artifact et les propriétés first_name, last_name et creates.
Lancer l’outil (Altova SemanticWorks 2006), cliquez l’icône New, choisir le niveau RDFS depuis la rubrique RDF/OWL et sauver. Avant toute chose, définir la base URI de votre espace de noms (rubrique Tools ). Pour ajouter une classe, choisir la rubrique Classes (figure 2) et cliquer l’icône .

GIF - 4 ko
fig. 2

On entre son URI relatif #Artist et un label Artist. La figure 3 montre la représentation de la class Artist

GIF - 4.2 ko
fig. 3

Pour ajouter la propriété creates on suit la même démarche mais en partant de la rubrique Properties. On va restreindre le domaine de valeur de cette propriété à la classe Artifact en utilisant le prédicat rdfs:range et indiquer que creates ne s’applique qu’à une ressource de type Artist au moyen du prédicat rdfs:domain. (figure 4)

GIF - 6.9 ko
fig. 4

On applique la même approche pour les propriétés first_name et last_name en se référant à la classe prédéfini rdfs:Literal (figure 5).

GIF - 6.9 ko
fig. 5

Précisons la hiérarchie des classes. Pour indiquer que la classe Painter est une sous-classe d’Artist on clique sur l’icône de la classe Painter et avec le bouton de droite de la souris on fait apparaître le menu add SubClassOf. En appliquant cette démarche à la classe Flemish elle-même sous classe de Painter on obtient (figure 6) les prémisses du schéma de la figure-1.

GIF - 5.1 ko
fig. 6

La figure 7 présente la propriété sculpts, sous-classe de la propriété creates, avec ses restrictions.

GIF - 9.7 ko
fig. 7

Quand on dispose de l’ensemble des classes et propriétés, dépendances comprises, on fait une sauvegarde pour obtenir le schéma sous la forme d’un fichier RDF (schema1.rdf#). On recommence tout le processus pour la classe ExtResource et les propriétés mime-type, title, file_size et last_modified (schema2.rdf#).

Création des instances

L’étape suivante, c’est l’instanciation proprement dite des ressources : on ouvre un fichier d’instance culture.rdf que nous allons compléter. Le préfixe cult est associé au vocabulaire défini par http://monsite/schema1.rdf (espace ns1 de la figure 1) et adm à http://monsite/schema2.rdf (espace ns2 de la figure 1).
La figure 8 illustre l’instance de l’autoportrait de 1629, huile sur toile de 43221 bytes.

GIF - 5 ko
fig. 9

La figure 9 illustre la ressource Rembrandt dans Wikipedia, peintre flamand qui a peint Bethsabée, huile sur toile exposée au Louvre.

GIF - 4.7 ko
fig. 10

Requêtes sur des fichiers RDF

Pour passer des requêtes, nous avons choisi d’importer notre fichier culture.rdf dans Sesame. Sesame [1] est une architecture pour stocker et interroger des ontologies (figure 10).

GIF - 12.5 ko
fig. 10

Cette architecture se caractérise principalement par le Storage And Inference Layer, ou SAIL API couche, qui assure l’abstraction des données et les moteurs de requêtes SeRQL et RQL. L’installation se fait sans difficulté sur un serveur Tomcat.
Les deux schémas et l’instance du paragraphe précédent ont été chargés dans une base MYSQL.
Le choix de RQL a été fait ici. SeRQL pour Sesame RDF Query Language est une extension du dialecte RQL. RQL comme l’indique G. Karvounarakis et al. se fonde formellement sur un modèle de graphes qui capture les primitives de modélisation de RDF et permet l’interprétation des descriptions des ressources à travers un ou plusieurs schémas superposés.

Comme premier exemple de requête RQL considérez l’expression :

select X, Y
from {X} cult:paints {Y}

La syntaxe a l’apparence d’une requête SQL. L’apparence seulement, car si la directive select précise bien les variables à renvoyer à l’image d’une requête SQL, la directive from précise la localisation dans le graphe RDF : X est le sujet, cult:paints le prédicat et Y l’objet. Nous verrons plus loin l’utilisation de la clause where. La figure 11 donne une image du résultat montrant les deux ressources concernant Rembrandt qui sont connectées à la propriété cult:paints. Notez également les références aux deux schémas de la figure1.

GIF - 7.8 ko
fig. 11

On peut nommer ( ce qui n’est pas forcément souhaitable) explicitement les noms des variables :

select PAINTER, PAINTING
from {PAINTER} cult:paints {PAINTING}

Le résultat de cette requête est identique à la précédente. Considérons cette troisième requête :

select X, $X, Y
from {X : $X } cult:paints {Y} , {X } cult:last_name {Z}
where ( $X < cult:Painter and Z like «*van*» )
from {X : $X } cult:paints {Y} , {X } cult:last_name {Z}:

Comme dans les exemples précédents, on considère en premier lieu la relation sujet objet à travers le prédicat cult:paints avec un petit plus la variable $X qui prend la valeur de la classe de la ressource et en second lieu, la relation à travers le prédicat cult:last_name .
Que dit cette clause where ( $X < cult:Painter and Z like « *v* » ) ?. Quand X et Y sont de type classe/propriété X < Y est vrai si X est une sous-classe/propriété de Y. Cette clause est donc vrai si $X prend la valeur cult:Cubist ou cult:Flemish, et si la propriété cult:last_name contient la chaîne van. Le résultat est figuré en figure 12.

GIF - 4.2 ko
fig. 12

Un quatrième exemple on affiche l’ensemble des sous-classes de cult:Painter et de leurs prédicats @P associées :

select $X, @P
from  { : $X} @P
where $X in subClassOf^( cult:Painter )

On peut retourner l’union de deux opérantes. Le premier select cherche des peintres qui ont un prénom le deuxième ceux qui n’en ont pas.

(select X, LNAME, FNAME
from  {X : $X} cult:first_name {FNAME},
        {X} cult:last_name {LNAME}
where $X <= cult:Painter
)
union
(select X, LNAME, NULL
from  {X : $X} cult:last_name {LNAME}
where $X <= cult:Painter
   and not (X in select X
                   from {X} cult:first_name
            )
)

Le but de ces quelques exemples et de faire sentir concrètement les particularités de ces requêtes dans des arbres RDF. Sur cette base vous pouvez aller à la découverte d’autres requêtes (http://openrdf.org/sesame/serql/serql-examples.html) et du dialecte SeRQL pour compléter votre formation.

Conclusion

Pour conclure, comme le remarque X.Lacot : Le formalisme introduit par RDF, OWL et les autres langages du Web sémantique permet sans doute de mieux structurer les données présentées sur le Web, mais produire des graphes RDF pour représenter des données diverses et variées n’est pas encore rentré dans les habitudes. Outre le manque d’outils réellement matures pour tous les publics, adopter une démarche sémantique dans l’organisation et la présentation de ses données nécessite des changements assez importants dans la gestion des flux informationnels, ce qui est rarement simple à mettre en oeuvre. Ouvrir son système d’informations au Sémantique devrait donc se faire par étapes, en profitant par exemple de l’existence de langages tels les microformats pour amorcer la transition. Les microformats sont des ensembles de conventions permettant d’ajouter des notions sémantiques aux documents HTML, tout en évitant le recours à de nouveaux langages.
Quelles suites ? Dans un premier temps, un second article sur OWL pour faire le tour des technologies de base du web sémantique, dans un deuxième une proposition d’une série de cours destinés à toutes celles et ceux, dans les laboratoires, qui se sentent concernés par la gestion et l’archivage d’importants volumes de données diverses à caractère scientifique, dans un troisième des expériences de terrain pour valider cette approche.

[1] BROEKSTRA J., KAMPMAN A., VAN HARMELEN F. (2002). Sesame : An Architecture for Storing and Querying RDF Data and Schema. Proc. of the 1st International Semantic Web Conference ISWC. Sardinia, Italia, (9-12 June), pp. 54. http://www.openrdf.org/doc/sesame/users/userguide.html



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.