Abstract

As abduction is getting more attention in the world of ontologies, multiple abduction solvers for description logics (DL) have been developed. So far, however, there was no attempt for a unified API that would facilitate the integration of diferent DL abduction solvers in an application, in the way e.g. the OWL API does it for deductive OWL reasoning systems. In order to fill this gap, we abstract the common functionalities of diferent DL abduction solvers and introduce the DL Abduction API.

Keywords

• abduction
• description logics
• ontologies
• software engineering

-

API for DL

1. Introduction

Abduction, stemming from the ideas of Peirce [ 1 ], is a reasoning task to provide hypothetical explanations of why some observations of a modelled phenomenon are not supported by deductive entailments of a knowledge model of the phenomenon. Specifically in DL, given a knowledge base and an observation in form of a set of axioms s.t. ⊧ ̸ , we are looking for explanations in form of sets of axioms ℰ that one can add to to support , that is, for which ∪ ℰ ⊧ [ 2 ]. For example, consider a knowledge base :

Mother ⊔ Father ⊑ Parent

Parent ⊑ Happy

Person(Jack),

Parent(Jill)

We may explain the observation 1 = {Happy(jack)} by any of the following explanations: ℰ1 = {Mother(jack)}, ℰ2 = {Father(jack)}, ℰ3 = {Parent(jack)}.

Depending on the type of axioms which are allowed in , and for which we are looking in ℰ, we distinguish ABox abduction (as in our example above) which looks for explanations on the data level, i.e. providing explanations as ABox axioms [ 3, 4, 5, 6 ].

In turn, TBox abduction looks for explanations on the conceptual level, i.e. providing explanations as TBox axioms [ 7, 8, 9 ]. Assume again be explained by ℰ4 = {Parent ⊑ Person}. as above, then 2 = {Mother ⊑ Person} may nEvelop-O LGOBE https://dai.fmph.uniba.sk/~homola/ (M. Homola); https://lat.inf.tu-dresden.de/~koopmann/ (P. Koopmann);

More generally, knowledge base abduction is not constrained to ABox or TBox axioms [ 10, 2 ]. For instance, 1 may also be explained w.r.t. by ℰ5 = {loves(jack, jill), Parent ⊑

Person, ∃loves.Person ⊑ Happy}.

