« SPARQL Protocol and RDF Query Language/Requêtes de découverte » : différence entre les versions
Contenu supprimé Contenu ajouté
Ligne 160 :
== Fabriquer un agent intelligent ==
Maintenant, vous savez découvrir les ontologies
Vous savez donc fabriquer une application avec SPARQL
La seconde étape est de prendre en compte l'aspect mouvant des données pour permettre à votre application de s'adapter aux données disponibles. <br/>
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 de données automatiquement demandent 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 qui doit maintenir son application.
=== Détection du changement ===
Certaine implémentation de triplestore contient 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 certaine 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 par exemple :
* Est-ce que cette requête test donne un résultat ?
Ainsi en fonction de vos requêtes SPARQL, vous pouvez développer des petites requêtes de tests pour estimer l'état de la base de données.
Si vos tests sont en erreur, il faut en avertir votre utilisateur et passer à l'étape suivante pour rechercher de nouvelles données consommables par l'application.
=== Recherche de nouvelles données ===
▲==== Dans la même base de 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 aussi en SPARQL pour trouver quelles bases de données proposent tel ou tel type de données. Pour le moment, le nombre d'ontologies explosent et donc un annuaire n'est pas pour demain mais des prototypes, comme [http://en.sparql.pro 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 échecs. 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.<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/>
Il faut permettre de changer simplement les source des données (endpoint) 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 roadmap du Web Sémantique. Si on considère que le stockage commence à être satisfaisant, la découverte doit être améliorer et la mise en place d'annuaires devient indispensable. <br/>
▲=== Modification de l'application ===
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/>
C'est la technologie [[w:RIF|RIF (Rule Interchange Format)]] qui permettra de compléter SPARQL pour permettre l'arrivée des premiers agents intelligents. Donc à suivre...
{{Bas de page
| |||