I'm running a Stardog 5.2.2 PATHS query over a very simple set of triples that represent the order of "Things". See the attached TTL file.
Each eg:Thing is assigned a type:
eg:Thing1 rdf:type eg:Thing
When I execute a PATHS query starting at eg:Thing1:
PREFIX eg: <http://www.example.org/myproject#>
PATHS START ?s = eg:Thing1
END ?o
VIA ?p
it returns the path that includes the rdf:type for that first node. But types for the 2nd node onward are not returned, yet their skos:prefLabel is returned. See attached graph that I create after processing the returned PATHS triples.
I know the rdf:type is in the database because I can SPARQL query for
?s rdf:type eg:Thing
and all 4 entities are returned.
Is there something I am not doing correctly? I find it very curious how rdf:type path is returned for the root node in the path but not in the later nodes.
This is happening because of your variable predicate VIA ?p. It’s telling you there’s a path from eg:Thing1 to eg:Thing via rdf:type. The rest of the paths won’t go through that, obviously, since eg:Thing1 doesn’t connect to anything else, but you DO get some paths that go eg:Thing1 -> eg:andThen -> eg:Thing2 -> skos:prefLabel -> “The second thing,” etc.
You’ll likely want to narrow down your VIA a bit, e.g., paths start ?s = eg:Thing1 end ?o via eg:andThen.
If you want to bind rdf:types to your nodes, you can give start/end graph patterns, e.g., paths start ?s = eg:Thing1 end ?o { ?o rdf:type ?oType } via eg:andThen
Sorry, it is still not clear to me. I had thought that the query would return “all triples descendant from eg:Thing1.”
I don’t understand why I get the skos:prefLabel from eg:Thing2, but not the rdf:type.
This path is returned correctly:
eg:Thing1 eg:andThen eg:Thing2
There are three predicates attached to eg:Thing2. They are: eg:andThen, skos:prefLabel and rdf:type . Only two of these three are returned. I would have expected all three. Instead I get eg:andThen and skos:prefLabel, but not the rdf:type.
eg:Thing2
rdf:type eg:Thing ;
skos:prefLabel "The second Thing."^^xsd:string .
By default, it will return just the shortest path(s) from ?s to ?o, so since it already connected eg:Thing1 to eg:Thing, it doesn’t bother to give you longer ones.
You can run PATHS ALL to get what you’re expecting to see