reasoner never finishes query

19 views
Skip to first unread message

Jim Balhoff

unread,
Sep 22, 2014, 4:23:31 PM9/22/14
to elk-reasone...@googlegroups.com
I am having some trouble with ELK queries on a large dataset. I have an OWL ontology in a 778 MB RDF/XML file. Using ELK I can precompute the class hierarchy for this ontology within several minutes. The process uses about 8 GB of RAM out of the 12 GB I allocated it. When I query for subclasses of an anonymous class expression, it returns the answer in less than a second. When I query a second class expression, the memory usage rapidly increases to 12 GB and all (4) CPUs are maxed out. In the log I see that ELK messages are printed up to this point:

INFO org.semanticweb.elk.reasoner.stages.LoggingStageExecutor - Loading of Axioms started
INFO org.semanticweb.elk.reasoner.stages.AbstractReasonerStage - Loading of Axioms using 4 workers
INFO org.semanticweb.elk.reasoner.stages.LoggingStageExecutor - Loading of Axioms finished in 0 ms
INFO org.semanticweb.elk.reasoner.stages.LoggingStageExecutor - Incremental Context Completion started
INFO org.semanticweb.elk.reasoner.stages.AbstractReasonerStage - Incremental Context Completion using 4 workers
INFO org.semanticweb.elk.reasoner.stages.LoggingStageExecutor - Incremental Context Completion finished in 1 ms
INFO org.semanticweb.elk.reasoner.stages.LoggingStageExecutor - Incremental Deletions Initialization started
INFO org.semanticweb.elk.reasoner.stages.AbstractReasonerStage - Incremental Deletions Initialization using 4 workers
INFO org.semanticweb.elk.reasoner.stages.LoggingStageExecutor - Incremental Deletions Initialization finished in 80 ms
INFO org.semanticweb.elk.reasoner.stages.LoggingStageExecutor - Incremental Deletion started
INFO org.semanticweb.elk.reasoner.stages.AbstractReasonerStage - Incremental Deletion using 4 workers

It never proceeds beyond there, after waiting more than an hour. The particular class expression doesn't matter. If I have two ObjectSomeValuesFrom restrictions, A and B, I can query A in less than a second and then have B go out of control. If I query B first, then querying A will go out of control.

It is somewhat confusing because within a different application I have previously used ELK for datasets of this size. However I can reproduce the problem with this small Scala application:

https://github.com/balhoff/test-elk/blob/master/src/main/scala/org/nescent/Main.scala

I encountered the issue with both ELK 0.4.0 and 0.4.1. Is this anything you have experienced before?

Thank you,
Jim


____________________________________________
James P. Balhoff, Ph.D.
National Evolutionary Synthesis Center
2024 West Main St., Suite A200
Durham, NC 27705
USA



Yevgeny Kazakov

unread,
Sep 22, 2014, 5:15:03 PM9/22/14
to elk-reasone...@googlegroups.com
Hi Jim,

Thanks for reporting the problem!

On Mon, Sep 22, 2014 at 10:23 PM, Jim Balhoff <bal...@nescent.org> wrote:
> I am having some trouble with ELK queries on a large dataset. I have an OWL ontology in a 778 MB RDF/XML file. Using ELK I can precompute the class hierarchy for this ontology within several minutes. The process uses about 8 GB of RAM out of the 12 GB I allocated it. When I query for subclasses of an anonymous class expression, it returns the answer in less than a second. When I query a second class expression, the memory usage rapidly increases to 12 GB and all (4) CPUs are maxed out. In the log I see that ELK messages are printed up to this point:
>
> INFO org.semanticweb.elk.reasoner.stages.LoggingStageExecutor - Loading of Axioms started
> INFO org.semanticweb.elk.reasoner.stages.AbstractReasonerStage - Loading of Axioms using 4 workers
> INFO org.semanticweb.elk.reasoner.stages.LoggingStageExecutor - Loading of Axioms finished in 0 ms
> INFO org.semanticweb.elk.reasoner.stages.LoggingStageExecutor - Incremental Context Completion started
> INFO org.semanticweb.elk.reasoner.stages.AbstractReasonerStage - Incremental Context Completion using 4 workers
> INFO org.semanticweb.elk.reasoner.stages.LoggingStageExecutor - Incremental Context Completion finished in 1 ms
> INFO org.semanticweb.elk.reasoner.stages.LoggingStageExecutor - Incremental Deletions Initialization started
> INFO org.semanticweb.elk.reasoner.stages.AbstractReasonerStage - Incremental Deletions Initialization using 4 workers
> INFO org.semanticweb.elk.reasoner.stages.LoggingStageExecutor - Incremental Deletions Initialization finished in 80 ms
> INFO org.semanticweb.elk.reasoner.stages.LoggingStageExecutor - Incremental Deletion started
> INFO org.semanticweb.elk.reasoner.stages.AbstractReasonerStage - Incremental Deletion using 4 workers
>
> It never proceeds beyond there, after waiting more than an hour. The particular class expression doesn't matter. If I have two ObjectSomeValuesFrom restrictions, A and B, I can query A in less than a second and then have B go out of control. If I query B first, then querying A will go out of control.

Since the process gets stuck in the incremental deletion stage, it is
clear that it affects the second query. ELK internally materializes
the query by defining a new atomic class with the class expression in
the query. It then re-classifies the ontology incrementally and
extract the sub-classes / super-classes from this result. For the
second query, ELK will need to delete the previous definition and
perform some cleanup. It seems that something goes wrong during
deletion. It is hard to say what from this log. You could try set the
log level to DEBUG, perhaps it will give us some more information.

>
> It is somewhat confusing because within a different application I have previously used ELK for datasets of this size. However I can reproduce the problem with this small Scala application:
>
> https://github.com/balhoff/test-elk/blob/master/src/main/scala/org/nescent/Main.scala
>
> I encountered the issue with both ELK 0.4.0 and 0.4.1. Is this anything you have experienced before?

Could you, please, try running the same program on ELK nightly builds:

https://code.google.com/p/elk-reasoner/wiki/GettingElk

We have fixed a few problems since the last release, perhaps it will
work now. If not, please give us a link to your ontology so that we
could reproduce the problem and try to investigate.

Best regards,

Yevgeny

>
> Thank you,
> Jim
>
>
> ____________________________________________
> James P. Balhoff, Ph.D.
> National Evolutionary Synthesis Center
> 2024 West Main St., Suite A200
> Durham, NC 27705
> USA
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "elk-reasoner-discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to elk-reasoner-disc...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Jim Balhoff

unread,
Sep 23, 2014, 10:25:07 AM9/23/14
to elk-reasone...@googlegroups.com
Hi Yevgeny,

Thank you for your response. I tried both of your suggestions. DEBUG logging didn't seem to print out anything more informative. And I got the same result with the nightly build. Here is a link to my ontology:

https://dl.dropboxusercontent.com/u/6704325/elk-query/tbox.owl.gz

If you would like, I can file an issue at the Google tracker. Also, the program is very simple, but I can convert to Java if that would be helpful.

Thank you for your help,
Jim

Pavel Klinov

unread,
Sep 23, 2014, 10:36:40 AM9/23/14
to elk-reasone...@googlegroups.com
On Tue, Sep 23, 2014 at 4:25 PM, Jim Balhoff <bal...@nescent.org> wrote:
> Hi Yevgeny,
>
> Thank you for your response. I tried both of your suggestions. DEBUG logging didn't seem to print out anything more informative. And I got the same result with the nightly build. Here is a link to my ontology:
>
> https://dl.dropboxusercontent.com/u/6704325/elk-query/tbox.owl.gz

Thanks for the good bug report! We'll track it down and get back to you.

>
> If you would like, I can file an issue at the Google tracker. Also, the program is very simple, but I can convert to Java if that would be helpful.

Yes, an issue would be good (keeping track of issues helps to produce
release notes for the next release). The program is OK, we'll let you
know if we are unable to reproduce the problem.

Cheers,

Pavel
Reply all
Reply to author
Forward
0 new messages