SPARQL Protocol and RDF Query Language/Requêtes de découverte

Dans ce chapitre, nous allons décrire comment un administrateur et, demain, un agent intelligent peuvent découvrir des données pour les utiliser. Pour finir, nous indiquerons quelques pistes pour imaginer les moyens à mettre en œuvre afin de fabriquer des applications robustes, bien que les données évoluent au gré d'une méthode agile.

**Requêtes de découverte**
Leçon : SPARQL Protocol and RDF Query Language

Chapitre n^o 7
Chap. préc. :	Requêtes d'écriture
Chap. suiv. :	Requêtes d'exportation

En raison de limitations techniques, la typographie souhaitable du titre, « SPARQL : Requêtes de découverte
SPARQL Protocol and RDF Query Language/Requêtes de découverte », n'a pu être restituée correctement ci-dessus.

Introduction : la méthode agile appliquée aux données

Quand on choisit un système d'information, c’est un peu comme une voiture : on se renseigne avant sur le prix des pneus, l’assurance, les options, etc.
Mais il y a une chose qu'on chiffre très mal en amont : c’est le temps, non pas du développement du système, mais celui que prendra une modification du système. Est-ce que la personne qui l'a développé sera encore là ? Est-ce que la documentation est suffisante ? Quel sera le délai pour se réapproprier le système ? La qualité de service ? La plateforme de développement et de tests à mettre en œuvre est-elle aussi documentée ? Etc.

Nous allons essayer de comparer les méthodes actuelles pour modifier une base de données et comprendre pourquoi SPARQL va simplifier la manière de développer des applications.

Avec une base de données SQL

Exemple de table avec des colonnes

Dans une base de données classique de type SQL, on découvre la structure des données sous forme de tables avec des colonnes à travers une application comme PHPMyAdmin ou à travers quelques requêtes de descriptions.
Est-ce suffisant pour comprendre la structure d'une base de données afin de pouvoir la modifier ?
Bien souvent, non. Avant de modifier une base de données, on cherche la documentation. On regarde la date de la documentation, ainsi que la date des derniers scripts SQL de mise à jour et, bien souvent, la documentation est périmée.
On commence alors une enquête policière pour deviner pourquoi cette structure existe. Rapidement, on imprime un plan de la base de données au format A3. Une fois qu'on a le plan sous les yeux, on est obligé d'étudier table par table à quoi correspond chaque colonne.
Quand les noms des colonnes sont fantaisistes (par exemple : custom1, custom2...), on est obligé d'ouvrir le code source des applications insérant des données dans les colonnes concernées.

Le coût de modification d'une base de données peut être réduit avec une documentation adéquate, mais il existe un coût incompressible pour s'assurer du bon fonctionnement du système après modification.

Avec un mapping objet-relationnel

Les systèmes se complexifiant, on commence à arrêter d'essayer de comprendre une base de données avec plus de 50 tables. On fait maintenant le plan des objets métiers qui servent à représenter le système, en faisant ainsi abstraction de la base de données.
Cela permet de réduire la complexité de l'analyse (moins de tables à étudier), mais les systèmes étant plus complexes, cela ne change pas le coût final, incompressible, d'appropriation du système à chaque mise à jour.

Avec SPARQL

Il n’est pas indispensable de définir une structure de données avec SPARQL avant de commencer à enregistrer les données. Ce sont les données et les liens entre eux qui dessinent la structure de votre base de données. Les liens entre les données (les prédicats) sont des données comme les autres qui peuvent changer au gré des insertions de données.
Les nouvelles données avec une structure différente ne remplacent en rien les données précédentes avec leur propre structure. Un objet peut être décrit avec deux structures différentes dans la même base de données.
Le coût de mise à jour de la base de données devient nul, car l'insertion de nouvelles données ne demande pas la remise à plat du système en production.

Des applications peuvent cohabiter pendant des années et utiliser la même base de données.

Par exemple :

Une application A est développée. Elle utilise l'ontologie A.
Ensuite, une application B est développée. Elle utilise l'ontologie B.
Avec la même base de données, l’application B remplace progressivement l’application A et, pour ce faire, un script passe les objets de l'ontologie A à l'ontologie B les uns après les autres sans interruption de services des applications A et B.

Et demain ?

Le coût de mise à jour de la base de données devient plus faible avec SPARQL. Quand une application est remplacée par une autre, il faut juste restructurer progressivement la base de données avec un autre programme pour migrer les objets d'une ontologie à un autre. Toutes les données étant toutes visibles au même endroit, il n'y a pas de problèmes de migration, mais juste des réécritures de données.
Cela est parfaitement envisageable quand l'environnement du système est sous contrôle, mais dès lors que l’on utilise des données extérieures, une application est soumise à l’aléa des changements des ontologies de données.

