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

[Evren Sirin]

On 3/26/07 3:18 AM, Manuel Möller wrote:
> 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.
Yes, and I think this the real problem. The ontology also contains 130K 
individuals) and is quite expressive (ALCOIQ(D) in DL jargon). This 
means it has inverse properties. nominals and cardinality restrictions. 
Their combination is hard to reason with (even the existence of one or 
the other may make reasoning hard enough).

>
> 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.
Pushing the translation of 1.5 million triples through the HTTP bridge 
over DIG will be quite brutal so I wouldn't recommend doing it all. But 
I'm not surprised that API interface also didn't work given the size and 
complexity of this ontology.
>
> 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?
When you use PelletReasonerFactory_THE_SPEC to create a jena ontology 
model, Jena would not create objects for unnamed classes so that is not 
the real issue.
>
> 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?
I don't think any reasoner can handle this ontology right now. Only 
plausible alternative is to partition the ontology into smaller modules 
which would be easier to reason with. We are currently investigating 
how/if the automatic partitioning algorithm from Bernardo et al [1] 
could be used to improve classification.

Cheers,
Evren

[1] http://www.cs.man.ac.uk/%7Ebcg/www433-cuenca.pdf
>
> TIA
>    Manuel
>
> References:
>
> [1] http://sig.biostr.washington.edu/projects/fm/AboutFM.html
> [2] http://protege.stanford.edu/
> ------------------------------------------------------------------------
>
> _______________________________________________
> Pellet-users mailing list
> Pellet-users at lists.owldl.com
> http://lists.owldl.com/mailman/listinfo/pellet-users
> _______________________________________________
>
> Sponsored by Clark & Parsia, LLC http://clarkparsia.com/