Unable to reason over small ontologies using Pellet 2.4

Fritz Lekschas

unread,

Aug 31, 2015, 7:02:28 PM8/31/15

to Pellet Users

I am building a small OWL parser using Jena. To be able to work with Jena 2.13 I got the most current version of Pellet (2.4) from GitHub. Reasoning over the pizza ontology works fine but other ontologies like cell ontology, experimental factor ontology or even the tiny little relations ontology (oborel or ro) never finish. I've tested Pellet in Protege but there doesn't even pop up the dialog box with the progress bar for any of the named ontologies (except the pizza ontology works).

Does anybody know how to debug Pellet to figure out what's really going on?

Thanks for your help.

Below is the code for loading an ontology:

this.model = ModelFactory.createOntologyModel(PelletReasonerFactory.THE_SPEC);

try {
    InputStream in = new FileInputStream(this.path_to_owl); // or any windows path
    this.model.read(in, null);
    in.close();
} catch (Exception e) {
    print_error("Error loading the ontology");
    print_error(e.getMessage());
    System.exit(1);
}

Ignazio Palmisano

unread,

Aug 31, 2015, 7:06:22 PM8/31/15

to pellet...@googlegroups.com

On 1 Sep 2015 12:02 am, "Fritz Lekschas" <f.lek...@gmail.com> wrote:
>
> I am building a small OWL parser using Jena. To be able to work with Jena 2.13 I got the most current version of Pellet (2.4) from GitHub. Reasoning over the pizza ontology works fine but other ontologies like cell ontology, experimental factor ontology or even the tiny little relations ontology (oborel or ro) never finish. I've tested Pellet in Protege but there doesn't even pop up the dialog box with the progress bar for any of the named ontologies (except the pizza ontology works).
>
> Does anybody know how to debug Pellet to figure out what's really going on?
>

How much memory have you assigned to the heap?

An easy way to profile the reasoning is using jvisualvm, included in all recent JDKs. It will also report on GC time and used memory.
Cheers,
Ignazio

> Thanks for your help.
>
> Below is the code for loading an ontology:
>
> this.model = ModelFactory.createOntologyModel(PelletReasonerFactory.THE_SPEC);
>
> try {
>     InputStream in = new FileInputStream(this.path_to_owl); // or any windows path
>     this.model.read(in, null);
>     in.close();
> } catch (Exception e) {
>     print_error("Error loading the ontology");
>     print_error(e.getMessage());
>     System.exit(1);
> }
>

> --
> You received this message because you are subscribed to the Google Groups "Pellet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pellet-users...@googlegroups.com.
> To post to this group, send email to pellet...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/pellet-users/d603f869-8081-4502-9c3a-45cb766e75ab%40googlegroups.com.

Fritz Lekschas

unread,

Aug 31, 2015, 7:10:46 PM8/31/15

to Pellet Users

Gave it up to 1 GB. OBOREL is only 360 KB in total and all other reasoners that I've tried (HermiT, Fact++, Jena's build-in reasoner) finish reasoning within 1-10 seconds. I'll have a look at jvisualvm, thanks.

Fritz Lekschas

unread,

Sep 1, 2015, 2:10:25 PM9/1/15

to Pellet Users

To check if it's an actual problem with Pellet 2.4 I've tried reasoning using Pellet 2.3.1 and it also never ends. Sometimes it runs into memory issues, no matter how much memory I give to Java and sometimes it just runs forever. (Again the ontology I am talking about comes at only 360 KB and other reasoners take 1-10s to finish reasoning!)

Ignazio Palmisano

unread,

Sep 1, 2015, 2:24:09 PM9/1/15

to Pellet Users

That's a really interesting ontology, then :-)

