Semantic Reasoning Services

Reasoning in DL [83] is a multi-faceted semantic service that may be broken down into five important functions.

Subsumption

Based on existing ontology axioms, semantic reasoners may infer knowledge that is not explicitly stated, but follows logically from previous assertions. For instance, let us consider the definitions9 of ontology concepts FrenchRivieraCity, NorthernMediterraneanCity and NorthernMediterraneanCountry (Fig. 2.4). Based on the fact that France is among the countries to the north of the Mediterranean Sea, a semantic reasoner will infer that concept FrenchRivieraCity subsumes (is a subclass of) NorthernMediterraneanCity. This automated inference would prove very useful in the context of a travel planning application: should the user request a list of all vacation destinations north of the Mediterranean Sea, the results list would contain all cities on the French Riviera, including those that are not directly listed as Mediterranean cities.

Class: FrenchRivieraCity EquivalentTo: VacationDestination

and (isLocatedIn value France)

Class: NorthernMediterraneanCity EquivalentTo: VacationDestination

and (isLocatedIn some NorthernMediterraneanCountry)

Class: NorthernMediterraneanCountry EquivalentTo:

{Spain, France, Monaco, Italy, Slovenia, Croatia, Bosnia and Herzegovina, Montenegro, Albania, Greece, Turkey}

Fig. 2.4:Concept definitions from an ontology describing vacation destinations - based on these, the reasoner subsumesFrenchRivieraCityunderNorthernMediterraneanCity

Subsumption simplifies the ontology design process, allowing the ontologist to focus on formulating accurate class and property definitions rather that investing effort in determining the correct place in the ontology hierarchy where a new concept should be inserted.

9_{All definitions of ontology concepts and properties are given in the Manchester OWL syntax, available at https:} //protegewiki.stanford.edu/wiki/Manchester_OWL_Syntax.

Satisfiability

A common problem with large ontologies is that subtle, usually unwanted and difficult to detect connections tend to appear between axioms. In this context, it is possible for a concept to become inconsistent (or unsatisfiable), meaning that no instances could be created from it. The example in Fig. 2.5 illustrates such a scenario: an ItalianRivieraCity is both an EuropeanCity and a NorthernMediterraneanCity, however, the touristic appeal of European cities, on the one hand, and northern Mediterranean cities, on the other hand, is reflected by different average ranks10: 3 and, respectively, 5. Given that hasAverageRank is a functional property, it follows that Italian Riviera cities have two average ranks, which is both conuterintuitive and logically incorrect. The reasoner will address this situation by flagging concept ItalianRivieraCity as inconsistent.

Class: ItalianRivieraCity SubClassOf:

EuropeanCity and NorthernMediterraneanCity

Class: EuropeanCity EquivalentTo: VacationDestination

and (hasAverageRank value "3"^^integer)

Class: NorthernMediterraneanCity EquivalentTo: VacationDestination

and (hasAverageRank value "5"^^integer)

Fig. 2.5:Concept definitions from an ontology describing vacation destinations - based on these, the reasoner infers that conceptItalianRivieraCityis unsatisfiable

Satisfiability checks are particularly useful during ontology design or when porting legacy databases to a semantic format, as they expose design flaws, usually too subtle for human domain experts to detect. Relative to the ItalianRivieraCity example, the ontologist is made aware that hasAverageRank causes an inconsistency, prompting either a redefinition of the culprit property, or, better yet, a reconfiguration of the concept hierarchy.

Synonymy

Ontology classes that have the exact same set of instances are called equivalent, a relationship that is automatically detected by the reasoner. In some cases, synonymy is useful: for instance, in the medical domain, determining that several terms refer to the same condition may support doctors with prescribing the correct treatment. In other cases, equivalent classes signal a design flaw, such as ambiguous definitions or insufficiently constrained axioms. The latter case is illustrated in Fig. 2.6, where concepts EuropeanCity and AsianCity lack the isLocatedIn property, therefore the reasoner will infer they are equivalent. Moreover, concept City is incorrectly defined as the intersection, rather than the reunion of the five continents, leading the reasoner to infer that City subsumes EuropeanCity and AsianCity. As the latter two concepts are asserted as subclasses of City, a cycle is formed. From

