Introduction

The majority of existing modularization approaches are specialized solutions, relying on semantic (cf., for example, [1][2][3][4][5]) or structural relatedness (e.g., [6][7][8]) and are only parametrizable to a limited degree. Parameters often reflect the internal operational mode of the modularization algorithm rather than requirements concerning the expected outcome of the modularization process from a user's point of view. Moreover, requirements may be related to different dimensions of the problem space. They can comprise functional requirements, i.e., requirements directly related to the problem domain or the task an ontology or ontology module is supposed to fulfill, and non-functional requirements, such as provenance information, multilingualism, or tractability of reasoning tasks.

The aspect-oriented programming paradigm allows for the separation of multidimensional requirements into dedicated software code modules (aspects), leading to better code modularity and therefore reusability. Using AOP, modules can be recombined (interwoven) either extensionally, by explicitly marking the points in the code where the execution flow should be diverted to a different module, or intensionally, by specifying a set of properties such code points are expected to have in common.

In this paper, we examine commonalities between ontology modules and software aspects and describe our ongoing work towards the application of the above mentioned principles of the AOP paradigm to ontologies. We argue that the latter enables (a) straightforward development of modular ontologies from scratch, and (b) flexible a-posteriori modularization, driven by user requirements.

Aspect-oriented software programming (AOP) languages provide syntactic means for the separation of so called cross-cutting concerns in software code into dedicated modules. As defined by the ISO/IEC/IEEE standard 42010 of software architecture1 , "concerns are those interests which pertain to the systems development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders". Cross-cutting concerns are concerns which emerge from requirements on different levels, concern the entire or a significant part of the system and are thus scattered across the system, diminishing code locality and hindering system evolution and reusability [9]. See Figure 1 for an explanatory example of cross-cutting concerns. In AOP terminology, the encapsulation of a single concern in a dedicated module is referred to as aspect. An aspect consists of two components: the actual implementation of the functionality, referred to as advice, and information about all points in the application's control flow at which the advice should be executed, referred to as join points. In this manner, we use the notion of aspects in order to relate ontological constructs to different requirements (see Figure 2). Listing 1.1 shows an example of a concern "authentication" that cross-cuts with the actual business logic of a bank application and leads to tangled code. Listing 1.2 shows how the authentication concern is encapsulated in an aspect "Authentication". The authentication handling code has been centralized in the advice of the aspect. Note that this example demonstrates the explicit (extensional) variant of join points, in the form of tags assigned to each part of the code where an aspect is applicable. In order to achieve complete detangling of cross-cutting concerns, AOP introduces two principles: quantification and obliviousness.

Quantification

AOP allows for an intensional definition of join points by using quantified statements in the form

∀m(p 1 , . . . , p n ) ∈ M : s(m(p 1 , . . . , p n )) → (m(p 1 , . . . , p n ) → a(p 1 , . . . , p n )),

where M is the set of all methods defined within the software product, s a predicate specifying the join point properties, m(p 1 , . . . , p n ) ∈ M a method adhering to the signature m(p 1 , . . . , p n ), and a(p 1 , . . . , p n ) the execution of the advice with all the parameters of each method, respectively [10]. The set of all join points defined by s is called a pointcut.

In the case of the authentication example, an instantiation of this formula would be:

∀m(p 1 , . . . , p n ) ∈ M : sig(m(p 1 , . . . , p n )) = m(Account acc, f loat amount) → (m(acc, amount) → Authentication(acc, amount)).

In order to select ontology axioms in the same fashion, a means of quantification over such axioms is necessary.

∀ax(p 1 , . . . p n ) ∈ O : s(ax(p 1 , . . . p n )) → (ax(p 1 , . . . p n ) → a(ax(p 1 , . . . p n ))),

