Elk plans?

[Chris Mungall]

Hi all,

Are there plans for a future Elk release?

What more could possibly be added? Elk is already fabulous, one feels guilty asking for more.

But just supposing, how hard would it be to have:

1. support for ObjectPropertyDomain

2. coordination with Protege such that we don't get those dialog boxes all the time

3. support for reasoner.getObjectPropertyValues

I'm tempted to write a reasoner that wraps elk to support these, possibly in a kludgy incomplete way. But I wouldn't bother doing this if support for this was planned in the near future.

[Yevgeny Kazakov]

Hi Chris,

On Sat, Jan 18, 2014 at 11:47 PM, Chris Mungall <cjmu...@lbl.gov> wrote:
> Hi all,
>
> Are there plans for a future Elk release?

Yes, we are currently extending Elk with new features (datatypes and
explanation support are in works). But we do not expect any new
release very soon, unless some major bugs need to be fixed urgently.

>
> What more could possibly be added? Elk is already fabulous, one feels guilty
> asking for more.
>
> But just supposing, how hard would it be to have:
>
> 1. support for ObjectPropertyDomain

I guess you mean ObjectPropertyRange because ObjectPropertyDomain
should be supported:

https://code.google.com/p/elk-reasoner/wiki/OwlFeatures

Regarding ObjectPropertyRange, this feature currently does not fit
very well in the current reasoner model (it is a bit technical to
explain).
Do you expect many inferences that use ObjectPropertyRange?

> 2. coordination with Protege such that we don't get those dialog boxes all
> the time

Unfortunately Protege does not currently have a good mechanism for
error reporting and cannot recover very well from unsupported
exceptions
(legally) thrown by OWL API methods. That's why we had to implement
all those dialog boxes to let the user know what is going on and what
to do about it.

An alternative solution would be to silently ignore all problems and
implement all unsupported OWL API methods in some default way
(essentially producing incorrect results). But we afraid this will
cause lots of confusions. Previously we had ELK to only print messages
in the console, but not many users run Protege from the command line
to see those warning. We had some users mistakingly reporting about
missing inferences when we had it in this way.

Of course we can easily add a setting which can disable all those
dialog messages permanently, but again, it is very easy to forget that
all warnings are disabled. That's why, as a compromise, we offer to
disable a particular type of warnings within a current session, but if
you have a better idea how to approach this problem, please let us
know!

Which particular dialogs causes the most problems for you?

> 3. support for reasoner.getObjectPropertyValues
>
> I'm tempted to write a reasoner that wraps elk to support these, possibly in
> a kludgy incomplete way. But I wouldn't bother doing this if support for
> this was planned in the near future.

We did not add any property reasoning methods so far (so even
computing object property hierarchy and checking consistency of object
properties is not supported yet). Once we have a proper infrastructure
for this in place (classification of object properties), we can look
into more advanced reasoning tasks, such as computation of property
values and property ranges.

Before that, please create tickets for your feature requests here:

https://code.google.com/p/elk-reasoner/issues/list

This way, we can track various user requests and prioritize them accordingly.

Best regards,

Yevgeny

[Chris Mungall]

On Mon, Jan 20, 2014 at 10:27 AM, Yevgeny Kazakov <yevgeny...@uni-ulm.de> wrote:

Hi Chris,

On Sat, Jan 18, 2014 at 11:47 PM, Chris Mungall <cjmu...@lbl.gov> wrote:
> Hi all,
>
> Are there plans for a future Elk release?

Yes, we are currently extending Elk with new features (datatypes and
explanation support are in works). But we do not expect any new
release very soon, unless some major bugs need to be fixed urgently.

OK, great, thanks

 

>
> What more could possibly be added? Elk is already fabulous, one feels guilty
> asking for more.
>
> But just supposing, how hard would it be to have:
>
> 1. support for ObjectPropertyDomain

I guess you mean ObjectPropertyRange because ObjectPropertyDomain
should be supported:

Yes, sorry, that's what I meant.

 

https://code.google.com/p/elk-reasoner/wiki/OwlFeatures

Regarding ObjectPropertyRange, this feature currently does not fit
very well in the current reasoner model (it is a bit technical to
explain).
Do you expect many inferences that use ObjectPropertyRange?

Mostly for basic quality control with high level relations - e.g. the range of "occurs in" is some kind of material entity, we want to make sure people don't accidentally use it with a process as range.

Generally we get more out of using GCIs and disjointness axioms as constraints, and we can have a transform for our ranges. E.g.

(occurs_in some process) EquivalentTo Nothing

So it's more a matter of convenience.

 

> 2. coordination with Protege such that we don't get those dialog boxes all
> the time