Il faut, demain, que les programmes puissent être développés de manière robuste pour s'adapter à la structure des données. Par exemple, si les données sources changent, il faut qu'une alerte puisse arriver par mail à l'administrateur pour pouvoir modifier les paramètres de description des sources de données. Ici, l'administrateur est l'agent intelligent du système. Demain, des robots pourront, sans intervention humaine, découvrir des données, les utiliser, en découvrir de plus pertinentes, etc.

À travers les requêtes DESCRIBE et les requêtes SELECT, SPARQL pose les bases de nouveaux programmes logiques qui devront savoir s'adapter et raisonner en fonction des données dont ils disposent.

Découvrir des données

Découvrir un objet à travers sa référence

La requête DESCRIBE a pour fonction de décrire une référence. Bien souvent, c’est le premier niveau des données du graphe en partant de la référence qui est utilisée pour donner un résultat.

Par exemple :

DESCRIBE <http://example.org/>

Donnera un résultat qui contiendra les triplets dont la racine sera la référence à décrire :

@prefix a:          <http://www.w3.org/2000/10/annotation-ns#> .
@prefix dc:         <http://purl.org/dc/elements/1.1/> .

<http://example.org/>   a:annotates   <http://www.w3.org/TR/rdf-sparql-query/> ;
                        a:annotates   <http://www.w3.org/TR/rdf-sparql/> ;
                        a:annotates   <http://www.w3.org/TR/xsd> ;
                        dc:date       "2004-12-31T19:00:00-05:00".

On peut également décrire plusieurs références sélectionnées en même temps, qui respectent des conditions, par exemple :

PREFIX foaf:   <http://xmlns.com/foaf/0.1/>
DESCRIBE ?x
WHERE    { ?x foaf:name "Alice" }

Découvrir les types d'objets réellement utilisés

L'exemple ci-dessous montre une requête SELECT pour trouver les types (ou concepts) utilisés par la base de données.

L'avantage ici est de ne pas être obligé de connaître des exemples de références pour retrouver les ontologies utilisées.

Le masque du graphe dans cette requête de découverte est constitué d'un triplet avec deux variables : "?concept" et "?objet". Dans la définition, on affiche les solutions pour la variable "?concept".

Par exemple, dans le graphe RDF/Turtle :

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
<http://example.org/product1> rdf:type <http://www.linkbarcode.org/wiki/LinkBarcode_ontology#Product>.

On applique la requête SPARQL :

select distinct ?concept where { ?objet  a ?concept}

Qui est équivalente à :

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
select distinct ?concept where { ?objet rdf:type ?concept}

Cette requête, sur les données ci-dessus, a une seule solution.

Résultat de la requête:

predicate
<http://www.linkbarcode.org/wiki/LinkBarcode_ontology#Product>

En théorie en utilisant dans un navigateur la référence du type, on peut atteindre une page Web qui décrira ce type. Par exemple en cliquant sur le lien http://www.linkbarcode.org/wiki/LinkBarcode_ontology#Product vous pourrez lire sa description et les propriétés qu’il contient.

Référence de cet exemple : « Concepts in the graph LinkedBarcode » ^{(Archive • Wikiwix • Que faire ?)}. Consulté le 2014-11-15

Découvrir les prédicats réellement utilisés

L'exemple ci-dessous montre une requête SELECT pour trouver tous les prédicats utilisés par la base de données.
Cela est utile, car certaines bases de données disent utiliser de nombreuses ontologies et donc de nombreux types, mais en réalité, seules quelques propriétés sont utilisées.

Le masque du graphe dans cette requête de découverte est constitué d'un triplet avec trois variables : ?predicate, ?object et ?Value. Cependant dans la définition du résultat, on n'affichera que les solutions pour la variable ?predicate.

Par exemple, dans le graphe RDF/Turtle :

<http://example.org/book/book1> <http://purl.org/dc/elements/1.1/title> "Tutoriel SPARQL".

On applique la requête SPARQL :

SELECT DISTINCT ?predicate
WHERE
{
   ?object ?predicate ?value.
}

Résultat de la requête avec les données ci-dessus:

predicate
<http://purl.org/dc/elements/1.1/title>

Découvrir un prédicat via une expression régulière

Si vous recherchez à afficher des titres de films dans une base de données, on peut supposer que le prédicat doit contenir le texte "title" (titre en anglais).
Une fois le prédicat trouvé, on peut en théorie retrouver l'ontologie sur le Web pour savoir si ce lien répond à votre besoin.

