Explain the Inferring of Object Properties

I am trying to track down some odd reasoning results in Stardog 5.0.3. When I use reasoning, Stardog produces some new triples based on the ontologies that I have loaded. However, when I use reasoning explain, it only seems to work on type information (rdf:type) and not on object properties. It would be extremely useful for debugging to be able to use reasoning explain to figure how Stardog derived from the ontology the presented results.

To make this a bit more concrete, I am attempting to figure out how Stardog inferred the following triple from my database:

@prefix rel: <http://purl.org/vocab/relationship/> .

<http://example.com/Rawl_B502/nidu_dír_dermait.ttl#SétnaSithbacc> rel:siblingOf <http://example.com/LL/lagin.ttl#AugenUrgnaid>.

However, when I feed that into reasoning explain, I get the following:

Input axiom is not inferred; nothing to explain.

However, the only way in which Stardog could have found this triple is to have used reasoning to create it. This triple is, in fact, incorrect and I am attempting to determine what happened so I can fix the problem but from looking at the data and the ontologies, I cannot see why this triple is inferred by Stardog and having the ability to determine the origin of this triple would be very, very useful.

Are you able to share the data you’re using and any options you’ve set when creating your dB?

Sure, it is on github (https://github.com/cyocum/irish-gen). I would suggest that you checkout the branch rawl_b502_sec14 as that has the latest data that I am working on (and has some syntax fixes that I noticed while ingesting the files). You will also need at least the following ontologies loaded:

foaf:  <http://xmlns.com/foaf/0.1/> .
rel: <http://purl.org/vocab/relationship/>.
irishRel: <http://example.com/earlyIrishRelationship.ttl#> .

The query the caused the issue is:

select ?a where {
     <http://example.com/LL/lagin.ttl#AugenUrgnaid> rel:siblingOf ?a

The individual http://example.com/Rawl_B502/nidu_dír_dermait.ttl#SétnaSithbacc is not the sibling of Augen Urgnaid but is, in fact, his parent and thus should not appear in the results at all. I have noticed that this has happened in a few other queries which reference the file nidu_dír_dermait.ttl but I have not been yet able to determine why this is happening which is why I need to see how Stardog’s reasoner came up with it.

I did not set any options while creating but I did alter the database settings once I had ingested the files. Here is a possibly relevant selection:

ICV Enabled: true
ICV Reasoning Enabled: true
Reasoning type: SL
Reasoning approximate: false
SameAs Reasoning: Full
Punning: false
Search: true

I hope this helps.

Thanks. There’s a lot of stuff in your GitHub repo. What exactly are you loading from there?

I just loaded everything that I found in there. I don’t see <http://example.com/Rawl_B502/nidu_d%C3%ADr_dermait.ttl#SétnaSithbacc> as a result of the following query

select ?a where {
     <http://example.com/LL/lagin.ttl#AugenUrgnaid> rel:siblingOf ?a

The results that I get with reasoning enabled are

|                      a                       |
| http://example.com/LL/lagin.ttl#Nuadu        |
| http://example.com/LL/lagin.ttl#OengusUchae  |
| http://example.com/LL/lagin.ttl#Art          |
| http://example.com/LL/lagin.ttl#MisDelmond   |
| http://example.com/LL/lagin.ttl#AugenUrgnaid |

and without reasoning

|   a   |

I get the same results with 5.0.3 and 5.0.5

Is there any possibility that you accidentally loaded some incorrect data while working with it or failed to remove some data that you thought had been removed? You might want to try creating a new database and loading everything fresh to check. There’s only about 40k triple so it shouldn’t be a problem.

It looks like a bunch of files aren’t getting loaded. It looks like the files with non-ascii unicode characters in them can’t be found and are listed with garbled characters in the logs. Are you seeing the same thing in the stardog.log file?

Loading everything is fine. The main problem is that I cannot load directly from the creation of the db because of a bug with accents in file names (it was fixed in another place but not in the creation). I dropped and reloaded everything and I am still getting the incorrect results. I tried both the command line and the UI and I am getting the same results as before:

|                                        a                                         |
| http://example.com/Rawl_B502/nidu_dír_dermait.ttl#NuaduNecht                     |
| http://example.com/Rawl_B502/mínugud_senchusa_laigin_and_so_sís.ttl#ÓengusAuca   |
| http://example.com/Rawl_B502/mínugud_senchusa_laigin_and_so_sís.ttl#MisTelmannDo |
| mnainn                                                                           |
| http://example.com/Rawl_B502/mínugud_senchusa_laigin_and_so_sís.ttl#AugenAurgnai |
| d-94726800                                                                       |
| http://example.com/Rawl_B502/mínugud_senchusa_laigin_and_so_sís.ttl#NuaduNecht   |
| http://example.com/LL/lagin.ttl#MesDelmond-7e1cdde0                              |
| http://example.com/Rawl_B502/nidu_dír_dermait.ttl#SétnaSithbacc                  |

I am not sure what I am doing incorrectly but the feature request still stands as I would like to be able to figure out where in the reasoning I am getting this so I can track down the actual problem.

I seem to recall a report about loading file names with accent characters. I was able to load the data after db creation with about 75K triples. The results are still the same though but I am getting some warnings about “multiple restrictions for same bnode …owl#hasValue”. Do you know what you have preserve.bnode.ids set to?

Oddly the results I’m getting don’t even look close to what you’re getting…check that. I forgot to enable sameAs.

Ok, I think I’m on to something. I get slightly different results than you do but I think that’s a result of sameAs reasoning. I believe that Stardog will use a fixed but non determinant resource as the canonical resource. If I understand it correctly it will return the same IRI for a resource over repeated queries of the db but it my pick a different one if you reload the data.

I’m guessing you might have to use a different “sameAs” resource to get your reasoning explanation. It’s just a theory right now but I though I’d let you know in case you get a chance to test it before I do.

…No luck there. I tried all three sameAs resources an no luck. The only thing I’m left with is those hasValue warnings. Sorry for the disjoint response but I’m running in and out and just responding with what I can, when I can.

…after removing the triples containing owl:hasValue, which I don’t think should effect the results, I still get the same thing.

Here’s what I did to reproduce your database. Let me know if I’ve missed anything

git clone https://github.com/cyocum/irish-gen.git
git checkout -b rawl_b502_sec14 origin/rawl_b502_sec14
wget http://vocab.org/relationship/rel-vocab-20100607.rdf
wget http://xmlns.com/foaf/spec/20100809.rdf
stardog-admin db create -n irish-gen -o icv.enabled=true icv.reasoning.enabled=true reasoning.sameas=FULL -- foaf.rdf rel-vocab-20100607.rdf
stardog data add irish-gen irish-gen/*.ttl ./irish-gen/LL/*.ttl ./irish-gen/Rawl_B502/*.ttl

You are missing the ontologies that I have created to manage a few more things in the data. You need to load:

  • earlyIrishRelationship.ttl
  • earlyIrishTitles.ttl
  • oldIrishOntology.ttl

Yes, Stardog will randomly choose a URI to use when displaying results with sameAs.

preserve.bnode.ids is set to ON in the UI.

Thanks for trying though, I do appreciate the interest.

You’re welcome. It’s fun to try and track down problems. It’s also fun to see what other people are up to and oddly enough I was just looking into genealogy ontologies. Just to clarify for anyone following along I’m not suggesting that the explain command doesn’t honor sameAs which I would expect it to but just that it was something to look into to try and figure out what might be going on. I had accidentally added a path to the db name but I believe the first wildcard path should pick up those files.