How to report reasoner warnings

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

How to report reasoner warnings

Markus Krötzsch
Dear Protege users/developers,

OWL reasoners typically have some limitations in the features they
support. When encountering an unsupported feature (e.g., a new
datatype), reasoners can still derive many entailments that are
certainly correct, but they may miss some entailments that are produced
by the new feature. Moreover, even if the reasoner can guarantee sound
and complete reasoning, an input may violate constraints of the OWL
standard (example: EL reasoners do not care about regularity of property
chain axioms, but OWL EL and DL disallow them.)

How should a reasoner plugin for Protege (4.1) behave in such cases?
Here are some options:

(1) Keep calm and carry on: produce as many results as possible
(2) Panic: throw an exception (terminate, report no results)
(3) Be honest: report "Unknown" (which is a valid return value of OWL
reasoners according to spec) whenever you cannot be sure
(4) Warning: produce whatever results you can get, but warn the user
(5) Mix and match: adopt a different strategy for each concrete
reasoning task and issue, possibly partially based on user configuration

I don't know if/how (3) is technically possible at all. For ELK, we
tried to do (4) by printing an error to Standard Error, which ends up in
the command line that Protege is launched from (if any). For most users,
this is like (1) since they do not see/notice the warning. This is not
good, since users are likely to misinterpret the result.

(2) is not good, at least not in general, since there are too many
unrelated conditions that would require some small or large warning.
Aborting on each little irregularity would not help users.

(5) is only as good as any of the other strategies could be. In the
worst case, it introduces additional confusion by making seemingly
random default choices that may vary among tools and/or delegates
technical design choices to the user.

Cheers,

Markus

--
Dr. Markus Kroetzsch
Department of Computer Science, University of Oxford
Room 306, Parks Road, OX1 3QD Oxford, United Kingdom
+44 (0)1865 283529               http://korrekt.org/
_______________________________________________
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: How to report reasoner warnings

Timothy Redmond

These are difficult questions but I have two small thoughts.

First, this situation would be better if Protege had profile support.  
Potentially we could somehow make a link between the selected reasoner
and the appropriate profile.  I think that making a nice user interface
for profile support is tricky but perhaps we should start passing around
some strawman proposals to see if we can figure out what needs to be
done and how hard it would be.

Second, which option your reasoner takes could be controlled by reasoner
preferences.  I have made a plugin for this to allow reasoner developers
to create options for exactly this type of thing.  If you created a
reasoner preferences plugin it would show up when the user clicks the
Reasoner->Configure Reasoner dialog.  In addition, if you warn the user,
the warning dialog could have a check box for saying don't warn me about
this anymore.

Sorry not much of a reply yet but I have got to disappear again...

-Timothy




On 05/09/2012 02:01 AM, Markus Krötzsch wrote:

> Dear Protege users/developers,
>
> OWL reasoners typically have some limitations in the features they
> support. When encountering an unsupported feature (e.g., a new
> datatype), reasoners can still derive many entailments that are
> certainly correct, but they may miss some entailments that are
> produced by the new feature. Moreover, even if the reasoner can
> guarantee sound and complete reasoning, an input may violate
> constraints of the OWL standard (example: EL reasoners do not care
> about regularity of property chain axioms, but OWL EL and DL disallow
> them.)
>
> How should a reasoner plugin for Protege (4.1) behave in such cases?
> Here are some options:
>
> (1) Keep calm and carry on: produce as many results as possible
> (2) Panic: throw an exception (terminate, report no results)
> (3) Be honest: report "Unknown" (which is a valid return value of OWL
> reasoners according to spec) whenever you cannot be sure
> (4) Warning: produce whatever results you can get, but warn the user
> (5) Mix and match: adopt a different strategy for each concrete
> reasoning task and issue, possibly partially based on user configuration
>
> I don't know if/how (3) is technically possible at all. For ELK, we
> tried to do (4) by printing an error to Standard Error, which ends up
> in the command line that Protege is launched from (if any). For most
> users, this is like (1) since they do not see/notice the warning. This
> is not good, since users are likely to misinterpret the result.
>
> (2) is not good, at least not in general, since there are too many
> unrelated conditions that would require some small or large warning.
> Aborting on each little irregularity would not help users.
>
> (5) is only as good as any of the other strategies could be. In the
> worst case, it introduces additional confusion by making seemingly
> random default choices that may vary among tools and/or delegates
> technical design choices to the user.
>
> Cheers,
>
> Markus
>