Pellet 2.4 (I assume you're referring to the ignazio1977 branch) has
been used with bigger ontologies than that, so its contents must be
hitting some expensive corner cases.
I've tried looking for an OBOrel version online but could not locate
one - do you have a link to the exact version you're using?
Cheers,
Ignazio

>
> --
> You received this message because you are subscribed to the Google Groups
> "Pellet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pellet-users...@googlegroups.com.
> To post to this group, send email to pellet...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pellet-users/27612475-cfc4-45da-8b0f-3693639dbac5%40googlegroups.com.

Fritz Lekschas

unread,

Sep 1, 2015, 3:52:28 PM9/1/15

to Pellet Users

Am Dienstag, 1. September 2015 14:24:09 UTC-4 schrieb Ignazio Palmisano:

On 1 September 2015 at 19:10, Fritz Lekschas <f.lek...@gmail.com> wrote:
> To check if it's an actual problem with Pellet 2.4 I've tried reasoning
> using Pellet 2.3.1 and it also never ends. Sometimes it runs into memory
> issues, no matter how much memory I give to Java and sometimes it just runs
> forever. (Again the ontology I am talking about comes at only 360 KB and
> other reasoners take 1-10s to finish reasoning!)

That's a really interesting ontology, then :-)

Pellet 2.4 (I assume you're referring to the ignazio1977 branch) has
been used with bigger ontologies than that, so its contents must be
hitting some expensive corner cases.
I've tried looking for an OBOrel version online but could not locate
one - do you have a link to the exact version you're using?
Cheers,
Ignazio

Thanks for your help! Yes I am basically using your branch. ;-)

The following ontologies "reason forever" (until I kill the process), they are sorted by size:

OBOREL (RO): https://github.com/oborel/obo-relations/blob/master/ro.owl

Cell Ontology (CL): https://github.com/obophenotype/cell-ontology/blob/master/cl.owl

I ran Fact++ and HermiT on CL and both finished:

- FaCT++ classified in 2.938.384ms

- HermiT 1.3.8.3 classified in 45.425ms

Fritz Lekschas

unread,

Sep 1, 2015, 4:23:39 PM9/1/15

to Pellet Users

Am Dienstag, 1. September 2015 15:52:28 UTC-4 schrieb Fritz Lekschas:

Am Dienstag, 1. September 2015 14:24:09 UTC-4 schrieb Ignazio Palmisano:
On 1 September 2015 at 19:10, Fritz Lekschas <f.lek...@gmail.com> wrote:
> To check if it's an actual problem with Pellet 2.4 I've tried reasoning
> using Pellet 2.3.1 and it also never ends. Sometimes it runs into memory
> issues, no matter how much memory I give to Java and sometimes it just runs
> forever. (Again the ontology I am talking about comes at only 360 KB and
> other reasoners take 1-10s to finish reasoning!)

That's a really interesting ontology, then :-)

Pellet 2.4 (I assume you're referring to the ignazio1977 branch) has
been used with bigger ontologies than that, so its contents must be
hitting some expensive corner cases.
I've tried looking for an OBOrel version online but could not locate
one - do you have a link to the exact version you're using?
Cheers,
Ignazio

Thanks for your help! Yes I am basically using your branch. ;-)

The following ontologies "reason forever" (until I kill the process), they are sorted by size:
OBOREL (RO): https://github.com/oborel/obo-relations/blob/master/ro.owl
Cell Ontology (CL): https://github.com/obophenotype/cell-ontology/blob/master/cl.owl

Quick update:

When trying to reason over CL (I am using Protege and started it with max mem 4 GB), I see the following error popping up after some time

Error logged

java.lang.StackOverflowError 
 at shared.SharedObjectFactory.build(SharedObjectFactory.java:224) 
 at aterm.pure.PureFactory.makeAppl(PureFactory.java:191) 
 at aterm.pure.PureFactory.makeAppl(PureFactory.java:185) 
 at aterm.pure.PureFactory.makeAppl(PureFactory.java:223) 
 at org.mindswap.pellet.utils.ATermUtils.makeAllValues(ATermUtils.java:486) 
 at org.mindswap.pellet.tableau.blocking.Block2.isBlockedByChain(Block2.java:63) 
 at org.mindswap.pellet.tableau.blocking.Block2.isBlocked(Block2.java:50) 
 at org.mindswap.pellet.tableau.blocking.EqualityBlocking.isDirectlyBlockedBy(EqualityBlocking.java:56) 
 at org.mindswap.pellet.tableau.blocking.Blocking.isDirectlyBlockedByDescendant(Blocking.java:130) 
 at org.mindswap.pellet.tableau.blocking.Blocking.isDirectlyBlockedByDescendant(Blocking.java:142)
 ... (line above is repeated a couple of time)

Ignazio Palmisano

unread,

Sep 1, 2015, 4:48:18 PM9/1/15

to Pellet Users

Memory does not seem to be the problem in this case: I'm trying with
three gigs but after a while memory consumption seems stable at 200
megs.

The error you found seems related to either infinite recursion, or a
deep enough recursion to break Java - I should be able to replicate
this, I think.

Most of the time so far (about fifteen minutes) is spent in the
State.move() method. Unfortunately, I cannot see a simple optimization
for what is being done in that method...
I.

> https://groups.google.com/d/msgid/pellet-users/7fbb4048-f04b-47d6-b952-976c53c30d6f%40googlegroups.com.

Ignazio Palmisano

unread,

Sep 2, 2015, 5:52:28 PM9/2/15

to Pellet Users

On 1 September 2015 at 21:48, Ignazio Palmisano

I've managed some acceptably simple optimizations for the move()
methods and reproduced the stackoverflow issue after a few minutes of
running.
Looks like an infinite recursion on this method:

at org.mindswap.pellet.tableau.blocking.Blocking.isDirectlyBlockedByDescendant(Blocking.java:142)
at org.mindswap.pellet.tableau.blocking.Blocking.isDirectlyBlockedByDescendant(Blocking.java:142)
at org.mindswap.pellet.tableau.blocking.Blocking.isDirectlyBlockedByDescendant(Blocking.java:142)
at org.mindswap.pellet.tableau.blocking.Blocking.isDirectlyBlockedByDescendant(Blocking.java:142)
at org.mindswap.pellet.tableau.blocking.Blocking.isDirectlyBlockedByDescendant(Blocking.java:142)
at org.mindswap.pellet.tableau.blocking.Blocking.isDirectlyBlockedByDescendant(Blocking.java:142)
at org.mindswap.pellet.tableau.blocking.Blocking.isDirectlyBlockedByDescendant(Blocking.java:142)
at org.mindswap.pellet.tableau.blocking.Blocking.isDirectlyBlockedByDescendant(Blocking.java:142)
at org.mindswap.pellet.tableau.blocking.Blocking.isDirectlyBlockedByDescendant(Blocking.java:142)

Looks like this crash happens in a five thousand deep recursion. I'll
try rewriting it iteratively - Java is not that great with deep
recursions.
Cheers,
Ignazio

Fritz Lekschas

unread,

Sep 2, 2015, 6:26:36 PM9/2/15

to Pellet Users

Thanks so much for your help! Unfortunately I am no logic expert but I am wondering what semantic construct causes this deep recursions.

Ignazio Palmisano

unread,

Sep 3, 2015, 2:24:01 AM9/3/15

to Fritz Lekschas, Pellet Users

It's difficult to tell - the issue happens while checking for
blocking, which is part of the tableaux expansion rules - it stops the
reasoner from creating infinite individuals, which is of course not a
desirable situation.
All tableaux reasoners do this, in some form, but small differences in
heuristics used to decide which tableaux branch to explore first can
have a huge effect. My working hypothesis is that HermiT and FaCT++
are not affected because either their algorithms deal better with this
kind of tableaux structure (HermiT uses hypertableaux, not simple
tableaux), or their heuristics work better - also, FaCT++ is written
in C++, which can handle deep recursion better than Java, so it might
just be able to breeze through the same algorithm. I've found this to
be the case before in my FaCT++ port to Java.
Cheers,
I.

> https://groups.google.com/d/msgid/pellet-users/2f935909-33c3-4395-8564-e973dffea6a8%40googlegroups.com.

Claudia Villalonga

unread,

Sep 23, 2015, 10:48:12 PM9/23/15

to Pellet Users, f.lek...@gmail.com

Dear Ignazio,

I got the same problem than Fritz. I'm trying to reason on top of the W3C Semantic Sensor Network ontology (http://purl.oclc.org/NET/ssnx/ssn) which imports DUL version 3.22 (http://www.loa-cnr.it/ontologies/DUL.owl).

If I import SSN into Protege 4.3 and reason on it using the Pellet plugin (v2.2), I get the following error:

Error 1 Logged at Thu Sep 24 10:22:53 KST 2015

StackOverflowError: null

aterm.pure.ATermApplImpl.equivalent(ATermApplImpl.java:75)

shared.SharedObjectFactory.build(SharedObjectFactory.java:247)

aterm.pure.PureFactory.makeAppl(PureFactory.java:191)

aterm.pure.PureFactory.makeAppl(PureFactory.java:185)

aterm.pure.PureFactory.makeAppl(PureFactory.java:223)

org.mindswap.pellet.utils.ATermUtils.makeAllValues(ATermUtils.java:486)

org.mindswap.pellet.tableau.blocking.Block2.isBlockedByChain(Block2.java:63)

org.mindswap.pellet.tableau.blocking.Block2.isBlocked(Block2.java:50)

org.mindswap.pellet.tableau.blocking.OptimizedDoubleBlocking.isDirectlyBlockedBy(OptimizedDoubleBlocking.java:66)

org.mindswap.pellet.tableau.blocking.Blocking.isDirectlyBlockedByDescendant(Blocking.java:130)

org.mindswap.pellet.tableau.blocking.Blocking.isDirectlyBlockedByDescendant(Blocking.java:142)

....

I tried with HermiT resoner and there is not such a problem, but my ontology includes SWRL rules and I need to use Pellet because it supports the SWRL built-ins.

Are you aware of any possible solution? Any hint or idea would be very much appreciated.

Thank you very much in advance.

Claudia

Ignazio Palmisano

unread,

Sep 24, 2015, 2:45:18 AM9/24/15

to Claudia Villalonga, Pellet Users, Fritz Lekschas

On 24 September 2015 at 03:48, Claudia Villalonga

Hi,
I'm currently trying to rewrite the recursion as an iteration, but I'm
not finding it easy.

The code is in Blocking.java.
For reference, it looks like this:

protected boolean isDirectlyBlockedInt(Individual blocked) {
Individual parentBlocked = blocked.getParent();
if (blocked.isRoot() || parentBlocked.isRoot()) {
return false;
}
BlockingContext cxt = new BlockingContext(blocked);
while (cxt.moveBlockerUp()) {
if (isDirectlyBlockedBy(cxt)) {
blocked.setBlocked(true);
if (log.isLoggable(Level.FINER)) {
log.finer(blocked + " blocked by " + cxt.blocker);
}
return true;
}
}
if (PelletOptions.USE_ANYWHERE_BLOCKING) {
System.out.println("Blocking.isDirectlyBlockedInt() start
recursion");
assert cxt.blocker.isRoot();
return isDirectlyBlockedByDescendant(cxt);
}
return false;
}

protected boolean isDirectlyBlockedByDescendant(BlockingContext cxt) {
if (cxt.blocked.getParent().equals(cxt.blocker)) {
return false;
}
if (!cxt.blocker.isRoot() && isDirectlyBlockedBy(cxt)) {
cxt.blocked.setBlocked(true);
if (log.isLoggable(Level.FINER)) {
log.finer(cxt.blocked + " blocked by " + cxt.blocker);
}
return true;
}
Individual blocker = cxt.blocker;
for (Edge e : blocker.getOutEdges()) {
Node child = e.getTo();
System.out.println("Blocking.isDirectlyBlockedByDescendant()
" + child);
if (cxt.moveBlockerDown(child)) {
if (isDirectlyBlockedByDescendant(cxt)) {
return true;
}
cxt.moveBlockerUp();
}
}
return false;
}

I'm still working on it, but if anyone has a suggestion on how to go
about it, it would be very welcome :-)
Cheers,
I.

> https://groups.google.com/d/msgid/pellet-users/e0f42588-d1ac-4de3-b10d-f7f1f33165d9%40googlegroups.com.

Message has been deleted

Ehsan Majidi

unread,

Apr 25, 2016, 9:10:05 AM4/25/16

to Pellet Users, claudiav...@gmail.com, f.lek...@gmail.com

Hi,

I have the same problem as was being discussed here. I am wondering if the issue has been resoled or not.
I developed two almost similar (in size and structure) ontologies; one of them is inferred by pellet but the inference of the second one never ends. I checked the log, there is no error registered. The memory size is set to 10G so it shouldn't be the problem. I am guessing there is an infinite recursion.

I appreciate your help.

Regards,
Ehsan

Reply all

Reply to author

Forward