Ontology development and maintenance are complex tasks, so automatic tools are essential for a successful integration between the modeller's intention and the formal semantics in an ontology. Nevertheless, tools need to provide a way to capture the intuitive structures inherent to the conceptual modelling and to focus on ontology elements currently being refactored by abstracting the user from the whole ontology without losing consistency. This can be done by means of a set of extension rules that identify elements from an ontology and suggest possible consistent evolutions. Rules guide the development of ontologies by taking source elements and refactoring. In this paper, we present a small catalogue of extension rules to cover these identified requirements and thus to be integrated into a tool for ontological modelling as builtin reasoning services. Each rule is defined and analysed by considering different theories of design patterns.
Ontology development and maintenance are complex tasks, so automatic tools are essential for a successful integration between the modeller’s intention and the formal semantics in an ontology. Domain experts capture the knowledge in the universe of discourse but they have a limited understanding of the semantics of ontology representation languages. Moreover, a good comprehension of the implicit knowledge in a middle-size ontology formalisation is difficult even for IT experts. Thus, automatic tools are essential for a successful integration between the modeller’s intention and the formal semantics in an ontology.
Two of the most important features for any ontology development tool are support for graphical representation and a consistent integration with a backend reasoner for helping in the management of implicit knowledge. Nevertheless, tools also need to provide a way to capture the modeller’s intentions or the intuitive structures inherent to the conceptual modelling. The first ones are sources for abstractions and for exploring, composing and checking the ontology by making explicit to the user its overall semantic. The last one provides a way to focus on ontology elements currently being refactored by abstracting the user from the whole ontology maintaining consistency and giving support
to the ontological evolution. This can be done by means of a set of extension rules that identify elements from an ontology and suggest possible consistent evolutions. Rules guide the development of ontologies by taking source elements and refactoring together with the underlying reasoning services.
In order to offer rules-based support, some efforts have been undertaken. In
particular, Guizzardi et al. [
In this paper, we present a set of extension rules which work at intentional
level (TBox) of an ontology. An extension rule is a Description Logic (DL)
structure with an antecedent which must be satisfied in the model to be applied, and
a consequent which contains the new knowledge to be asserted. Extension rules
are to be used together with other artefacts as user queries and reasoning
systems, where the former identifies relevant parts of an ontology and the latter
inquires the model to check rules applicability, their possible consequences and
side effects. A rule is applicable iff its antecedent is satisfied and its consequent
maintains the consistency of the model. Our rules-based approach and the
ontology design patterns [
This rule-based approach is to be implemented on the methodology
underlying to ICOM tool [
ICOM language, including non-graphical extensions of role hierarchies and the view language. Moreover, ICOM allows partial graphical evolution of an ontology schema (intentional knowledge) by adding axioms which are inferred through defined reasoning services. Users will see the ontology graphically completed and evolved with all the deductions and expressed in the graphical language itself.
This work is structured as follows. Section 2 details the set of rules with a brief explanation and an example of each one of them. Discussions and related works are presented in section 3. To conclude the paper, section 4 elaborates on final considerations and directions for future works. 2
The objective of the extension rules is to reduce the search space of ontology elements, and thus decrease the complexity of designing and understanding ontologies. They also focus on identifying relevant parts of models, and facilitate ontology verification, maintenance and integration. This approach allows to discover knowledge which is not inferred from a logical point of view but it is suggested from an intuitive point of view. Rules can be inter-modules in order to reuse, combine and share modules, which are central issues in ontology engineering branches as modularity.
In comparison with ontology design patterns [
The aim is to integrate this set of rules to a graphical tool so that the graphical ontology and rules are mapped to the ICOM DL. This logical support enables defining when an extension rule can be applied, deducing implicit axioms to display the implications of the suggestions derived from extension rules and asserting the new intentional knowledge in the underlying knowledge base.
The general form of the rules is the following:
{A1, A2, ..., An} ⇛ {B1, B2, ..., Bm} such that Ai and Bj are TBox formulae from DL of the underlying reasoner, 1 ≤ i ≤ n and 1 ≤ j ≤ m.
In order to apply a rule, we must check if its antecedent is satisfied in the logical representation of the graphical ontology Ω, denoted by Θ, and if its consequences are consistent with this representation. Thus, a back-end reasoner should be inquired about the satisfiability of the following properties of Ω, {A1, A2, ..., An}, and about consistency of every resulting ontology after applying the rule consequent. Each Bi represents a different possible ontology extension and it is the user who is required to select which Bi, 1 ≤ i ≤ m will be applied, 4
if any. Therefore, the back-end reasoner would be inquired if Θ ∪ Bi is consistent for any i, 1 ≤ i ≤ m
We present the extension rules catalogue by means of a brief explanation
about each rule with some comparisons with other approaches such as design
patterns or OntoUML [
The aim of this rule is to identify missing IsA relationships between classes (and associations) and suggest them. It is intended to capture those scenarios whose concepts could be related by means of possibly the same role, and thus suggest a missing relationship as a subsumption axiom obtaining a more precise model or an equivalence axiom in which case the involved classes could be factored.
The rule, which is graphically rendered as shown in Fig. 1a and 1b, can be
legitimised by analysing the involved classes and their relationships. By definition,
if A2 ⊑ A1 and A1 ⊑ ∃r1.C1 then A2 ⊑ ∃r1.C1. Moreover, if any explicit
inequality exists in the ontology then we can suppose both roles r1 in A1 ⊑ ∃r1.C1 and
A2 ⊑ ∃r1.C2 represent the same role and they are identically defined.
Considering these arguments, the rule consequent {C2 ⊑ C1,C2 ≡ C1} could be proposed
as possible extensions. Similar to Gangemi’s design patterns [
A1 A2 r1 r1 (a)
C1 C2
A1 A2
C1 ≡ C2
the relations between concepts and entities and Type of entities, which allows to identify the type of any element of the knowledge base.
Another way of validating this rule is using the Guizzardi’s definitions in [
Example 1. Let us suppose the following partial and textual ontology Ω: hasSport ⊑ ∃f rom.OlympicSport OlympicSport hasSport min ⊑ OlympicSport ⊓ (≥ 1 f rom−.hasSport) OlympicSport hasSport max ⊑ OlympicSport ⊓ (≤ 1 f rom−.hasSport) hasW interSport ⊑ ∃f rom.W interSport W interSport hasW interSport min ⊑ W interSport ⊓ (≥ 1 f rom−.hasW interSport) W interSport hasW interSport max ⊑ W interSport ⊓ (≤ 1 f rom−.hasW interSport) hasW interSport ⊑ hasSport If we match these ontology elements to the ⊑-rule # 1, we can obtain a ′ consistent ontology Ω , which defines a new type for the OlympicSport by means of W interSport ⊑ OlympicSport as depicted in Fig. 1c, or a Ω′′ where W interSport ≡ OlympicSport. ⊑-rule # 2 {C2 ⊔ C3 ⊔ ... ⊔ Cn ⊑ C1, A1 ⊑ ∃r1.C2,..., A1 ⊑ ∃r1.Cn} ⇛ {A1 ⊑ ∃r1.C1} This rule, which is graphically represented as depicted in Fig. 2a, intends to identify redundant relationships between concepts within an IsA relationship. The same roles involving each subclass of an IsA could be defined by relating it to the superclass of the hierarchy.
Although it is not caught by the current definition of the rule, if a totality constraint is defined then the rule suggestion is a strong suggestion since each instance of the superclass belongs to one of its subclasses. Consequently the validation can be obtained from a logical point of view: if ∀i, 2 ≤ i ≤ n, Ci ⊑ C1 and A1 ⊑ ∃r1.Ci then A1 ⊑ ∃r1.C1. Nevertheless, if any other constraint (exclusive or partial) is defined then the rule suggestion is weaker than the previous one.
Despite being ⊑-rule # 2 a common-sense rule, in our methodological context it enables the user to optimise relationships in possibly big-size ontologies without removing existing ones in order to show each consistent modelling scenarios.
C2 . . .
Cn
A1
r1 r1 r1
C1 Example 2. Let us consider the ontology shown in Fig. 2b where an olympicSport can be a winterSport or a summerSport and both related to other classes by means of the association hasSport and the role f rom. The DL representation of this ontology is not included here but it is similar to the one shown in the example associated to ⊑-rule # 1.
The new relationship hasSport ⊑ ∃f rom.OlympicSport will be suggested by the rule, as depicted in Fig. 2b in dashed line, and thus it will allow to optimise the ontology and reduce the underlying representation as follows (as long as user decides to remove the redundant existing relationships).
W interSport ⊔ SummerSport ⊑ OlympicSport
hasSport ⊑ ∃f rom.OlympicSport OlympicSport hasSport min ⊑ OlympicSport ⊓ (≥ 1 f rom−.hasSport) OlympicSport hasSport max ⊑ OlympicSport ⊓ (≤ 1 f rom−.hasSport) c-rule {A1 ⊑ ∃r1.C1, C2 ⊑ C1, A2 ⊑ A1, A2 ⊑ ∃r1.C2, C1 ⊑ ∃r1−.A1} ⇛ {C2 ⊑ ∃r1−.A2}
The c-rule intends to capture those cardinalities that cannot be logically deduced but they can be considered as graphically intuitive in models such as the ontology shown in Fig. 3a. At first, nothing can be concluded about the minimum participation of r1 relating C2 with A2, since the A2 relationship may not contain all instances of C2 in the A1 relationship. Nevertheless, from an intuitive and graphical point of view, we consider that this minimum participation could be inherited since both C2 and A2 are subclasses of C1 and A1 respectively, then they have the same properties than their parents. In certain contexts, the crule can be considered as an instance of the Gangemi’s pattern named Role task where C2 is a role, which is represented in the pattern as a concept that classifies an object, and A2 is a task. While the pattern does not explicit any cardinality, we conclude that roles make sense only if they have at least one task associated.
According to Guizzardi’s definitions, this rule can be also considered as an
instance of the Role Modeling Design pattern [
A1 A2 r1 r1
C1 C2 as a role, i.e. an anti-rigid type similar to phase type but the changes among subtypes occur due to changes in their relational properties. As a consequence, there exists a relational dependence between C2 and A2 which requires minimum cardinality ≥ 1 in order to justify the existence of A2 in the model. Example 3. Let us suppose the following partial ontology Ω from Phone domain, which is depicted in Fig. 3b and translated to DL as follows. Ω models calls and mobile calls which could have different origins.
Call ⊑ (≤ 1 r1−.origin)
Call ⊑ ∃r1−.origin origin ⊑ ∃r1.Call Call origin min ⊑ Call ⊓ (≥ 1 r1−.origin) Call origin max ⊑ Call ⊓ (≤ 1 r1−.origin)
mOrigin ⊑ ∃r1.M obileCall M obileCall mOrigin min ⊑ M obileCall ⊓ (≥ 1 r1−.mOrigin) M obileCall mOrigin max ⊑ M obileCall ⊓ (≤ 1 r1−.mOrigin)
M obileCall ⊑ Call mOrigin ⊑ origin
According to rule description, M obileCall ⊑ ∃r1−.mOrigin could be proposed to extend Ω. Notice that intuitively only one origin is possible for any call so that this could be considered for a mobileCall since it is also a call. r-rule
{C2 ⊑ C1, A1 ⊑ ∃r1.C1, A2 ⊑ ∃r2.C2, A2 ⊑ A1} ⇛ {r2 ⊑ r1}
The aim of this rule, depicted in Fig. 4a, is to find recurrent ontological
structures where a hierarchy of roles can be defined and suggested. From a
logical point of view, if A2 ⊑ A1 and A1 ⊑ ∃r1.C1 then A2 ⊑ ∃r1.C1. Moreover,
if C2 ⊑ C1 and A1 ⊑ ∃r1.C1 then A1 ⊑ ∃r1.C2. Consequently, both A2 and C2
concepts are related to C1 and A1 respectively through r1 so that there could
exist unexpected relationships between A2 and C1 or C2 and A1. This scenario
can be identified as the Relation Specialization anti-pattern in [
A1 A2 r1 r2 C1 C2 Example 4. Fig. 4b shows a model extracted from ontology Phone and how the rule can be applied to this model. Let us suppose that two instances PhonePoint, for example phonePoint1 and phonePoint2, are related to origin1 and origin2 respectively. Notice that without asserting r2 ⊑ r1 and if both phone points are considered as instances of Cell then it could not be guaranteed that these cells belongs to the same origin. 3
All the logical systems suppose ideal objects but they do not consider the information about the reality or intuition. This explains that only those axioms implied by the current models will be suggested as possible ontology evolutions. Nevertheless, if we consider the modelling as an approach based on empirical facts, we need something more than only the formal logic. We need observations, experiments and pattern analysis to confirm our hypothesis. The benefit of a rules-based approach is to offer a trade-off between the inherent rigidity to the logic systems and the intuitive characteristics of the ontological modelling.
Similar to our approach, Guizzardi in [
In order to analyse the current graphical tools, we consider the following
key factors: the graphical, automatic reasoning and evolution support and their
integration in the tool. OntoUML [
The intention behind rules is to reduce the complexity of the evolution process and they are defined to be implemented within a graphical tool. Nevertheless, they cannot be isolated from other complementary artefacts such as user queries which allow to identify relevant parts of an ontology and back-end reasoning systems which allow to inquire the model to check rules applicability and their possible consequences. In any case, it is the user who decides which of the suggestions (rule consequences) are appropriate, if any, according to his intended model. 4
This work introduces a small catalogue of extension rules which intends to
capture the intuitive characteristics inherent to the ontology modelling. Each rule
has been defined and analysed by considering different theories of design patterns
and by showing the intended meaning through illustrations where the intuition
is presented. The aim is to place emphasis on a reduced search space of possible
ontology extensions, and thus also reduce the complexity when trying with large
ontologies. This alternative offers flexibility and a fine-grained level where the
focus is on a subset of ontology elements to analyse in order to introduce new
ones, in contrast to design patterns which are not orientated towards ontology
evolution since its smallest unit of work is an ontology when in rules it is an
ontological element. Then they have the effect of changing only the ontology
elements involved in the refactoring, which can be intra- or inter-ontology ones.
Rules must be used together with other artefacts such as user queries and
backend reasoning systems to identify relevant parts of an ontology and check the
consequences of application on the whole model. Furthermore, the modularity is
a key property in this approach so that some changes on the set of rules are
independent of the underlying methodology. An example about the usage of these
rules in a methodology has been published in [
As future works, we propose to identify new extension rules and define a logical formalism as an application framework for these rules. The rules will be also evaluated by means of two techniques such as a behaviour-based one, which will allow us to register the number of suggestions accepted by user, and
an opinion-based one, which will enable us to elicit users opinions about the
use of them [