_______________________________________________
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: How to report reasoner warnings

Markus Krötzsch
On 11/05/12 01:39, Timothy Redmond wrote:
>
> These are difficult questions but I have two small thoughts.

Thanks for keeping the thread alive :-)

>
> First, this situation would be better if Protege had profile support.
> Potentially we could somehow make a link between the selected reasoner
> and the appropriate profile. I think that making a nice user interface
> for profile support is tricky but perhaps we should start passing around
> some strawman proposals to see if we can figure out what needs to be
> done and how hard it would be.

That could be useful in general, but may not solve the present problem
in many cases, since there are hardly any reasoners that exactly cover
one profile. Usually some features are omitted, but it also happens that
more features are supported. So referring to a profile would neither
work as a lower nor as an upper bound for what a typical reasoner can
actually do. Profile support in Protege could still be useful for other
purposes though.

>
> Second, which option your reasoner takes could be controlled by reasoner
> preferences. I have made a plugin for this to allow reasoner developers
> to create options for exactly this type of thing. If you created a
> reasoner preferences plugin it would show up when the user clicks the
> Reasoner->Configure Reasoner dialog. In addition, if you warn the user,
> the warning dialog could have a check box for saying don't warn me about
> this anymore.

Indeed, this is a very useful feature. It also makes the possible
choices more visible to Protege users, which already helps to prevent
misunderstandings.

Ideally, there should be some mechanism for reasoners to report
errors/warnings to Protege users. Exceptions currently seem to be the
only way for doing this, but they necessarily interrupt the program
flow. There already is a facility for relaying information from the
reasoner to Protege in the form of the ProgressMonitor. A simple message
reporting interface could work in the same fashion (maybe it could even
be an extension of the ProgressMonitor interface? two naive methods
reportError and reportWarning would suffice for a start; more advanced
logging, e.g., with log4j, could always be added later).

Maybe there could also be a way to say -- with every answer that the
reasoner gives -- whether this result is guaranteed to be sound and/or
complete. But this would require more changes to the reasoner interface
than a messaging system.

Markus

>
>
> On 05/09/2012 02:01 AM, Markus Krötzsch wrote:
>> Dear Protege users/developers,
>>
>> OWL reasoners typically have some limitations in the features they
>> support. When encountering an unsupported feature (e.g., a new
>> datatype), reasoners can still derive many entailments that are
>> certainly correct, but they may miss some entailments that are
>> produced by the new feature. Moreover, even if the reasoner can
>> guarantee sound and complete reasoning, an input may violate
>> constraints of the OWL standard (example: EL reasoners do not care
>> about regularity of property chain axioms, but OWL EL and DL disallow
>> them.)
>>
>> How should a reasoner plugin for Protege (4.1) behave in such cases?
>> Here are some options:
>>
>> (1) Keep calm and carry on: produce as many results as possible
>> (2) Panic: throw an exception (terminate, report no results)
>> (3) Be honest: report "Unknown" (which is a valid return value of OWL
>> reasoners according to spec) whenever you cannot be sure
>> (4) Warning: produce whatever results you can get, but warn the user
>> (5) Mix and match: adopt a different strategy for each concrete
>> reasoning task and issue, possibly partially based on user configuration
>>
>> I don't know if/how (3) is technically possible at all. For ELK, we
>> tried to do (4) by printing an error to Standard Error, which ends up
>> in the command line that Protege is launched from (if any). For most
>> users, this is like (1) since they do not see/notice the warning. This
>> is not good, since users are likely to misinterpret the result.
>>
>> (2) is not good, at least not in general, since there are too many
>> unrelated conditions that would require some small or large warning.
>> Aborting on each little irregularity would not help users.
>>
>> (5) is only as good as any of the other strategies could be. In the
>> worst case, it introduces additional confusion by making seemingly
>> random default choices that may vary among tools and/or delegates
>> technical design choices to the user.
>>
>> Cheers,
>>
>> Markus
>>
>
> _______________________________________________
> 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
>

_______________________________________________
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: How to report reasoner warnings

Timothy Redmond

> That could be useful in general, but may not solve the present problem
> in many cases, since there are hardly any reasoners that exactly cover
> one profile. Usually some features are omitted, but it also happens
> that more features are supported. So referring to a profile would
> neither work as a lower nor as an upper bound for what a typical
> reasoner can actually do. Profile support in Protege could still be
> useful for other purposes though.

Maybe it would help if we designed the profile mechanism so that you
could create your own?

> Ideally, there should be some mechanism for reasoners to report
> errors/warnings to Protege users.

I had toyed with the idea that the lower left hand corner of Protege
could be a message area where plugins would write relevant information.  
There is not much space there though.  I think that several plugins
could use a message capability but I am not sure how it should look in
the ui.

> Maybe there could also be a way to say -- with every answer that the
> reasoner gives -- whether this result is guaranteed to be sound and/or
> complete. But this would require more changes to the reasoner
> interface than a messaging system.

Here we are getting into an OWL api discussion.  It would seem sad if
this capability was only accessible to Protege.  The other problem that
the OWL api (and Protege) bring is that the developers try to be
conservative about making changes to the API.

I will talk to Matthew today and see what thoughts he has.

-Timothy





On 05/11/2012 01:50 AM, Markus Krötzsch wrote:

> On 11/05/12 01:39, Timothy Redmond wrote:
>>
>> These are difficult questions but I have two small thoughts.
>
> Thanks for keeping the thread alive :-)
>
>>
>> First, this situation would be better if Protege had profile support.
>> Potentially we could somehow make a link between the selected reasoner
>> and the appropriate profile. I think that making a nice user interface
>> for profile support is tricky but perhaps we should start passing around
>> some strawman proposals to see if we can figure out what needs to be
>> done and how hard it would be.
>
> That could be useful in general, but may not solve the present problem
> in many cases, since there are hardly any reasoners that exactly cover
> one profile. Usually some features are omitted, but it also happens
> that more features are supported. So referring to a profile would
> neither work as a lower nor as an upper bound for what a typical
> reasoner can actually do. Profile support in Protege could still be
> useful for other purposes though.
>
>>
>> Second, which option your reasoner takes could be controlled by reasoner
>> preferences. I have made a plugin for this to allow reasoner developers
>> to create options for exactly this type of thing. If you created a
>> reasoner preferences plugin it would show up when the user clicks the
>> Reasoner->Configure Reasoner dialog. In addition, if you warn the user,
>> the warning dialog could have a check box for saying don't warn me about
>> this anymore.
>
> Indeed, this is a very useful feature. It also makes the possible
> choices more visible to Protege users, which already helps to prevent
> misunderstandings.
>
> Ideally, there should be some mechanism for reasoners to report
> errors/warnings to Protege users. Exceptions currently seem to be the
> only way for doing this, but they necessarily interrupt the program
> flow. There already is a facility for relaying information from the
> reasoner to Protege in the form of the ProgressMonitor. A simple
> message reporting interface could work in the same fashion (maybe it
> could even be an extension of the ProgressMonitor interface? two naive
> methods reportError and reportWarning would suffice for a start; more
> advanced logging, e.g., with log4j, could always be added later).
>
> Maybe there could also be a way to say -- with every answer that the
> reasoner gives -- whether this result is guaranteed to be sound and/or
> complete. But this would require more changes to the reasoner
> interface than a messaging system.
>
> Markus
>
>>
>>
>> On 05/09/2012 02:01 AM, Markus Krötzsch wrote:
>>> Dear Protege users/developers,
>>>
>>> OWL reasoners typically have some limitations in the features they
>>> support. When encountering an unsupported feature (e.g., a new
>>> datatype), reasoners can still derive many entailments that are
>>> certainly correct, but they may miss some entailments that are
>>> produced by the new feature. Moreover, even if the reasoner can
>>> guarantee sound and complete reasoning, an input may violate
>>> constraints of the OWL standard (example: EL reasoners do not care
>>> about regularity of property chain axioms, but OWL EL and DL disallow
>>> them.)
>>>
>>> How should a reasoner plugin for Protege (4.1) behave in such cases?
>>> Here are some options:
>>>
>>> (1) Keep calm and carry on: produce as many results as possible
>>> (2) Panic: throw an exception (terminate, report no results)
>>> (3) Be honest: report "Unknown" (which is a valid return value of OWL
>>> reasoners according to spec) whenever you cannot be sure
>>> (4) Warning: produce whatever results you can get, but warn the user
>>> (5) Mix and match: adopt a different strategy for each concrete
>>> reasoning task and issue, possibly partially based on user
>>> configuration
>>>
>>> I don't know if/how (3) is technically possible at all. For ELK, we
>>> tried to do (4) by printing an error to Standard Error, which ends up
>>> in the command line that Protege is launched from (if any). For most
>>> users, this is like (1) since they do not see/notice the warning. This
>>> is not good, since users are likely to misinterpret the result.
>>>
>>> (2) is not good, at least not in general, since there are too many
>>> unrelated conditions that would require some small or large warning.
>>> Aborting on each little irregularity would not help users.
>>>
>>> (5) is only as good as any of the other strategies could be. In the
>>> worst case, it introduces additional confusion by making seemingly
>>> random default choices that may vary among tools and/or delegates
>>> technical design choices to the user.
>>>
>>> Cheers,
>>>
>>> Markus
>>>
>>
>> _______________________________________________
>> 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
>>
>

_______________________________________________
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: How to report reasoner warnings

Markus Krötzsch
On 15/05/12 15:50, Timothy Redmond wrote:

>
>> That could be useful in general, but may not solve the present problem
>> in many cases, since there are hardly any reasoners that exactly cover
>> one profile. Usually some features are omitted, but it also happens
>> that more features are supported. So referring to a profile would
>> neither work as a lower nor as an upper bound for what a typical
>> reasoner can actually do. Profile support in Protege could still be
>> useful for other purposes though.
>
> Maybe it would help if we designed the profile mechanism so that you
> could create your own?

The definition of what a reasoner can and cannot handle can be very
complex and even implicit (it may only know when it sees it). So I am
not sure how much a custom profile could do.

>
>> Ideally, there should be some mechanism for reasoners to report
>> errors/warnings to Protege users.
>
> I had toyed with the idea that the lower left hand corner of Protege
> could be a message area where plugins would write relevant information.
> There is not much space there though. I think that several plugins could
> use a message capability but I am not sure how it should look in the ui.

Something that could be useful would be a simple log4j appender that
writes to Protege's existing notification panel (the one that shows red
warning signs on exceptions). Plugins could then register this appender
to their own log4j logging levels, and it would even be possible to
configure this behaviour in Protege's log4j configuration. In general,
log4j is a good basis for a global message reporting architecture that
is already used in Protege.

I have now written a log4j appender to show popup windows on (important)
log messages; it will be extended to allow this to be configured ("do
not show this message again"). This is getting application-specific
(what means "this message"?) and may not have a generic solution that
Protege could provide. Also, this can be tricky because Protege is
issuing reasoner queries on window paint events -- so closing an error
popup that is in front of the main window will trigger a new reasoner
call, which may in turn create a new popup. This shows that some care is
needed when using UI elements for reporting logs; similar issues may
occur elsewhere, and not always be apparent immediately since they
depend on the warnings/errors that a plugin sends.

>
>> Maybe there could also be a way to say -- with every answer that the
>> reasoner gives -- whether this result is guaranteed to be sound and/or
>> complete. But this would require more changes to the reasoner
>> interface than a messaging system.
>
> Here we are getting into an OWL api discussion. It would seem sad if
> this capability was only accessible to Protege. The other problem that
> the OWL api (and Protege) bring is that the developers try to be
> conservative about making changes to the API.
>
> I will talk to Matthew today and see what thoughts he has.

Ok. I agree that this would require more changes than might be useful.

Cheers,

Markus

>
> -Timothy
>
>
>
>
>
> On 05/11/2012 01:50 AM, Markus Krötzsch wrote:
>> On 11/05/12 01:39, Timothy Redmond wrote:
>>>
>>> These are difficult questions but I have two small thoughts.
>>
>> Thanks for keeping the thread alive :-)
>>
>>>
>>> First, this situation would be better if Protege had profile support.
>>> Potentially we could somehow make a link between the selected reasoner
>>> and the appropriate profile. I think that making a nice user interface
>>> for profile support is tricky but perhaps we should start passing around
>>> some strawman proposals to see if we can figure out what needs to be
>>> done and how hard it would be.
>>
>> That could be useful in general, but may not solve the present problem
>> in many cases, since there are hardly any reasoners that exactly cover
>> one profile. Usually some features are omitted, but it also happens
>> that more features are supported. So referring to a profile would
>> neither work as a lower nor as an upper bound for what a typical
>> reasoner can actually do. Profile support in Protege could still be
>> useful for other purposes though.
>>
>>>
>>> Second, which option your reasoner takes could be controlled by reasoner
>>> preferences. I have made a plugin for this to allow reasoner developers
>>> to create options for exactly this type of thing. If you created a
>>> reasoner preferences plugin it would show up when the user clicks the
>>> Reasoner->Configure Reasoner dialog. In addition, if you warn the user,
>>> the warning dialog could have a check box for saying don't warn me about
>>> this anymore.
>>
>> Indeed, this is a very useful feature. It also makes the possible
>> choices more visible to Protege users, which already helps to prevent
>> misunderstandings.
>>
>> Ideally, there should be some mechanism for reasoners to report
>> errors/warnings to Protege users. Exceptions currently seem to be the
>> only way for doing this, but they necessarily interrupt the program
>> flow. There already is a facility for relaying information from the
>> reasoner to Protege in the form of the ProgressMonitor. A simple
>> message reporting interface could work in the same fashion (maybe it
>> could even be an extension of the ProgressMonitor interface? two naive
>> methods reportError and reportWarning would suffice for a start; more
>> advanced logging, e.g., with log4j, could always be added later).
>>
>> Maybe there could also be a way to say -- with every answer that the
>> reasoner gives -- whether this result is guaranteed to be sound and/or
>> complete. But this would require more changes to the reasoner
>> interface than a messaging system.
>>
>> Markus
>>
>>>
>>>
>>> On 05/09/2012 02:01 AM, Markus Krötzsch wrote:
>>>> Dear Protege users/developers,
>>>>
>>>> OWL reasoners typically have some limitations in the features they
>>>> support. When encountering an unsupported feature (e.g., a new
>>>> datatype), reasoners can still derive many entailments that are
>>>> certainly correct, but they may miss some entailments that are
>>>> produced by the new feature. Moreover, even if the reasoner can
>>>> guarantee sound and complete reasoning, an input may violate
>>>> constraints of the OWL standard (example: EL reasoners do not care
>>>> about regularity of property chain axioms, but OWL EL and DL disallow
>>>> them.)
>>>>
>>>> How should a reasoner plugin for Protege (4.1) behave in such cases?
>>>> Here are some options:
>>>>
>>>> (1) Keep calm and carry on: produce as many results as possible
>>>> (2) Panic: throw an exception (terminate, report no results)
>>>> (3) Be honest: report "Unknown" (which is a valid return value of OWL
>>>> reasoners according to spec) whenever you cannot be sure
>>>> (4) Warning: produce whatever results you can get, but warn the user
>>>> (5) Mix and match: adopt a different strategy for each concrete
>>>> reasoning task and issue, possibly partially based on user
>>>> configuration
>>>>
>>>> I don't know if/how (3) is technically possible at all. For ELK, we
>>>> tried to do (4) by printing an error to Standard Error, which ends up
>>>> in the command line that Protege is launched from (if any). For most
>>>> users, this is like (1) since they do not see/notice the warning. This
>>>> is not good, since users are likely to misinterpret the result.
>>>>
>>>> (2) is not good, at least not in general, since there are too many
>>>> unrelated conditions that would require some small or large warning.
>>>> Aborting on each little irregularity would not help users.
>>>>
>>>> (5) is only as good as any of the other strategies could be. In the
>>>> worst case, it introduces additional confusion by making seemingly
>>>> random default choices that may vary among tools and/or delegates
>>>> technical design choices to the user.
>>>>
>>>> Cheers,
>>>>
>>>> Markus
>>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>
>


