Analysis, Enrichment and Repair of Linked Data with ORE Tool
The ORE tool supports knowledge engineers in enriching the schema of OWL based knowledge bases, either accessible as ﬁle or via SPARQL. Additionally, it allows for the detection and repair of logical errors as well as the validation of instance data by deﬁning constraints in forms of OWL axioms. ORE also integrates the PaOMat framework (see Sect. 3), thus, it allows for the detection and repair of naming issues. The ORE tool is published as an open source project.
Along with the uptake of Semantic Web technologies, we observe a steady increase of the amount of available OWL ontologies as well as an increase of the complexity of such ontologies. While the expressiveness of OWL is indeed a strong feature, it can also lead to a misunderstanding and misusage of particular types of constructs in the language. In turn, this can lead to modeling errors in the ontology, i.e. inconsistency or unsatisfiable classes. Inconsistency, in simple terms, is a logical contradiction in the knowledge base, which makes it impossible to derive any meaningful information by applying standard OWL reasoning techniques. Unsatisﬁable classes usually are a fundamental modeling error, in that they cannot be used to characterize any individual, that means they cannot have any individual.
Both kinds of modeling errors are quite easy to detect by standard OWL reasoners, however, determining why the errors hold can be a considerable challenge even for experts in the formalism and in the domain, even for modestly sized ontologies. The problem worsens signiﬁcantly as the number and complexity of axioms of the ontology grows. Clearly, only with the understanding of why such an undesired entailment holds, it is possible to get rid of the errors, i.e. to repair the ontology.
In the area of ontology debugging, a speciﬁc type of explanation called justifications [1, 7, 8, 18] was introduced by the research community, which is basically a minimal subset of the ontology that is suﬃcient for the entailment to hold. The set of axioms corresponding to the justiﬁcation is minimal in the sense that if an axiom is removed from the set, the remaining axioms no longer support the entailment. One such justiﬁcation could be the following example, which gives an explanation why the class metal is unsatisﬁable.
Support in ORE
The debugging view for OWL ontologies (see Fig. 6), here described for unsatisﬁable classes, consists mainly of four parts: The ﬁrst part on the left side (→1 ) gives
Fig. 6. Screenshot of the debugging view for OWL ontologies.
a list of the unsatisﬁable classes which were detected in the selected knowledge base. In this list itself, root unsatisﬁable classes, i.e. classes which unsatisﬁability does not depend on the unsatisﬁability of other classes, are tagged with “Root”. Usually, in a repair process it is recommended to handle such root unsatisﬁable classes ﬁrst, as other conﬂicts will be solved then too. The second main part contains the presentation of the explanations, which are computed once an unsatisﬁable class is selected, and shown as tables (→3 ). In addition to the axioms of the justiﬁcation, each of the tables contains two metrics which give some insights into how an axiom is involved in other justiﬁcations (frequency) and how strong an axiom is connected in the ontology (usage), both metrics ﬁnally aggregated in total score (score). The menu (→2 ) allows for the choice between the computation of regular or laconic justiﬁcations as well as for the limitation of the maximum number of computed justiﬁcations. Furthermore, it gives the option to show an aggregated view of all the axioms contained in the computed justiﬁcations, compared to the presentation of each justiﬁcation in its own table. In the third part (→4 ) the repair plan a list of all changes a user has chosen in order to repair the knowledge base is displayed. The changes can either be the removal or addition of axioms and will be executed once a user has decided to do so by clicking the “Execute” button. The last part of the debugging view, located at the bottom right (→5 ), contains an outline of the eﬀects the changes of the repair plan would have to the knowledge base, i.e. it contains lost and retained entailments. If an entailment is found to be lost when executing the repair plan, it is possible to add an axiom to the knowledge base which retains that entailment. This part is only available during the debugging of unsatisﬁable classes, as it is (currently) impossible to compute such entailments in inconsistent knowledge bases.