The definition of abduction outlined above provides the basic semantic framework for establishing what is an explanation of a given problem. On the other hand, if one does not further constrain possible explanations, there may be too many. In fact, due to the monotonicity of standard DL, if there is one explanation, then there are already infinitely many in the general sense. Explanations are therefore often constrained to be minimal. This may be either considered in a syntactic sense (subset minimal), e.g. all ℰ1–3 are subset minimal explanations of 1 while on the other hand ℰ6 = {{Parent(jack), {Person(jack)} is not, as ℰ3 ⊊ ℰ6 is smaller.

Or in a more refined semantic sense where only semantically weakest 1 explanations are considered [ 2 ], e.g. out of ℰ1–3, only ℰ3 is semantically minimal, as ∪ℰ 1 ⊧ ℰ3 and ∪ℰ 2 ⊧ ℰ3, but not the other way around.

Other relevant constraints which are almost always assumed are consistency ( ∪ ℰ is consistent), relevance (ℰ ⊧ ̸ ), and explanatoriness ( ⊧ ̸ ). However, depending on the application, diferent additional constraints may be useful, e.g. solipsisticity (ℰ only contains individuals from ). All explanations illustrated above are consistent, relevant and explanatory, and all but ℰ5 are also solipsistic. For more details refer to Elsenbroich et al. [ 2 ].

Another way how to constrain the explanations – and thus the search space for the abduction reasoner – is by constraining the set of expressions that could possibly become explanations. This is done by specifying the abducibles. Here, abducibles may either refer to a restricted set of axioms of which the explanation has to be a subset [ 12, 13 ], or to a restricted signature of individual, concept and role names [ 14, 4 ], in which case there is still an unbounded set of axioms that can be used in an explanation. Indeed, given a particular application, the user may only be interested in explanations involving a certain specific set of concepts, roles or individuals. If such constraints are known beforehand, it may significantly improve the reasoner’s running time, but they can also impact the computational complexity of abduction negatively [ 4 ].

Abduction in DL has a number of interesting applications, e.g. ontology debugging and support for test-driven ontology development [ 15 ], manufacturing control [ 16 ], medical diagnosis [ 17 ], multimedia interpretation [ 11 ], ontology repair [ 9 ] and explaining missing entailments [ 18, 14, 13 ].

A number of DL abduction solvers have been developed, including the works of Du et al. [ 12 ], Del-Pinto and Schmidt [ 19, 20 ], Pukancová and Homola [ 21 ], and Homola et al. [ 22 ], and Koopmann et al. [ 10 ]. Each of the solvers provides its own interface to the user (most often a command-line interface).

To our best knowledge, there was no attempt so far to specify a unified API interface, that could be used to integrate one of the solvers into an application that needs to use abductive reasoning – much in the fashion of how the popular OWL API [ 23 ] covers this task for deductive reasoning.

We propose the DL Abduction API with the aim to fill this gap. Similarly to the OWL API, it is implemented in Java. Once an abduction solver implements the API, any Java application can easily integrate it to compute answers for abduction problems over ontologies. The API 1Depending on the application, in some cases semantically strongest explanations may be preferred [ 11 ]. encapsulates the most common abduction inputs such as the input ontology, observations and abducibles, and includes switches for other common options. As most of the inputs and outputs are in fact OWL ontologies, axioms, and symbols, the OWL API is used for their handling, conveniently for developers already acquainted with it.

2. Abduction Solvers

A DL abduction solver needs to process inputs and provide outputs. We have analyzed several stand-alone solvers (mainly AAA [ 21 ], MHS-MXP [ 22, 24 ], and LETHE [ 10, 4 ]), and herein we summarize their main common characteristics: Input ontology: Also called background knowledge, this is usually specified as a set of DL axioms in form of an OWL ontology.

Observations: Some solvers support observations that are single axioms [ 20, 7 ], while others support observations that consist of several axioms [ 21, 10 ].

Abducibles: The simplest approach is to specify abducibles by giving a set of abducible axioms.

Hypotheses are then generated by picking appropriate subsets of the given set of abducible axioms [ 24 ]. In contrast, in signature-based abduction, abducibles are provided in form of a set of concept and role names, so that hypotheses are required to only use those abducible names provided, but can combine those names to build respective axioms [ 21, 24 ], including possibly complex ones [ 10 ] in arbitrary ways. Finally, approaches like [ 21, 24 ] allow to give further constraints on the shape of the axioms in addition to the signature restriction, for example by allowing loops in role assertions, allowing only concept names rather than complex concepts, or only allowing concepts of the form and ¬ for an atomic concept .

Outputs: Each abduction solver computes one or several solutions, called hypotheses or explanations, which usually consist of a single axiom or a set of axioms. For some approaches, the space of solutions is potentially infinite, or can at least get very large [ 4 ], and the computation of solutions can potentially take a long time.

In addition to these, even if the proposed API is very broad in trying to incorporate all possible features, there might always be some additional internal settings and debug outputs and it might be desired to allow these to be handled by the API in a solver specific format. Thus, an API for DL abduction needs to address the following challenges: • find a uniform way of representing abducibles, while supporting the diferent types of abducibles each solver may support; • not only specify abducibles by means of axiom sets or signatures, but also allow to give specific restrictions on the syntactic shape; • be flexible regarding the shape of axioms allowed in observations and explanations: in TBox abduction, those are restricted to be TBox axioms; in ABox abduction, they have to be ABox axioms, and finally, in KB abduction, there is no restriction at all; • deal with potentially long computation times; • deal with potentially large to infinite solution sets.

3. DL Abduction API

We implemented the proposed DL Abduction API in Java using OWL API [ 23 ]. A UML class diagram of the central classes and interfaces is shown in Figure 1. In order to support the API with their abduction library, developers have to implement the interfaces A b d u c t i o n M a n a g e r , A b d u c i b l e C o n t a i n e r and A b d u c t i o n M a n a g e r A n d A b d u c i b l e C o n t a i n e r F a c t o r y . The A b d u c t i o n M a n a g e r handles the main abduction process: here one specifies background knowledge, the observation and abducibles, and starts the abduction process. Since the computation of hypotheses can take time, it is possible to use the abduction manager in an asynchronous manner. For this, the user registers an abduction M o n i t o r , which receives the hypotheses from the abduction manager once they are computed. For the abducibles, we ofer a range of settings restricting the shape of axioms that can be used in the explanation. This is managed by A b d u c i b l e C o n t a i n e r , which stores information about abducible axioms, abducible signatures, and additional properties on the shape of axioms. To deal with the diferent types of axioms that are allowed in the abducibles, explanations and hypotheses, we use generic types, which allow to parametrize the type for instance to only allow for TBox axioms as explanations and observations.

In the following, we illustrate the usage of the API step-by-step, where for simplicity, we do not showcase the use of generics.

3.1. Basic Initialization

To instantiate A b d u c t i o n M a n a g e r and A b d u c i b l e C o n t a i n e r , the user uses the interface A b d u c t i o n M a n a g e r A n d A b d u c i b l e C o n t a i n e r F a c t o r y as implemented by the respective abduction library. The initialization is as follows: A b d u c t i o n M a n a g e r A n d A b d u c i b l e C o n t a i n e r F a c t o r y a b d u c t i o n F a c t o r y = new A b d u c t i o n M a n a g e r A n d A b d u c i b l e C o n t a i n e r F a c t o r y I m p l ( ) ; A b d u c t i o n M a n a g e r a b d u c t i o n M a n a g e r

= a b d u c t i o n F a c t o r y . c r e a t e A b d u c t i o n M a n a g e r ( ) ; A b d u c i b l e C o n t a i n e r a b d u c i b l e C o n t a i n e r

= a b d u c t i o n F a c t o r y . c r e a t e A b d u c i b l e C o n t a i n e r ( ) ; a b d u c t i o n M a n a g e r . s e t A b d u c i b l e s ( a b d u c i b l e C o n t a i n e r ) ;

We then use the A b d u c t i o n M a n a g e r instance to configure the background ontology w.r.t. which we will perform the abduction task. The ontology is initialized and loaded via OWL API via an O W L O n t o l o g y M a n a g e r instance and it is loaded from an IRI.

OWLOntologyManager man = OWLManager . createOWLOntologyManager ( ) ; I R I b g O I R I = I R I . c r e a t e ( ” h t t p : / / e x a m p l e . o r g / o n t o l o g y ” ) ; OWLOntology b g O n t o l o g y = man . l o a d O n t o l o g y ( b g O I R I ) ; a b d u c t i o n M a n a g e r . s e t B a c k g r o u n d K n o w l e d g e ( b g O n t o l o g y ) ;

We also use the A b d u c t i o n M a n a g e r instance to specify the observation. Most abduction reasoners accept observations in the form of a single axiom (which we will treat a singleton set) or set of axioms. Observations consisting of several axioms may not be supported and also not all possible forms of axioms may be accepted by the given reasoner. If the user supplies an <<Interface>>

AbductionManager  + monitor: Monitor + run():                                     void + getMonitor():                           Monitor + setAbducibles(ABDUCIBLES):                 void + setObservation(OBSERVATION_TYPE):          void + setObservation(Set<OBSERVATION_TYPE>):     void + getObservation():            <OBSERVATION_TYPE> + getExplanations():        Set<OBSERVATION_TYPE> + getExplanationsIncrementally():            void + getOutputAdditionalInfo():               String + setAdditionalSolverSettings(String):       void + setBackgroundKnowledge(BCKGRNDKNW_TYPE):   void + getBackgroundKnowledge():     <BCKGRNDKNW_TYPE> + sendExplanation(EXPLANATION_TYPE):         void + getAbducibles():                     ABDUCIBLES

<<Interface>> AbductionManagerAndAbducibleContainerFactory

<ABDUCTION_MANAGER, ABDUCIBLE_CONTAINER> + createAbducibleContainer():  ABDUCIBLE_CONTAINER + createAbductionManager():      ABDUCTION_MANAGER

<<Interface>>

AbducibleContainer  + allowLoops(Boolean):                      void  + allowRoleAssertions(Boolean):             void  + allowConceptAssertions(Boolean):          void  + allowComplexConcepts(Boolean):            void  + allowConceptComplement(Boolean):          void  + areLoopsEnabled():                     boolean  + areRoleAssertionsEnabled():            boolean  + areConceptAssertionsEnabled():         boolean  + areConceptComplementsEnabled():        boolean  + addSymbol(SYMBOL_ABDUCIBLE):              void  + addSymbols(Collection<SYMBOL_ABDUCIBLE>): void + Monitor() + addNewExplanation(EXPLANATION_TYPE):      void + getNextExplanation():         EXPLANATION_TYPE + getExplanations():      List<EXPLANATION_TYPE> Extends exception «interface»

Runnable + ThreadVersionException()

ThreadVersionException

AxiomObservationException + AxiomObservationException(Exception) + AxiomObservationException(String)

MultiObservationExceptionException + MultiObservationException() «interfa«cien»terface» RuntimeERxucnetpitmieoEnxception

Extends

CommonException + serialVersionUID: long + CommonException(String, Exception) + CommonException(String)

Extends Extends

Extends

Extends

AxiomAbducibleSymbolExceptionException + AxiomAbducibleSymbolException(Exception) + AxiomAbducibleSymbolException(String)

AxiomAbducibleAssertionExceptionException + AxiomAbducibleAssertionException(Exception) + AxiomAbducibleAssertionException(String)

AxiomAbducibleException + AxiomAbducibleException() observation that is not supported, the abduction manager will throw MultiObservationException or AxiomObservationException respectively.

I R I obsOIRI = I R I . c r e a t e ( ” http : / / example . org / o b s e r v a t i o n s ” ) ; OWLOntology obsOntology = man . loadOntology ( obsOIRI ) ; Set <OWLOntology> obsOntologySet = new HashSet < >() ; o b s O n t o l o g y S e t . . add ( o b s O n t o l o g y ) ; t r y {

a b d u c t i o n M a n a g e r . s e t O b s e r v a t i o n ( o b s O n t o l o g y S e t ) ; } c a t c h ( CommonException ex ) {

throw new CommonException ( ” S o l v e r e x c e p t i o n : ” , ex ) ;

3.2. Configuring Abducibles

Abducibles are vital to constrain the solution space. They can be specified in multiple ways. The ifrst option is to specify possible symbols from which possible explanations may be constructed (in which case we are essentially performing signature-based abduction). For this we initialize an instance of and OWLDataFactory. Consecutively the abducibleContainer is configured by adding all these OWL API entity representations.

OWLDataFactory d f = o . getOWLOntologyManager ( ) . getOWLDataFactory ( ) ; O W L I n d i v i d u a l i n d J a c k = d f . getOWLNamedIndividual ( bgOIRI +”# j a c k ” ) ; O W L I n d i v i d u a l i n d J i l l = d f . getOWLNamedIndividual ( bgOIRI +”# j i l l ” ) ; OWLClass c l s P a r e n t = d f . getOWLClass ( bgOIRI +”# P a r e n t ” ) ; OWLObjectProperty o p r H a s C h i l d = d f . g e t O W L O b j e c t P r o p e r t y ( bgOIRI +”# h a s C h i l d ” ) ; t r y { a b d u c i b l e C o n t a i n e r . addSymbol ( i n d J a c k ) ; a b d u c i b l e C o n t a i n e r . addSymbol ( i n d J i l l ) ; a b d u c i b l e C o n t a i n e r . addSymbol ( c l s P a r e n t ) ; a b d u c i b l e C o n t a i n e r . addSymbol ( o p r H a s C h i l d ) ; } c a t c h ( CommonException ex ) {

throw new CommonException ( ” S o l v e r e x c e p t i o n : ” , ex ) ; } }

Alternatively, we allow passing of abducible symbols via an ontology that contains declarations of all abducible symbols.

OWLOntology a b d S y m b o l L i s t =

man . loadOntologyFromOntologyDocument ( new F i l e ( ” abd −s y m b o l s . owl ” ) ) ; t r y {

a b d u c i b l e C o n t a i n e r . addSymbols ( a b d S y m b o l L i s t ) ; } c a t c h ( CommonException ex ) {

throw new CommonException ( ” S o l v e r e x c e p t i o n : ” , ex ) ;

The addSymbol and addSymbols methods may throw an AxiomAbducibleSymbolException in case the passed symbols are not supported by the respective abduction solver.

In addition to specifying the signature, AbducibleContainerImpl features a number of Boolean switches to control the shape of the axioms in a solution. allowConceptAssertions and allowRoleAssertions respectively allow or disallow axioms in the hypotheses that are concept or role assertions. If concept assertions are allowed, allowConceptComplement and allowComplexConcepts can be used to determine whether only concept names, negated concept names, or also complex concepts are allowed. With role assertions enabled, allowLoops may be used to toggle reflexive role assertions (loops).

Alternatively to the option above (i.e. to specify abducible symbols, possibly supplemented by constraints on the generated axioms), users may also directly specify the set of abducible axioms. Both approaches are mutually exclusive: if one tries to specify abducible symbols and abducible axioms, the API will throw an exception. Similarly it is not possible to specify abducible axioms and additional constraints on their shape (as constraints only apply to axioms generated from abducible symbols).

An example of the latter option (i.e. abducible axioms) follows: O W L I n d i v i d u a l i n d J a c k = d f . getOWLNamedIndividual ( bgOIRI +”# j a c k ” ) ; OWLClass c l s P e r s o n = d f . getOWLClass ( bgOIRI +”# P e r s o n ” ) ; OWLClass c l s P a r e n t = d f . getOWLClass ( bgOIRI +”# P a r e n t ” ) ; OWLObjectComplementOf c l s C 1 = d f . getOWLObjectComplementOf ( c l s P a r e n t ) ; O W L O b j e c t I n t e r s e c t i o n O f c l s C 2

= d f . g e t O W L O b j e c t I n t e r s e c t i o n O f ( c l s P e r s o n , c l s C 1 ) ; t r y { a b d u c i b l e C o n t a i n e r . a d d A s s e r t i o n (

d f . g e t O W L C l a s s A s s e r t i o n A x i o m ( c l s P e r s o n , i n d J a c k ) ) ; a b d u c i b l e C o n t a i n e r . a d d A s s e r t i o n (

d f . g e t O W L C l a s s A s s e r t i o n A x i o m ( c l s P a r e n t , i n d J a c k ) ) ; a b d u c i b l e C o n t a i n e r . a d d A s s e r t i o n (

d f . g e t O W L C l a s s A s s e r t i o n A x i o m ( c l s C 1 , i n d J a c k ) ) ; a b d u c i b l e C o n t a i n e r . a d d A s s e r t i o n (

d f . g e t O W L C l a s s A s s e r t i o n A x i o m ( c l s C 2 , i n d J a c k ) ) ; } c a t c h ( CommonException ex ) {

throw new CommonException ( ” S o l v e r e x c e p t i o n : ” , ex ) ; } }

Similarly as for the abducible signatures, it is possible to add several assertions at once by providing an OWLOntology object. Then, all axioms of that ontology are added. OWLOntology a b d A x i o m L i s t =

man . loadOntologyFromOntologyDocument ( new F i l e ( ” abd −axioms . owl ” ) ) ; t r y {

a b d u c i b l e C o n t a i n e r . a d d A s s e r t i o n s ( a b d A x i o m L i s t ) ; } c a t c h ( CommonException ex ) { throw new CommonException ( ” S o l v e r e x c e p t i o n : ” , ex ) ;

Depending on the solver implementation, if e.g. an unsupported abducible axiom is passed then AxiomAbducibleAssertionException is thrown.

3.3. Internal Solver Settings

Diferent solvers may have additional specific functionalities which are not covered by our API. While this being the case it may still be useful to pass control parameters into the solver. We include a method to pass such information as a single string in a format prescribed by the given solver: a b d u c t i o n M a n a g e r . s e t A d d i t i o n a l S o l v e r S e t t i n g s ( ” i n t e r n a l S e t t i n g s ” ) ;

3.4. Running the Solver

Once everything is configured, users can run the solver and compute explanations, for which we again support diferent methods. If the number of solutions is finite, the following method can be used to compute all explanations: S e t < E x p l a n a t i o n > e x p l a n a t i o n s = a b d u c t i o n M a n a g e r . g e t E x p l a n a t i o n s ( ) ;

If one only requires single explanation, i.e. one that is found first, this can be computed as follows: E x p l a n a t i o n e x p l a n a t i o n = a b d u c t i o n M a n a g e r . g e t E x p l a n a t i o n ( ) ;

The solvers may output additional information associated with the explanations (debug logs, etc.). This is also accessible via the API as follows: S t r i n g l o g = a b d u c t i o n M a n a g e r . g e t O u t p u t A d d i t i o n a l I n f o ( ) ;

The search for all abductive explanations is computationally hard, and the implementation of the solver may in fact find some explanations early on, while it may take much longer to completely search through the whole search space. In order to make the explanations accessible on-the-fly, as soon as they are computed DL Abduction API implements a multi-threaded version based on the monitor design pattern. The respective UML sequential diagram in printed in Fig. 2.

First the monitor that handles the communication is obtained from the a b d u c t i o n M a n a g e r instance: m o n i t o r = a b d u c t i o n M a n a g e r . g e t M o n i t o r ( ) ;

Then, in order to process the explanations as they are obtained, we initialize a second thread in which we iteratively query the monitor for new explanations: T h r e a d c t = new T h r e a d ( ) { p u b l i c v o i d run ( ) { w h i l e ( t r u e ) { s y n c h r o n i z e d ( m o n i t o r ) { t r y { m o n i t o r . w a i t ( ) ; O b j e c t e x p l a n a t i o n = m o n i t o r . g e t N e x t E x p l a n a t i o n ( ) ; i f ( e x p l a n a t i o n == n u l l ) { m o n i t o r . n o t i f y ( ) ; b r e a k ; : app thread 1 : Monitor : AbductionManager thread 2 : solver

Then abduction is called by the method getExplanationsIncrementally and a new the computation is started in a new thread in the abductionManager: a b d u c t i o n M a n a g e r . g e t E x p l a n a t i o n s I n c r e m e n t a l l y ( ) ;

Once the solver’s search for new explanations is over, the monitor.getNextExplanation() call returns null and the processing loop will break.

start() addExplanation getNextExplanation() return newExplanation

notify() getNextExplanation() return newExplanation opt [solver is terminated] addNewExplanation(explanation)

notify() addNewExplanation(null) notify()

solve() sendExplanation()

return

List of explanations sendExplanation(null)

computing newExplanation

4. Implementation in MHS-MXP Solver

The DL Abduction API has been implemented into MHS-MXP [ 22, 24 ] which is an ABox abduction reasoner. The API functionality integrated includes all main abduction inputs: passing the background ontology, the observation (including a set of axioms), and abducibles.

Signature-based abducibles are supported by passing symbols (individuals and concepts), and the switch to allow or disallow negated concept assertions in explanations is implemented too. Axiom-based abducibles are also supported. (These two options are exclusive.) A depthlimitation for the MHS-tree and a time out can be passed as internal settings.

The solver may be run via both the non-threaded and threaded version of the API. If the solver is extended in the future to support role explanations and abducibles, also this part of the API implementation is already prepared.

5. Conclusions and Future Work

Based on our analysis of several ABox abduction solvers, we have proposed DL Abduction API, a Java API that may be implemented by DL abduction solvers in order to facilitate their integration into applications.

Our API allows to pass the most relevant inputs, including the background ontology, observations, and abducibles, and it features settings to toggle the most common options. Any additional specific options can be also passed in a format required specific to a given solver.

The inputs and outputs such as ontologies, axioms, or symbols are passed using OWL API [ 23 ] constructs as much as possible to facilitate the implementation for developers who are likely already acquainted with OWL API due to its popularity in the DL community.

As abduction is computationally demanding and explanations are found by exploring the given search space, our API includes a mechanism of incremental reporting of the found explanations that is based on the monitor design pattern.

The API is available as source code and as a j a r file 2. It has been already integrated into the latest version3 of the experimental reasoner MHS-MXP [ 24 ]. Its integration into the LETHE reasoner [ 10, 4 ] is currently ongoing.

Acknowledgments

This work was supported by the Slovak Research and Development Agency under the Contract no. APVV-19-0220 (ORBIS) and by the EU H2020 programme under Contract no. 952215 (TAILOR). Martin Homola is also supported by projects VEGA 1/0621/22 and APVV-20-0353. 2https://github.com/elratondesusi/DT 3https://github.com/elratondesusi/DT-demo

References

[1] C. S. Peirce , Illustrations of the logic of science VI: Deduction, induction, and hypothesis , Popular Science Monthly 13 ( 1878 ) 470 - 482 .

[2] C. Elsenbroich , O. Kutz , U. Sattler , A case for abductive reasoning over ontologies , in: Proceedings of the OWLED*06 Workshop on OWL: Experiences and Directions , Athens, GA, US, volume 216 of CEUR-WS , 2006 .

[3] J. Pukancová , M. Homola , Tableau-based ABox abduction for description logics: Preliminary report , in: Proceedings of the 29th International Workshop on Description Logics , Cape Town, South Africa, April 22-25 , 2016 , 2016 .

[4] P. Koopmann , Signature-based abduction with fresh individuals and complex concepts for description logics , in: Z. Zhou (Ed.), Proceedings of the Thirtieth International Joint Conference on Artificial Intelligence, IJCAI 2021 , Virtual Event / Montreal, Canada, 19 -27 August 2021 , ijcai .org, 2021 , pp. 1929 - 1935 .

[5] S. Klarman , U. Endriss , S. Schlobach, ABox abduction in the description logic ℒ , Journal of Automated Reasoning 46 ( 2011 ) 43 - 80 .

[6] K. Halland , K. Britz , Abox abduction in ℒ using a DL tableau , in: 2012 South African Institute of Computer Scientists and Information Technologists Conference, SAICSIT '12, Pretoria , South Africa, 2012 , pp. 51 - 58 .

[7] F. Haifani , P. Koopmann , S. Tourret , C. Weidenbach , Connection-minimal abduction in ℰ ℒ via translation to FOL , in : Proceedings of the International Joint Conference on Automated Reasoning (IJCAR 2022), Lecture Notes on Computer Science , Springer, 2022 . To appear.

[8] J. Du , H. Wan , H. Ma, Practical TBox abduction based on justification patterns , in: Proceedings of the Thirty-First AAAI Conference on Artificial Intelligence , 2017 , pp. 1100 - 1106 .

[9] F. Wei-Kleiner , Z. Dragisic , P. Lambrix , Abduction framework for repairing incomplete ℰ ℒ ontologies: Complexity results and algorithms , in: Proceedings of the Twenty-Eighth AAAI Conference on Artificial Intelligence, July 27 -31 , 2014 , Québec City , Québec, Canada., 2014 , pp. 1120 - 1127 .

[10] P. Koopmann , W. Del-Pinto , S. Tourret , R. A. Schmidt , Signature-based abduction for expressive description logics , in: Proceedings of the 17th International Conference on Principles of Knowledge Representation and Reasoning , KR 2020, Rhodes, Greece, 2020 , pp. 592 - 602 .

[11] G. Petasis , R. Möller , V. Karkaletsis , BOEMIE : Reasoning-based information extraction , in: Proceedings of the 1st Workshop on Natural Language Processing and Automated Reasoning co-located with 12th International Conference on Logic Programming and Nonmonotonic Reasoning (LPNMR 2013 ), A Corunna , Spain, September 15th , 2013 ., 2013 , pp. 60 - 75 .

[12] J. Du , G. Qi, Y. Shen , J. Z. Pan , Towards practical ABox abduction in large description logic ontologies , Int. J. Semantic Web Inf. Syst . 8 ( 2012 ) 1 - 33 .

[13] İ. İ. Ceylan , T. Lukasiewicz , E. Malizia , C. Molinaro , A. Vaicenavicius , Explanations for negative query answers under existential rules , in: D. Calvanese , E. Erdem, M. Thielscher (Eds.), Proceedings of KR 2020 , AAAI Press, 2020 , pp. 223 - 232 .

[14] D. Calvanese , M. Ortiz , M. Simkus , G. Stefanoni, Reasoning about explanations for negative query answers in DL-Lite , J. Artif . Intell. Res . 48 ( 2013 ) 635 - 669 .

[15] K. Schekotihin , P. Rodler , W. Schmid, Ontodebug: Interactive ontology debugging plug-in for protégé , in: Foundations of Information and Knowledge Systems - 10th International Symposium, FoIKS 2018 , Budapest, Hungary, May 14 -18, 2018 , Proceedings, volume 10833 of LNCS , Springer, 2018 , pp. 340 - 359 .

[16] T. Hubauer , C. Legat , C. Seitz , Empowering adaptive manufacturing with interactive diagnostics: A multi-agent approach , in: Advances on Practical Applications of Agents and Multiagent Systems - 9th International Conference on Practical Applications of Agents and Multiagent Systems, PAAMS 2011 , Salamanca, Spain, 2011 , pp. 47 - 56 .

[17] J. Pukancová , M. Homola , Abductive reasoning with description logics: Use case in medical diagnosis , in: Proceedings of the 28th International Workshop on Description Logics (DL 2015 ), Athens, Greece, volume 1350 of CEUR-WS , 2015 .

[18] P. Koopmann , Two ways of explaining negative entailments in description logics using abduction , in: XLoKR 21 , 2021 .

[19] W. Del-Pinto , R. A. Schmidt , Forgetting-based abduction in ℒ , in: Proceedings of the Workshop on Second-Order Quantifier Elimination and Related Topics (SOQE 2017 ), Dresden, Germany, volume 2013 of CEUR-WS , 2017 , pp. 27 - 35 .

[20] W. Del-Pinto , R. A. Schmidt , Abox abduction via forgetting in ALC, in: The Thirty- Third AAAI Conference on Artificial Intelligence , AAAI 2019 , Honolulu, Hawaii, USA, AAAI Press, 2019 , pp. 2768 - 2775 .

[21] J. Pukancová , M. Homola, The AAA abox abduction solver , Künstliche Intell . 34 ( 2020 ) 517 - 522 .

[22] M. Homola , J. Pukancová , J. Gablíková , K. Fabianová , Merge, explain, iterate, in: S. Borgwardt, T. Meyer (Eds.), Proceedings of the 33rd International Workshop on Description Logics (DL 2020 ), Online Event [Rhodes, Greece], volume 2663 of CEUR-WS , 2020 .

[23] M. Horridge , S. Bechhofer , The OWL API: A Java API for OWL ontologies , Semantic Web 2 ( 2011 ) 11 - 21 .

[24] M. Homola , J. Pukancová , I. Balintová , J. Boborová , Hybrid MHS-MXP ABox abduction solver: First empirical results , in: Proceedings od the 35rd International Workshop on Description Logics (DL 2022 ), Haifa, Israel, 2022 .