Consider making it possible for a reasoner to return incomplete results

[matthewhorridge]

We could introduce a new class, Result which allows reasoners to partially answer queries, not answer queries at all or indicate that the query could not be answered because the KB is inconsistent (rather than throwing an InconsistentOntologyException). I'm thinking of something similar to Optional, but with a few more fields :)

Something like this

Result.isInconsistentKb()  

Result.isComplete()  

Result.isUnknown() 

<T> T Result.get()   // throws IllegalStateException for inconsistent or unknown results.

Result.get() gets the result if it is present. Result.isInconsistentKb() should returns false and Result.isUnknown() should return false otherwise an IllegalStateException will be thrown.

We also have static methods

 <T> Result<T> Result.of(T value) // static factory method

 <T> Result<T> Result.incompleteOf(T value) // static factory method

 <T> Result<T> Result.inconsistentKb() // static factory method

 <T> Result<T> Result.unknown() // static factory method

On our reasoner we have things like

Result<NodeSet<OWLClass>> getSubClasses()

or

Result<Boolean> isSatisfiable(OWLClassExpression)
// or
Result<Satisfiability> getSatisfiability(OWLClassExpression) // Satisfiability is an enum with SAT and UNSAT as values.

[ignazio1977]

I like the "no answers because inconsistent" concept.

The rest reminds me of a streaming design for reasoning results, where the reasoner might answer right away with a few answers and keep adding to the results when they are ready. There would be some form of hasNext() that could say yes, no, not yet, and then the client can decide if it wants to wait for more or if it's happy enough with what it's got so far.

The problem with this is that to properly implement it we need reasoners to change their architecture enough to implement this. FaCT++ and JFact could be modified to do this, at least up to a point, but the JNI wall in FaCT++ would make the trick quite complex.

[matthewhorridge]

I like the "no answers because inconsistent" concept.

Yeah, I think it's nicer than the exception

There would be some form of hasNext() t

Interesting idea.

The problem with this is that to properly implement it we need reasoners to change their architecture enough to implement this

True, but for the current reasoners (which are meant to be complete) we can have a wrapper around them.... certainly for the inconsistent KB case.

[matthewhorridge]

By the way, Yevgeny K. (@ykazakov) wanted to be able to deal with fine-grained incompleteness. He might have some useful sensible input into this.

[ignazio1977]

Yes the simpler implementation is just a wrapper around the current functionality. Being able to stream results right from the tableaux while reasoning is still ongoing would be a nice addition, especially when a few results obtained quickly are enough.

[matthewhorridge]

For sure. That would be very nice.... although for non-monotonic things (e.g. DirectSubClassOf) the results might change.

[ignazio1977]

Yes but the actors collecting the results only add to their internal collections, so once a result has reached the relevant actor, it is never retracted. That does not all happen at the end of the process, so it can be streamed meaningfully.

Of course this is the case for JFact, but I can't say whether Pellet, HermiT or ELK do anything similar.

[sesuncedu]

Cyc has a streaming mode patterned after jdbc results sets.

Any finite results on an inconsistent kb must be partial :) On Apr 16, 2014 5:54 PM, "Ignazio Palmisano" notifications@github.com wrote:

I like the "no answers because inconsistent" concept.

The rest reminds me of a streaming design for reasoning results, where the reasoner might answer right away with a few answers and keep adding to the results when they are ready. There would be some form of hasNext() that could say yes, no, not yet, and then the client can decide if it wants to wait for more or if it's happy enough with what it's got so far.

The problem with this is that to properly implement it we need reasoners to change their architecture enough to implement this. FaCT++ and JFact could be modified to do this, at least up to a point, but the JNI wall in FaCT++ would make the trick quite complex.

— Reply to this email directly or view it on GitHubhttps://github.com/owlcs/owlapi/issues/161#issuecomment-40657332 .

[ignazio1977]

current implementation returns 0 results for inconsistent kbs, so in streaming that finishes pretty quickly ;-)

[matthewhorridge]

o.k. I put up a gist... https://gist.github.com/matthewhorridge/10939609 might need refining a bit (and checking!)

[ykazakov]

Hi guys, yes, we have discussed something like that with Matthew at ISWC Specifically, we are interested in following features relevant to this discussion:

1. Be able to report that the answer to a query is complete or incomplete, sound or unsound (ideally, which results are definite, which results are possible like in HermiT can do)
2. Be able to ask several queries at once.

For the first we are interested when reasoning about an ontology for which we do not support all constructors. E.g., ELK supports a fragment of OWL EL, but can also be used for more expressive ontologies in a sound way (ignoring unsupported features). Currently there is no standard mechanism to report that the answer is incomplete, so we throw exceptions / report warnings in the logger.

The second is to achieve better performance when answering several quires, specifically quires about complex classes. The way how it is implemented in ELK: the queries are materialized (some temporary new classes are introduced that define complex classes) and the ontology is re-classified (incrementally). This way, it is more efficient to process several quires at once rather than one query after the other. The intended application scenario is something like a "reasoner on the Web" where several clients can pose queries concurrently. I am thinking about something like "Future" in Java to do asynchronous query answering. Being able to "fill" the answer incrementally like Ignazio mentioned could be also useful, but probably not that important for us at the moment.

[ignazio1977]

1. Complete/incomplete wrt supported profile

Good one, I hadn't considered this angle. Yes that would be a good feature.

1. Multiple queries

This reminds me of the other OWLReasoner discussion we were having. Matt, this would fit into events for query to the reasoner, right? #155