Les langages conçus pour le formalisme RDF

La première catégorie de langage est nommée « famille de SPARQL ». Elle regroupe les langages qui considèrent l’ensemble des informations, que ce soit les ontologies ou les données, comme un ensemble de triplets. Ils permettent ainsi d’interroger des données RDF sans savoir si le moteur de requêtes inter-prétera la sémantique qui peut être associée aux différents éléments de ces triplets comme par exemple le vocabulaire RDF-Schema. Dans cette catégorie se trouvent, en particulier, les langages SPARQL [Pru-d’hommeaux and Seaborne, 2006], RDQL [Seaborne, 2004], SquishQL [Miller et al., 2002] et TriQL [Carroll et al., 2005]. Nous avons choisi d’évaluer le langage SPARQL car il est en cours de standardisa-tion par le W3C, très cité dans la littérature et utilisé dans de nombreux travaux dans le domaine du Web Sémantique.

3.1.1 Présentation du langage SPARQL

SPARQL [Prud’hommeaux and Seaborne, 2006] est un langage de requêtes pour des données repré-sentées en RDF. Il propose quatre types de requêtes :

– les requêtes SELECT permettent d’extraire des informations du graphe RDF interrogé ;

– les requêtes CONSTRUCT permettent de créer de nouveaux triplets à partir du résultat d’une re-quête ;

– les requêtes DESCRIBE permettent d’obtenir la description d’une ressource donnée. Les spécifi-cations de SPARQL ne précisent pas la nature de la description d’une ressource. Elles imposent seulement que cette description soit un sous-ensemble du graphe interrogé ;

– les requêtes ASK retournent un booléen indiquant si la requête à une solution ou n’en a pas.

Requête Select. Une requête SPARQL SELECT se présente sous la forme générale¹¹suivante : PREFIX namespacesList

SELECT variablesList [FROM sourcesRDFList] WHERE graphPattern [ORDER BY expList]

La clause PREFIX permet d’indiquer des alias sur les espaces de noms utilisés dans la requête. La clause FROM permet d’indiquer la ou les sources RDF interrogées. Cette clause est optionnelle. Si elle n’est pas spécifiée, l’environnement dans lequel la requête est exécutée est chargé de fournir la source de triplets. Par exemple, lorsqu’une requête SPARQL est exécutée sur une BDBO, les données RDF interro-gées sont celles contenues dans la BDBO. Dans les exemples fournis dans cette section, nous supposons que la source de données interrogée est implicite. La clause WHERE est constituée d’un ensemble de tri-plets pouvant contenir des variables (préfixées par ?). Un interpréteur de requêtes SPARQL recherche les valeurs de ces variables pour lesquelles les triplets de la clause WHERE sont inclus dans le graphe RDF interrogé. Il retourne le sous-ensemble de ces valeurs correspondant aux variables spécifiées dans la clause SELECT. Ce résultat peut être trié en spécifiant des expressions dans la clause ORDER BY.

Exemple. Retourner la valeur des propriétés name et email pour les ressources décrites par ces proprié-tés. Les résultats doivent être triés par ordre croissant sur les noms.

PREFIX sioc: <http://rdfs.org/sioc/ns#> SELECT ?name ?email

WHERE { ?x sioc:name ?name . ?x sioc:email ?email } ORDER BY ASC(?name)

Explication. Dans cette requête, la variable ?x est introduite dans deux triplets (éventuellement sépa-rés par un point) de la clause WHERE. Cette variable repsépa-résente les ressources RDF psépa-résentant une valeur pour les propriétés name et email définies sur l’ontologie SIOC dont l’espace de nom est http://rdfs.org/sioc/ns. Les clauses SELECT et ORDER BY indiquent que cette requête retourne les noms (?name) et adresses email obtenues (?email) par ordre alphabétique croissant (ASC) sur les noms.

SPARQL permet d’indiquer des conditions sur les variables utilisées dans la requête. Ces conditions sont définies dans la clause WHERE grâce à l’opérateur FILTER. Cet opérateur prend en paramètre une ex-pression booléenne. Par exemple, l’ajout de FILTER (?name = "Dupont") dans la requête précédente permet de ne retourner que les noms et adresses emails des ressources dont le nom est Dupont.

