Skip to content

Sparql Endpoint : entrer dans une base de triplets

20/11/2012

La rédaction du précédent billet m’a fait découvrir les interfaces prévues par les bases de triplets pour accéder (via requête SPARQL) aux données qui y sont stockées.

J’y ai constaté que dans le formulaire sont généralement proposées, très obligeamment, des requêtes par défaut.

Par exemple, pour la DBpedia anglophone, la requête est :

select distinct ?Concept where {[] a ?Concept} LIMIT 100

Sur le catalogue collectif Libris :

PREFIX owl: <http://www.w3.org/2002/07/owl#&gt;
PREFIX foaf: <http://xmlns.com/foaf/0.1/&gt;
PREFIX dbpedia: <http://dbpedia.org/ontology/&gt;
PREFIX rdfs: <http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;

select ?subject ?predicate ?object {
?subject a foaf:Person .
?subject foaf:name « August Strindberg » .
?subject ?predicate ?object .
}

Sur Isidore (tiens, c’est la même que pour la DBpedia anglophone) :

SELECT DISTINCT ?Concept WHERE {
[] a ?Concept.
}

Sur la DBpedia francophone :

select distinct * where {?s rdfs:label ?l} LIMIT 100

Quand on se contente simplement de valider et exécuter ces requêtes, puis qu’on les modifie progressivement, cela permet d’entrer progressivement dans la base et de comprendre en quoi les linked data sont « auto-documentées » (par comparaison avec les API, par exemple).

Je vais m’arrêter sur 2 de ces requêtes, en guise d’illustration

Requête proposée par Isidore et la DBpedia anglophone

Je la remets ici, et vais la commenter en détail :

SELECT DISTINCT ?Concept WHERE {
[] a ?Concept.
}

La requête (WHERE) est : [] a ?Concept.

On y retrouve la structure du triplet, avec l’utilisation d’abbréviations propres à SPARQL :

Le type se dit : rdf:type, mais peut être abrégé a.

A présent reprenons la requête ci-dessus :

SELECT DISTINCT ?Concept WHERE {
[] a ?Concept.
}

La requête vise à identifier dans la base tous les triplets qui définissent le type des ressources.

Typiquement, dans la DBpedia, on pourrait dire (très grossièrement) que cette requête va identifier pour chaque page Wikipedia à quel type de ressource la page est rattachée : un pays, une personne, une maladie, etc.

On aura sans doute au moins autant de types qu’il y a de pages Wikipedia (et une même page est souvent rattachée à plusieurs types). Sauf que la fonction DISTINCT permet de dédoublonner ces types de ressources : chaque valeur différente n’est renvoyée qu’une seule fois.

Donc cette requête renvoie la liste des types de ressources contenues dans la base de triplets.

C’est donc une bonne idée de la proposer comme requête par défaut : pour quelqu’un qui ignore complètement ce que la base contient, ces résultats en donnent une première idée, et permettent, en les analysant, d’affiner progressivement le tir.

Mais il est certain que chacun de ces types sera exprimé sous forme d’une URI, dont il faudra décrypter la signification. Donc dans un sens, cette requête ne va fournir que des résultats frustrants, ou du moins pas « lisibles » immédiatement.

La requête de la DBpedia francophone

select distinct * where {?s rdfs:label ?l} LIMIT 100

Ce 19 novembre est signé le partenariat entre le Ministère de la Culture, Wikimedia France et l’Inria : SémanticPédia est lancé, avec différents projets en ligne de mire. Intéressons-nous donc à la DBpedia francophone.

Son SPARQL Endpoint est : http://fr.dbpedia.org/sparql

La requête par défaut est différente :

{?s rdfs:label ?l} identifie dans la base toutes les relations qui expriment des libellés. Par exemple : le titre de chacune des pages.

La liste des résultats (select distinct *) affiche tout ce qui est exprimé sous forme de variable (précédé d’un ?) dans la requête : ce sera donc un tableau à 2 colonnes (colonne 1 : le sujet, colonne 2 : le libellé).

Pour éviter de récupérer toute la liste des labels stockés dans la DBpedia, seuls les 100 premiers résultats sont récupérés.

Donc cette requête par défaut (cf. ci-dessous un extrait des résultats produits) ramène un résultat plus lisible, mais qui renseigne moins bien sur le contenu de la base.

