SPARQL (SPARQL Protocol and RDF Query Language - page en wikipédia) est un langage de requête et un protocole. Il permet d’interroger, supprimer, modifier des données qui se trouvent au format RDF. Le langage SPARQL est un standard recommandé par le W3C depuis 2008.

Le RDF (Resource Description Framework - page en wikipédia) est un modèle de donnée graph orienté. Il est utilisé pour décrire des ressources web avec leurs métadonnées. Il est apparu en 1996 et recommandé depuis 1999 par le W3C.

Le modèle repose sur l'utilisation de triplet, c'est-à-dire qu'une donnée est composée de trois informations : un sujet, un prédicat et un objet. À l'instar d'une phrase composée d'un sujet, d'un verbe et d'un complément, ici une donnée est répartie entre :

• un sujet, la ressource à décrire

• un prédicat, le type de propriété pour laquelle est applicable la ressource

• un objet, une autre ressource ou donnée ; la valeur de la propriété

exemple:

<http://dbpedia.org/resource/Yuri_Maltsev> dpb:birthDate <“1950-12-31”>

Il est possible de “traduire” ce triplet de la façon suivante : Yuri Maltsev (sujet) est né (prédicat) le 31 décembre 1950 (objet).

“dpb:” est un préfixe qui dans lequel sont regroupés tous les types de ressources de DBpedia. Cela permet de faire en sorte que tout le monde utilise le même vocabulaire pour décrire des choses semblables.

Ce document fournie par le W3C permet de comprendre le fonctionnement du RDF.

Voici le vocabulaire de base à utiliser pour le langage de requête SPARQL:

PREFIX # définit des espaces de noms
 
SELECT # permet de choisir les variables du résultat, parmi les résultats de la clause WHERE
SELECT DISTINCT # enlève les doublons parmi les couples
SELECT * # conserver toutes les variables de la requête
 
WHERE # contient des triplets qui définissent le pattern recherché
 
--------------------------------------------------------
 
FILTER # permet de mettre des conditions
GROUP BY # partitionner la solution en plusieurs groupes, sur lesquels on peut appliquer une fonction d’agrégat.
HAVING # Indique les valeurs lorsque les conditions sont respectés avec des agrégats de valeurs
BIND # sert à définir de nouvelles variables et à leur affecter une valeur.
LIMIT # permet de mettre une limite sur le nombre de résultats affichés
OFFSET # signifie qu’on ”passe” les n premières solutions.
OPTIONAL # on peut mettre des parties optionnelles, même lorsque qu'il ne pas de valeurs dans l'objet
SERVICE # permet d'agréger des points d'accès SPARQL
 
--------------------------------------------------------
 
ASK # retourne un booléen indiquant l’existence d’une solution qui satisfait le motif
CONSTRUCT # pour construire un graphe RDF solution, à partir des valuations des variables
DESCRIBE # retourne un graphe RDF décrivant les ressources trouvées. Le résultat dépend du service qui publie la donnée
INSERT # permet d'ajouter des données à un graph

Ce vocabulaire réalisé à partir du document de Caron Anne-Cécile, «sparql, Langage d’interrogation du web sémantique» dans le cadre du Master image parcours ipi-nt, 2016-2017.

Cette «anti-sèche» permet aussi de retrouver l'ensemble de la syntaxe du langage SPARQL.

