-
Notifications
You must be signed in to change notification settings - Fork 1
Working with counterexample and model generators
The small model generator generates an ontology model trying to reduce the number of successors created for existential restrictions. The reduction is obtained by reusing existing individuals as successors. The generator constructor takes the following arguments:
- boolean
treeModel. If its value is set totrue, the function of reusing individuals will be disabled. - Set<OWLIndividualAxiom>
avoidedEntailments. Since the generator reuses individuals as successors, the model may satisfy assertions that do not necessarily follow from the ontology. Thus, this argument can be used to set assertions that should not be in the model. - int
maxDepth. WhentreeModelis set totrue, in order to obtain termination, the maximum depth of generated trees may be limited. By default, the maximum depth is 10.
This generator implements the IOWLModelGenerator interface containing the setOntology and generateModel methods, whose function is intuitive. However, the interface also contains the getMarkedIndividuals method which returns Set<IRI>. In the case of the small model generator, the marked individuals will be those already present in the ontology and not created by the generator.
It is also important to note that the generator supports only the description logic EL as well as the bottom concept. All more expressive axioms from the ontology are ignored by the generator. The generator also supports progress trackers. An instance of a class implementing IHasProgressTracker can be passed as a constructor argument when creating a small model generator.
All currently available counterexample generation services inherit from the AbstractCounterexampleGenerationService class found in the de.tu_dresden.inf.lat.evee.protege.core.counterexample package. This abstract class performs all functionality common to all services. In fact, the different services differ mainly in the counterexample generator used, which is set using the setCounterexampleGenerator method in their class constructors.
However, if desired, some other things can be changed in classes inherited from AbstractCounterexampleGenerationService without rewriting the methods of the abstract class. For example, one can set the message displayed next to the "Generate Explanation" button using the setSupportsExplanationMessage method.
Like other explanation generation services, AbstractCounterexampleGenerationService implements the INonEntailmentExplanationService<OWLIndividualAxiom> interface and implements all of its methods, including setSignature, setOntology, computeExplanation and getResult. Implementation of the setOntology method creates a working copy of the ontology and passes it to the used counterexample generator using its setOntology method. The creation of a copy is necessary because in the process of interacting with the graphical representation of the model, the user can add disjointness axioms to the ontology and see changes in the model. To avoid changes in the active ontology and possible errors, these axioms will be added to the working copy.
When executing the computeExplanation method, we use SwingWorker to perform the computation in a separate thread and not block the UI. This method creates a so-called InteractiveGraphModel, which encapsulates 3 components:
- graphical model. Graphical representation of the generated counterexample.
- control panel. A graphical user interface that allows to interact with the model.
- the counterexample itself, which is a set of OWLIndividualAxiom, and the functionality needed to recompute or refresh the counterexample.
The interactive graphical model is a key concept of the counterexample generation service and is described in detail in the next chapter. The InteractiveGraphModel class is located in the de.tu_dresden.inf.lat.evee.protege.core.counterexample package. Two control panel implementations (ControlPanel and SimpleControlPanel) as well as the GraphModelView are in the de.tu_dresden.inf.lat.lat.evee.protege.core.counterexample.ui package.
All classes listed here implement the IInteractiveComponent interface. Conceptually, all classes implementing IInteractiveComponent encapsulate some Swing component as well as some additional functionality (various click listeners, methods of model recalculation or any other functions). This interface has one single method, toComponent, which is used to obtain the swing component that is encapsulated.
Now, returning to AbstractCounterexampleGenerationService, we can describe how the implementation of the getResult method works. After the InteractiveGraphModel is obtained using the computeExplanation method, the getResult method obtains its graphical content using the toComponent method.
The InteractiveGraphModel constructor takes quite a few arguments and we need to describe them in detail.
-
CounterexampleGenerator. Used to generate a counterexample as a set of axioms. -
GraphViewService. Used to obtain a graphical representation of a counterexample that is a set of axioms. - ontology. Since an
InteractiveGraphModelcan recalculate a counterexample and add axioms, it needs an ontology. - observation. Required for some checks. For example, ontology consistency
GraphViewGenerator, which we use to obtain a graphical representation of the model, is implemented using GraphStream. GraphStream is a Java library for the modeling and analysis of dynamic graphs. Our generator implements the IGraphViewService interface which has 2 methods: computeView and doPostProcessing. The computeView method is used directly to obtain the graphical model. The method returns an IGraphView that extends the already described IInteractiveComponent interface, which has one method toComponent, and adds the setControlPanel method, which is used to link to the control panel.
The doPostProcessing method of IGraphViewService is necessary due to the nature of the framework used. When creating other classes that implement the interface IGraphViewService, which can use other frameworks, this method is not required to be implemented since it has a default implementation.
The most important thing when creating new graph view services is the implementation of the computeView method. The returned view can have any functionality and interact in any way with any implementation of the control panel. As an argument, the method needs only a model represented as a set of axioms
Our implementation of the service is called GraphViewGenerator and we called the generated IgraphView as GraphModelView. We designed them so that the generated graphical representation could convey information about the selected element to the control panel when the user clicks on the element with the mouse.
When the InteractiveGraphModel constructor is called, first a model representing a set of axioms is created using the counterexample generator. Then, this model is used as an argument to the computeView method of the GraphViewGenerator and thus a graphical model is obtained. In the same way, a control panel is created and the setControlPanel method is used to link them together. Thus, after creation InteractiveGraphModel already has a ready graphical component, which can be obtained using the method toComponent.
Next, we describe how the two graphical components interact. Afterwards, we describe how the model is recalculated and new axioms are added to the ontology when the corresponding buttons on the control panel are pressed.
As mentioned earlier, graphical components interact in the following way: when a user clicks on a node on the graphical model, the control panel displays a list of classes to which the individual corresponding to this node belongs. Our control panel implements the IGraphModelControlPanel interface, which, among other things, contains methods for modifying the content displayed on it. For example, refreshSelectedClasses, which takes a collection of classes as an argument and displays this collection in the list of selected classes. This is the method that is used by GraphModelView when a graph node is clicked. GraphModelView has a mouse listener that has a setNodeSelectionEventSink method to set the sink for mouse pressed events. When a control panel is paired with the model view, this method is called and the control panel is set as the sink.
Now we describe how actions are performed when buttons on the control panel are pressed. The encapsulating other components InteractiveGraphModel implements the ICounterexampleGenerationEventListener interface, containing methods such as onModelRefreshed and onModelRecomputed. When a control panel is created, InteractiveGraphModel is registered as a listener. Then, when the buttons are clicked, it receives the appropriate event and executes methods (onModelRefreshed or onModelRecomputed) depending on which button is pressed.
Various components of InteractiveGraphModel are designed so that, if necessary, they can be replaced by other implementations of their interfaces with minimal adaptation of other components. In the following we consider several possible scenarios for the substitution of some components with new implementations. Except the last described case, we assume that when certain components are replaced, a new counterexample generation service is created. This service should inherit from AbstractCounterexampleGenerationService and rewrite some of its methods.
If a new counterexample generator is needed, it can simply be set using the setCounterexampleGenerator method in the newly created service inheriting AbstractCounterexampleGenerationService.
In order to use InteractiveGraphModel methods such as onModelRefreshed and onModelRecomputed, a new control panel implementation must have InteractiveGraphModel as ICounterexampleGenerationEventListener and implement the IGraphModelControlPanel interface. Then, when these methods need to be called, the new control panel calls methods onModelRefreshed or onModelRecomputed of IGraphModelControlPanel, giving itself as a 'source' argument.
In order to interact with an existing GraphModelView, the new control panel implementation must be set in it using the setControlPanel method. Then, when an element in the graphical model is selected, the refreshSelectedClasses method in the new control panel will be called.
In this case it is needed to create a class that implements IGraphViewService and then use an instance of this class as an argument when creating the InteractiveGraphModel. Any IGraphViewService implementation implements the computeView method, which generates an IGraphView, which is a graphical representation of the model.
The IGraphView interface contains a setControlPanel method. The implementation of this method can be empty if no interaction between new graphical representation of the model and the control panel is intended. Otherwise, the control panel that is an argument to this method can be stored as a variable. Further, any control panel methods can be called from within the graphical representation of the model, e.g. refreshSelectedClasses.
Using ELSmallModelGenerator in combination with GraphViewGenerator in any plugin that requires model visualization is very simple: one needs to use ELSmallModelGenerator to obtain the ontology model as a set of axioms, and then use it as an argument to the computeView method. From the resulting GraphModelView one can get the swing component using the toComponent method.
The resulting component, which is a graphical representation of the model, can then be embedded in any graphical interface. After obtaining the component, we recommend calling the doPostProcessing method of the GraphViewGenerator. By calling this method, the model elements will stop arbitrary movement caused by the autolayout algorithm used in the GraphStream.