4 commentaires
  1. 20/11/2012 09:04

    Quelques remarques :
    – Les requêtes par défaut d’Isidore et de Dbpedia sont les mêmes car ils utilisent le même triple store (Virtuoso d’OpenLink Software). Or, cette requête est celle qui est positionnée par défaut dans la configuration. Il est vrai comme tu l’as bien expliqué qu’elle est bien pratique pour découvrir pas à pas la structure du graphe.

    – la notation « [ ] » ne désigne pas un nœud blanc, mais n’importe quelle type de ressource en position de sujet. Comme tu l’as deviné, cette notation permet plutôt de préciser que la valeur de cette variable importe peu. Attention cette notation n’est pas standard et ne fonctionne qu’avec Virtuoso. Quant au nœud blanc, il s’agit d’une ressource qui ne possède pas d’URI mais qui est contextuel à une déclaration de triplets.

    – Ce n’est pas rdfs:type mais rdf:type : http://www.w3.org/TR/rdf-schema/#ch_type même s’il est vrai que cette propriété primitive a été déclarée dans la recommandation sur RDFS

    – « la liste des types de ressources » ou autrement dit les classes instanciées dans le graphe interrogé

    – Last but not least : Une fois qu’on a récupéré les différentes classes, il est intéressant pour une classe de connaître les différentes propriétés (c’est-à-dire prédicat) instanciée pour une classe, par exemple sur Dbpedia pour voir tous les prédicats associés à la classe bibo:Book :

    select distinct ?predicat
    where
    {
    ?s a .
    ?s ?predicat ?objet.
    }

    Encore mieux en remontant l’étiquette de chaque propriété (et ainsi montrer la puissance de l’autodocumentation du RDF dans le graphe :

    PREFIX rdfs:
    select distinct ?predicat ?label
    where
    {
    ?s a .
    ?s ?predicat ?objet.
    OPTIONAL {?predicat rdfs:label ?label.}
    }

    Amuse-toi bien😉

  2. 20/11/2012 09:17

    @Got : merci de ces précisions. Oui, je m’étais douté que la requête était configurée par défaut.
    Pour le « noeud blanc », ça me semblait curieux (disons que ça ne correspondait pas à ce que j’avais lu sur les noeuds blancs, qui apparaissent plutôt dans les résultats que dans les requêtes), mais je suis allé sur RDF Sparql Query où j’ai cherché [] dans la page, et je suis tombé sur :
    Blank nodes are indicated by either the label form, such as « _:abc », or the abbreviated form « [] ».

    J’ai un peu de mal à m’approprier toute la terminologie (« les classes instanciées ») et beaucoup de scrupules à les restituer sur ce blog : je compte sur ton indulgence !

    Ton conseil d’extraire les propriétés d’une classe est très judicieux, merci. Quant à récupérer le label, oui, c’était mon billet suivant (va falloir que je trouve autre chose !)

    rdfs:type : damned ! Il y a un moyen mnémotechnique pour s’en souvenir ?
    (en gros, on ne rencontre que rdf:RDF, rdf:about, rdf:Description, rdf:type et rdf:resource, donc — le reste est en rdfs: ?)

  3. 21/11/2012 08:56

    Evidemment que je suis indulgent, tu es en train d’apprendre toutes ces technos seul, c’est logique que tout ne soit pas clair. J’ai eu la même démarche il y a plusieurs années et cela m’a pris pas mal de temps avant que les choses ne s’éclaircissent vraiment.

    Si l’expression « Une classe instanciée » n’est pas limpide, je te conseille de jeter un coup d’oeil au slide 65 et suivantes de cette présentation : http://fr.slideshare.net/lespetitescases/les-technologies-du-web-appliques-aux-donnes-structures-1re-partie-encoder-et-structurer-les-donnes

    Ma requête extrait les propriétés d’une classe et les étiquettes attachées à ces propriétés, on est d’accord ?

    Non pas de moyen mnémotechnique et petite remarque tu confonds les noms d’éléments et d’attributs liés strictement à la syntaxe RDF/XML (rdf:RDF, @rdf:about, rdf:Description et @rdf:resource) et l’URI d’une propriété abrégée avec un préfixe. Et ce n’est que le début😉

Trackbacks

  1. Sparql Endpoint : entrer dans une base de triplets | Bibliolab, l'atelier des hybrides | Scoop.it

Les commentaires sont fermés.

%d blogueurs aiment cette page :