SPARQL permet également d’indiquer que des triplets sont optionnels dans la clause WHERE grâce à l’opérateur OPTIONAL. En conséquence, des résultats ne satisfaisant pas les triplets optionnels seront quand même retournés. Et, lorsqu’une variable utilisée uniquement dans des triplets optionnels n’a pas d’affectation correspondant au graphe interrogé, la valeur UNBOUND est retournée. Par exemple, si nous modifions la requête de l’exemple précédent pour que le triplet ?x foaf:email ?email soit optionnel (OPTIONAL { ?x sioc:email ?email }), les ressources présentant une valeur pour la propriété name mais pas pour la propriété email seront quand même retournées avec la valeur UNBOUND pour la va-riable ?email.

SPARQL dispose également de l’opérateur UNION pour joindre deux ensembles de triplets dans la clause WHERE. Pour une requête où deux ensembles de triplets sont liés par cet opérateur, un résultat est retourné dès lors qu’il permet de satisfaire l’un des deux ensembles de triplets. Pour prendre un exemple, supposons qu’il existe une deuxième version de l’ontologie SIOC définissant un espace de noms référencé par l’alias sioc2 et considérons la requête suivante :

PREFIX sioc: <http://rdfs.org/sioc/ns#> PREFIX sioc2: <http://rdfs.org/sioc2/ns#> SELECT ?name ?email

WHERE { { ?x sioc:name ?name . ?x sioc:email ?email } UNION

{ ?x sioc2:name ?name . ?x sioc2:email ?email } } ORDER BY ASC(?name)

Cette requête complète celle de l’exemple précédent pour retourner les ressources ayant un nom et une adresse email quelle que soit la version de l’ontologie SIOC utilisée.

Requête Construct. Une requête CONSTRUCT propose les clauses FROM, WHERE et ORDER BY pré-sentées précédemment. Par contre, dans de telles requêtes, la clause SELECT est remplacée par la clause CONSTRUCT. Cette clause est construite comme une clause WHERE, c’est-à-dire par un ensemble de tri-plets pouvant contenir des variables. Le résultat d’une telle requête est un nouveau graphe RDF construit en substituant les variables contenues dans la clause CONSTRUCT par les valeurs qui satisfont la clause WHERE. L’exemple suivant montre comment une requête CONSTRUCT permet de construire un nouveau graphe RDF utilisant les propriétés définies dans l’ontologie référencée par l’alias sioc2 à partir du graphe RDF utilisant l’ontologie référencée par l’alias sioc. Pour simplifier cet exemple ainsi que les suivants, les espaces de noms ne sont pas précisés.

Exemple. Créer chaque ressource de l’ontologie sioc décrite par les propriétés name et email dans l’ontologie sioc2. Dans cette ontologie, ces ressources devront être caractérisées par les propriétés nameet email de l’ontologie sioc2.

CONSTRUCT { ?x sioc2:name ?name ?x sioc2:email ?email } WHERE { ?x sioc:name ?name .

?x sioc:email ?email }

Explication. Pour chaque ressource décrite par un nom et une adresse email grâce aux propriétés définies dans l’ontologie sioc, deux triplets sont retournées dans le graphe résultat qui utilisent cette fois-ci les propriétés name et email définies dans l’ontologie sioc2.

Nous ne détaillons pas les requêtes ASK et DESCRIBE disponibles en SPARQL qui ne permettent pas de répondre à plus d’exigences que les requêtes que nous venons de présenter.

3.1.2 Analyse du langage SPARQL par rapport aux exigences définies

Exigence 1 (Expression de requêtes niveau ontologique)

Le langage SPARQL permet d’exprimer des requêtes sur les données à partir des ontologies. Cette capacité est illustrée dans l’exemple suivant.

Exemple. Rechercher les Item qui ont eu une réponse. SELECT ?i

WHERE { ?i rdf:type sioc:Item . ?i sioc:has_reply ?r }

Explication. Le premier triplet caractérise les instances de la classe Item (?i). Le second permet de rechercher, parmi ces instances, celles qui présentent une valeur pour la propriété has_reply.

