« SPARQL Protocol and RDF Query Language/Requêtes de découverte » : différence entre les versions

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 [[w:méthode agile|méthode agile]].

 

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.<br />

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.

 

[[Fichier:Database-excel.png|thumb|500px|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.<br />

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.

 

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.<br />

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.

 

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.<br />

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.<br />

# 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.

 

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 pas de problèmes de migration, mais juste des réécritures de données.<br />

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.

À 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 un objet à travers sa référence ===

 

WHERE { ?x foaf:name "Alice" }</pre>

 

 

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

Référence de cet exemple : {{lien brisé|consulté le=2014-11-15|url=http://en.sparql.pro/wiki/Concepts_in_the_graph_LinkedBarcode|titre=Concepts in the graph LinkedBarcode}}

 

 

L'exemple ci-dessous montre une requête SELECT pour trouver tous les prédicats utilisés par la base de données.<br />

|}

 

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).<br />

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.

Référence: [http://www.regular-expressions.info/ tutoriel expression régulière ]

 

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.<br />

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.

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.

 

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.

 

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.

 

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 {{lien brisé|url=http://en.sparql.pro|titre=sparql.pro}}, 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.

 

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.<br />

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.<br />

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 ;)

 

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. <br />

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. <br />