Stored query with reasoning does not run with reasoning when reused

dagmaray · April 24, 2021, 11:50am

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

pavel · April 24, 2021, 12:01pm

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

dagmaray · April 24, 2021, 1:15pm

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

pavel · April 24, 2021, 1:23pm

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

dagmaray · April 24, 2021, 2:45pm

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

pavel · April 24, 2021, 2:51pm

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

dagmaray · April 24, 2021, 4:10pm

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

pavel · April 24, 2021, 4:24pm

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

dagmaray · April 24, 2021, 4:56pm

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)
         }

pavel · April 24, 2021, 5:12pm

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

dagmaray · April 24, 2021, 5:19pm

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)
               }

pavel · April 24, 2021, 5:29pm

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

dagmaray · April 24, 2021, 6:55pm

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

pavel · April 24, 2021, 8:22pm

No worries 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

system · May 8, 2021, 8:22pm

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

Topic		Replies	Views
SPARQL query on inferred data does not return any data Support	6	820	July 1, 2018
Federated query with local reasoning only Support	4	312	April 23, 2021
Behaviour with federation and reasoning Support	8	903	April 5, 2018
Problem running (apparently) simple query Support	5	335	November 9, 2018
Reasoning returns no result Support	8	468	July 30, 2018

Stored query with reasoning does not run with reasoning when reused

Related Topics