Understanding logs

For some time already I have been ignoring many warnings that are repeatedly written in the stardog.log file:

WARN  2019-05-02 10:15:04,976 [stardog-user-64] com.clarkparsia.blackout.ProfileFilterBase:apply(39): Not a valid SL axiom: EquivalentClasses(ex:E, or(ex:N, ex:P))

WARN  2019-05-02 10:15:04,977 [stardog-user-64] com.clarkparsia.blackout.ProfileFilterBase:apply(39): Not a valid SL axiom: EquivalentClasses(ex:ManualCloth, and(ex:Cloth, not(ex:Prefabricated)))

WARN  2019-05-02 10:15:05,012 [stardog-user-63] com.clarkparsia.pellet.rdf.DefaultRDFAxiomReader:handleException(1703): Multiple http://www.w3.org/1999/02/22-rdf-syntax-ns#first values for _:genid2 [http://www.ex.com/pr#uses, http://www.ex.com/ex#isOwnedBy]

WARN  2019-05-02 10:15:05,013 [stardog-user-63] com.clarkparsia.pellet.rdf.DefaultRDFAxiomReader:handleException(1703): Multiple http://www.w3.org/1999/02/22-rdf-syntax-ns#first values for _:genid1 [http://www.ex.com/ex#executes, http://www.ex.com/ex#executes]

WARN  2019-05-02 10:15:05,013 [stardog-user-63] com.clarkparsia.pellet.rdf.DefaultRDFAxiomReader:handleException(1703): Multiple http://www.w3.org/1999/02/22-rdf-syntax-ns#first values for _:genid4 [http://www.ex.com/pr#uses, http://www.ex.com/ex#isOwnedBy]

....

The first two seem to be because they are not managed by SL reasoning. I suppose the best I can do is to remove the triples in the ontology, and forget about that functionality. Is this correct?

The others are confusing to me. They are autogenerated by property chains in Protege (like: 'reads' o 'pageBelongsToBook' -> 'reads'). I suppose the problem is that data came from two different files, so there is a repetition of _:genid1, etc. And although each file has been inserted in a different graph, since they are queried all together, the issue happens. The solution to this is to manually rename the ids of one of the files? By the way, the property chains seem to work.

The first two are just as you said, they aren't supported in SL. I believe that they would be with DL but using DL comes with its own set of restrictions which are explained here

I think there's a special name for those types of classes but I can't remember what it is. Complex class expression? Conjunctive class expression? Something like that. Maybe if I get it wrong enough times I'll summon the @pavel genie to give me the answer :slight_smile:

You could remove and it would obviously get rid of the warning. You might also be able to try setting the 'reasoning.approximate' property but I'm not sure if it would cover this case. The documentation describes that property as follows:

Enables approximate reasoning. With this flag enabled Stardog will approximate an axiom that is outside the profile Stardog supports and normally ignored. For example, an equivalent class axiom might be split into two subclass axioms and only one subclass axiom is used.

If you leave it in there I believe the default behavior is to

general concept inclusion axioms (GCIs)? Where the left-side of a subclass axiom is a complex concept aka complex class expression when speaking in OWL terms? And yes, union and intersection are, among others, (complex) class expressions.

That said

EquivalentClasses(ex:E, or(ex:N, ex:P))

isn't supported in SL profile because although it supports all of OWL RL, EL and QL, allowed axiom rules for OWL RL for example state

EquivalentClasses := 'EquivalentClasses' '(' axiomAnnotations subClassExpression subClassExpression { subClassExpression } ')'

with

subClassExpression :=
Class |
subObjectSomeValuesFrom | DataSomeValuesFrom

so, no union (or operator) is allowed here.
Similar restriction do exist for OWL EL (no union at all) and OWL QL profile (no union/intersection in subclass).

Indeed, those axioms perfectly fit into OWL DL, but its reasoning is based on tableau algorithm and likely to be less efficient compared to rule-based reasoning. I also guess that is has to load the whole schema into memory in order to use the Pellet reasoner (is it still the underlying OWL DL reasoner?)

GCI, that’s what I was trying to come up with. It was rattling around in my brain but didn’t want to come out. Thanks :slight_smile:

I suppose so, looking at the logs.

So for the second issue I mentioned, what is the problem exactly?

Well the second problem:
As far as I understand, you loaded two ontology files into Stardog, right? And each of them into a separate named graph?
Well, it looks like the blank node IDs from the file have been kept the same in the database.
As far as I know, the scope of a blank node is based on documents or in the RDF world then a graph. So while the ID of the blank node is the same in multiple graphs, it denotes different entities.
But I'm not a Stardog developer or expert. They know for sure better what the log message means, and whether it's a problem or not. Maybe it comes from the reasoning layer and the parser there isn't aware of named graphs, thus, thinks that multiple rdf:first nodes occur which of course isn't allowed.
But yeah, I'm just guessing here, I'm interested to see what the devs will tell us.

At least the "problem" should be easily reproducible. One property chain axiom per file, make bnode ID the same in both files for the rdf:first value. Load each of the file into a graph. Enable SL reasoning. Run a query. Or at lest, at one of those steps the warning should occur in the logs.

You should look at the preserve bnodes option. On my phone right now. Will follow up with a link but you can search the docs for it.

It's a little late but I promised a link

https://www.stardog.com/docs/java/snarl/com/complexible/stardog/db/databaseoptions#PRESERVE_BNODE_IDS

Yes, lorenz_b, your assumptions were right.

Thanks Zachary for the link, it seems this is just what I might need! It sounds very reasonable, I will have a look.

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