--
Dr. Markus Kroetzsch
Department of Computer Science, University of Oxford
Room 306, Parks Road, OX1 3QD Oxford, United Kingdom
+44 (0)1865 283529               http://korrekt.org/
_______________________________________________
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: How to report reasoner warnings

Yevgeny Kazakov
On Tue, May 15, 2012 at 5:18 PM, Markus Krötzsch
<[hidden email]> wrote:

> On 15/05/12 15:50, Timothy Redmond wrote:
>> I had toyed with the idea that the lower left hand corner of Protege
>> could be a message area where plugins would write relevant information.
>> There is not much space there though. I think that several plugins could
>> use a message capability but I am not sure how it should look in the ui.
>
>
> Something that could be useful would be a simple log4j appender that writes
> to Protege's existing notification panel (the one that shows red warning
> signs on exceptions). Plugins could then register this appender to their own
> log4j logging levels, and it would even be possible to configure this
> behaviour in Protege's log4j configuration. In general, log4j is a good
> basis for a global message reporting architecture that is already used in
> Protege.

Regarding the ui: my concern with the red warning sign in the upper
right corner might not be sufficiently noticeable for the user. A
dedicated panel, similar to the one Eclipse, that shows log4j messages
would be much better, but of course, it might be tricky to find a
space for that. One compromise solution, which I think, should work
OK, at least for reasoners, would be to build this panel into the
"progress monitor" window, where in addition to the progress of
operations one could display log4j messages. It would probably be even
more cleaner if this integrated window can be "minimised" into small
area of the Protege window, again, in a similar way it is done in
Eclipse. This has several advantages, namely: (1) one can monitor
progress of operations without having popup windows at all, so most
operations are un-obstructive, (2) this would encourage the plugin
developers to make more progress monitors: we could add, e.g., a
monitor for property classification, for instance retrieval, etc..
Since these operation are *usually* fast, having pop-up windows to
display the progress would be just annoying, (3) one would always be
able to switch to full log / progress and back with a single click,
and (4) one can have some settings that in case of errors / warnings
this window would be popped up automatically.

One related question (sorry fo hijacking thread): can anyone explain
what is the proper way of catching the "cancel" request from the
Protege progress monitor window? It seems that canceling operations of
existing reasoners does not work at the moment: the progress window
disappears, but the reasoners are still running in the background.