with O being an ontology, ax(p 1 , . . . p n ) axioms (in the form of n-ary predicates the domain of which is the union of the vocabulary of the ontology language in question and the vocabulary of the problem domain, such as class, property and individual names), and a(ax(p 1 , . . . p n )) a function that applies the aspect to ax(p 1 , . . . p n ), whereupon we define the application of an aspect to an axiom as the inclusion of that particular axiom in the module represented by the aspect. In this manner, the aspect "tractability" from the example scenario could be implemented by building a query that selects all axioms which are compatible with the OWL-EL profile. As mentioned in section 1, join points can also be specified extensionally, for example, by manually annotating axioms which cover a particular aspect with a dedicated OWL Annotation (see Figure 3). This is of particular use for a priori modular ontology development if used, e. g., by an ontology editor with switchable contexts, each context representing an aspect. A user could then extensionally define an aspect-oriented ontology module by switching aspects.

Obliviousness and Harmlessness

The fact that in aspect-oriented software systems control flow is handed over from the main module to the aspects, making the main module (and any other modules) unaware of the (quantified or extensionally specified) assertions made about it by external aspects that might possibly be applied to it, is termed obliviousness [9]. The practical consequence of obliviousness is that the developer of a module is not required to have knowledge about or spend additional effort in anticipation of a possible application of an aspect to her module.

Danters et al. allude to the problem that obliviousness is only guaranteed on a syntactic level while external aspects have in fact the potential to alter the semantics of the target module, making them potentially dangerous [11]. They propose the adaption of the harmlessness property for aspect-oriented systems, defining a harmless aspect as an aspect which, when applied to a target module, does not alter the semantics of the target.

While it is obvious that the obliviousness property naturally holds for ontology modules, the harmlessness property does not. Nevertheless, it is agreed upon in the recent literature that it is desirable if an ontology module is uninvasive, i.e., its addition to an ontology has no side effects. Whether uninvasiveness of a module applied by the means of an aspect is a required feature or not depends on the specific use case.

Grau et al. [12] as well as Konev et al. [13] propose the notion of conservative extensions which guarantee that a module added to an ontology does not alter the meaning of the original ontology:

Let O 1 ⊆ O ontologies, S a signature and L a logic. O is a conservative extension of O 1 wrt. L, if for every axiom ax with sig(ax) ⊆ S: O |= ax iff O 1 |= ax.

In the same vein, we define a harmless aspect of an ontology O as an aspect that yields the selection of a module O 1 that is the conservative extension of O with respect to L.

It has been noted that determining whether a module is a conservative extension of an ontology is a highly complex problem and even undecidable for expressive ontologies [12,13]. However, semantic locality is a sufficient condition for a conservative extension [4], and [14] suggests that the less complex syntactic locality constitutes a practically acceptable approximation.

Conclusion and Future Work

In this paper, we pointed out that ontology modularization and aspect-oriented programming share interesting commonalities and that the aspect-oriented paradigm can be applied to a priori modular ontology development as well as a posteriori module extraction. The next step will consist in providing a proof-of-concept system that dynamically interweaves aspects defined in the above manner.

Further work is necessary in order to achieve a functional meta description of ontology axioms for the purpose of pointcut definition. The formalism described in section 2.1 works in terms of meta predicates with the domain consisting of vocabulary of the ontology language, reifing axioms contained in the ontology.

The research question raised in this paper is how the application of the aspect-oriented paradigm affects the quality of ontology modularizations. Our hypothesis is that aspect-oriented ontology development yields useful ontology modules wrt. to cross-cutting modularization requirements, such as dynamic access, understandability, maintenance, and re-use. We expect that the intensional specification of ontology modules with pointcuts adds dynamicity and flexibility to modular development, making it easier to evolve modular ontologies in situations where evolution implies modularization requirement changes.

To evaluate our approach and test our hypothesis, we will apply the approach to different modularization use-cases in the context of ontology development projects. Aspects considered in these use cases will comprise project affiliation, temporal attribution, workflow affiliation, re-use, and module understandability. We then use quality metrics in order to assess the quality of the modularizations gained using our approach and compare it with existing approaches.