Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inferred axioms not updated for non-buffering reasoner #128

Closed
ykazakov opened this issue Feb 21, 2015 · 4 comments
Closed

Inferred axioms not updated for non-buffering reasoner #128

ykazakov opened this issue Feb 21, 2015 · 4 comments

Comments

@ykazakov
Copy link
Contributor

We are trying to enabling automatic background reclassification for the ELK reasoner in Protege using the ELK incremental reasoning facility. For this, we created an experimental build [1] in which we set getRecommendedBuffering() to BufferingMode.NON_BUFFERING in the implementation of ProtegeOWLReasonerInfo. All seems to work as expected except that the inferences are not (immediately) refreshed after changes. I tried Protege 5 beta 15 and the build from the current master (beta 16).

To reproduce the issue do the following:

  1. copy the ELK jar [1] to the Protege' plugins directory and start Protege
  2. create a new ontology with:
  3. class "A",
  4. class "B" subclass of "A",
  5. object property "r"
  6. defined class "rSomeA" = "r some A"
  7. defined class "rSomeB" = "r some B"
  8. Start ELK reasoner from the Reasoner menu
  9. open class "rSomeB" in the class hierarchy (the one that is not "inferred")
    Protege correctly shows that "rSomeB" has an inferred subclass of "rSomeA" (yellow entry under "SubClass Of" in the panel "Description: rSomeB")
  10. now remove the definition for "rSomeB" (press on "x" next to the "Equivalent to" entry)

EXPECTED: The inferred subclass entry should disappear
ACTUAL: The inferred subclass entry remains visible

Further Observation: if after that to click on another class in the class hierarchy panel, say class "A" and then switch back to "rSomeB", the description will be updated and the inferred subclass entry will disappear.

Suggested behaviour: I think Protege should perform all updates of the UI that are normally performed when calling "Synchronise reasoner" from the Reasoner menu for buffering reasoners when the ontology is out of sync. In my understanding, if the reasoner uses non-buffering mode, the reasoner should be "synchronised" automatically after every change made with the ontology, i.e., whenever the "ontology is out of sync" is detected.

B.t.w., is there any way to switch the buffering mode of the reasoner within Protege?

[1] https://www.dropbox.com/s/fi5ycgr9ic2oeip/org.semanticweb.elk.jar?dl=0

Best regards,

Yevgeny

@ykazakov
Copy link
Contributor Author

A small update:
I have noticed that a similar problem takes place already with the "show inferences" check box. When it is checked or unchecked the inferences for the selected class are not refreshed (see the screenshot). If to click somewhere else in the editor and then return to the selected class, the inferences will be refreshed. This issue does not seem to depend on a reasoner (or its buffering mode): I tried HermiT, the result was identical.

screen shot 2015-02-22 at 21 51 43

@ykazakov
Copy link
Contributor Author

Created a separate issue #131 for the problem with the checkbox.

@matthewhorridge
Copy link
Contributor

@ykazakov I'm trying to clean things up. Do you know if this issue is stale or resolved?

@matthewhorridge matthewhorridge added the Status: Waiting for Feedback Indicates that the person who is working on the issue needs feedback from someone else label Jan 15, 2019
@ykazakov
Copy link
Contributor Author

I think this issue was fixed #130. I do not notice any problems for non-buffering mode of ELK any more.

@matthewhorridge matthewhorridge removed the Status: Waiting for Feedback Indicates that the person who is working on the issue needs feedback from someone else label Jan 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants