Export (save) the inferred ontology II, still failing (Protege crashes)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Export (save) the inferred ontology II, still failing (Protege crashes)

Daniel Schober
Dear all,
I have updated and installed the Protege 4.1 beta of today, updated all
plugins. The I let Hermit classify my ontology (dco importing Biotop, it
took ca.10 Minutes). Then I tried to save the inferred ontology using
the "export inferred axiom" option, pretty much accepting all defaults
there, but Protege still hangs (just as described by others before e.g.
on this list as of 5.9). I have attached the files in question.
Please let me know how I can sail around this problem (it is a little
frustrating if reasoning becomes so slow AND one can't save the inferred
ontology ;-) ).
Cheers, Daniel.

--

-------------------------------------------------------------
   Dr. Daniel Schober
   Universit├Ątsklinikum
   Institut f├╝r Medizinische Biometrie und Medizinische Informatik
   Stefan-Meier-Strasse  26 Raum 6
   D-79104 Freiburg Germany
   Tel: +49 (0)761 2036807 FAX: +49 (0)761 2036711












_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03

dco.owl (701K) Download Attachment
biotop.owl (432K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Export (save) the inferred ontology II, still failing (Protege crashes)

Timothy Redmond

It is interesting but not surprising that such a small ontology can give
a reasoner so much trouble.  I suspect that the problem is simply that
generating the exported inferred ontology is taking a very long time.  
In my experiment, I saved the exported inferred ontology with "Disjoint
classes" turned off and the export happened very fast.  When I do the
export with "Disjoint classes" selected, the export  seems to be taking
a long time.  In addition, when I take stack traces of what Protege is
doing I see it spending a lot of  time in
InferredDisjointClassesAxiomGenerator.  I originally came to suspect
that the disjoint classes might be the problem because when I did the
classify  with the "Inferred Disjoint Classes" option turned on, my
classify was taking considerably longer than 10 minutes on a very fast
machine.

I suspect that the action item on the Protege side is to add a progress
bar that gives some useful information about what it is doing.  Without
the progress bar, a user is likely to suspect that something is wrong
even if the program is operating perfectly normally.   Also a good
progress bar would allow you to discover  that it is the calculation of
the disjoint classes that is giving you trouble.

-Timothy

BTW - Birte: he is classifying dco.owl which imports biotop.owl.

On 09/27/2010 07:09 AM, Dr. Daniel Schober wrote:

> Dear all,
> I have updated and installed the Protege 4.1 beta of today, updated
> all plugins. The I let Hermit classify my ontology (dco importing
> Biotop, it took ca.10 Minutes). Then I tried to save the inferred
> ontology using the "export inferred axiom" option, pretty much
> accepting all defaults there, but Protege still hangs (just as
> described by others before e.g. on this list as of 5.9). I have
> attached the files in question.
> Please let me know how I can sail around this problem (it is a little
> frustrating if reasoning becomes so slow AND one can't save the
> inferred ontology ;-) ).
> Cheers, Daniel.
>

_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03

