Ontology engineering on the web requires a well-defined ontology module system that allows sharing knowledge. This involves declaring modules that expose their content through an interface which hides the way concepts are modeled. We provide a straightforward syntax for such modules which is mainly based on ontology alignments. We show how to adapt a generic semantics of alignments so that it accounts for the hiding of non-exported elements, but honor the semantics of the encapsulated ontologies. The generality of this framework allows modules to be reused within different contexts built upon various logical formalisms.
Separate development. Since what imported modules provide is well-defined, software developers can rely on this interface and develop their own part. This would be useful as well for ontology development in which one can concentrate on the development of part of the model while the part it is relying on are still underspecified.
Separate compilation decreases development time by avoiding recompiling huge
applications at every change. This has has been ackled by [
Reusability. Because module specifications are descriptions of a coherent and explicit set of primitives that a module is meant to provide, a module can be reused in another similar context.
Separate execution allows to be more efficient by executing local code first. In
ontology engineering, this is especially useful for inference system [
This paper describes a framework for making modules that can offer most of the features of software engineering modules. Other features like modularization of existing ontologies or optimizing particular properties (e.g., inference needs) are not considered here. As far as designing modules is concerned two approaches can be considered: Composing (M ( M10 : : : M n0) is the favorite approach in software engineering where a software is built by assembling modules; Partitioning (O ) O10 : : : On0) is the back-up strategy when one starts with some monolithic software (or ontology) and attempts at transforming it into a modular software. Depending on the reasons to do this (allowing separate inference or generating modules for reuse), the results may be different.
Some other approaches aim at identifying the subparts of ontologies required for
interpreting some particular piece of knowledge [
We adopt here an ontology engineering approach to modules: we do concentrate on how to specify reusable modules rather than how to partition legacy ontologies. Of course, for this to work correctly, the perimeter of each module must be precisely defined and interfaces between modules be precisely designed. This requires to be able to express what is visible or hidden, thanks to the definition of interfaces. Moreover, in order to reuse modules designed independently, the module infrastructure has to provide means of relating them in a consistent way. This is achieved by specifying—or referring to existing—ontology alignments in the modules. This way, the module framework can take advantage of ontology alignment technologies, in particular alignment composition. These modules can replace ontologies wherever they are used. For that purpose, we must define their semantics, i.e., what are the consequences of an ontology module. We propose a syntax for specifying explicit modules that can be reused and provide the hiding properties that have been considered and that allows relating modules with alignments. We give a thorough overview of existing module semantics and analyzes their appropriateness with regard to the desired features. We show that our module framework can be adapted to most of these logical formalisms.
We will first motivate this work with a concrete example in Sect. 2. We will then provide a syntax (Sect. 3) and describe a generic semantics (Sect. 4) that can be adapted AF
LH Plane
Flight
City Flug Stay
Flight
BA Train
Town Rail
Trip
Country Package
Country Region
City BoatTrip
Geo
Boat Excursion Accomodation
Transportation
Animation TravelAgent to most of the existing module languages. Last, in Sect. 5, we discuss the advantage of using such or such formal semantics with regard to the desiderata we provided here, and finally compare this work to other work on the same topic, that have been recently published. 2
Imagine an integrating application like a travel agent that sells packages including travel tickets and hotel stays, among other products and services. It is necessary that this agent be able to use information provided by other sources. For that purposes, it will take advantage of other modular ontologies. For instance, this TravelAgent module will provide packages including trip, accommodation and excursion and will rely on other more qualified sources to define these facilities that it sells. These imported modules will provide the necessary information about Transportation, Accommodation and Animation. This is displayed in Fig. 1.
Defining the module’s imports: A module like TravelAgent is an aggregating module that generates new services by aggregating previously available information. Transportation is a module that provides a homogeneous interface to other heterogeneous ontologies. For instance, this ontology could rely on several ontologies provided by specific providers: Plane, Rail, Boat, for transportation means ontologies and Geo for geographic information. So our module language should allow to express that: – Module Transportation uses Modules Plane, Rail, Boat and Geo.
In fact, Transportation will only import specific information from the other modules: destinations and origin properties of the Flight class but not planeNumber ; BoatTrip from the Boat module, but not Cruise . For that matter, the language has to express: – Module Transportation imports Class Flight and Properties originCity , destinationCity , company , price, tax and date from Module Plane. – Module Transportation imports Class Train and Properties startStation, endStation, fees and date from Module Rail. – Module Transportation imports Class BoatTrip and Properties boardingPort , unboardingPort , price and date from Module Boat. – Module Transportation imports Classes City and Country and Property partOf from
Module Geo.
Declaring the module’s content: The goal of the Transportation module is to provide the Trip class which will describe trips between two cities. It will also provide some refined classifications of them such as DomesticTrip and InternationalTrip: – Module Transportation defines Class Trip with Properties from which must be a City , to which must be a City , price which must be an Integer, date which must be a Date and means which must be a String. – Module Transportation defines Class DomesticTrip as a kind of Trip. – Module Transportation defines Class InternationalTrip as a kind of Trip. – Module Transportation exports Classes Trip, DomesticTrip, InternationalTrip and Geo:City and Properties from, to, price, date and means.
Additionally, the Transportation module will provide more information about its core business, that is, its ontology definition. It will define what is the information that it describes: i.e., Trip and its subclasses: – A DomesticTrip is a Trip which starts from the same country as it is going to. – An InternationalTrip is a Trip which is Not a DomesticTrip.
Aligning different modules: the Transportation ontology will have to provide a way to map the export interface of the various ontologies into entities used in its body or in its export interface. This is expressed by correspondences like the following: – Class Flight in Module Plane is a kind of Trip in Module Transportation such that Property means is equal to "plane". – The sum of Properties price and tax of Module Plane corresponds to Property price of
Module Transportation. – Property originCity of Module Plane corresponds to Property from of Module Transportation. – Property destinationCity of Module Plane corresponds to Property to of Module Transportation. – Class Train in Module Rail is a kind of Trip in Module Transportation such that Property means is equal to "train". – Class BoatTrip in Module Boat is a kind of Trip in Module Transportation such that
Property means is equal to "boat". – Property country of Module Transportation corresponds to Property partOf of Module Geo with a range restricted to Class Country of Module Geo.
Of course, the Plane module itself may be the integration of the ontologies of various providers (LH, AF, BA). No one would require that ontologies modeling these providers are semantically compatible: this is why such correspondences are needed. The case of the Plane module is interesting since it can take advantage of existing available alignments (see Fig. 1). Such alignments could exist in an alignment repository, and the module framework should allow to refer to them. Note that the correspondence involving Property country is not expressible in OWL so far, because range restrictions only apply to classes, not properties.
Summarizing our needs: In summary, in this example, we would like to use some external modules in such a way that: – What is exported by each module is precisely defined:Transportation exports Trip; – The importing module can restrict the imported entities that are used: TravelAgent can import Stay but not Meal from Accommodation for instance; and – The imported entities can be rewritten by matching the imported entities to internal forms: a Flight is matched to a Trip.
But by doing so we would like that some semantic consequences apply to modules. In particular we want that: – What is true of a Flight in BA is also true of a corresponding Trip in Transportation; – Whatever consequence of BA that does involve entities not imported in Transportation is not necessarily a consequence of Transportation.
These intuitions will be made more precise later.
This organisation provides independence between the different modules that participate in the module system. The only contract between two modules is that they provide definition for the elements in their export interface.
In particular, modules do not provide any guarantee on the “implementation” of these modules, i.e., the axioms that govern the concepts defined inside the module. As a result, the implementation of a module can be improved without altering the export interface and thus without preventing the application to work. This is encapsulation.
On the contrary, if the export interface is modified in such a way that the application will not be able to work, this can be checked without looking at the axioms. This ensures the separate development property for these modules. For instance, the Flight modules may integrate new company ontologies without changing its export interface.
This also allows to reuse modules more easily: if a new better module providing Rail information is available, it can, as soon as it provides the same export interface, replace the old one without breaking the whole application. The Geo module has typically been reused from an external source.
These properties require a particular semantics for these modules that differ from the classical semantics that would result from the transitive closure of imports in OWL Feature Description Syntactical representation id Module identifier URI reference
IMPORT INTERFACE uses List of modules URI references imported-entities List of ontology entities from im- URI references or keyword ALL ported modules
DEFINITIONS alignments List of alignments URI references or locally defined correspondences content Entity definitions and axioms either an external ontology identified by a URL or axioms that can use imported classes and properties
EXPORT INTERFACE exported-entities List of entities from either the on- given by URI references or by keytology defined in content or from words ALL or ALL* the imported entities in imports comments Textual description of what the a character string
module is made for (that is the union of all axioms of the transitive closure of imports). In particular, the consequences of a module can only be formulas made of the concepts and properties in the interface of modules and as soon as a module does not export the entities that it imports, they are not visible anymore from importing ontologies.
We provide a concrete syntax for doing this and we define a generic semantics that encompasses several specific formalisms. We discuss to what extent these formalisms can satisfy the requirements. 3
This section introduces the various features that can be put in a module definition and proposes a general module definition for ontology language. We will mostly rely on Description Logics (like OWL) as an ontology language. However, the semantics can accommodate other languages as we show in Sect. 4. 3.1
Module features A module contains an ontology definition which can use entities of imported modules (i.e., classes and properties). So the module syntax proposed here imposes that imported modules be clearly specified, and only entities from these modules are used, in addition to locally defined ones. In order to correlate potentially heterogeneous imported modules, they are related thanks to ontology alignments, that may be defined locally into the module definition or referred to with a URI reference. Finally, in order to ensure encapsulation, the module definition explicitly states which entities are exported, i.e., which ones are allowed to be used by other importing modules. Additionally, there should be a textual description of what the exported concepts represent, which should explain what is guaranteed to stay true throughout the evolution of the module. This allows specifying the behavior of the module while not displaying the internal implementation. In particular, only the terms given in the export interface need to be showed to external users. These elements are presented in Table 1.
Of course, the module content (i.e., alignments and ontology) can only refer to imported ontology entities that are part of the import interface. In turn, the import interface can only refer to entities which are part of the export interface of the imported modules.
Alignments and ontologies can be referred to by a URI reference, which means that it is possible to reuse published alignments and ontologies independently of a module definition. In this case an ontology is interpreted without its owl:import features.
The graph of imported modules, i.e., the uses relation, must be acyclic.
We have defined an RDF/XML syntax that follows the same structure. Instead of
using this equation based syntax, it reuses the RDF/XML syntax of OWL and that of
the Alignment format [
Definition 1 (Ontology module). An ontology module M = hid; M; I ; A; O; Ei is a sextuple such that: – id is a URI identifying the module; – M = (Mi)i2J is the set of imported modules defined over a set of indices J ; – I = (Ii)i2J is the import interfaces for M ; – O is the content ontology, defining local terms and local axioms that may use imported terms; – A = (Aij )i;j2J is a set of alignments interconnecting ontologies from M or O, and – E is the export interface of M.
A base module encapsulating an ontology will typically be expressed as hid; ;; ;; ;; O; Ei.
We must now introduce the other elements. Ontologies can be seen as OWL
ontologies but, as we will see, the semantics does not need to rely on this assumption.
An alignment is a restriction of the definition of alignment found in [
Alignments are based on correspondences which relates entities from two ontologies: 3 An example of the concrete XML syntax can be http://www.inrialpes.fr/exmo/people/zimmer/module.xml. found at Definition 2 (Ontology alignment). An ontology alignment between ontologies O1 and O2 is a set of triples he1; e2; ri such that: – e1 2 O1 and e2 2 O2 are ontology elements (e.g., class, properties, individuals) from the two ontologies to align; – r is an alignment relation (taken from a given set R) that is asserted to hold between e1 and e2 (e.g., subsumption, equivalence, disjunction, etc.).
These triples are called correspondences.
It is clear that any module described with the concrete syntax can be translated in a module description in the abstract syntax. 4
The semantics describes how to interpret modules and what are the semantic consequences of a module. In this section, we do not describe a specific semantics, but rather we give generic notions that are common to most of module logical formalisms.
Whichever formalism is used, there is a need to differentiate between local interpretation of a module (i.e., interpretation of the ontological content) and global interpretation which takes into account imported modules and alignments. This section first present the local semantics with very general definition (§4.1). Then, a generic semantics of alignments is proposed (§4.2). Finally, we describe the notions introduced by the global semantics (§4.3). 4.1
Local semantics
Since many ontology languages can be used to specify the local content of a module, we
will give a very general definition of interpretation and models of an ontology. However,
as in our examples, the ontology language will typically be a Description Logics (e.g.,
OWL-DL), as it is the case in most of existing modular ontology languages (in fact, all
but E -connection [
All the modularization formalisms have in common that a local ontology O is characterized by its signature4 S and a set of axioms built over this signature.
To each ontology language is associated a notion of interpretation I which is a mapping from the elements of a signature to elements of a domain of interpretation , and a notion of satisfaction j=l which relates interpretations to the axioms they satisfy5. A model of an ontology O is an interpretation I of the signature of O that satisfies all of its axioms. 4 The signature of an ontology is the set of syntactic elements (e.g., classes, properties, individuals) used in O. 5 In order to differentiate the interpretations of (non-modular) ontologies and the interpretations of modules, we use the term “local” when we interpret the ontological (non-modular) content of a module, thus the indice l in the satisfaction relation j=l. An alignment connects entities from 2 different ontologies. Interpreting them implies interrelating both ontology interpretations. In the literature, there are several ways of expressing correspondences in alignment. They can be plain ontological axioms, bridge rules, queries, or E -connections.
Nevertheless, all these formalisms can be describe with the definition given in §3.2 with a common “meta-semantics”. Relation symbols r 2 R appearing in the correspondences are associated to a binary relation r, of which definition is specified by the e modular ontology language used.
Definition 3 (Satisfied correspondence). Let c = he1; e2; ri be a correspondence in an alignment between O1 and O2. If I1 and I2 are interpretations of O1 and O2 respectively, then hI1; I2i is said to satisfy c iff e1I1 ree2I2 . This is written I1; I2 j= c.
For instance, consider an alignment language where relation symbol v is associated to the inclusion of sets, i.e., ve is . In this case, he1; e2; vi is satisfied iff e1I1 e2I2 . Definition 4 (Model of an alignment). Given two ontologies O1 and O2 and an alignment A of O1 and O2, a model of A is a pair hI1; I2i such that for all c 2 A, I1; I2 j= c. The set of all models of A is written Mod(A).
With this definition, the models of an alignment do not have to satisfy the ontologies. This is useful when one needs to determine consistency of an alignment, but do not have access to the ontologies, or when for other alignment manipulations. Moreover, this also ensures encapsulation at the alignment level, since it prevents alignment satisfiability to be dependent on a particular ontology implementation. Sect. 5 describes how existing alignment formalisms comply with these abstract definitions and discusses their advantages and disadvantages.
With the notable exception of E -connection, all these formalism can be adopted to provide a formal semantics to alignments in our module framework. The next section describe the global module semantics. 4.3 Interpreting modules In the most general case, the interpretation of a module is recursively defined in function of the interpretations of its imported modules. This recursive definition assumes that there is no cycle in the import chain, so each chain eventually leads to a base module with no import. Detection of cycles should be syntactically checked, since this definition is not well founded otherwise. If one thinks in term of software engineering, this is not a major limitation. Indeed, when a new module is designed, it has to import existing modules. This way, it is not possible to have cyclic references.
Definition 5 (Base module interpretation). Let M = hid; ;; ;; ;; O; Ei be a base module. An interpretation of M is a local interpretation I of the content O of M, with domain of interpretation D.
Definition 6 (Module interpretation). Let M = hid; M; I; A; O; Ei be a module. An interpretation of M is a triple I = hI; (Im)m2M ;ei such that: – I is an (local) interpretation of the content O of M, with domain of interpretation
D. D is also called the domain of interpretation of module M; – For each imported module m 2 M , Im is a module interpretation of m over domain of interpretation Dm; – e is a mapping that associates to each r 2 R a binary relation re according to the corresponding semantics of alignments (see §5.1 for specific alignment semantics).
In order for an interpretation to satisfy a module, there are four conditions: 1. the local interpretation must be a model of the content of the module, i.e., all local axioms must be satisfied; 2. the imported modules must be satisfied by their respective interpretations; 3. the alignments between the imports must be satisfied by the respective pairs of interpretations; 4. finally, the local interpretation and the imported modules interpretation must agree on the interpretation of the interface I. hI; (Im)m2M ;ei of M, I j= .
The fourth item is a bit ambiguous. The notion of “agreement” on the interpretation actually depends on the specific formalism used. This is discussed in the next section.
In order to reason with modular ontologies, we have to define what are the semantic consequences of a module. They are defined as follows: Definition 7 (Consequences of a module). Let M = hid; M; I; A; O; Ei be a module. Let be an axiom built upon the signature of the content of M (which includes the import interfaces of I). is a consequence of M, written M j= iff for all models
Obviously, if a formula is a consequence of the content ontology of a module, then it is a consequence of the module itself.6 Additionally, it is desirable to derive knowledge about the imported terms according to the imported modules knowledge. However, if something is true about a concept C in a module, it is not necessarily true in another module that imports C.
Depending on the formalism used for module semantics, knowledge that is transfered from imported to importing modules varies. The next section describe how candidate semantics fits within our module framework, and discuss the relevance of each existing formalism. 5
Work related to modular ontologies has expended greatly in recent years. We will divide
this section into two parts. The first focuses on logical formalisms developed to reason
with modular ontologies. We show that our modular framework can be adapted to most
of them, but some better guarantee the properties that we advocate. The second section
presents other related work.
6 Note that only the consequences related to the exported terms are useful to an external module
that imports them.
An already deep and interesting discussion about modular ontology languages have
been carried on in [
Modular ontologies without ontology languages: It is possible to implement
modules without any specific formal language dedicated to it. [
Morevoer, in [
Nonetheless, an advantage of this approach is that the consequences of a module
relative to its export are correctly transfered to the modules that import it.
Modularity without alignments: This is the approach offered by P-DL [
Pan et al. [
Using bridge rules: Bridge rules were introduced with DDL [
Because of the domain relations, this type of semantics very well comply with
heterogeneous knowledge. However, they lead to unintuitive inferences, that are partly
solved by [
A non-directional version of bridge rules is given in [
Relating ontologies via queries: In [
E-connection: E -connections [
Other related work
Since non-modular ontologies already exist, several teams are working on extracting
modules out of existing large ontologies [
Modularity with CASL as described in [
Ontology modules are now urgently needed on the semantic web: the lack of support for modules in OWL has to be corrected. Most of the effort has so far concentrated on partitioning ontologies for providing more efficient reasoning, or on studying the semantic properties that have to be ensured by a module system. Real engineering facilities were often overlooked, with notable exceptions.
In this paper we have rather focused on ontology modules from an ontology engineering standpoint. As such, the important properties of modules are encapsulation, information hiding, replaceability of modules and reusability. Moreover, a module system should provide some glue in order to align the interface between imported modules or imported and importing modules.
From this perspective, we designed a module system reusing ontologies and ontology alignments. This ensures a flexible accommodation of existing external ontology alignments. We provided a syntax allowing the specification of what is imported and exported by a module, while not being stuck to a particular logical formalism. The concrete XML syntax is grounded on OWL ontologies and the Alignment format.
An important issue is to define what are the consequences of a module in the same way the consequences of an ontology are defined. We showed how to accommodate existing modular ontology formalism in order to reason with modules. Unfortunately, we showed that none of them gathers all the properties expected from a modular system. Yet, our framework is general enough to capture many ontology and ontology alignment languages, and considers alignments as distinct objects that can be manipulated separately.
According to this specification, we are currently developing a module system able to fully take advantage of existing OWL ontologies and alignments. In the near future, we will integrate additional facilities for the export interface, that will allow to guarantee by proof that a property holds for the exported terms (like invariance of the concept hierarchy).