Aspect-Oriented Ontology Modelling

Ontology reuse and integration are mainly hindered by two factors: a lack of contextual information about the contents of an ontology, and a lack of means to identify, examine and reuse only the parts of an ontology that are useful in the context of the scenario at hand. In this work package, we develop a flexible and dynamic approach to ontology decomposition based on requirements from different stakeholders, inspired by the Aspect-Oriented Programming paradigm (AOP).

Existing ontology modularization approaches aim at creating meaningful partitions of large ontologies. However, the criteria for what a meaningful partition is is highly dependent on the use case at hand and may even change within the same application.

In software engineering, this kind of multi-faceted requirements is referred to as cross-cutting concerns 1 because they emerge on different levels of an application and reflect different points of view on and goals of a software system formulated by different stakeholders. Cross-cutting concerns are omnipresent throughout the system and cannot easily be encapsulated in separate modules. Likewise, different parties involved in the development or later usage of an ontology may have completely different assumptions about the conceptualization formalized in the ontology. We believe that introducing a formal specification of the assumptions behind a certain conceptualiization and attributing it to the relevant parts of an ontology help understanding and adaptation of ontology parts to the needs of diverse user groups.

For example, a vendor of photography gear may deploy an ontology about digital cameras. Different actors will have a completely different view on the product.

Cross-cutting concerns in an ontology by the example of the concept of a digital camera.

Cross-cutting concerns in an ontology by the example of the concept of a digital camera.

Potential customers see a digital camera as technical device and are interested in features such as chips size, pixel size, and file formats the device supports. The sales team, on the other hand, sees the camera in terms of a sales item, with features such as wholesale price, profit margin, and the number of units in stock. The fact that these properties are part of the conceptualization is based on requirements formulated from each stakeholder's point of view. Because these requirements concern the functinality of the ontologies, i.e., the concepts and relations the ontology is supposed to specify, they are referred to as functional requirements. Besides that, further requirements may exist that do not concern the actual functionality of the ontology but are still relevant in the context of the application. Examples for this sort of requirement are the need for provenance information, temporal attributions (e.g., validity periods for certain facts, such as temporary special offers), and reasoning efficiency (as outlined above). This type of requirement is referred to as non-functional requirements.

Each of these requirements or concerns affect a particular subset or module of the facts contained in the ontology. The modules might be overlapping, i.e., a certain fact might be associated with multiple concerns.

In an application, different concerns can become relevant or irrelevant at particular points in time. Using the notion of aspects from Aspect-Oriented Programming and applying it to ontology modules, it will be possible to dynamically adapt the ontology to the situational context, the user's point of view and current requirements, such as expressiveness vs. reasoning efficiency.

Research Associate: Ralph Schäfermeier


AOOD-related technologies

  1. As defined by the IEEE standard 1471 of software architecture "concerns are those interests which pertain to the system’s development, its operation or any other aspects that are critical or otherwise important to one or more stakeholders"