Unfortunately Protege does not currently have a good mechanism for
error reporting and cannot recover very well from unsupported
exceptions
(legally) thrown by OWL API methods. That's why we had to implement
all those dialog boxes to let the user know what is going on and what
to do about it.

An alternative solution would be to silently ignore all problems and
implement all unsupported OWL API methods in some default way
(essentially producing incorrect results). But we afraid this will
cause lots of confusions. Previously we had ELK to only print messages
in the console, but not many users run Protege from the command line
to see those warning. We had some users mistakingly reporting about
missing inferences when we had it in this way.

Of course we can easily add a setting which can disable all those
dialog messages permanently, but again, it is very easy to forget that
all warnings are disabled. That's why, as a compromise, we offer to
disable a particular type of warnings within a current session, but if
you have a better idea how to approach this problem, please let us
know!

Which particular dialogs causes the most problems for you?

All of them!

Yep, I understand that you need to warn about the missing inferences.

Maybe this is more of a protege request, to remember settings between sessions.

I suppose it wouldn't be hard for us to build a special purpose jar that hides these warnings, we would use this jar in our projects, knowing full well that answers may be incomplete.

Sounds like it's not worth you worrying about though.

> 3. support for reasoner.getObjectPropertyValues
>
> I'm tempted to write a reasoner that wraps elk to support these, possibly in
> a kludgy incomplete way. But I wouldn't bother doing this if support for
> this was planned in the near future.

We did not add any property reasoning methods so far (so even
computing object property hierarchy and checking consistency of object
properties is not supported yet). Once we have a proper infrastructure
for this in place (classification of object properties), we can look
into more advanced reasoning tasks, such as computation of property
values and property ranges.

OK, great

 

Before that, please create tickets for your feature requests here:

https://code.google.com/p/elk-reasoner/issues/list

This way,  we can track various user requests and prioritize them accordingly.

I will do, thanks.

 

Best regards,

Yevgeny

[Yevgeny Kazakov]

OK, I see.
To prevent using a "process" as a range of "occurs_in", this should
probably work, but what if somebody use "occurs_in" with some new
class, for which you do not have similar disjointness axioms?
I think a safer solution would be to check externally if, e.g., all
fillers of property restrictions with this property are indeed
sub-classes of the range.
I recall, in Galen ontology there was a similar mechanism using
"sanctions", which basically say that a property can only be used with
some particular classes as domains and ranges (e.g., "part-of" can be
either a relation between anatomical structures, or between, say
ingredients and drugs). Then a classifier was used to check if each
"part-of" was used for one of these valid situations. E.g., if there
was an axiom A part-of B then it was checked whether both A and B are
subclasses of anatomical organs, or wether A is a subclass of
ingredients and B is a subclass of drug, etc. If neither of these was
the case, the editor would return an error.

The settings can be remembered between the sessions, no problems. ELK
does that already for remembering the number of workers and
incremental reasoning option (specifically in the file
~/.Protege/org.semanticweb.elk/elk.properties). So we could, in
principle, add there an option to disable all warning messages in
Protege -- but this would solve only half of the problem, one has to
do something about non-supported OWL API methods which Protege calls
and gets runtime exceptions.

But we are also concerned that disabling warnings permanently could
cause some misunderstanding, where the users could expect some results
which are not produced by ELK (the users could easily forget that they
disabled all warnings long time ago). We could try to add this as a
"hidden" configuration option (set in the file but not in the menu),
and see if that works well for you.

>
> I suppose it wouldn't be hard for us to build a special purpose jar that
> hides these warnings, we would use this jar in our projects, knowing full
> well that answers may be incomplete.
>
> Sounds like it's not worth you worrying about though.
>
>>
>> > 3. support for reasoner.getObjectPropertyValues
>> >
>> > I'm tempted to write a reasoner that wraps elk to support these,
>> > possibly in
>> > a kludgy incomplete way. But I wouldn't bother doing this if support for
>> > this was planned in the near future.
>>
>> We did not add any property reasoning methods so far (so even
>> computing object property hierarchy and checking consistency of object
>> properties is not supported yet). Once we have a proper infrastructure
>> for this in place (classification of object properties), we can look
>> into more advanced reasoning tasks, such as computation of property
>> values and property ranges.
>
>
> OK, great
>
>>
>> Before that, please create tickets for your feature requests here:
>>
>> https://code.google.com/p/elk-reasoner/issues/list
>>
>> This way, we can track various user requests and prioritize them
>> accordingly.
>
>
> I will do, thanks.

Thanks, we look forward for your tickets!

Yevgeny

>
>>
>> Best regards,
>>
>> Yevgeny
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "elk-reasoner-discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to elk-reasoner-disc...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Chris Mungall]

