[Pellet-users] (no subject)

[Evren Sirin]

Hi Massimo,

On 7/5/07 1:15 PM, Massimo Paolucci wrote:
> Dear all,
>
> I am running Pellet 1.5 RC1, the latest release and I encountered a 
> couple of strange behavious that I cannot quite explain (which is to 
> say that I suspect that there is a bug somewhere).
>
> I load a bunch of ontologies (UsersKB attached and imported files), I 
> do the needed classifications, and then I query the KB to extract the 
> types of an instance.  I then load a new ontology (MVV.owl) and I run 
> exactly the same query.  The first query goes fine and returns a 
> result in 2 secs, The second query takes 65 secs and when I try to 
> extract the results from the ResultSet  iterator, the statement  
> results.hasNext() hangs for ever.   The code that I use is in 
> Drop_Incremental_query.java , the hanging line is 117. 
>
> My first question is of course why it is hanging, which is my main 
> concern at this point.
> My second question is why by adding only a few nominals which do not 
> affect the classification I get a degrade of performance of such a 
> dimension: from 2 secs to 65 secs during query time (see log in 
> "Pellet test 2").
First, it is not true that classification is not affected. There is a 
problem in your code (more details about it below) that classification 
does not happen when you intend it to happen. It happens the first time 
query engine hits the reasoner which takes place inside that hasNext() 
function. Classification takes 44sec on my machine and realization takes 
another 10sec (with REALIZE_INDIVIDUAKL_AT_A_TIME set to false).

Second, reasoning with nominals is no easy task. Pellet was the first 
(and for a long time only) reasoner that supported nominals and includes 
some novel optimizations for nominals [1]. The reasoning mechanism with 
nominals is quite different and even adding one nominal might change the 
performance (and surprisingly sometimes for the better, again see [1]).

But what is really happening is due to some unusual (and probably 
incorrect) modeling in the ontology related to the class Interval. Using 
equivalentClass axioms in combination with maxCardinality has some weird 
consequences. For example, in the ontology it says

EquivalentClasses( OpenEndInterval Restriction(end_at_instant 
maxCardinality(0)) )

which means that any instance that does not have a end_at_instant value 
will be classified under OpenEndInterval. That includes all the 
instances that have nothing to do with Intervals, e.g. an Address 
wouldn't have that value. OpenStartInterval and Interval classes have 
similar equivalent class axioms. Changing these to exact cardinality 
(which I think is better modeling anyway) would solve the problem. Or 
maybe it was intended to use subClassOf axioms rather than 
equivalentClass? That is not having an end time would be a necessary but 
not a sufficient condition for being an OpenEndInterval (which again I 
think is better than the original axioms). The axioms as they are create 
too many decision points for the reasoner (since an Address or a 
SocialThing would be considered as subclasses of OpenEndInterval, 
OpenStartInterval, so on).

>
> The third question is that I tried to modify the way the models are 
> constructed by using 
>
> model =   ModelFactory.createOntologyModel( PelletReasonerFactory. 
> THE_SPEC );
>
> and the rest of the code is pretty much the same.  But I get a much 
> worse performance (the classification takes between 280 and 438 secs) 
> but the query answering is almost instantaneous and the bug reported 
> above does not happen.
There is some kind of a cyclic dependency here. A model created with 
PelletReasonerFactory. THE_SPEC is backed by a PelletInfGraph which 
contains an OWLReasoner as one field. In your code. a separate 
OWLReasoner is created and the Pellet-backed model is loaded into that 
reasoner and then the loaded model is modified by the read statements 
which is not the right way to do it (e.g. without a prepare statement 
the loaded model is not updated properly and then classification does 
not happen when you call the OWLReasoner.classify() function).

The clean way I would suggest for you is not to deal with the 
OWLReasoner or KnowledgeBase at all. Just create the model as above:

model =   ModelFactory.createOntologyModel( PelletReasonerFactory. 
THE_SPEC );

and if you want to trigger classification explicitly just do

((PelletInfGraph) model.getGraph()).classify();

which will do both the classification and the realization for the loaded 
ontology.

Hope this helps,
Evren

[1] http://pellet.owldl.com/docs/#pub6

>
> Unfortunately I have no time to analyze the code any further digging 
> into Jena or Pellet's code, but I am wondering whether I am doing 
> something wrong.
>
> Best Regards,
>
> --- Massimo
>
>
> ------------------------------------------------------------------------
>
>  
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------
> Massimo Paolucci
> Senior Researcher
> DoCoMo Communications Laboratories Europe GmbH
> Landsberger Strasse 308-312, 80687 Munich
>
> Phone:  +49-89-56824-238
> Fax:    +49-89-56824-301
> Mobile: +49-163-34860553
>
> mailto:paolucci at docomolab-euro.com
> http://www.docomolab-euro.com
>
> Managing Directors (Geschaeftsfuehrer):
> Dr. Toru Otsu, Dr. Narumi Umeda, Kazushige Yoshida
> Amtsgericht Muenchen, HRB 132967
> --------------------------------------------------
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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/