a logical point of view, a cycle is not an inconsistency, therefore the reasoner does not flag such cases as problems. However, in some situations, as is the one illustrated in Fig. 2.6, a cycle may mask a design flaw. Specifically, the fact that concepts City, EuropeanCity and AsianCity are reported as synonyms will allert the ontologist to the error in the definition of concept City (where and should be replaced by or) as well as the ambiguity in the definitions of the other two concepts.

Class: EuropeanCity EquivalentTo: City

and (hasAverageRank value "3"^^integer)

Class: AsianCity EquivalentTo: City

and (hasAverageRank value "3"^^integer)

Class: City EquivalentTo:

EuropeanCity and AsianCity and AmericanCity and AfricanCity and AustralianCity

Fig. 2.6:Concept definitions from an ontology describing vacation destinations - based on these, the reasoner infers that conceptsEuropeanCity,AsianCityandCityare synonyms

Query Answering

Provided that the underlying ontology is consistent, semantic reasoners are capable of automatically answering queries based on both asserted and inferred knowledge. Relative to the example in Fig. 2.4, asking whether France is a northern Mediterranean country represents a query of the former type, whereas requesting the list of all northern Mediterranean cities would fall under the latter category. Queries based on inferred knowledge are particularly powerful, allowing entries such as Nice, defined in Fig. 2.7, to be included in the results list, even though there is no explicit ontology axiom directly linking them to NorthernMediterraneanCity, the only search criterion mentioned in the query.

Individual: Nice

Types: FrenchRivieraCity

Fig. 2.7:Individual definition from an ontology describing vacation destinations - based on this and the concepts in Fig. 2.4, the reasoner infers thatNiceis a northern Mediterranean city

The practical applications of answering queries based on inferred knowledge (ranging from allowing Google to provide more relevant results to supporting Siri with better understanding questions) come at a computational cost. Specifically, in order to determine that Nice is a northern Mediterranean city, that statement needs to be verified for all states of the modelled domain that satisfy the ontology’s axioms. In the example given here, that is not an intense computation, however, realistic ontologies are of a much larger size. The complexity of semantic query answering can be traced back to the Open World Assumption (OWA), according to which facts that are not explicitly asserted are not assumed

to be false (as is the case with relational databases). Consequently, there is a compromise to be made between the flexibility enabled by OWA - the only realistic option available when modelling uncertain domains where missing knowledge is a given - and the effort entailed by computing entailments (query answers), a process close in nature to theorem proving [83]. In contract, query answering is significantly faster with relational databases, given that they operate under the Closed World Assumption (CWA). Regardless, modern reasoner implementations, such as FaCT++ [175] and Pellet [161], are capable of resolving ontological queries in a realistic time frame.

Inference Explaining

A fundamental service provided by semantic reasoners, tightly connected to the trust level of the Semantic Stack, is that of explaining inferences. Every semantic operation, particularly queries with counter-intuitive or unexpected results and computations that uncover design problems, such as concept inconsistency, is justified by a reasoning chain. For instance, when inquiring whether Nice is a north Mediterranean city, all axioms that support the result, namely the ones shown in Fig. 2.4 and Fig. 2.7, will be available for inspection upon producing the answer. Revealing the reasoning chain supporting a query answer is particularly useful when the ontology underpins an exploratory system, such as a career management application. For instance, users searching for the academic qualifications necessary to get a job in Physics, may come across other, related professional fields among the axioms in the reasoning chain and thus expand their range of job options.

In case of detecting unsatisfiable classes, the explanation is akin to the debugger output for code written in some programming language, in the sense that the ontologist can use the axiom trace to locate and address design flaws.