Un document qui permet d'avoir toutes les clés en main pour comprendre le langage SPARQL : Du Charme Bob, Learning SPARQL: querying and updating with SPARQL 1.1, Beijing, Chine, Pays multiples, 2011. Il est aussi possible de consulter le site de l'auteur, ainsi que son blog (ici l'ancienne version avec les articles avant février 2019).

PREFIX foaf: <http://xmlns.com/foaf/0.1/> # exemple d'espace de nom (foaf pour Friend of a friend; vocabulaire qui permet de décrire les personnes)
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX dbp: <http://dbpedia.org/property/>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
 
SELECT DISTINCT ?s ?name (YEAR(xsd:dateTime(?Birth_Date)) AS ?YEAR) #ce sont les variables que l'on veut afficher
# la clause "year" permet de convertir une date (Année/Mois/Jour) en une année 
WHERE
       {?s a dbo:Person .
        ?s foaf:name ?name .
        ?s dbp:birthDate ?Birth_Date .
        ?s dbo:abstract ?abstract .
 
        FILTER REGEX(?abstract, "lawyer") # la clause regex permet d'aller chercher dans les résumés ceux qui ont comme motif "lawyer" 
        FILTER (xsd:date (?Birth_Date) > "1770-01-01"^^xsd:date) # permet de ne garder que ceux qui sont nés après 1770.
        }
ORDER BY (?YEAR) #Cela ordonne les données par année de façon croissante
LIMIT 50 # c'est important quand on ne sait pas le nombre de résultat à afficher et qu'il peut être important

Ici, le but est d'afficher les juristes qui sont nés après 1770 avec leur nom. Il est possible de l’exécuter sur un point d'accès SPARQL.

Les points d'accès permettent d'accéder à des jeux de données.

Dans ce projet, nous exécutons nos requêtes directement avec le langage python. Pour cela, nous utilisons la bibliothèque SPARQLWrapper (il faut l'installer préalablement avec conda ou pip en ligne de commande sur un terminal).

Bien qu'il est la plupart du temps impossible d'associer différents jeux de données (provenant de sites différents) sur un même point SPARQL (pour des raisons de sécurité), il est possible de les fédérer via un système tiers (documentation W3C) sur le sujet. Nous avons fait le choix d'utiliser la version gratuite de GraphDB (documentation et lien de téléchargement), qui a une interface graphique permettant d'avoir un serveur local. GraphDB permet notamment de faire des requêtes SPARQL fédérées. Pour les réaliser, il faut indiquer dans la requête les points d'accès que l'on veut utiliser en se servant de la clause SERVICE (voir le lien sur les requêtes fédérées pour l'utiliser correctement).

GraphDB est aussi très utile pour mettre les individus sur un serveur local, afin de fusionner les données présentes sur plusieurs bases de données ainsi que de ne plus à aller chercher sur les différentes bases de données. Nous montrons comment nous faisons pour le réaliser à cette page. Il est possible par la suite d'aligner les données avec un vocabulaire propre au serveur local.

Il est aussi possible de faire les requêtes directement dans un carnet python. Pour cela, il faut utiliser l'API de GraphDB (documentation), plus précisément dans le serveur local, cela se situe dans REST API -lui-même dans help- puis il faut choisir SPARQL puis expend operations- soit en choissant GET pour interroger les données ou bien POST pour les modifier. Il suffit ensuite de reporter le chemin -localhost:7200/webapi/repositories/{repositoryID} par exemple- dans le wrapper sur python).

Pour conserver les différentes requêtes que nous avons réalisé et pouvoir les effectuer à nouveau, nous avons eu recours à une base de données SQLite. Elle a l'avantage d'être légère et permet facilement de sauvegarder les requêtes. Ce carnet montre comment la créer. Elle est bien sûr modifiable selon les besoins. Pour la lire, il est préférable d'avoir recours à un logiciel de requêtage de base de données comme DBeaver (lien vers le téléchargement, Mac Os, Windows et Linux).

Un point d'accès SPARQL Virtuoso a été crée et il est hébergé par l'ABES (Agence Bibliographique de l'Enseignement Supérieur). Il est possible d'effectuer des requêtes pour interroger les données. Les requêtes se font de la même façon que dans d'autres point SPARQL, néanmoins, il est obligatoire de préciser dans quel graphe la requête est faite, sinon cela ne fonctionne pas. Pour cela il suffit d'ajouter la clause GRAPH et de mettre entre chevrons le graphe: <http://dataforhumanities.org/graph/economists_jurists>.

Légende: Exemple de requête faite dans Virtuoso avec la clause GRAPH

De la même façon que pour GraphDB, il est possible de faire les requêtes directement sur python. Néamnoins, il faut savoir qu'il y a une limite (comme tous les graphes publics) de 100 000 lignes.

Afin de vérifier si la syntaxe d'une requête est bien faite, il existe des outils :

• query-validator: pour les requêtes avec un SELECT ou un CONSTRUCT
• update-validator : pour les requêtes pour mettre à jour les données (INSERT, DELETE, etc.)

Ils vérifient uniquement si la requête est bien formulée, mais cela ne permet pas de juger de la pertinence de la requête ou de sa réussite.