> Also, this can be tricky because Protege is issuing reasoner queries on
> window paint events -- so closing an error popup that is in front of the
> main window will trigger a new reasoner call, which may in turn create a new
> popup. This shows that some care is needed when using UI elements for
> reporting logs; similar issues may occur elsewhere, and not always be
> apparent immediately since they depend on the warnings/errors that a plugin
> sends.

This might indeed be annoying to have repeated warnings/errors when
windows are resized / redrawn. Is it due to some general design
principle of Protege, so that it does not have to cache any results?


Yevgeny
_______________________________________________
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
|

Cancelling reasoners in Protege (Was: How to report reasoner warnings)

Markus Krötzsch
On 16/05/12 11:31, Yevgeny Kazakov wrote:
<snip>
>
> One related question (sorry fo hijacking thread): can anyone explain
> what is the proper way of catching the "cancel" request from the
> Protege progress monitor window? It seems that canceling operations of
> existing reasoners does not work at the moment: the progress window
> disappears, but the reasoners are still running in the background.

Our current understanding is that this request triggers a call to the
OWL API reasoner's interrupt() method. The reasoner should then stop
itself globally (i.e., terminate all reasoning processes that this
reasoner object is running in any thread in the current JavaVM; the
implicit assumption seems to be that every reasoner object only works on
one reasoning operation at any one time, even if it uses many threads
for them).

Markus

--
Dr. Markus Kroetzsch
Department of Computer Science, University of Oxford
Room 306, Parks Road, OX1 3QD Oxford, United Kingdom
+44 (0)1865 283529               http://korrekt.org/
_______________________________________________
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
|

Reasoning during window painting (Was:How to report reasoner warnings)

Markus Krötzsch
In reply to this post by Yevgeny Kazakov
On 16/05/12 11:31, Yevgeny Kazakov wrote:
<snip>

>
>> Also, this can be tricky because Protege is issuing reasoner queries on
>> window paint events -- so closing an error popup that is in front of the
>> main window will trigger a new reasoner call, which may in turn create a new
>> popup. This shows that some care is needed when using UI elements for
>> reporting logs; similar issues may occur elsewhere, and not always be
>> apparent immediately since they depend on the warnings/errors that a plugin
>> sends.
>
> This might indeed be annoying to have repeated warnings/errors when
> windows are resized / redrawn. Is it due to some general design
> principle of Protege, so that it does not have to cache any results?

This behaviour of Protege also leads to some other problems. All OWL API
reasoning methods can throw exceptions (e.g., for timeouts). If a
buffered OWL API reasoner does not accept fresh entities, then Protege
will make many calls that cause FreshEntitiesExceptions. Now due to the
current implementation, these exceptions occur during window paint
activities, thus cancelling the UI painting. The user ends up with a
broken UI that does not display all elements. Protege catches the
exceptions (displaying the red triangle), but too late to complete the
window painting. Any attempt to fully repaint the window leads to new
exceptions.

Since OWLAPI declares all of its exceptions as RuntimeExceptions, it is
easy to miss such problems, of course. I suppose Protege has just
generic Exception catching code somewhere at the top and is not even
aware of the actual OWL API exceptions it causes. So this needs to be
fixed (reasoners that implement the OWL API are required to throw
exceptions in certain cases, so it cannot be avoided that this occurs).

Of course, it would also be good if Protege would generally avoid calls
to the OWL API that cannot be informative and may even (be required to)
throw exceptions. For example, if a reasoner is not synched, then
Protege should not query it about newly created classes that the
reasoner cannot know of (this requires an exception depending on
reasoner configuration).

It is good that Protege lets the reasoner do the caching of reasoning
results (this will typically be more efficient than if Protege would do
it), but maybe it could still cache the appearance of its own GUI so
that it does not need to query the reasoner for re-freshing an unchanged
application window.

Markus

--
Dr. Markus Kroetzsch
Department of Computer Science, University of Oxford
Room 306, Parks Road, OX1 3QD Oxford, United Kingdom
+44 (0)1865 283529               http://korrekt.org/
_______________________________________________
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: Cancelling reasoners in Protege (Was: How to report reasoner warnings)