Dans notre requête, on va utiliser la variable ?predicat, qui sera ensuite utilisée dans la clause FILTER. La clause FILTER va nous permettre de convertir cet IRI en texte avec la fonction str() pour l’utiliser comme argument dans la fonction regex(). On va ainsi pouvoir rechercher un mot dans les références des prédicats. On utilisera le paramètre i comme paramètre de la fonction regex pour ne pas être sensible à la casse de l'IRI.

Par exemple, dans le graphe RDF/Turtle :

@prefix linkbarcode: <http://www.linkbarcode.org/wiki/LinkBarcode_ontology#>.
<http://example.org/product1> linkbarcode:isMadeOf <http://en.linkbarcode.org/wiki/Special:URIResolver/Dehydrated_garlic>.

La requête SPARQL recherche les prédicats qui contiennent le mot made :

SELECT  DISTINCT ?predicat 
WHERE   { ?o ?predicat ?v .
          FILTER (regex(str(?predicat), "^.*made.*$", "i")) }

Elle donnera le résultat :

predicat
<http://www.linkbarcode.org/wiki/LinkBarcode_ontology#isMadeOf>

Référence: tutoriel expression régulière

Fabriquer un agent intelligent

Maintenant, vous savez découvrir les ontologies qui sont utilisées au sein d'une base de données et rebondir sur le site de description de cette ontologie.
Vous savez donc fabriquer une application avec SPARQL en fonction des données disponibles, en supposant que ces données sont stables dans le temps.

La seconde phase consiste à prendre en compte l'aspect mouvant des données, pour permettre à votre application de s'adapter aux données disponibles.
On divise ce processus en trois étapes : détection du changement, recherche de nouvelles données et modification des requêtes de l'application.

Si ces trois étapes sont automatiques, on peut parler d'agent intelligent (AI). Pour le moment, la détection peut être automatique, mais la recherche automatique de données demande encore de nombreux travaux au W3C. Ainsi, dans cette partie, on va essayer de décrire ce que devrait faire un agent intelligent et, par défaut, ce que doit faire un développeur pour maintenir son application.

Détection du changement

Certaines implémentations de triplestore contiennent des déclencheurs (triggers), mais ils ne font pas encore partie de la recommandation du W3C. Ces déclencheurs auront pour fonction d'alerter les AI si une requête cesse de renvoyer des résultats, par exemple.

En attendant ces déclencheurs, on peut insérer dans une application SPARQL des requêtes de tests comme :

Est-ce que cette base de données existe ?
Est-ce que cette requête test donne un résultat ?

Ainsi, en fonction de vos requêtes SPARQL, vous pouvez développer de petites requêtes de tests pour estimer l'état de la base de données.

Si vos tests aboutissent à des erreurs, il faut en avertir votre utilisateur et passer à l'étape suivante pour rechercher de nouvelles données utilisables par l'application.

Recherche de nouvelles données

Un AI, en théorie, aura accès à des annuaires de bases de données. Ainsi, un AI peut, en cas de recherche de données, faire une requête en SPARQL pour trouver quelles bases de données proposent tel ou tel type de données. Actuellement, le nombre d'ontologies explose et la publication d'un annuaire n’est pas pour demain, mais des prototypes, comme « sparql.pro » ^{(Archive • Wikiwix • Que faire ?)}, commencent à illustrer des solutions pour y parvenir.

En attendant ces annuaires Machine2Machine, un développeur peut programmer son application pour recevoir des alertes si ses tests sont en échec. Dès lors, il pourra rechercher des données alternatives pour réécrire les requêtes SPARQL obsolètes de son application.

Modification des requêtes de l’application

Une fois que le développeur ou, dans le futur, un AI aura trouvé de nouvelles données et donc réécrit de nouvelles requêtes, il lui faudra les déployer.
Pour faciliter cette étape, il ne faut pas coder en dur les sources des données et les requêtes. Seule la définition des nouvelles requêtes sera identique aux anciennes requêtes.
Il faut permettre de changer simplement les sources des données (adresse des endpoints) et les requêtes à travers un service de mise à jour.

Si vous prenez en compte ces trois étapes dès le début du développement, votre application gagnera en durée de vie et le développeur de cette application gagnera en temps de sommeil ;)

Demain ?

Le W3C est à mi-chemin de la feuille de route du Web Sémantique. Si on considère que le stockage commence à être satisfaisant, la découverte doit être améliorée et la mise en place d'annuaires devient indispensable.
C'est seulement après ces améliorations que nous pourrons développer des algorithmes logiques sur les données pour que des agents puissent, entre autres, atteindre automatiquement des données disponibles sans intervention humaine.
C'est la technologie RIF (Rule Interchange Format) qui permettra de compléter SPARQL pour permettre l'arrivée des premiers agents intelligents.
À suivre...

SPARQL Protocol and RDF Query Language

Requêtes d'écriture

Requêtes d'exportation