Stardog 5: Query with reasoning returning 0 results when run inside transaction

Support Bug
1

Hi,

The following query returns results when run outside of a transaction (from java), but returns 0 when run inside a transaction.


select distinct ?skjulbarEnhet  where {  
   ?skjulbarEnhet a virksomhet:SkjulbarEnhet.      
}

virksomhet:SkjulbarEnhet is:

Screen Shot 2017-07-06 at 13.48.30.png2582×1484 363 KB

Query plan is:

From all
Distinct [#35]
`─ Projection(?skjulbarEnhet) [#145]
   `─ Union [#145]
      +─ Union [#141]
      │  +─ Union [#133]
      │  │  +─ Scan[POSC](?skjulbarEnhet, rdf:type, <http://data.einnsyn.no/virksomhetmeta/Kommune>) [#1]
      │  │  `─ Scan[POSC](?skjulbarEnhet, rdf:type, <http://data.einnsyn.no/virksomhetmeta/Virksomhet>) [#132]
      │  `─ Union [#8]
      │     +─ Filter(Datatype(?jevdsuss) = xsd:string) [#1]
      │     │  `─ MergeJoin(?skjulbarEnhet) [#1]
      │     │     +─ Scan[POSC](?skjulbarEnhet, rdf:type, <http://data.einnsyn.no/virksomhetmeta/AdministrativEnhet>) [#199]
      │     │     `─ Scan[PSOC](?skjulbarEnhet, <http://data.einnsyn.no/virksomhetmeta/orgnummer>, ?jevdsuss) [#140]
      │     `─ Filter(Datatype(?jaoawjiz) = xsd:string) [#7]
      │        `─ MergeJoin(?skjulbarEnhet) [#15]
      │           +─ Scan[POSC](?skjulbarEnhet, rdf:type, <http://data.einnsyn.no/virksomhetmeta/Bydel>) [#15]
      │           `─ Scan[PSOC](?skjulbarEnhet, <http://data.einnsyn.no/virksomhetmeta/orgnummer>, ?jaoawjiz) [#140]
      `─ Union [#4]
         +─ Union [#2]
         │  +─ Filter(Datatype(?zrmyybfn) = xsd:string) [#1]
         │  │  `─ MergeJoin(?skjulbarEnhet) [#1]
         │  │     +─ Scan[POSC](?skjulbarEnhet, rdf:type, <http://data.einnsyn.no/virksomhetmeta/DummyEnhet>) [#3]
         │  │     `─ Scan[PSOC](?skjulbarEnhet, <http://data.einnsyn.no/virksomhetmeta/orgnummer>, ?zrmyybfn) [#140]
         │  `─ Filter(Datatype(?tdpvnkue) = xsd:string) [#1]
         │     `─ MergeJoin(?skjulbarEnhet) [#2]
         │        +─ Scan[POSC](?skjulbarEnhet, rdf:type, <http://data.einnsyn.no/virksomhetmeta/Enhet>) [#2]
         │        `─ Scan[PSOC](?skjulbarEnhet, <http://data.einnsyn.no/virksomhetmeta/orgnummer>, ?tdpvnkue) [#140]
         `─ Union [#2]
            +─ Filter(Datatype(?hrgckdwc) = xsd:string) [#1]
            │  `─ MergeJoin(?skjulbarEnhet) [#2]
            │     +─ Scan[POSC](?skjulbarEnhet, rdf:type, <http://data.einnsyn.no/virksomhetmeta/Organ>) [#2]
            │     `─ Scan[PSOC](?skjulbarEnhet, <http://data.einnsyn.no/virksomhetmeta/orgnummer>, ?hrgckdwc) [#140]
            `─ Filter(Datatype(?fvlrjlpt) = xsd:string) [#1]
               `─ MergeJoin(?skjulbarEnhet) [#1]
                  +─ Scan[POSC](?skjulbarEnhet, rdf:type, <http://data.einnsyn.no/virksomhetmeta/Utvalg>) [#30]
                  `─ Scan[PSOC](?skjulbarEnhet, <http://data.einnsyn.no/virksomhetmeta/orgnummer>, ?fvlrjlpt) [#140]

Here is some sample data:

@prefix arkiv: <http://www.arkivverket.no/standarder/noark5/arkivstruktur/> .

<http://data.einnsyn.no/virksomhet/1a68a5d6-1bb5-42e8-8de1-4bd2594df6a4> a <http://data.einnsyn.no/virksomhetmeta/Virksomhet> ;
	<http://data.einnsyn.no/virksomhetmeta/epost> "virksomhet@example.org" ;
	<http://data.einnsyn.no/virksomhetmeta/oppdatertDato> "2017-07-06T13:50:37.168+02:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;
	<http://data.einnsyn.no/virksomhetmeta/opprettetDato> "2017-07-06T13:50:37.168+02:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;
	<http://data.einnsyn.no/virksomhetmeta/kontaktperson> <http://data.einnsyn.no/virksomhet/a757428d-d09b-4add-960d-d004f015566c> .

<http://data.einnsyn.no/virksomhet/a757428d-d09b-4add-960d-d004f015566c> a <http://data.einnsyn.no/virksomhetmeta/Kontaktperson> ;
	<http://data.einnsyn.no/virksomhetmeta/epost> "kontaktperson@example.org" ;
	<http://data.einnsyn.no/virksomhetmeta/navn> "kontaktperson1499341833200" .

<http://data.einnsyn.no/virksomhet/1a68a5d6-1bb5-42e8-8de1-4bd2594df6a4> <http://data.einnsyn.no/virksomhetmeta/avsluttetDato> "2017-07-06T13:50:33.200+02:00"^^<http://www.w3.org/2001/XMLSchema#dateTime> ;
	<http://data.einnsyn.no/virksomhetmeta/orgnummer> "999999999" ;
	<http://data.einnsyn.no/virksomhetmeta/telefon> "12345678" ;
	<http://data.einnsyn.no/virksomhetmeta/adresse> "Adresse" ;
	<http://data.einnsyn.no/virksomhetmeta/navn> "virksomhet1499341833200"@no-nb ;
	<http://data.einnsyn.no/virksomhetmeta/skjult> false .

This data is inserted in our transaction, and we use the query before and after the insertion to see if there are any new virksomhet:SkjulbarEnhet, for this data there should be one new virksomhet:SkjulbarEnhet <http://data.einnsyn.no/virksomhet/1a68a5d6-1bb5-42e8-8de1-4bd2594df6a4>

Entire ontology can be found here: ontology.ttl · GitHub

Cheers,
Håvard

2

Thanks for the report! I’m able to reproduce this problem via Java and HTTP, so I’ve opened up a ticket. We’ll be looking further into it.

3

Great that you can reproduce it :slight_smile:

Håvard

4

This thread is quite stale. I'm running into this same issue. Was this confirmed as a defect?

5

Yes, it was confirmed back then. Which version of Stardog are you using?

Thanks,
Pavel

6

Our cluster is running 5.3.2 however I tested a local community version of 6.0.1 where I can also reproduce this issue.

7

Not being able to use reasoning inside a transaction was fixed in version 5.3.0 but there is a limitation that if reasoning is not enabled when the transaction begins then it cannot be enabled afterwards. If you are using the Java code reasoning should be enabled for the connection config when transaction begins so queries with reasoning can be used. If you are using the HTTP API you should enable reasoning as follows:

curl -X POST -sku admin:admin http://localhost:5820/DB/transaction/begin?reasoning=true

Best,
Evren