Cependant, le résultat de la requête précédente est directement dépendant des triplets représentés dans la BDBO. Si pour une classe C, la BDBO représente un triplet (i, rdf:type, C) pour chaque instance directe ou indirecte de C, alors la requête précédente retourne également les instances de la classe Post, sous-classe de la classe Item. Si, par contre, elle ne représente un triplet (i, rdf:type, C) que pour les instances directes de C, (les autres liens pouvant se déduire de la relation de subsomption), cette requête ne retournera que des instances de la classe Item à moins que l’interpréteur de requêtes ne réalise la clôture transitive de la relation de subsomption. Ainsi, cette requête retournera soit les instances directes de la classe Item soit également ses instances indirectes selon les triplets représentés dans la BDBO et l’interprétation qui en est faite.

Le langage SPARQL ne répond donc que partiellement à notre exigence de pouvoir exprimer des requêtes ontologiques indépendamment de la représentation au niveau logique des données. Il permet d’exprimer de telles requêtes mais le résultat de ces requêtes est dépendant des triplets RDF représentés dans la BDBO ou de leur interprétation.

Exigence 2 (Définition de concepts non canoniques)

SPARQL ne propose pas de langage de définition de données. Il ne permet donc pas de définir des concepts non canoniques. Cependant, si ces concepts sont construits manuellement ou via une API dans

la BDBO, SPARQL permet d’en calculer automatiquement l’extension à partir des concepts canoniques comme le montre l’exemple suivant.

Exemple. Calculer l’extension de la classe ForumWithoutHost définie comme étant l’ensemble des forums qui n’ont pas d’hôte.

CONSTRUCT { ?f rdf:type sioc:ForumWithoutHost } WHERE { ?f rdf:type sioc:Forum .

OPTIONAL {?f sioc:has_host ?h} FILTER ( !bound(?h) ) }

Explication. La clause WHERE de cette instruction permet de rechercher les instances de la classe Forum qui n’ont pas de valeur pour la propriété has_host en utilisant la fonction bound dans une clause FILTER. Cette fonction retourne vrai si et seulement si la variable prise en paramètre n’a pas la valeur UNBOUND. La clause CONSTRUCT permet d’associer les instances trouvées à la classe Forum-WithoutSiteen ajoutant un triplet de typage.

SPARQL satisfait donc partiellement l’exigence 2. Il ne permet pas de définir des concepts non cano-niques mais permet par contre d’en calculer l’extension via des requêtes CONSTRUCT. Notons cependant que cette extension doit être modifiée explicitement chaque fois que l’extension des concepts canoniques sur lesquels elle se base est modifiée (différence avec les vues dans les bases de données).

Exigence 3 (Exploitation linguistique)

SPARQL propose des opérateurs pour exploiter le fait que les valeurs de type chaîne de caractères en RDF peuvent prendre une valeur pour plusieurs langues naturelles. Il permet d’une part de préciser dans une requête la langue naturelle dans laquelle une chaîne de caractères doit être évaluée (suffixe @lg où lg est un code à deux lettres identifiant une langue naturelle donnée). De plus, il fournit des fonctions pour faciliter l’exploitation du multilinguisme. Par exemple, la fonction lang permet de retrouver la langue dans laquelle une chaîne de caractères est donnée. SPARQL satisfait donc l’exigence 3.

Exigence 4 (Indépendance par rapport à un modèle d’ontologies donné)

SPARQL est défini pour le langage RDF et donc indépendamment d’un modèle d’ontologies donné. SPARQL considère ainsi une ontologie définie dans un modèle d’ontologies particulier comme un en-semble de triplets utilisant les constructeurs d’un modèle d’ontologies décrit également en RDF dans un autre espace de noms. Il permet donc d’interroger toute ontologie exprimée en RDF mais cela sans attribuer une quelconque sémantique aux constructeurs du modèle d’ontologies utilisé.

Exigences 5 et 6 (Compatibilité avec l’architecture traditionnelle des bases de données)

Même si la syntaxe proposée par SPARQL suit la forme d’une requête SQL (SELECT-FROM-WHERE), elle est adaptée à l’interrogation de triplets et diverge donc de SQL (exigence 5). D’autre part, le schéma des données étant considéré comme immuable (sujet, prédicat, objet), le langage SPARQL ne fournit pas d’opérateur pour définir, manipuler et interroger ce schéma (exigence 6).

Exigences 7 et 8 (Définition et manipulation des ontologies et des données)

Comme nous l’avons indiqué précédemment, le langage SPARQL ne propose pas de langage de définition et de manipulation de données. En conséquence, les données RDF doivent être modifiées manuellement dans les fichiers RDF utilisés ou par API si ces données sont stockées dans une BDBO.

