Stored query with reasoning does not run with reasoning when reused

Support
1

Dear community,

I would like to reuse a stored query in another complex query that needs to run without reasoning. However, I need the stored query to run with reasoning. I stored it via Stardog user interface where I enabled reasoning on the database. It looks like this and is called SNOMEDSubclass:

SELECT ?rt WHERE {

    ?rt rdfs:subClassOf ?iri .

}

However, if I call this service in another query, it always runs without reasoning:

prefix sqs: <tag:stardog:api:sqs:>
SELECT ?subject WHERE {
  
SERVICE <query://SNOMEDSubclass> {
    [] sqs:vars ?rt ;
       sqs:var:iri sct:64572001;
}

?subject rdf:type owl:Class ;
.... (a complicated query continues that must run without reasoning)

}

Is there another way how to enable reasoning on the called stored query that I am missing? Thank you very much for your help.

Kind regards,

Dagmar

2

Hi Dagmar,

Yeah, good question but this is the expected behaviour (at least currently). Whether reasoning is enabled or not is defined by the main query solely.

You can try the following workaround: enable reasoning for the main query but then disable it for everything but the subquery with a hint:

prefix sqs: <tag:stardog:api:sqs:>
SELECT ?subject WHERE {
  
SERVICE <query://SNOMEDSubclass> {
    [] sqs:vars ?rt ;
       sqs:var:iri sct:64572001;
}

{ #pragma reasoning off
  ?subject rdf:type owl:Class ;
  .... (a complicated query continues that must run without reasoning)
}
}

Let us know if that doesn't work.

Cheers,
Pavel

3

Dear Pavel,

thanks a lot for your quick answer. I appreciate it. It works but now I have another problem that I cannot pass the variable ?rt into that complicated query, it appears there as an empty list, even though the service itself returns the correct list - is it because the complicated query is inside extra curly brackets {}? Thanks,

Kind regards,

Dagmar

4

Maybe, but let's see. Could you:

  • show Stardog version
  • show the part of the main query where ?rt is bound?
  • show the part of the stored query where ?rt is used?

Cheers,
Pavel

5

Dear Pavel,

here you are:

stardog version: 7.6.0

main query - ?rt is bound in the filter at the end of the query:

SELECT ?label WHERE {
  { #pragma reasoning off
  ?subject rdf:type owl:Class ;
                                  owl:equivalentClass [ owl:intersectionOf ( ?p
                                                                             [ rdf:type owl:Restriction ;
                                                                               owl:onProperty <http://snomed.info/id/609096000> ;
                                                                               owl:someValuesFrom [ owl:intersectionOf ( [ rdf:type owl:Restriction ;
                                                                                                                           owl:onProperty <http://snomed.info/id/116676008> ;
                                                                                                                           owl:someValuesFrom ?rs
                                                                                                                         ]
                                                                                                                         [ rdf:type owl:Restriction ;
                                                                                                                           owl:onProperty <http://snomed.info/id/363698007> ;
                                                                                                                           owl:someValuesFrom ?rr
                                                                                                                         ]
                                                                                                                       ) ;
                                                                                                    rdf:type owl:Class
                                                                                                  ]
                                                                             ]
                                                                           ) ;
                                                        rdf:type owl:Class
                                                      ] .

filter(?rr = ?rt)
?subject rdfs:label  ?label.
  }
}

stored query:

SELECT ?rt WHERE {

?rt rdfs:subClassOf ?iri .

}

Thanks a lot.

Kind regards,

Dagmar

6

Oh I see. In that case, I think, it should be sufficient to pull the filter outside of the block so that it's applied after the join of the service results and the complicated block results:

prefix sqs: <tag:stardog:api:sqs:>
SELECT ?subject WHERE {
  
SERVICE <query://SNOMEDSubclass> {
    [] sqs:vars ?rt ;
       sqs:var:iri sct:64572001;
}

{ #pragma reasoning off
  ?subject rdf:type owl:Class ;
  .... (a complicated query continues that must run without reasoning)
}

filter(?rr = ?rt)
}

If it still doesn't work, let's look at the query plan.

Cheers,
Pavel

7

