[Pellet-users] Problems with huge ontology/unnamed classes

[Manuel Möller]

Hi all,

I asked this question on the jena-dev mailing list but the replys were 
not too helpful so I will try it here.

I am looking for a way to reason with huge ontologies, namely the
Foundational Model of Anatomy (FMA) [1]. I am using an OWL-DL version of
the FMA from
http://bioontology.org/projects/ontologies/FMA/fmaOwlDlComponent_1_4_0.owl

This ontology consists of approx. 143 MB, has more that 70.000 named
classes and about 1.5 million triples.

System setup: Intel DualCore (=> 32-Bit-System), 2 GB Ram, WinXP, Java 1.6

The OWL file itself seems to be okay since I can load it into Protege
[2], make changes and save it again without any problems (aside from the
fact, that loading it into Protege alone takes about 30 minutes  ;-)  ).

Loading the file into Jena takes about 100 seconds on my machine and
makes the process grow to a size of ca. 360 MB. So far so good.

But as soon as I start to use a reasoner like Pellet (v. 1.4.0-rc2) or
RacerPro (v.1.9.0) and do things like

model.validate();

or

model.listStatements(null, RDFS.subClassOf, node);

the memory consumption goes up like a rocket and after 30 seconds the
1.6 GB of RAM that I gave to Java (-Xmx1600m) are filled up and the
program stops with a Java.lang.OutOfMemoryError.

For Pellet I tried using the API interface as well as the DIG http
interface but that makes no difference for me.

My problem is that the *jena application* is consuming too much memory 
after I start using the reasoner. This happens even if I use the 
reasoner via the DIG interface. So it is not the reasoner, that dies 
with an OutOfMemoryException but the application, that processes the 
answer from the reasoner.

Due to open world assumption (and postings like [2]) my guess is that 
the reasoner is creating huge numbers of unnamed classes and jena 
creates an object for each of them. I did not got far enough into the 
jena API to trace that. Did anyone of look at that?

I wonder if there is a way to turn off the generation of objects for 
those unnamed classes or if it is possible to prohibit the DIG interface 
from returning them to the application at all.

Any ideas / hints what to do?

TIA
    Manuel

References:

[1] http://sig.biostr.washington.edu/projects/fm/AboutFM.html
[2] http://protege.stanford.edu/
-- 
Manuel Möller -- DFKI GmbH, Kaiserslautern
http://www.manuelm.org -- manuel.moeller at dfki.de
phone: +49 631 20575-132 -- fax: +49 631 20575-103
-------------- next part --------------
A non-text attachment was scrubbed...
Name: manuel.moeller.vcf
Type: text/x-vcard
Size: 384 bytes
Desc: not available
Url : http://lists.owldl.com/pipermail/pellet-users/attachments/20070326/c59cfa7c/attachment.vcf