Path queries over multiple named graphs with propertychain


I am trying to execute path queries over multiple named graphs which depend on reasoning with property chaining. Based on the documentation I also added query.all.graphs=true in file. The property chain is something like: prop1 o prop2 -> prop1, where prop2 is transitive. When I run path queries over prop1, it is not giving me the results from all named graphs as expected, only from one named graph.

Is this currently supported with path queries?

Hi, and welcome to the community! Could you provide a minimal example dataset and query that we could use to reproduce your issue? Also, what version of Stardog are you using?

Thank you for your response. I am using stardog v6.2.1 and the CLI to execute the queries. Here is a minimal example and the path query.

@prefix : <>
@prefix ex: <> .
:Task rdf:type owl:Class .
:assist rdf:type owl:ObjectProperty ,
owl:TransitiveProperty .
:object rdf:type owl:ObjectProperty ;
owl:propertyChainAxiom ( :object
) .

In named graph g1
ex:T16 a :Task ;
:assist ex:T4 .
ex:T4 a :Task ;
:assist ex:T69 .

In named graph g2
ex:T20 a :Task ;
:assist ex:T16 .
ex:T22 a :Task ;
:assist ex:T20 .
ex:T69 a :Task .
ex:T999 a :Task ;
:object ex:T22 .

The path query "PATHS ALL START ?x = <> END ?y VIA <>" should result in T22, T20, T16, T4, T69, however it only shows T22 which is bound to graph g2 only, leaving values from g1.

Hi Stephen,

Just following up here. I ran some tests with Stardog Studio with similar use cases I submitted earlier. The same problem persists over named graphs when reasoning involves transitivity and property chain together.

I am not sure if this is a bug or intentional when it comes to named graphs.

Hi Manir,

It is the first time I see a property chain definition refering to itself (:object is the ObjectProperty that is a property chain and its own defintion includes itself). Usually, there are at least two object properties that are combined in a third one.

For example, you can have Employee ==> holds ==> Position ==> in ==> Organization where Employee and Position are some classes and holds and in are some object properties. And you can have a third holdsPositionIn object property defined as a :holds :in property chain. That third object property allow you to do directly Employee ==> holdsPositionIn ==> Organization with reasoning.


Hi Daniel,

I understand that this is not a typical use of property chain. Here, :assist is transitive, and my goal is to take advantage of reasoning over this property.

This scenario is what I need for solving a particular problem and works fine (both transitivity and property chain) in the default graph. Unfortunately, when the triples are in separate named graphs, it works partially i.e. transitivity only.

From my experiments, this seems to be a named graph related problem as I understand, not property chain related.


Hi Manir,

Property paths are supposed to work over named graphs and there might be a bug here that we will look into. However, there is a fundamental problem with combining transitivity/property chain reasoning with path queries as in your example. Enabling reasoning in your example is supposed to make T999 related to all the other nodes via the object property. So if you ask for shortest paths all the nodes will be returned as one hop away. If you ask for all paths as in your query you'll get everything repeated and Stardog will end up computing the paths multiple times.

Another possibility to consider here is the explanation functionality but that is a two-step process: first you run a reasoning query to get the inferences and then get the explanation for the result you are interested in. Behind the scenes explaining transitivity and recursive property chains use path queries as well but there are some cases these explanations can be incomplete at the moment. We have an open ticket for this issue and we will fix this in a future release.



I ran three test cases to identify the problem related to '*combining transitivity/property chain reasoning with path queries'. *

These test cases are targeted towards named graphs only. For default graphs, I did not notice any problem.

There is a README containing instructions and necessary files which can be readily loaded and queried. For each case, I have also included an image describing the scenario.


Manir (161 KB)

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.