Thanks a lot, Pavel, for your patience. It works but now I have found another type of problem.

If I run the same query directly, it is so much faster than if I call the stored query. If I call it directly, it takes just 82 ms to execute. It is especially problematic, if I want to call the stored service twice within another query - it fails due to timeout. I think the reason is that in the log file I am getting: "com.complexible.stardog.reasoning.blackout.TypeOracle:inferTypes(234): The type of variable tag:stardog:api:sqs:vars is ambiguous; it will be assumed to be PROPERTY." But I do not know, how to fix it :(.

Calling stored query with reasoning:

SERVICE <query://SNOMEDSubclass> {
        [] sqs:vars ?rt ;
           sqs:var:iri sct:64033007 ;
         
    }

SnomedSubclass:

SELECT ?rt WHERE {

?rt rdfs:subClassOf ?iri .

}

Calling the query with reasoning directly:

SELECT ?rt WHERE {

?rt rdfs:subClassOf sct:64033007 .

}

Kind regards,

Dagmar

8

This now sounds like a bug. To clarify, you run

SELECT * {
SERVICE <query://SNOMEDSubclass> {
        [] sqs:vars ?rt ;
           sqs:var:iri sct:64033007 ;
    }
}

with reasoning (i.e. without the other complicated part) and it's much slower than

SELECT ?rt WHERE {
  ?rt rdfs:subClassOf sct:64033007 .
}

also with reasoning? Or do you run the full query (with the service and the other part)?

Either way, query plans would help (Show Plan button in Studio or "stardog query explain" CLI command).

Cheers,
Pavel

9

Dear Pavel,

Yes, I run

SELECT * {
SERVICE <query://SNOMEDSubclass> {
        [] sqs:vars ?rt ;
           sqs:var:iri sct:64033007 ;
    }
}

without the complicated part. Aaah, I think I know - I can repeat the behaviour also without calling the stored query. Is it correct that the query results are cached somewhere before the reasoning is turned off? Because the first time, I run the query with reasoning, it takes around 38018 ms. Next time I run it, it is only around 80 ms. Then I turn reasoning off, run it, then I turn reasoning on again, and it takes then 38018 ms. Then I run again, it is around 80 ms. ...

Is this the helpful plan?

Slice(offset=0, limit=1000) [#1.0K]
`ā”€ Distinct [#10K]
   `ā”€ Projection(?rt) [#10K]
      `ā”€ StoredQuery(SNOMEDSubclass) {
         +ā”€ iri -> sct:64033007
         +ā”€ rt -> ?rt
         +ā”€ prefix sct: <http://snomed.info/id/>
         +ā”€ 
         +ā”€ Projection(?rt)
         +ā”€ `ā”€ Scan[SPO](?rt, <http://www.w3.org/2000/01/rdf-schema#subClassOf>, ?iri)
         }
10

I think we've seen this bug before (we'll check on Monday). It's not query results that are cached, it's the ontology class hierarchy that is computed and then should be reused for all subsequent queries (unless data is updated). It sounds like if you turn off/on reasoning, the class hierarchy is recomputed for no good reason.

We will look into this but you're right that it's not specific to stored queries.
Pavel

11

But still, it is interesting, that I could resolve my initial problem with your workaround #pragma reasoning off and without using stored queries, just using these lines within the complicated query:

?rs rdfs:subClassOf sct:3898006 .
?rt rdfs:subClassOf sct:64033007 .

But if I run the same with stored queries:

SERVICE <query://SNOMEDSubclass> {
        [] sqs:vars ?rs ;
           sqs:var:iri sct:3898006 ;
    }

SERVICE <query://SNOMEDSubclass> {
        [] sqs:vars ?rt ;
           sqs:var:iri sct:64033007 ;
    }

it takes approx. double the time, but I get an empty list.

The plan for the stored queries is this one:

prefix sqs: tag:stardog:api:sqs:

Slice(offset=0, limit=1000) [#1.0K]
`ā”€ Distinct [#3.1K]
   `ā”€ Projection(?label) [#3.1K]
      `ā”€ Filter(?rr IN(?rt)) [#3.1K]
         `ā”€ NestedLoopJoin(_) [#6.3K]
            +ā”€ Filter(?ss IN(?rs)) [#2.5K]
            ā”‚  `ā”€ NestedLoopJoin(_) [#5.0K]
            ā”‚     +ā”€ MergeJoin(?subject) [#67]
            ā”‚     ā”‚  +ā”€ Scan[PSOC](?subject, <http://www.w3.org/2000/01/rdf-schema#label>, ?label) [#354K]
            ā”‚     ā”‚  `ā”€ MergeJoin(?subject) [#67]
            ā”‚     ā”‚     +ā”€ Scan[POSC](?subject, <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>, <http://www.w3.org/2002/07/owl#Class>) [#683K]
            ā”‚     ā”‚     `ā”€ Sort(?subject) [#11]
            ā”‚     ā”‚        `ā”€ MergeJoin(?_list_ba28ede0_06a4_48a8_bca8_a9af4fb92e7d) [#11]
            ā”‚     ā”‚           +ā”€ Scan[PSC](?_list_ba28ede0_06a4_48a8_bca8_a9af4fb92e7d, <http://www.w3.org/1999/02/22-rdf-syntax-ns#first>, _) [#742K]
            ā”‚     ā”‚           `ā”€ Sort(?_list_ba28ede0_06a4_48a8_bca8_a9af4fb92e7d) [#10]
            ā”‚     ā”‚              `ā”€ HashJoin(?_listNode_d89bc719_b071_4fab_8182_e64f25c07685) [#10]
            ā”‚     ā”‚                 +ā”€ MergeJoin(?_anon_6) [#182]
            ā”‚     ā”‚                 ā”‚  +ā”€ MergeJoin(?_anon_6) [#16K]
            ā”‚     ā”‚                 ā”‚  ā”‚  +ā”€ Scan[POSC](?_anon_6, <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>, <http://www.w3.org/2002/07/owl#Class>) [#683K]
            ā”‚     ā”‚                 ā”‚  ā”‚  `ā”€ Sort(?_anon_6) [#7.7K]
            ā”‚     ā”‚                 ā”‚  ā”‚     `ā”€ MergeJoin(?_listNode_d89bc719_b071_4fab_8182_e64f25c07685) [#7.7K]
            ā”‚     ā”‚                 ā”‚  ā”‚        +ā”€ Scan[POSC](?_listNode_d89bc719_b071_4fab_8182_e64f25c07685, <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest>, <http://www.w3.org/1999/02/22-rdf-syntax-ns#nil>) [#329K]
            ā”‚     ā”‚                 ā”‚  ā”‚        `ā”€ Sort(?_listNode_d89bc719_b071_4fab_8182_e64f25c07685) [#20K]
            ā”‚     ā”‚                 ā”‚  ā”‚           `ā”€ MergeJoin(?_list_bd43126e_6c05_4d2a_9502_f68125b31859) [#20K]
            ā”‚     ā”‚                 ā”‚  ā”‚              +ā”€ Scan[POSC](?_anon_6, <http://www.w3.org/2002/07/owl#intersectionOf>, ?_list_bd43126e_6c05_4d2a_9502_f68125b31859) [#329K]
            ā”‚     ā”‚                 ā”‚  ā”‚              `ā”€ MergeJoin(?_list_bd43126e_6c05_4d2a_9502_f68125b31859) [#54K]
            ā”‚     ā”‚                 ā”‚  ā”‚                 +ā”€ Scan[PSOC](?_list_bd43126e_6c05_4d2a_9502_f68125b31859, <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest>, ?_listNode_d89bc719_b071_4fab_8182_e64f25c07685) [#873K]
            ā”‚     ā”‚                 ā”‚  ā”‚                 `ā”€ Sort(?_list_bd43126e_6c05_4d2a_9502_f68125b31859) [#54K]
            ā”‚     ā”‚                 ā”‚  ā”‚                    `ā”€ MergeJoin(?_anon_8) [#54K]
            ā”‚     ā”‚                 ā”‚  ā”‚                       +ā”€ Scan[POSC](?_list_bd43126e_6c05_4d2a_9502_f68125b31859, <http://www.w3.org/1999/02/22-rdf-syntax-ns#first>, ?_anon_8) [#873K]
            ā”‚     ā”‚                 ā”‚  ā”‚                       `ā”€ MergeJoin(?_anon_8) [#60K]
            ā”‚     ā”‚                 ā”‚  ā”‚                          +ā”€ Scan[PSOC](?_anon_8, <http://www.w3.org/2002/07/owl#someValuesFrom>, ?ss) [#698K]
            ā”‚     ā”‚                 ā”‚  ā”‚                          `ā”€ MergeJoin(?_anon_8) [#59K]
            ā”‚     ā”‚                 ā”‚  ā”‚                             +ā”€ Scan[POSC](?_anon_8, <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>, <http://www.w3.org/2002/07/owl#Restriction>) [#698K]
            ā”‚     ā”‚                 ā”‚  ā”‚                             `ā”€ Scan[POSC](?_anon_8, <http://www.w3.org/2002/07/owl#onProperty>, <http://snomed.info/id/116676008>) [#59K]
            ā”‚     ā”‚                 ā”‚  `ā”€ Sort(?_anon_6) [#13K]
            ā”‚     ā”‚                 ā”‚     `ā”€ MergeJoin(?_anon_5) [#13K]
            ā”‚     ā”‚                 ā”‚        +ā”€ MergeJoin(?_anon_5) [#213K]
            ā”‚     ā”‚                 ā”‚        ā”‚  +ā”€ Scan[PSOC](?_anon_5, <http://www.w3.org/2002/07/owl#someValuesFrom>, ?_anon_6) [#698K]
            ā”‚     ā”‚                 ā”‚        ā”‚  `ā”€ MergeJoin(?_anon_5) [#213K]
            ā”‚     ā”‚                 ā”‚        ā”‚     +ā”€ Scan[POSC](?_anon_5, <http://www.w3.org/2002/07/owl#onProperty>, <http://snomed.info/id/609096000>) [#213K]
            ā”‚     ā”‚                 ā”‚        ā”‚     `ā”€ Scan[POSC](?_anon_5, <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>, <http://www.w3.org/2002/07/owl#Restriction>) [#698K]
            ā”‚     ā”‚                 ā”‚        `ā”€ Sort(?_anon_5) [#56K]
            ā”‚     ā”‚                 ā”‚           `ā”€ MergeJoin(?_listNode_2cc923dd_2306_460d_b9a9_62050be28942) [#56K]
            ā”‚     ā”‚                 ā”‚              +ā”€ MergeJoin(?_listNode_2cc923dd_2306_460d_b9a9_62050be28942) [#329K]
            ā”‚     ā”‚                 ā”‚              ā”‚  +ā”€ Scan[POSC](?_listNode_2cc923dd_2306_460d_b9a9_62050be28942, <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest>, <http://www.w3.org/1999/02/22-rdf-syntax-ns#nil>) [#329K]
            ā”‚     ā”‚                 ā”‚              ā”‚  `ā”€ Scan[PSOC](?_listNode_2cc923dd_2306_460d_b9a9_62050be28942, <http://www.w3.org/1999/02/22-rdf-syntax-ns#first>, ?_anon_5) [#873K]
            ā”‚     ā”‚                 ā”‚              `ā”€ Sort(?_listNode_2cc923dd_2306_460d_b9a9_62050be28942) [#184K]
            ā”‚     ā”‚                 ā”‚                 `ā”€ MergeJoin(?_list_ba28ede0_06a4_48a8_bca8_a9af4fb92e7d) [#184K]
            ā”‚     ā”‚                 ā”‚                    +ā”€ Scan[PSOC](?_list_ba28ede0_06a4_48a8_bca8_a9af4fb92e7d, <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest>, ?_listNode_2cc923dd_2306_460d_b9a9_62050be28942) [#873K]
            ā”‚     ā”‚                 ā”‚                    `ā”€ Sort(?_list_ba28ede0_06a4_48a8_bca8_a9af4fb92e7d) [#184K]
            ā”‚     ā”‚                 ā”‚                       `ā”€ MergeJoin(?_anon_3) [#184K]
            ā”‚     ā”‚                 ā”‚                          +ā”€ Scan[POSC](?_anon_3, <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>, <http://www.w3.org/2002/07/owl#Class>) [#683K]
            ā”‚     ā”‚                 ā”‚                          `ā”€ MergeJoin(?_anon_3) [#120K]
            ā”‚     ā”‚                 ā”‚                             +ā”€ Scan[PSOC](?_anon_3, <http://www.w3.org/2002/07/owl#intersectionOf>, ?_list_ba28ede0_06a4_48a8_bca8_a9af4fb92e7d) [#329K]
            ā”‚     ā”‚                 ā”‚                             `ā”€ Scan[POSC](?subject, <http://www.w3.org/2002/07/owl#equivalentClass>, ?_anon_3) [#120K]
            ā”‚     ā”‚                 `ā”€ MergeJoin(?_anon_9) [#64K]
            ā”‚     ā”‚                    +ā”€ Scan[POSC](?_listNode_d89bc719_b071_4fab_8182_e64f25c07685, <http://www.w3.org/1999/02/22-rdf-syntax-ns#first>, ?_anon_9) [#873K]
            ā”‚     ā”‚                    `ā”€ MergeJoin(?_anon_9) [#76K]
            ā”‚     ā”‚                       +ā”€ Scan[POSC](?_anon_9, <http://www.w3.org/1999/02/22-rdf-syntax-ns#type>, <http://www.w3.org/2002/07/owl#Restriction>) [#698K]
            ā”‚     ā”‚                       `ā”€ MergeJoin(?_anon_9) [#76K]
            ā”‚     ā”‚                          +ā”€ Scan[POSC](?_anon_9, <http://www.w3.org/2002/07/owl#onProperty>, <http://snomed.info/id/363698007>) [#76K]
            ā”‚     ā”‚                          `ā”€ Scan[PSOC](?_anon_9, <http://www.w3.org/2002/07/owl#someValuesFrom>, ?rr) [#698K]
            ā”‚     `ā”€ StoredQuery(SNOMEDSubclass) {
            ā”‚        +ā”€ iri -> sct:3898006
            ā”‚        +ā”€ rs -> ?rs
            ā”‚        +ā”€ prefix sct: <http://snomed.info/id/>
            ā”‚        +ā”€ 
            ā”‚        +ā”€ Projection(?rt)
            ā”‚        +ā”€ `ā”€ Scan[SPO](?rt, <http://www.w3.org/2000/01/rdf-schema#subClassOf>, ?iri)
            ā”‚        }
            `ā”€ StoredQuery(SNOMEDSubclass) {
               +ā”€ iri -> sct:64033007
               +ā”€ rt -> ?rt
               +ā”€ prefix sct: <http://snomed.info/id/>
               +ā”€ 
               +ā”€ Projection(?rt)
               +ā”€ `ā”€ Scan[SPO](?rt, <http://www.w3.org/2000/01/rdf-schema#subClassOf>, ?iri)
               }
12

I think

SERVICE <query://SNOMEDSubclass> {
        [] sqs:vars ?rs ;
           sqs:var:iri sct:3898006 ;
    }

is wrong because the variable to be projected from the stored subquery is ?rt, not ?rs.

SQS allows you to map stored query's variables to main query variables like this:

SERVICE <query://SNOMEDSubclass> {
        [] sqs:var:rt ?rs ;
           sqs:var:iri sct:3898006 ;
    }

It's always easier to first run just the SERVICEs to make sure they return the right bindings, and then put them into the context of a larger query. Otherwise it's hard to tell if the SERVICE returned 0 results or the main query or neither (but the results don't combine).

Best,
Pavel

14

Dear Pavel,

you are the best - you are right, my stupid mistake :).

I cannot express thank you enough with words. I appreciate a lot your awesome support.

Kind regards,

Dagmar

15

No worries :slight_smile: And you're right that if the original reason to use SQS was to enable reasoning selectively for a part of the query, then the #pragma reasoning hint is a more direct and concise way. Admittedly, it's not very easy to find it in the docs.

Best,
Pavel