Exigences 9 et 10 (Interrogation des ontologies et à la fois des ontologies et des données)

SPARQL permet l’interrogation des ontologies en les considérant comme un ensemble de triplets (exigence 9). SPARQL permet également d’interroger à la fois les ontologies et les données en permettant d’utiliser une variable à la place d’un prédicat (exigence 10). Cette capacité est illustrée dans l’exemple suivant.

Exemple. Rechercher l’ensemble des classes OWL dont le nom commence par For avec les URI des instances de ces classes ainsi que leurs valeurs de propriétés.

SELECT ?c ?i ?p ?val

WHERE { ?c rdf:type owl:Class .

?c rdfs:label ?l . FILTER REGEX (?l, "^For") . ?p rdfs:domain ?c .

?i rdf:type ?c . ?i ?p ?val }

Explication. Les deux premières lignes de la clause WHERE permettent de rechercher les classes OWL dont le nom commence par For. Le triplet suivant permet de retrouver les propriétés attachées à ces classes via le prédicat rdfs:domain. Les deux derniers triplets permettent de retrouver les ins-tances des classes trouvées et de rechercher la valeur de ces insins-tances pour les propriétés déterminées précédemment.

Exigences 11 et 12 (Implantation du langage)

La sémantique du langage SPARQL est définie formellement dans les spécifications de ce langage [Prud’hommeaux and Seaborne, 2006]. Une sémantique compositionnelle lui a également été associée dans [Pérez et al., 2006]. Enfin, les outils conçus autour de ce langage sont nombreux¹². Elles permettent une utilisation aisée de ce langage.

Synthèse et conclusion

L’analyse du langage SPARQL par rapport aux exigences définies est synthétisée dans le tableau 2.1. Nous utilisons le symbole • pour indiquer qu’une solution est proposée pour répondre à une exigence. Lorsque cette solution ne permet de satisfaire que partiellement une exigence, nous utilisons le symbole ◦. Enfin, le symbole - est utilisé si aucune solution n’est proposée pour une exigence donnée. Nous utiliserons des tableaux similaires pour tous les langages analysés.

Le langage SPARQL est donc un langage très puissant pour l’interrogation de triplets RDF. Il pro-pose une syntaxe simple et donc facile à appréhender. La simplicité du modèle de données sous-jacent

Exigences SPARQL

Expression de requête niveau ontologique ◦

Définition de concepts non canoniques ◦

Exploitation linguistique •

Indépendance par rapport à un modèle d’ontologies donné ◦

Compatibilité avec SQL

-Définition, manipulation et interrogation du schéma des données

-Définition et manipulation des ontologies

-Définition et manipulation des données

-Interrogation des ontologies •

Interrogation à la fois des ontologies et des données •

Définition d’une sémantique formelle •

Outils permettant l’exploitation du langage •

T. 2.1 – Analyse du langage SPARQL par rapport aux exigences définies

et l’utilisation d’un typage faible permettent d’interroger des données basées sur un modèle d’ontologies quelconque à condition toutefois que tous les triplets soient explicitement représentés. Notons que lors-qu’une table unique est utilisée pour représenter les données, dans laquelle, de plus, toutes les relations transitives (par exemple l’héritage) doivent être saturées, ce langage devient inopérant pour des pro-blèmes de grande taille. En effet, les requêtes nécessitent alors souvent des auto-jointures de la table de triplets [Dehainsala et al., 2007a]. Ce problème est actuellement l’objet de plusieurs travaux de recherche [Abadi et al., 2007, Wilkinson, 2006, Chong et al., 2005].

Dans le contexte de l’architecture de BDBO que nous avons proposée, le langage SPARQL présente les limitations suivantes :

– le résultat des requêtes est dépendant des triplets représentés dans la BDBO et de l’interprétation qui en est faite par le moteur de requêtes. Cette dépendance va à l’encontre de notre exigence de disposer d’un langage permettant d’interroger les données au niveau ontologique indépendam-ment de la représentation logique des données ou de leur interprétation ;

– le langage SPARQL ne propose pas de langages de définition et de manipulation de données qui, dans le cadre d’une BDBO, sont nécessaires pour ne pas avoir à modifier ni à recharger des données contenues dans des fichiers RDF ;

– le langage SPARQL ne permet pas de manipuler les données d’une BDBO au niveau logique.