sourish-rygbee / elk-reasoner

Automatically exported from code.google.com/p/elk-reasoner
Apache License 2.0
0 stars 1 forks source link

Missing Implementation of OWL API Reasoning Methods #11

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Currently, ELK does not implement some methods in its OWL API Reasoner 
interface implementation (search for "TODO"):

https://code.google.com/p/elk-reasoner/source/browse/trunk/elk-owlapi/src/main/j
ava/org/semanticweb/elk/owlapi/ElkReasoner.java

In order for ELK to work for one of our tools (DL-Learner - 
http://sourceforge.net/projects/dl-learner/), some of those methods would need 
to be implemented, e.g. retrieving domains/ranges of properties. 

I hope you can give this higher priority to make it easier to use ELK via OWL 
API in general.

Original issue reported on code.google.com by jenslehm...@googlemail.com on 6 Sep 2012 at 8:37

GoogleCodeExporter commented 9 years ago
Thanks for letting us know about your use of ELK!

We are planning to add some OWL API functions for object properties, including 
querying object property hierarchies and, perhaps, object property domains. So, 
please stay tuned.

Proper support for object property range axioms is, however, quite low in our 
priority list. There are some technical difficulties with that. Without being 
able to express property ranges, I am not sure it would be useful to query for 
property ranges. Can you provide an example ontology (a few axioms would be 
enough) for your use case showing in which situations you need property ranges? 
Perhaps we can then understand this requirement better.

Yevgeny

Original comment by ykazako...@gmail.com on 11 Sep 2012 at 5:49

GoogleCodeExporter commented 9 years ago
Thanks for your comment. I already replied quite a while ago, but for some 
reason my reply did not appear here (and I did not save it elsewhere).

About are use case: We are developing and using DL-Learner 
(http://dl-learner.org) and currently experiment with life science datasets 
(phenotype prediction). DL-Learner relies on the OWL API reasoner interface and 
calls several methods there for internal optimisations. Missing implementations 
of methods lead to either exceptions (if they are necessary) or lower 
performance. We worked around some missing methods via try-catch-blocks for the 
moment, but in other cases, it is a bit harder/slower to work around them. 

For instance, when we call "isEntailed" in 
http://code.google.com/p/elk-reasoner/source/browse/elk-owlapi/src/main/java/org
/semanticweb/elk/owlapi/ElkReasoner.java then it always throws an exception - 
it would be much better if you could check the requested axiom and only throw 
the exception only if it is indeed unsupported. For instance, we would like to 
check whether an instance belongs to a class (without having to call getTypes 
which is inefficient if we just want to check one specific class).

Another method, which is very important for us, but currently unsupported, is 
getObjectPropertyValues(). For getInstances(), we would need support for 
complex class expressions (not only named classes).

As for property ranges: I think OWL2 EL has support for property ranges, so it 
would be good if those can be used with ELK as well. 

Examples of ontologies we are using are here:
http://purl.obolibrary.org/obo/mp.owl
http://purl.obolibrary.org/obo/mp_xp.owl

Kind regards,

Jens

Original comment by jenslehm...@googlemail.com on 18 Oct 2012 at 8:32

GoogleCodeExporter commented 9 years ago
Dea Jens,

I understand your problems, but unfortunately there is no easy way to solve 
them except for implementing the missing methods fairly. For example, ELK 
cannot check an instance of a class directly. The algorithm will have to do 
that by computing all entailed types of the instance anyway. The same about 
checking subclass relation. It might be possible to precompute all such 
relations and store them, but it will require more memory. Currently ELK only 
stores direct types and direct superclasses to save space.

For checking instances and subclasses of complex class expressions, see the 
workaround here:

http://code.google.com/p/elk-reasoner/wiki/QueryingComplexClasses

This is a difficult problem (even from the theoretical point of view), and we 
are trying to work on a solution.

Implementing getObjectPropertyValues() is possible; we might have a solution 
soon.

As I said, asserting and query object property ranges will probably not come 
very soon. B.t.w., I do not see in the OWL2 specification that *querying* for 
object property ranges should be supported in the OWL2 EL profile. I can see 
only that object property range *axioms* can be used in OWL2 EL ontologies.

Regarding your ontologies:

I have briefly looked at mp.owl. I do not see anything interesting that can be 
queried for this ontology. It contains only one object property which is used 
only in one transitivity axiom and nowhere else. Other axioms are just subclass 
axioms between atomic classes. There are no individuals. Can you elaborate what 
are you trying to do with this ontology, preferably using an example?

The link to the second ontology mp_xp.owl is broken.

Best regards,

Yevgeny

Original comment by ykazako...@gmail.com on 18 Oct 2012 at 12:33

GoogleCodeExporter commented 9 years ago
Set for 0.5

Original comment by pavel.kl...@gmail.com on 5 Jun 2013 at 10:27