I have used PATH queries to find paths and have several questions:
I noticed that the PATH queries only work for explicitly defined relationships (single direction: subject -> predicate -> object), but it cannot do reasoning on inferred inverse relationships defined in our ontology file. In order for a bidirectional path discovery to work, do relationships need to be defined explicitly in both directions?
Do PATH queries work on virtual graph? If yes, is the work being done by pushing SQL to the DB Engine? I noticed that PATH queries are not standard SPARQL, but GraphQL. I also noticed PATH queries can only be operated from command line, not from Stardog web interface.
Can I use PATH queries on the ontology schema (not instance) without explicitly converting ontology class to triple format? Currently, I found PATH works on instances, not on ontology itself. Do I need to explicitly convert ontology file into triple format in order to use PATH on abstract schema to facilitate SPARQL query generation?
PATH queries should work over the inferred graph. Make sure reasoning is enabled for your query. If you can see reasoning working for, say, a SELECT query but not a PATH query, please create a minimal example and we’ll happily take a look.
Web interface is deprecated in favour of the new Stardog Studio desktop application. It already supports PATH queries. No, currently PATH queries are not executed live over virtual graphs but it’s on the roadmap. You’re correct that it’s an extension to SPARQL.
PATH queries work over the RDF graph. Ontology axioms (assuming we’re talking about OWL) are stored in RDF according to the standardized OWL to RDF mapping, so they’re queryable using the same kind of queries as instance data. You don’t need to convert anything, Stardog handles that transparently. Again, if you feel something isn’t working, just make a precise test case and we’ll provide more specific answers.
My ontology file for class Individual and class Device with predicate usesDevice and usedByIndividual. This format is not recognized by PATH when I tried to use start = :Device and end = :Individual
Let’s try to figure out the first issue and then move to the second. Can you share the exact data file which you’re loading? This stuff’s got to work, here’s what I did:
pavel$ stardog-admin db create -n test
Successfully created database 'test'.
pavel$ stardog query test "insert data { <urn:a> <urn:p> <urn:b> . <urn:a> <urn:p> <urn:c> . <urn:p> <http://www.w3.org/2002/07/owl#inverseOf> <urn:q> . }"
3 triples added in 00:00:00.356
pavel$ stardog query --reasoning test "paths start ?x = <urn:b> end ?y = <urn:c> via ?predicate"
+-------+-----------+-------+
| x | predicate | y |
+-------+-----------+-------+
| urn:b | urn:q | urn:a |
| urn:a | urn:p | urn:c |
+-------+-----------+-------+
Query returned 1 paths in 00:00:01.182
Now all we need to do is to figure out what’s different in your case.
I don’t quite understand the problem 3. What’s the path(s) from :Device to :Individual that you expect to be returned? What’s the full query that you’re using? There’re no directed paths in your schema graph from Device to Individual, you’d need to write a query which traverses edges both ways.
Since I defined a predicate :usedByIndividual in the ontology file with the range and domain as following, I expect to get a path from :Device to :Individual with the path :usedByIndividual.
Right, but both Device and Individual only have incoming edges in this sub-graph so you need to traverse edges both ways. Or do you expect some sort of reasoning to happen for this query as well?
No, they don’t. We’re talking about pure simple RDF here so in your RDF graph :Device has 2 incoming edges only: one rdfs:range from :usesDevice node and one rdfs:domain from :usedByIndividual node. Same for :Individual. You can draw your graph to see that. There’re no directed paths from :Device to :Individual. There’re undirected ones though.
The fact that your RDF graph represents RDFS axioms plays no role here. Paths queries (just as any other queries) without reasoning are evaluated over asserted triples regardless of what those triples represent [1].
Cheers,
Pavel
[1] I’m ignoring here virtual graphs and other enterprise features which we are not discussing at the moment.