par exemple, avec le mot clé a tu parle d'uri mais elles interviennent où ?
Bonne question. Les uris, c'est les identifiants de la base de données. Toute ressource, propriété, élément, possède son uri. Par exemple, l'uri de l'entité correspondant au concept d'être humain dans Wikidata est : http://www.wikidata.org/entity/Q5 . On peux l'utiliser telle quelle dans une requête SPARQL, mais il existe un mécanisme de préfixes pour éviter d'avoir à se taper l'url en entier à chaque fois.
Pour simplifier l'écriture, parce que c'est long pour un identifiant toute une uri, il y a un mécanisme qui permet de définir des préfixes :
PREFIXwd:<http://www.wikidata.org/entity/>
dans une vraie requête sur query.wikidata.org on pourra taper de manière équivalente à l'url http://www.wikidata.org/entity/Q5 le code wd:Q5. La page de requête définit par défaut les préfixes habituels.
J'ai du mal avec ces techno, j'ai l'impression qu'elles veulent trop bien faire et répondent trop tard et avec trop de complexité au besoin.
Je peux pas forcément te contredire, peut être que d'autres technos feraient aussi bien l'affaire, je ne sais pas. Mais ce que je sais c'est que Wikidata n'a pas l'air d'avoir moins de succès que freebase, au contraire, qu'on ne manque pas vraiment d'exemples de requêtes pour Wikidata voir la page de requête donc que communautairement la communauté ne semble pas spécialement avoir eu de difficulté à s'approprier SPARQL. Je sais aussi que le service précédent de requête, proposé par un unique individu, un poil plus simple et moins puissant a fini par fermer sans que personne ne semble s'en émouvoir plus que ça. Je sais aussi que l'équipe de développement a pas mal attendu avant de se lancer dans le moteur de requête officiel, ils ont semblé s'orienter vers le choix du moteur spécifique avant de finalement faire le choix de SPARQL. Je pense que le fait que ça existait déjà, que c'était standard (dés le déploiement suffisait d'inclure une lib python pour faire une requête par exemple) a largement joué dans leur choix plutôt que de se lancer dans un chantier finalement assez inutile. Bref, si je peux pas formellement te contredire, j'aurai tendance à penser que tu as une mauvaise impression.
Je n'ai pas l'impression que ça dit une vraie solution à tout cela. La forme des requêtes, leurs éventuelles limitation est souvent là pour avoir des temps de réponse acceptable. Et le crissement des données se fait très bien côté client avec la possibilité de choisir ce qui se passe lorsque l'un des serveurs est inaccessible, de faire du cache, etc
Ben justement, ldf tire dans cette direction. La forme des requête peut être arbitrairement complexe sur ta machine tout en respectant le serveur. Après le système de cache habituel du web doit très bien marcher sur les fragments et tout ça. Et que ldf n'est pas du tout incompatible avec tous ces mécanismes qui sont plus parallèle qu'en opposition. Par exemple les fragments étant plus réguliers qu'une requête arbitraire, tu as largement plus de chance que ton fragment soit en cache quelque part que ta requête à toi. Il suffit que quelqu'un ait besoin du même fragment que toi bien qu'il ne fasse pas la même requête pour profiter du cache, alors que le serveur Wikidata sans fragment ne sait que faire du cache des résultat pour les requêtes identiques.
[^] # Re: Bof
Posté par thoasm . En réponse à la dépêche SPARQL, le SQL du Web, et Linked Data Fragment : le point sur le requêtage du Web. Évalué à 3.
Bonne question. Les uris, c'est les identifiants de la base de données. Toute ressource, propriété, élément, possède son uri. Par exemple, l'uri de l'entité correspondant au concept d'être humain dans Wikidata est : http://www.wikidata.org/entity/Q5 . On peux l'utiliser telle quelle dans une requête SPARQL, mais il existe un mécanisme de préfixes pour éviter d'avoir à se taper l'url en entier à chaque fois.
Pour simplifier l'écriture, parce que c'est long pour un identifiant toute une uri, il y a un mécanisme qui permet de définir des préfixes :
dans une vraie requête sur query.wikidata.org on pourra taper de manière équivalente à l'url
http://www.wikidata.org/entity/Q5le codewd:Q5. La page de requête définit par défaut les préfixes habituels.Je peux pas forcément te contredire, peut être que d'autres technos feraient aussi bien l'affaire, je ne sais pas. Mais ce que je sais c'est que Wikidata n'a pas l'air d'avoir moins de succès que freebase, au contraire, qu'on ne manque pas vraiment d'exemples de requêtes pour Wikidata voir la page de requête donc que communautairement la communauté ne semble pas spécialement avoir eu de difficulté à s'approprier SPARQL. Je sais aussi que le service précédent de requête, proposé par un unique individu, un poil plus simple et moins puissant a fini par fermer sans que personne ne semble s'en émouvoir plus que ça. Je sais aussi que l'équipe de développement a pas mal attendu avant de se lancer dans le moteur de requête officiel, ils ont semblé s'orienter vers le choix du moteur spécifique avant de finalement faire le choix de SPARQL. Je pense que le fait que ça existait déjà, que c'était standard (dés le déploiement suffisait d'inclure une lib python pour faire une requête par exemple) a largement joué dans leur choix plutôt que de se lancer dans un chantier finalement assez inutile. Bref, si je peux pas formellement te contredire, j'aurai tendance à penser que tu as une mauvaise impression.
Ben justement, ldf tire dans cette direction. La forme des requête peut être arbitrairement complexe sur ta machine tout en respectant le serveur. Après le système de cache habituel du web doit très bien marcher sur les fragments et tout ça. Et que ldf n'est pas du tout incompatible avec tous ces mécanismes qui sont plus parallèle qu'en opposition. Par exemple les fragments étant plus réguliers qu'une requête arbitraire, tu as largement plus de chance que ton fragment soit en cache quelque part que ta requête à toi. Il suffit que quelqu'un ait besoin du même fragment que toi bien qu'il ne fasse pas la même requête pour profiter du cache, alors que le serveur Wikidata sans fragment ne sait que faire du cache des résultat pour les requêtes identiques.