Ontology content patterns are meant to be used not only for new ontologies but also for reengineering of existing ontologies. However, the modelling style of such ontologies often differs from the best-practice pattern that is to be imported to their root portions, which makes the integration of the two models time-consuming and error-prone. We explore how the recently developed PatOMat transformation framework could be applied to ease the adaptation of 'legacy' ontologies to a widely used content pattern from the OntologyDesignPatterns.org library. We also investigate the link between transformation choices and logical patterns as those earlier proposed by the W3C SWBPD Group.
Ontology content patterns [
In the easiest setting, generic CPs can be (as kind-of foundational ontology fragments) ‘passed under’ the current root concepts of the ontology. However, as the same conceptualisation can be expressed using different modelling styles in a language such as OWL,1 the need for style transformations may often arise. A straightforward example of such transformation is change from ‘class-centric’ to ‘property-centric’ style, or vice versa, considering that the same notion can be modelled as a class (e.g. ‘Purchase’) or an object property (‘bought from’).
In our previous work on the PatOMat project,2 we already addressed the
general need for style transformation in ontological engineering. A general
framework, a simple transformation pattern language, and a set of RESTful services
1 In our framework we implicitly assume the use of OWL (possibly in version OWL 2
[
The new scenario in this paper is rather one related to ontology import. However, compared to the generic scenario of either matching or importing an arbitrary ontology into another one, we consider here a particular, small and widely reusable ontological component—a content pattern—to which an existing ‘provisional’ ontology is adapted in order to gain both in rigour and comprehensibility.
The rest of the paper is structured as follows. Section 2 briefly reviews the
PatOMat framework, transformation language and implemented prototype
services, as described in [
The central notion in the PatOMat framework3 is that of transformation pattern
(TP). A TP contains two ontology patterns (the source OP and the target OP)
and the description of transformation betweem them, called pattern
transformation (PT). The representation of OPs is based on the OWL 2 DL profile.
However, while an OWL ontology refers to particular entities, e.g. to class Person, in
the patterns we generally use placeholders. Entities are specified (i.e.
placeholders are instantiated) at the time of instantiation of a pattern. An OP consists of
entity declarations, axioms, and naming detection patterns; the last capture the
naming aspect of the OP important for its detection. A PT consists of a set of
transformation links and a set of naming transformation patterns.
Transformation links are either logical equivalence relationships or extralogical relationships
holding between two entities of different type. Naming transformation patterns
serve for generating new names for old or newly created entities. Naming
patterns range from passive naming operations such as detection of a head noun for
a noun phrase to active naming operations such as derivation of verb form of a
noun. The framework prototype implementation consists of three core services:4
– The OntologyPatternDetection service takes the transformation pattern and
a particular original ontology on input, and returns the binding of entity
3 [
placeholders on output, in XML. The structural/logical aspect is captured in the structure of an automatically generated SPARQL query; the naming aspect is dealt with based on its description within the source pattern. – The InstructionGenerator service takes the particular binding of placeholders and the transformation pattern on input, and returns particular transformation instructions on output, also in XML. Transformation instructions are generated according to the transformation pattern and the pattern instance. – The OntologyTransformation service takes the particular transformation instructions and the particular original ontology on input, and returns the transformed ontology on output.
The third service is partly based on OPPL [
As mentioned in the Introduction, the initially considered scenario for patternbased ontology transformation was the ontology matching scenario, schematically depicted in Fig. 1 (the ‘structural changes’ shown are merely illustrative and don’t claim to correspond to meaningful transformations). The transformation step here precedes the actual matching step in the whole workflow. A given ontology (possibly just a fragment thereof), which is to be matched to a second ontology, is first matched to the source OP of a TP; the choice of the fragment as well as of the TP is however guided by an analysis of the second ontology (such that the target OP of the TP should use the same modelling style as the second ontology). The transformed ontology is built in the style of the target OP of the TP. This makes the subsequent matching to the second ontology easier; e.g. simple and fast string matching methods can be used instead of sophisticated and fragile matching methods.
The content pattern import scenario (adapting a prototype ontology, via transformation, to the style of a CP), depicted in Fig. 2, differs from the previous one in the overall workflow, in the sense that the import literally precedes the transformation. Namely, in the first step, the CP is included in the ontology as a separate structure, merely subordinated to owl:Thing. Then the transformation takes place; however, only TPs specifically tailored to the given CP are considered. In the transformed ontology,6 shaped to the style of the target OP of the TP, the CP is already integrated into the ontology, as part of its root structure. 5 http://owlapi.sourceforge.net/ 6 For illustration, Fig. 2 also contains an entity B, which is not matched by the TP and thus implicitly copied to the transformed ontology.
Fig. 2. Schematic depiction of transformation for CP import
Even if a part of the input to the transformation, the content pattern, is fixed, there is potentially great variability in the ways different ontologies can be adapted to the pattern. The variability goes along (at least) three different dimensions: the style of the source pattern occurrence proper, the style of the target pattern (apart from the imported content pattern itself), and the existence of additional axioms external to the source pattern that refer to entities from the pattern. We exemplify each of these dimensions in Section 5. 4 4.1
The notion of role7 has repeatedly appeared in the history of knowledge
modelling. We will not examine this phenomenon in depth here (for thorough
discussion refer e.g. to [
For expressing general notions in OWL, essentially, one has two atomic entity types available. An ontology designer not deeply acquainted with the notion of ontological role will typically model a role implicitly, as – a class that is a subclass of a class expressing a natural concept (e.g. Teacher as subclass of Person), such that the ‘role’ class is endowed with restrictions over one or more properties (e.g. an instance of Teacher has to be teacherOf some Student and teacherAt some University ), or – just as one or multiple separate properties (such as teacherOf, teacherAt ) representing aspects of the role.
It should be mentioned that Sunagawa [
The wiki-based web portal at OntologyDesignPatterns.org contains a vast number of patterns of various types, all related to ontology design and exploitation. The most represented category is that of content patterns as immediately reusable ontology building blocks: there are 80 such patterns (though none yet certified) at the time of writing this paper. As the library aims to lower the threshold for even less experienced ontology designers, most CPs are relatively simple, yet grounded in well-designed foundational ontologies such as the lightweight version of DOLCE.8 The AgentRole pattern, depicted in UML-like notation in Fig. 3, is an example of such a simple content pattern leveraging 7 This general notion should not be confused with the term ‘role’ used for binary relation in description logics (as formal underpinning of OWL). 8 http://www.loa-cnr.it/ontologies/DUL.owl on the modular structure of imports. The AgentRole pattern, displayed with its elements in solid, specializes the ObjectRole pattern (entities from the ‘or’ namespace), which in turn specializes the Classification pattern (entities from the ‘class’ namespace), both displayed with their elements in dashed. Following from the most generic model, the Classification pattern merely allows to state the relationship between an entity and the concept to which this entity is somehow classified; this corresponds to an informal ‘reification’ of the subClassOf relationship. ObjectRole, in turn, already deals with role playing, understood as a specific type of classification;9 entities playing roles can be any objects (i.e. no arbitrary things such as properties any more). Finally, AgentRole introduces an even more specific class of such role-playing objects, called Agent, which is declared as disjoint with class Role. As core example of input ontology to be adapted, we will use an existing ontology from the OntoFarm10 collection, the ConfOf ontology. It models the domain of ‘organizing conferences’ from the point of view of a particular review (and other activity) support software: the ConfTool.11 We will however also discuss patterns alternative to those used in ConfOf.
One ‘role-playing’ fragment in ConfOf is depicted in Fig. 4. The notion of authorship is modelled as the Author class being subclass of Person. The Author class has a pair of existential and universal restriction over the writes property, and also appears in the domain of this property and in the range of its inverse, writtenBy. 9 There is a subproperty relationship (not depicted in the diagram) between isRoleOf and Classifies, and hasRole and isClassifiedBy, respectively. 10 For an overview on the OntoFarm project see http://nb.vse.cz/~svatek/ ontofarm.html. 11 http://www.conftool.net
In this section we will demonstrate the aspects of the ‘CP import’ scenario of pattern-based ontology transformation, outlined in Section 3, on the concrete setting presented in Section 4. 5.1
As natural candidates for the source pattern we can consider the simple role patterns from Section 4.1: we can call them ‘class-oriented’ and ‘property-oriented’ pattern, respectively. Obviously, ConfOf sticks to the ‘class-oriented’ role pattern. Another ontology could however, for example, avoid the Author class and model the author role merely in terms of properties such as writes and written by (or e.g. authorOf and hasAuthor ), with domain/range set to Person, this leading to the ‘property-oriented’ pattern.
In addition, due to the above-mentioned sequencing of operations, the content pattern is already present in the ontology when the ontology is submitted to transformation, and thus has to be a part of the source pattern. However, it is unconnected to the rest of the ontology (and source pattern) yet. 5.2
Obviously, the content pattern is transferred to the target pattern without change. However, the way the rest of the source pattern occurrence is shaped and linked to the content pattern may vary.
Note that, in the particular context of AgentRole pattern and the
classoriented role modelling style of ConfOf, the transformation of the notion of
‘author’ from a (seemingly) natural concept to a role amounts to transition from
the ‘instance of’ relationship (being a language primitive in OWL DL) to the
hasRole relationship (i.e. object property). By consequence, the fact of a person
having the author role, which was previously expressed as e.g. “John rdf:type
Author”, now has to connect the individual John to some ‘author role’ entity
through the hasRole property. Assuming we formalise the author role as class in
the target pattern, we arrive to an instance of the “defining classes as property
values” problem, treated as a logical pattern in [
From the set of five ‘modelling approaches’ (actual logical patterns, in fact) of
this published pattern we will only consider those expressible in OWL DL. This
eliminates “Approach 1: Use classes directly as property values”. The remaining
are, in turn (in the original terminology of [
Transformation to Approach 2. It may lead, assuming some naming transformations, to the situation depicted in Fig. 5 (we omit the namespace prefixes and don’t distinguish imports, for better readability). The Author class was removed, while there is a new class, with the same name but different meaning, subordinated to Role; there is now also now a distinguished instance of the latter class, called AuthorRole12 (in rounded rectangle) as part of the ontology. While populating the transformed ontology, an instance of Person can be connected by the hasRole property with the AuthorRole individual.
ConfOf models authorship in a simple way such that there are no subclasses of Author. However, if there were such subclasses (e.g. PosterAuthor ), they would be transformed to subclasses of the new Author class; each such class would also have a corresponding individual (e.g. PosterAuthorRole) as direct instance. Transformation to Approach 3. The transformation corresponds to the setting in Fig. 6. The difference from Approach 2 is that Author has no longer the semantics of role and thus is not subclass of Role. As AuthorRole is still instance of Role, we link it to Author using the annotation property rdfs:seeAlso.
The most important distinction is however not visible in this simple diagram.
Namely, if there were a subclass system under Author in the original ontology,
it would have to be transferred to the instance level. Instead of subclasses, there
12 In the “books-about-animals” example in [
Transformation to Approach 4. This is similar to Approach 2 (including the treatment of a hypothetical subclass system), except that – the original Author class is not removed – consequently, the new class (subclass of Role) is not named Author but
AuthorRole – no special instances are generated for the new (AuthorRole) class – instead, an additional restriction (in bold) is imposed on the Author class, relating it to the AuthorRole class.
The result is in Fig. 7.
Transformation to Approach 5. The transformation corresponds to the setting
in Fig. 8. In this approach, similarly to Approach 3, Author is not subclass of
Role, and represents, together with its hypothetical subclasses, a branch of the
ontology separate from Person, too. The Role class and the original hasRole and
isRoleOf object properties, although imported with the AgentRole pattern, are
not used at all. Instead, a new pair of annotation properties, borrowing the name
of these two object properties, is defined. They can be used to directly connect
instances of Person to class Author (or its subclass), as using classes as values
of annotation properties is possible within OWL DL. Obviously, the downside is
unavailability of information in annotations to conventional DL reasoners.
Feedback to the W3C Pattern. The context of transformation probably makes
obvious that the five approaches from [
Specifically, when looking at Fig. 4, we see that the original Author class is used both in local (existential and universal) and global (domain and range) restrictions. If we use e.g. Approach 2, the Author class is however removed. The easiest but most lossy way of dealing with axioms that referred to it would be to drop the local restrictions together with the class, and to let the global restrictions refer to the immediate superclass (i.e., Person). However, we can also (at the cost of complexity overhead) replace the removed named class with the composed class expression Person u ∃ hasRole.Author in these axioms. While this is straightforward for the global restrictions (just setting the domain/range of the respective properties to be this class expression), for modelling the local restrictions in OWL 2 DL we would have to employ an explicit anonymous class in order to link the two composed concept expressions, e.g.: 1 ≡ Person u ∃ hasRole.Author
1 v ∃ writes.Contribution Detailed discussion of the impact of such manipulations is however beyond the scope of this paper. 6
Fig. 9 shows the XML serialisation of the transformation pattern for Approach 2. The codes for all four mentioned approaches are available in the transformation pattern library accessible from http://nb.vse.cz/~svabo/patomat/tp/.
As mentioned in Section 2, the transformation pattern consists of two ontology patterns, the source and the target one, plus a pattern transformation. Both OPs contain the given CP (AgentRole), with concrete classes, in their ‘axioms’ part (last six axioms in each OP).
In addition, the source OP declares two placeholders for classes, ?A and ?B, such that the second is subclass of the first (such as Author is of Person): this is the only axiom with placeholders. There is no naming detection pattern, for simplicity (as none is needed in this simple example). Additional axioms, mentioned in Section 5.3, are not yet considered either.
The target pattern declares two placeholders for classes, ?C and ?D, and one for individual, ?b, which is instance of the latter class. The first two of its axioms however already interlink the imported CP with placeholder classes (this corresponds to subordinating Person to Agent and Author to Role). The third axiom states that ?b is instance of ?D (such as AuthorRole to Author ).
The pattern transformation, finally, declares the logical equivalence13 transformation links between the classes from the source and target OP, and a simple naming pattern transformation for creating the name of the new individual by concatenating the name of class ?B with the string ‘Role’. 7
We are unaware of any style transformation approach used in connection with content patterns as in our current research. As regards our framework as such, several generic approaches to ontology transformation have recently been published. We refer here to two that look most relevant to our work (aside pure OPPL, which we ourselves use as an external component of our framework).
In [
In comparison with the previous work the authors of [
We demonstrated that transformation patterns are a useful mediator for adequately importing content patterns into ontologies, especially into prototype ones that have been designed ad hoc, are not yet widely used, and now are to be put (through the content patterns) onto a more solid and shared foundation. Although the scenario used in this paper is quite narrow, we believe that it uncovers recurrent issues related to ontology style heterogeneity in general.
Aside the AgentRole pattern and its generalizations, we plan to explore other
content patterns from OntologyDesignPatterns.org. Analogously, we will
experiment with different input ontologies, which will require new transformation
operations such as changing between properties and classes (‘de/objectification’),
as e.g. in the ‘n-ary relations’ logical pattern [
The most critical future work, which is not specific for content pattern import but generic for pattern-based transformation, is however support for recursive and optional parts of patterns. This will lead to much more efficient transformation, as the transformation process, triggered at a ‘root’ entity (such as the Author class in ConfOf ) could be propagated down the subclass (for different specific types of authors) or subproperty links, and yield an analogous, though stylewise different structure in the target ontology.
Another generic functionality we also plan to achieve in long term is
systematic, pattern-based swapping of the information lost during style transformation
into OWL 2 annotations, see e.g. [
From the research point of view, a challenging task is to automatically suggest
fragments of ontologies that should be (transformed and) subordinated to a
content pattern. For the AgentRole pattern, for example, this challenge amounts
to recognising classes or properties that implicitly express a role. In [