Yevgeny Kazakov
In reply to this post by Markus Krötzsch
On Thu, May 17, 2012 at 10:15 AM, Markus Krötzsch
<[hidden email]> wrote:

> On 16/05/12 11:31, Yevgeny Kazakov wrote:
> <snip>
>>
>>
>> One related question (sorry fo hijacking thread): can anyone explain
>> what is the proper way of catching the "cancel" request from the
>> Protege progress monitor window? It seems that canceling operations of
>> existing reasoners does not work at the moment: the progress window
>> disappears, but the reasoners are still running in the background.
>
>
> Our current understanding is that this request triggers a call to the OWL
> API reasoner's interrupt() method.

This is what I thought as well, but it does not seem that Protege
calls the reasoner's interrupt() method when the "cancel" button of
the progress monitor is pressed. I recall I was trying to print some
messages to the console inside this method, but nothing seems to be
printed when I press "cancel".
_______________________________________________
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: Reasoning during window painting (Was:How to report reasoner warnings)

Alan Ruttenberg-2
In reply to this post by Markus Krötzsch
You could add an exception handler around each general type of interface element - text field, popup, image, etc that gives a default error contents "error", red circle with x, popup with title "error" etc, or which just changes the background color and leaves everything else alone, and push the exception information into a list to be included in the red box.

At least the window will be coherent and should be able to redraw itself properly after the errors stop happening.

On Thu, May 17, 2012 at 5:28 AM, Markus Krötzsch <[hidden email]> wrote:
On 16/05/12 11:31, Yevgeny Kazakov wrote:
<snip>

Also, this can be tricky because Protege is issuing reasoner queries on
window paint events -- so closing an error popup that is in front of the
main window will trigger a new reasoner call, which may in turn create a new
popup. This shows that some care is needed when using UI elements for
reporting logs; similar issues may occur elsewhere, and not always be
apparent immediately since they depend on the warnings/errors that a plugin
sends.

This might indeed be annoying to have repeated warnings/errors when
windows are resized / redrawn. Is it due to some general design
principle of Protege, so that it does not have to cache any results?

This behaviour of Protege also leads to some other problems. All OWL API reasoning methods can throw exceptions (e.g., for timeouts). If a buffered OWL API reasoner does not accept fresh entities, then Protege will make many calls that cause FreshEntitiesExceptions. Now due to the current implementation, these exceptions occur during window paint activities, thus cancelling the UI painting. The user ends up with a broken UI that does not display all elements. Protege catches the exceptions (displaying the red triangle), but too late to complete the window painting. Any attempt to fully repaint the window leads to new exceptions.

Since OWLAPI declares all of its exceptions as RuntimeExceptions, it is easy to miss such problems, of course. I suppose Protege has just generic Exception catching code somewhere at the top and is not even aware of the actual OWL API exceptions it causes. So this needs to be fixed (reasoners that implement the OWL API are required to throw exceptions in certain cases, so it cannot be avoided that this occurs).

Of course, it would also be good if Protege would generally avoid calls to the OWL API that cannot be informative and may even (be required to) throw exceptions. For example, if a reasoner is not synched, then Protege should not query it about newly created classes that the reasoner cannot know of (this requires an exception depending on reasoner configuration).

It is good that Protege lets the reasoner do the caching of reasoning results (this will typically be more efficient than if Protege would do it), but maybe it could still cache the appearance of its own GUI so that it does not need to query the reasoner for re-freshing an unchanged application window.

Markus

--
Dr. Markus Kroetzsch
Department of Computer Science, University of Oxford
Room 306, Parks Road, OX1 3QD Oxford, United Kingdom
<a href="tel:%2B44%20%280%291865%20283529" value="+441865283529" target="_blank">+44 (0)1865 283529               http://korrekt.org/
_______________________________________________
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


_______________________________________________
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