dco.owl (938K) Download Attachment
biotop.owl (580K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Export (save) the inferred ontology II, still failing (Protege crashes)

Timothy Redmond

> If you give HermiT a progress monitor, it will report progress also
> for computing disjoint classes, so I agree that this should be done
> from the Protege side.

During the classify, Protege had a progress bar and HermiT gave very
clear information about what was taking a long time.  During the export,
Protege is calling an OWL API utility that makes a variety of reasoner
calls and I will have to look and see if the OWL utility has a hook for
a progress monitor.

-Timothy



On 09/28/2010 02:14 AM, Birte Glimm wrote:

> On 28 September 2010 00:46, Timothy Redmond<[hidden email]>  wrote:
>    
>> It is interesting but not surprising that such a small ontology can give a
>> reasoner so much trouble.  I suspect that the problem is simply that
>> generating the exported inferred ontology is taking a very long time.  In my
>> experiment, I saved the exported inferred ontology with "Disjoint classes"
>> turned off and the export happened very fast.  When I do the export with
>> "Disjoint classes" selected, the export  seems to be taking a long time.
>>      
> Computing disjoint classes is very expensive, it's definitely harder
> than class classification. We tried already different ways of doing
> it, but without much improvement :-(
>
>    
>> In
>> addition, when I take stack traces of what Protege is doing I see it
>> spending a lot of  time in InferredDisjointClassesAxiomGenerator.  I
>> originally came to suspect that the disjoint classes might be the problem
>> because when I did the classify  with the "Inferred Disjoint Classes" option
>> turned on, my classify was taking considerably longer than 10 minutes on a
>> very fast machine.
>>
>> I suspect that the action item on the Protege side is to add a progress bar
>> that gives some useful information about what it is doing.  Without the
>> progress bar, a user is likely to suspect that something is wrong even if
>> the program is operating perfectly normally.   Also a good progress bar
>> would allow you to discover  that it is the calculation of the disjoint
>> classes that is giving you trouble.
>>      
> If you give HermiT a progress monitor, it will report progress also
> for computing disjoint classes, so I agree that this should be done
> from the Protege side.
>
> Birte
>
>
>    
>> -Timothy
>>
>> BTW - Birte: he is classifying dco.owl which imports biotop.owl.
>>
>> On 09/27/2010 07:09 AM, Dr. Daniel Schober wrote:
>>      
>>> Dear all,
>>> I have updated and installed the Protege 4.1 beta of today, updated all
>>> plugins. The I let Hermit classify my ontology (dco importing Biotop, it
>>> took ca.10 Minutes). Then I tried to save the inferred ontology using the
>>> "export inferred axiom" option, pretty much accepting all defaults there,
>>> but Protege still hangs (just as described by others before e.g. on this
>>> list as of 5.9). I have attached the files in question.
>>> Please let me know how I can sail around this problem (it is a little
>>> frustrating if reasoning becomes so slow AND one can't save the inferred
>>> ontology ;-) ).
>>> Cheers, Daniel.
>>>
>>>        
>>
>>      
>
>
>    

_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03
Reply | Threaded
Open this post in threaded view
|

Re: Export (save) the inferred ontology II, still failing (Protege crashes)

Timothy Redmond

BTW - Protege was still struggling with the disjoint classes this
morning.  It failed to complete overnight.

> Since the OWL API is not to be updated soon I guess (3.1 is just
> released), you could fix that by dynamically overwriting the axiom
> generator, which I assume you use.

I will be looking at this code soon.  I have a gforge and I added your
comments for when I modify the code.

-Timothy

[1] https://bmir-gforge.stanford.edu/gf/project/owleditor/tracker/?action=TrackerItemEdit&tracker_item_id=2654&start=0


On 09/28/2010 08:20 AM, Birte Glimm wrote:

> On 28 September 2010 15:35, Timothy Redmond<[hidden email]>  wrote:
>    
>>      
>>> If you give HermiT a progress monitor, it will report progress also
>>> for computing disjoint classes, so I agree that this should be done
>>> from the Protege side.
>>>        
>> During the classify, Protege had a progress bar and HermiT gave very clear
>> information about what was taking a long time.  During the export, Protege
>> is calling an OWL API utility that makes a variety of reasoner calls and I
>> will have to look and see if the OWL utility has a hook for a progress
>> monitor.
>>      
> I just looked at the code of InferredDisjointClassesAxiomGenerator and
> that is really stupid. The class does not use getDisjointClasses, but
> it tries to encode the reasoning problem itself by testing for each
> pair of classes, whether the intersection of the first with the
> negaion of the second class is satisfiable. This definitely should be
> changed since it bypasses all optimisations that we do within the
> reasoner. Ideally,
> precomputeInferences(InferenceType.DISJOINT_CLASSES) should be used.
> That way, we know that all such entailments are needed and we could
> use a one-pass classification with extra axioms which allows us to
> find all disjoint classes from the resulting class hierarchy. We
> wouldn't do that if you ask getDisjointClasses(class) for each class
> separately because in case you want to know the disjoint classes of
> just one class, the one-pass classification is too expensive and does
> more work than possibly required. Even getDisjointClasses is not as
> simplistic as to test the intersection of the given class with the
> negation of any other class.
>
> Since the OWL API is not to be updated soon I guess (3.1 is just
> released), you could fix that by dynamically overwriting the axiom
> generator, which I assume you use.
>
> List<InferredAxiomGenerator<? extends OWLAxiom>>  generators=new
> ArrayList<InferredAxiomGenerator<? extends OWLAxiom>>();
> // materialize subclasses
> generators.add(new InferredSubClassAxiomGenerator());
> // now add a customized one for isjoint classes
> generators.add(new InferredDisjointClassesAxiomGenerator() {
>      boolean precomputed=false;
>      protected void addAxioms(OWLClass entity, OWLReasoner reasoner,
> OWLDataFactory dataFactory, Set<OWLDisjointClassesAxiom>  result) {
>          if (!precomputed) {
>              reasoner.precomputeInferences(InferenceType.DISJOINT_CLASSES);
>              precomputed=true;
>          }
>          for (OWLClass cls :
> reasoner.getDisjointClasses(entity).getFlattened()) {
>              result.add(dataFactory.getOWLDisjointClassesAxiom(entity, cls));
>          }
>      }
> });
> ...add more generators as you please and finally materialize
>
> Computing disjoint classes will still be expensive, but at least our
> optimizations are then no longer ignored and you get the progress bar.
>   The code is not HermiT specific, so any OWLReasoner should work
> (provided they implemented the methods).
>
> Birte
>
>    
>> -Timothy
>>
>>
>>
>> On 09/28/2010 02:14 AM, Birte Glimm wrote:
>>      
>>> On 28 September 2010 00:46, Timothy Redmond<[hidden email]>    wrote:
>>>
>>>        
>>>> It is interesting but not surprising that such a small ontology can give
>>>> a
>>>> reasoner so much trouble.  I suspect that the problem is simply that
>>>> generating the exported inferred ontology is taking a very long time.  In
>>>> my
>>>> experiment, I saved the exported inferred ontology with "Disjoint
>>>> classes"
>>>> turned off and the export happened very fast.  When I do the export with
>>>> "Disjoint classes" selected, the export  seems to be taking a long time.
>>>>
>>>>          
>>> Computing disjoint classes is very expensive, it's definitely harder
>>> than class classification. We tried already different ways of doing
>>> it, but without much improvement :-(
>>>
>>>
>>>        
>>>> In
>>>> addition, when I take stack traces of what Protege is doing I see it
>>>> spending a lot of  time in InferredDisjointClassesAxiomGenerator.  I
>>>> originally came to suspect that the disjoint classes might be the problem
>>>> because when I did the classify  with the "Inferred Disjoint Classes"
>>>> option
>>>> turned on, my classify was taking considerably longer than 10 minutes on
>>>> a
>>>> very fast machine.
>>>>
>>>> I suspect that the action item on the Protege side is to add a progress
>>>> bar
>>>> that gives some useful information about what it is doing.  Without the
>>>> progress bar, a user is likely to suspect that something is wrong even if
>>>> the program is operating perfectly normally.   Also a good progress bar
>>>> would allow you to discover  that it is the calculation of the disjoint
>>>> classes that is giving you trouble.
>>>>
>>>>          
>>> If you give HermiT a progress monitor, it will report progress also
>>> for computing disjoint classes, so I agree that this should be done
>>> from the Protege side.
>>>
>>> Birte
>>>
>>>
>>>
>>>        
>>>> -Timothy
>>>>
>>>> BTW - Birte: he is classifying dco.owl which imports biotop.owl.
>>>>
>>>> On 09/27/2010 07:09 AM, Dr. Daniel Schober wrote:
>>>>
>>>>          
>>>>> Dear all,
>>>>> I have updated and installed the Protege 4.1 beta of today, updated all
>>>>> plugins. The I let Hermit classify my ontology (dco importing Biotop, it
>>>>> took ca.10 Minutes). Then I tried to save the inferred ontology using
>>>>> the
>>>>> "export inferred axiom" option, pretty much accepting all defaults
>>>>> there,
>>>>> but Protege still hangs (just as described by others before e.g. on this
>>>>> list as of 5.9). I have attached the files in question.
>>>>> Please let me know how I can sail around this problem (it is a little
>>>>> frustrating if reasoning becomes so slow AND one can't save the inferred
>>>>> ontology ;-) ).
>>>>> Cheers, Daniel.
>>>>>
>>>>>
>>>>>            
>>>>
>>>>          
>>>
>>>
>>>        
>>
>>      
>
>
>    

_______________________________________________
protege-owl mailing list
[hidden email]
https://mailman.stanford.edu/mailman/listinfo/protege-owl

Instructions for unsubscribing: http://protege.stanford.edu/doc/faq.html#01a.03