Commande dans une requête SPARQL transitive

Question

Est-il possible de garantir que les résultats d'une requête transitive dans SPARQL reviennent dans l'ordre dans lequel ils ont été parcourus?

Ainsi, compte tenu de certaines données simples:

<http://example.com/step0> ex:contains <http://example.com/step1> 
<http://example.com/step1> ex:contains <http://example.com/step2> 
<http://example.com/step2> ex:contains <http://example.com/step3> 

(en pratique, la relation pourrait répéter de nombreuses fois)

requête (en utilisant SPARQL 1.1):

SELECT ?parent 
WHERE { 
    ?parent ex:contains* <http://example.com/step3> 
} 

tel que vous reviendrait toujours [step0, step1, step2]. En essayant cela à Jena, je reçois des résultats cohérents mais ordonnés au hasard.

Sinon, ce serait bien si je pouvais revenir le parent et l'enfant à la marche transitif afin que je puisse réordonner à l'extérieur, mais je ne sais pas comment les deux se lient ?parent ex:contains* <http://example.com/step3> et revenir les objets des relations intermédiaires sans écrire une requête imbriquée très lente avec filtrage.

Answer 1

Pour de simples chemins linéaires, vous pouvez utiliser le nombre de sauts comme mesure pour la commande:

PREFIX ex: <http://example.com/> 

SELECT ?start 
WHERE 
    { ?start (ex:contains)+ ?mid . 
    ?mid (ex:contains)* ex:step3 
    } 
GROUP BY ?start 
ORDER BY DESC(COUNT(?mid)) 

Sortie:

------------ 
| start | 
============ 
| ex:step0 | 
| ex:step1 | 
| ex:step2 | 
------------ 

Answer 2

Étant donné vos données par exemple, essayez:

SELECT ?parent ?child ?subchid 
WHERE { 
    ?parent ex:contains <http://example.com/step3> . 
    ?child ex:contains ?parent . 
    OPTIONAL { ?subchild ex:contains ?child . } 
} 

Si toutes les relations ex:contains vont trois niveaux, vous devrez peut-être faire une correspondance de motif OPTIONAL.

Answer 3

Est-il possible de garantir que viennent les résultats d'une requête transitif dans SPARQL dans l'ordre dans lequel ils ont été parcourus?

Non (la norme SPARQL 1.1 ne définit pas l'ordre)

Ici, l'objet fixe et le fait que les données sont un chemin linéaire arrive à dire il y a un ordre de marche naturel. Comme l'exécution d'Apache Jena SPARQL est déterministe (dans ce cas), elle ne sortira dans un certain ordre que parce que la collection interne de résultats retiendra l'ordre. Toutes les versions d'Iéna ne le font pas: elles ont changé au fil du temps.

Pour d'autres chemins non linéaires, rien n'est certain. Les données sont stockées à l'aide de cartes de hachage.