On Tue, Jan 21, 2014 at 9:27 AM, Yevgeny Kazakov <yevgeny...@uni-ulm.de> wrote:

OK, I see.
To prevent using a "process" as a range of "occurs_in", this should
probably work, but what if somebody use "occurs_in" with some new
class, for which you do not have similar disjointness axioms?

yes, the pattern works better for upper-level classes (for which in theory

it should be possible to place all classes in your ontology)

 

I think a safer solution would be to check externally if, e.g., all
fillers of property restrictions with this property are indeed
sub-classes of the range.
I recall, in Galen ontology there was a similar mechanism using
"sanctions", which basically say that a property can only be used with
some particular classes as domains and ranges (e.g., "part-of" can be
either a relation between anatomical structures, or between, say
ingredients and drugs). Then a classifier was used to check if each
"part-of" was used for one of these valid situations. E.g., if there
was an axiom A part-of B then it was checked whether both A and B are
subclasses of anatomical organs, or wether A is a subclass of
ingredients and B is a subclass of drug, etc. If neither of these was
the case, the editor would return an error.

This is probably the more common scenario for us.

This results in the red triangle (that everyone ignores)?

 

But we are also concerned that disabling warnings permanently could
cause some misunderstanding, where the users could expect some results
which are not produced by ELK (the users could easily forget that they
disabled all warnings long time ago).  We could try to add this as a
"hidden" configuration option (set in the file but not in the menu),
and see if that works well for you.

That would be wonderful.

Let me check with some users (I am not a typical Protege user, I do more at the api/command line) but I suspect this would be popular, and people would use it wisely.

[Yevgeny Kazakov]

Dear Chris,

sorry for resurrecting a very old thread. Recently we made a few changes in ELK, some of which are related to the requests in this post. In particular, ELK now supports ObjectPropertyRanges and it is now possible to permanently suppress (all or selected) ELK warnings (but still see information about them in ELK settings menu: Preferences > Reasoner > ELK). I would appreciate if you could try the attached version of ELK (works best with Protege 5 beta) and tell us how it works for you.

Best regards,

Yevgeny

[Chris Mungall]

Thanks Yevgeny! This seems to work very well.

I went into the Preferences > Reasoner > Elk > Warnings and selected
"suppress all warnings". I then loaded my ontology and started Elk; the
usual warning popups had vanished, great.

However, on selecting a class it gave me a popup complaining about not
having getBottomProperty implemented. I checked the box not to be warned
of this again. I quit Protege, restarted, and I am now unable to
reproduce, so not sure if this was a temporary glitch, or it has
remembered my selection. Either way the end result is good for me.

(This is Protege 5 beta build 17 on OS X).

I'll keep using this version of Elk in my Protege setup and let you know
if I see anything unusual (we're still using Elk 0.4.x in our production
builds).

> --
> You received this message because you are subscribed to the Google
> Groups "elk-reasoner-discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to elk-reasoner-disc...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.
>
> [elk-distribution-0.5.0-SNAPSHOT-15-05-15-protege-plugin.zip]

[Yevgeny Kazakov]

Hi Chris,

On Fri, May 15, 2015 at 4:21 PM, Chris Mungall <cjmu...@lbl.gov> wrote:
> Thanks Yevgeny! This seems to work very well.
>
> I went into the Preferences > Reasoner > Elk > Warnings and selected
> "suppress all warnings". I then loaded my ontology and started Elk; the
> usual warning popups had vanished, great.
>
> However, on selecting a class it gave me a popup complaining about not
> having getBottomProperty implemented. I checked the box not to be warned of
> this again. I quit Protege, restarted, and I am now unable to reproduce, so
> not sure if this was a temporary glitch, or it has remembered my selection.
> Either way the end result is good for me.

Hm... strange. The checkbox should disable all warnings. I tried to
reproduce what you describe after reseting all preferences, but I was
not able to. Let me know if it happens to you again!
The preferences are now be saved as standard Protege preferences, so
they should persist after restarting Protege.

>
> (This is Protege 5 beta build 17 on OS X).

The next version of Protege should also deal properly with exceptions
about unsupported OWL API methods, so you should not see the red
triangle in the right upper corner (I submitted a patch for that).

>
> I'll keep using this version of Elk in my Protege setup and let you know if
> I see anything unusual (we're still using Elk 0.4.x in our production
> builds).

You might also try the new setting for auto-synchronization: if
checked, ELK updates the results immediately after changes, no need to
select Reasoner > Synchronise reasoner. I am particularly interested
if runs smoothly in your case, i.e., without any significant delays /
freezes or other glitches.

Best regards,

Yevgeny

> You received this message because you are subscribed to a topic in the
> Google Groups "elk-reasoner-discussion" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/elk-reasoner-discussion/Yp_1UKheL0M/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to