=Paper=
{{Paper
|id=None
|storemode=property
|title=Establishing a Bridge from Graph-based Modeling Languages to Ontology Languages
|pdfUrl=https://ceur-ws.org/Vol-604/paper5.pdf
|volume=Vol-604
|dblpUrl=https://dblp.org/rec/conf/tools/WalterSR10
}}
==Establishing a Bridge from Graph-based Modeling Languages to Ontology Languages==
https://ceur-ws.org/Vol-604/paper5.pdf
Establishing a Bridge from Graph-based Modeling
Languages to Ontology Languages ?
Tobias Walter1 , Hannes Schwarz1 , Yuan Ren2
1 University of Koblenz-Landau, {walter,hschwarz}@uni-koblenz.de
2 University of Aberdeen, y.ren@abdn.ac.uk
Abstract. In today’s software industry, the pursuit of Model-Driven Develop-
ment has become a serious option. Depending on their purpose, models can be
represented in different languages with different strengths and weaknesses. Re-
cently, ontologies with the predominant Web Ontology Language OWL are more
and more recognized as being able to adequately complement modelware, i.e.
the more traditional modeling languages such as MOF/UML or the TGraph ap-
proach. This paper compares the TGraph approach as representative for model-
ware with OWL and bridges both technologies by introducing a transformation
from TGraphs to OWL. Subsequently, the advantages of both technologies are
highlighted, showing how to benefit from the presented bridging approach.
1 Introduction
Today Model-Driven Development (MDD) plays a key role in building software sys-
tems. A variety of different modeling languages may be used to develop large software
systems. Each language focuses on different views and problems of the system [1] and
offers other features and advantages. Thus, it is often required to rely on different mod-
eling languages for the description of a single system. However, to represent the same
models in different languages, a proper bridging between the languages is essential.
In this paper we consider two modeling languages to be bridged: TGraphs combined
with the metamodeling language grUML and the query language GReQL [2], together
constituting the TGraph approach, and OWL 2 [3].
The TGraph approach belongs to the so-called modelware which comprises “tra-
ditional” modeling languages, with the Meta Object Facility (MOF) [4] including the
Object Constraint Language (OCL) [5] by the Object Management Group as its prob-
ably most popular representative. Essential MOF (EMOF) is a less complex subset of
MOF which dominates practical usage, especially with respect to tool-building. Nev-
ertheless, although the TGraph approach can basically be compared with EMOF and
OCL, we have chosen it for the purposes of this paper, for it offers advantages with
respect to expressivity and formal background. TGraphs have been used for various
applications, e.g. the development of meta-case tools and software reengineering [2].
TGraphs are a very general kind of directed graphs whose vertices and edges are
typed, attributed, and ordered. They provide all needed features for representing lan-
guages and models as graphs in a tool. An efficient implementation of the TGraph
? supported by EU STReP-216691 MOST
approach, the JGraLab Java API3 enables the easy use of TGraphs in practice. TGraphs
conform to metamodels, called schemas in TGraph terminology. Schemas are specified
in grUML [6] and can incorporate constraints formulated in GReQL, the Graph Repos-
itory Query Language [7]. The main features setting the TGraph approach apart from
EMOF are its formally defined semantics, its treatment of edges as first-class objects,
and the various orderings imposed on graph elements.
OWL 2 is a W3C recommendation with a comprehensive set of constructs for con-
cept definitions [3]. OWL 2 is an implementation of a description logic [8]. Description
logics constitute a family of logics for concept definitions that allow for joint as well as
for separate sound and complete reasoning at the model and at the instance level.
The motivation for this work comes from the different advantages and features pro-
vided by modelware and ontologies: while usually, development is mainly conducted
using modelware languages, developers are more and more interested in representing
selected models as ontologies to be able to benefit from their exclusive features. For
example, reasoning services could be applied to detect whether a schema’s constraints
are contradicting, resulting in the schema to be uninstantiable. In this paper, we will
therefore restrict ourselves to the description of a transformation-based bridge from
modelware to ontologies, or more precisely, from TGraphs to OWL.
The paper is structured as follows: in section 2, we introduce both relevant modeling
languages, i.e. TGraphs, grUML, and GReQL, as well as the Web Ontology Language.
Section 3 presents the transformation of TGraph schemas plus their constraints to an
OWL ontology. In section 4, we show the different advantages provided by the model-
ing approaches and we give an idea of the benefits of transforming TGraphs to an on-
tology representation. In section 5, we will examine some related modeling approaches,
including MOF and OCL. Finally, section 6 concludes the paper.
2 Modeling Approaches and Languages
In the following we introduce TGraphs together with grUML and GReQL in section 2.1
and OWL 2 in section 2.2. In section 2.3, we compare the modeling concepts provided
by the two approaches.
2.1 The TGraph Approach
TGraphs are a versatile kind of graphs whose edges are first class citizens, i.e. they are
distinguished graph elements with similar properties as vertices. TGraphs are directed,
their edges and vertices are typed and attributed, and for each vertex the incident edges
are ordered. In addition, the vertices and edges of the graph are ordered globally. Every
graph is an instance of a graph schema which defines the types of edges and vertices,
associates them with attributes, and structures them in generalization hierarchies.
grUML. The metamodeling language grUML used for modeling schemas corresponds
to a subset of UML class diagrams [6]. With regard to the OMG metamodeling archi-
tecture [4], graph schemas are defined on the M2 layer. Their instances, i.e. TGraphs,
3 http://jgralab.uni-koblenz.de
2
lie on the M1 layer, whereas the metaschema of grUML itself, prescribing the structure
of graph schemas, is defined on the M3 layer.
Figure 1 depicts a sample activity diagram in concrete syntax. It represents the visu-
alization of a TGraph describing the diagram’s abstract syntax which in turn conforms
to the grUML schema in figure 2. Here, action nodes (e.g. Receive Order, Fill Order)
are used to model concrete actions within an activity. Object nodes (e.g. Invoice) can
be used to model the flow of values or objects. Control nodes (e.g. the initial node be-
fore Receive Order, the fork and join nodes around Ship Order, and the final node after
Close Order) are used to coordinate the flows between other nodes. Activity diagrams
can contain two types of edges: object flows and control flows. Object flows model the
flow of values to or from object nodes. Control flows specify the sequencing of nodes.
[order
rejected]
Ship Order
Receive Order Fill Order Close Order
[order
accepted]
Send Invoice Make Payment Accept Payment
Invoice
Fig. 1. Example of Activity Diagram
Fig. 2. Schema of Activity Diagram
GReQL. The Graph Repository Query Language, is a declarative, expression-based
query language for TGraphs [7]. It can be used to extract information from TGraphs,
for example attributes of vertices and edges or complete structures inside of graphs.
Typical GReQL queries are the so-called FWR expressions and quantified expressions.
FWR expressions consist of the three clauses from, with and report. The from-clause
declares variables for concerned elements (e.g. vertices and edges) in the graph. The
variables’ domains can be taken from the types defined in the graph schema. The op-
tional with-clause summarizes predicates which have to be fulfilled by the variables.
These predicates can include powerful graph-oriented expressions such as regular path
expressions. Finally, the report-clause determines the result structure of the query.
Universally and existentially quantified expressions test whether all or some graph
elements fulfill specific conditions and return a boolean value, respectively.
3
For the purposes of this work, we consider GReQL as language for formulating con-
straints complementing grUML schemas. Since only expressions returning a boolean
value qualify as constraints, the bridging approach will exclusively address such ex-
pressions, with quantified expressions being the most important ones. Examples for
GReQL expressions can be taken from section 3.
2.2 OWL 2
In general, ontologies are used to define sets of concepts that describe domain knowl-
edge and allow for specifying classes by rich, precise logical definitions. Among vari-
ous existing ontology languages, we use the W3C standard OWL in its currently second
version (OWL 2) [3] in this paper. OWL actually stands for a family of languages with
increasing expressiveness. Furthermore, OWL inherits the modularisation mechanism
of XML, namely namespaces and imports (text inclusion).
The difference between OWL and modeling languages such as grUML is the capa-
bility to describe classes in many different ways and to handle incomplete knowledge.
These OWL features increase the expressiveness of the metamodeling language, mak-
ing OWL a suitable language to formally define classes of modeling languages. OWL
2 is axiom-based and thus provides different constructs to restrict classes or properties.
The full OWL 2 metamodel, which provides different kinds of expressions and ax-
ioms, can be found in [3]. In the following we use the textual Functional-Style Syntax
as a concrete syntax for OWL. Its terminal symbols directly refer to classes of the meta-
model. The model-theoretic semantics of OWL is presented in [9].
Example. In the following we give an example of an OWL ontology describing a small
excerpt of the schema in figure 2:
Declaration(Class(ActivityDiagram))
Declaration(Class(ActivityNode))
Declaration(Class(ObjectNode))
SubClassOf(ObjectNode ActivityNode)
Declaration(ObjectProperty(HasNode))
ObjectPropertyDomain(HasNode ActivityDiagram)
ObjectPropertyRange(HasNode ActivityNode)
Here three classes (ActivityDiagram, ActivityNode, ObjectNode) are declared. Ob-
jectNode is a subclass of ActivityNode. The object property HasNode is declared which
connects the classes ActivityDiagram and ActivityNode via a domain- and a range-axiom.
Open World vs. Closed World Assumption. While the semantics of grUML-based
modeling adopts the closed world assumption (CWA), description logics adopt open
world assumption (OWA) by default. The closed-world assumption states that the ele-
ments in the model are known and unchanging. The open world assumption assumes
incomplete information as default and allows for validating incomplete models which
are still in the design phase. However, research in the field of combining DL and logic
programming [10] provides solutions to support DL-based reasoning with closed world
assumption as well [11].
4
Knowledge Base and Reasoning. A DL knowledge base is established by a set of as-
sertions and a set of terminological axioms, e.g. concept definitions and constraints, and
can be structured into TBox (Terminological Box) and ABox (Assertional Box). The
TBox is used to specify concepts which denote sets of individuals and roles defining
binary relations between individuals. In the ABox, concrete knowledge is asserted by
defining individuals of concepts and linking them using the roles defined in the TBox.
OWL 2 is a language for modeling both TBox and ABox. Based on the DL knowledge
base, standard reasoners (e.g. Pellet [11]) can provide reasoning services such as consis-
tency checking, satisfiability checking, and subsumption checking. Consistency check-
ing proves that the ABox is consistent with regard to its TBox, satisfiability checking
verifies that a given concept can be instantiated, and subsumption checking determines
if a given concept subsumes (is super-concept of) another concept.
2.3 Structural Comparison
Before we go into the details of transforming TGraph concepts to OWL, we conduct a
first comparison of the different language constructs. An overview is given by table 1.
grUML schemas are used to describe the structure of conforming TGraphs. They
contain vertex classes to define sets of vertices and edge classes to define sets of edges.
The elements in graph schemas are instantiated to build a graph. Ontologies merge both
type and instance definitions and allow for using types in instance definitions and vice
versa. To separate the model elements which are provided by a graph schema, grUML
allows for the definition of packages. This is not supported in OWL. There, only one
ontology document can be modeled which cannot be further separated hierarchically.
grUML vertex classes and edge classes specify types for vertices and edges. OWL
provides class expressions to define types of individuals and object property expres-
sions to define possible relations between two individuals. The OWL correspondence
for attributes are data property expressions. Since edge classes can possess attributes,
but OWL does not provide a similar concept for object property expressions, we com-
pare an edge class to a class expression together with two object property expressions
connecting to the class expressions representing the start and end vertex classes. The ex-
istence of an object property between two individuals is specified by a so-called object
property assertion. Similarly, data property assertions assign values to individuals.
grUML OWL
Graph Schema, Graph Ontology
Package —
Vertex Class Class Expression
Edge Class Class Expression, two Object Property Expressions
Attribute Data Property Expression
Vertex Individual
Edge Individual, two Object Property Assertions
Attribute Value Data Property Assertion
Table 1. Comparison of language elements
5
3 Transformation from the TGraph Approach to OWL
In the following we define a transformation of TGraphs, their schemas and constraints
to an OWL representation. While sections 3.1 and 3.2 are concerned with the trans-
formation of pure TGraph and grUML concepts, sections 3.3 to 3.5 deal with GReQL
constraints. The mapping of TGraphs to OWL is complete with the exception of some
GReQL expressions which cannot be translated to OWL, for example those comparing
attribute values or using different functions of the GReQL library (see also section 4).
3.1 General Modeling of TGraphs and Schemas in OWL
In the following we define how vertex classes and edge classes of a graph schema are
transformed into OWL class expressions and object properties.
1. Each vertex class (e.g. ActivityNode) is represented as an OWL class:
Declaration(Class(ActivityNode))
2. All vertex classes (e.g. ActivityNode) are subsumed by a super concept Vertex:
Declaration(Class(Vertex))
SubClassOf(ActivityNode Vertex)
3. Each edge class (e.g. HasNode) in the graph schema which relates two vertex
classes (e.g. ActivityDiagram and ActivityNode) is represented by an OWL class.
Furthermore, there exist two object properties (e.g. fromHasNode and toHasNode)
which define the source and target vertices of an edge, respectively. In addition, a
separate object property (e.g. HasNodeProperty) is declared as the chain of these
two object properties, connecting the source and target vertices of the edge (e.g.
InverseObjectProperty(fromHasNode) and toHasNode):
Declaration(Class(HasNode))
Declaration(ObjectProperty(toHasNode))
ObjectPropertyDomain(toHasNode ActivityDiagram)
ObjectPropertyRange(toHasNode HasNode)
Declaration(ObjectProperty(fromHasNode))
ObjectPropertyDomain(fromHasNode ActivityNode)
ObjectPropertyRange(fromHasNode HasNode)
Declaration(ObjectProperty(HasNodeProperty))
SubObjectPropertyOf(SubObjectPropertyChain(InverseObjectProperty(fromHasNode) toHasNode)
HasNodeProperty)
4. All edge classes are subsumed by a super concept TopEdge. Furthermore there exist
two object properties to and from, which define source and target vertex of an edge.
toInverse and fromInverse are their inverse object properties, respectively:
Declaration(Class(TopEdge))
SubClassOf(HasNode TopEdge)
Declaration(ObjectProperty(to))
ObjectPropertyDomain(to Vertex)
ObjectPropertyRange(to TopEdge)
6
Declaration(ObjectProperty(from))
ObjectPropertyDomain(from Vertex)
ObjectPropertyRange(from TopEdge)
Declaration(ObjectProperty(toInverse))
Declaration(ObjectProperty(fromInverse))
InverseObjectProperties(toInverse to)
InverseObjectProperties(fromInverse from)
5. All OWL classes representing edge classes and their object properties to and from
are represented by one single object property topEdgeProperty, which is an object
property chain (a sequence of object properties) of fromInverse and to. Furthermore,
topEdgeProperty has a transitive super object property transitiveTopEdgeProperty:
Declaration(ObjectProperty(topEdgeProperty))
ObjectPropertyDomain(topEdgeProperty Vertex)
ObjectPropertyRange(topEdgeProperty Vertex)
SubObjectPropertyOf(SubObjectPropertyChain(fromInverse to) topEdgeProperty)
SubObjectPropertyOf(topEdgeProperty transitiveTopEdgeProperty)
TransitiveObjectProperty(transitiveTopEdgeProperty)
6. Each attribute (e.g. name) is transformed to a data property in OWL and bound to
the class it belongs to via a domain axiom. The datatype of the attribute (e.g. string)
is specified by a range axiom:
Declaration(DataProperty(name))
DataPropertyDomain(name ActivityNode)
DataPropertyRange(name xsd:string)
7. Specialization relationships relating vertex classes and edge classes, respectively,
are transformed to OWL subclass axioms. For example, the edge class ObjectFlow
is subclass of ActivityEdge and the vertex class Action is subclass of ActivityNode:
SubClassOf(ObjectFlow ActivityEdge)
SubClassOf(Action ActivityNode)
8. TGraphs themselves are transformed to a set of assertions. The example below
shows an excerpt of the OWL representation of the diagram in figure 1. Note the
transformation of edges to named individuals (ControlFlow 7 in this example).
ClassAssertion(MakePayment Action)
ClassAssertion(AcceptPayment Action)
ClassAssertion(ControlFlow 7 ControlFlow)
ObjectPropertyAssertion(fromControlFlow MakePayment ControlFlow 7)
ObjectPropertyAssertion(toControlFlow AcceptPayment ControlFlow 7)
DataPropertyAssertion(name MakePayment ”Make Payment”)
DataPropertyAssertion(name AcceptPayment ”Accept Payment”)
3.2 Cardinality Expressions
In grUML cardinalities are directly defined by annotating edge classes in graph schemas
(see figure 2 for an example). In OWL, cardinalities are realized by the class expressions
ObjectMinCardinality, ObjectMaxCardinality, and ObjectExactCardinality. They describe
those individuals which are connected via an object property to at least, at most, and
exactly a given number of individuals of a specified class expression, respectively.
7
In the following we restrict the concept ActivityNode by defining a superclass con-
taining those individuals of ActivityNode which are linked via the inverse of object prop-
erty HasNodeProperty with exactly 1 individual of ActivityDiagram.
SubClassOf(ActivityNode ObjectExactCardinality(1 InverseObjectProperty(HasNodeProperty) ActivityDiagram))
3.3 Quantified Expressions
While GReQL constraints are logics-based (thus, for a given instance the evaluation of
a constraint returns true or false), their OWL equivalence, so-called class expressions,
contain those individuals which fulfill the constraint.
In the following, we show how to transform GReQL’s quantified expressions to
OWL. Basically, quantifications specify whether all (universal quantification) or at least
one (existential quantification) element of a given set of elements must fulfill a given
condition. Universal quantification in GReQL is realized by using the forall keyword.
The following expression defines that all vertices n of vertex class ActivityNode must
fulfill the condition after @, i.e. the name-attribute may not be the empty string.
forall n:V{ActivityNode} @ not(n.name = ””)
Existential quantification is realized by using the exists keyword. The constraint
below defines that for each vertex f of vertex class Final, there exists at least one vertex
a of vertex class ActivityNode which is connected to f via an ActivityEdge.
forall f:V{Final} @ exists a:V{ActivityNode} @ a −−>{ActivityEdge} f
In OWL, the DataAllValuesFrom class expression allows for universal quantifica-
tion over a data property. It contains those individuals that are connected by a data
property expression only to a given data value. Therefore, the above universally quanti-
fied expression can be represented by the following subsumption axiom. The negation
is realized by an DataComplementOf construct.
SubClassOf(ActivityNode DataAllValuesFrom(name DataComplementOf(””)))
The existential quantification over an object property in OWL is realized by an Ob-
jectSomeValuesFrom class expression. It describes those individuals that are connected
via an object property to at least one instance of a given class expression. In the follow-
ing we restrict the concept Final by defining a superclass containing those individuals
which are linked to individuals of concept ActivityNode via the object property from.
SubClassOf(Final ObjectSomeValuesFrom(InverseObjectProperty(ActivityEdgeProperty) ActivityNode))
3.4 Boolean Connectives
Boolean connectives are logical operators that connect logical expressions returning a
boolean value. GReQL provides the operators and, or and not for boolean connectives.
They have two (in the case of not one) input parameters and return a boolean value.
The following GReQL constraint requires that each activity diagram must have at
least one initial node and at least one final node:
8
forall ad:V{ActivityDiagram} @ (exists i:V{Initial} @ ad −−>{HasNode} i) and (exists f:V{Final} @ ad −−>{
HasNode} f)
For negating some boolean expression in GReQL the not-operator is used. The fol-
lowing constraint requires that all initial nodes do not have incoming ActivityEdges:
forall i:V{Initial} @ not(exists n:V{ActivityNode} @ n −−>{ActivityEdge} i)
Boolean connectives in OWL are provided by ObjectIntersectionOf (and), Object-
UnionOf (or), and ObjectComplementOf (not) class expressions. They provide the stan-
dard set-theoretic operations on class expressions.
To state that an activity diagram contains at least one start and at least one final state,
both restrictions are formulated as class expressions and connected by ObjectIntersec-
tionOf to form a new class expression which becomes superclass of ActivityDiagram:
SubClassOf(ActivityDiagram ObjectIntersectionOf(ObjectSomeValuesFrom(HasNodeProperty Initial)
ObjectSomeValuesFrom(HasNodeProperty Final)))
The negation in OWL is realized by the ObjectComplementOf class expression. To
state that an initial node has no incoming transitions we describe the concept of incom-
ing transitions by an ObjectSomeValuesFrom class expression and negate it:
SubClassOf(Initial ObjectComplementOf(ObjectSomeValuesFrom(InverseObjectProperty(ActivityEdgeProperty)
ActivityNode)))
3.5 Path Descriptions
In the following we examine the constructs available for path descriptions in GReQL
and transform them into corresponding OWL constructs.
Simple Path Description. In GReQL a simple path description consists of an edge
symbol (--> (outgoing) , <-- (incoming), <-> (direction not important)) and option-
ally an edge type restriction in curly braces. In the following we define that each Action
has some outgoing edge (-->) and some incoming edge (<--), that all vertices in the
graph must be incident with some incoming or outgoing edge (<->), and that each
ObjectNode has some incoming edge of type ObjectFlow (-->{ObjectFlow}).
forall v:V{Action} @ exists w:V @ v −−> w
forall v:V{Action} @ exists w:V @ v <−− w
forall v:V @ exists w:V @ v <−> w
forall w:V{ObjectNode} @ exists v:V @ w <−−{ObjectFlow} v
In OWL we define super classes which are used to restrict a given class. Action
is restricted by an ObjectSomeValuesFrom class expression, which defines that there is
some outgoing edge from each Action to some further vertex via topEdgeProperty. Each
Action has some incoming edge via the inverse of topEdgeProperty. An ObjectUnionOf
class expression defines that there is some incoming or outgoing edge for each Action.
To define that each ObjectNode has some incoming edge of type ObjectFlow an Object-
SomeValuesFrom class expression is used to define that there exists some edge of type
ObjectFlow, which comes from some Vertex and goes to the given ObjectNode.
9
SubClassOf(Action ObjectSomeValuesFrom(topEdgeProperty Vertex))
SubClassOf(Action ObjectSomeValuesFrom(InverseObjectProperty(topEdgeProperty) Vertex))
SubClassOf(Vertex ObjectUnionOf(ObjectSomeValuesFrom(InverseObjectProperty(topEdgeProperty) Vertex)
ObjectSomeValuesFrom(topEdgeProperty Vertex)))
SubClassOf(ObjectNode ObjectSomeValuesFrom(objectFlowProperty Vertex)))
Edge Path Description. An edge path description --exp-> matches exactly one
edge, given as expression exp. The following constraint requires the edge e of edge
class ControlFlow between initial vertex and some other vertex:
forall i:V{Initial} @ exists e:E{ControlFlow} @ exists v:V @ i −−e−> v
In OWL, edge path descriptions are represented by class expressions. In the exam-
ple below, there is a ObjectOneOf class expression containing the individual e of type
ControlFlow. An ObjectSomeValues expression defines that each Initial vertex has some
outgoing (fromInverse) edge of type ObjectOneOf(e) which goes to some Vertex.
ClassAssertion(e ControlFlow)
SubClassOf(Initial ObjectSomeValuesFrom(fromInverse ObjectIntersectionOf(ObjectSomeValuesFrom(to Vertex)
ObjectOneOf(e))))
Goal- and Start-restricted Path Description. In GReQL the start and end vertices of
a path description can be restricted. A vertex class expression which restricts the start
or end vertex is separated from the path description with a &. The following restrictions
define that for each ObjectNode, there is an outgoing and an incoming edge to and from
a vertex of type Action or ObjectNode.
forall o:V{ObjectNode} @ exists v:V @ o −−> &{Action, ObjectNode} v
forall o:V{ObjectNode} @ exists v:V @ v {Action, ObjectNode}& −−> o
To restrict start or end vertex of an edge in OWL, the start or end is described by
a class expression. To define that for each ObjectNode there is some edge that ends at
an ObjectNode or Action, we create an ObjectUnionOf class expression that describes
the restricted end. We define an ObjectSomeValuesFrom class expression to define the
existence of an edge going to ObjectNode or Action. To define that for each ObjectNode
there is some incoming edge coming from an ObjectNode or Action vertex we define
the restricted start vertex by an ObjectUnionOf class expression. The incoming edge is
described by the inverse of topEdgeProperty. An ObjectSomeValuesFrom expression
defines that there exists an incoming edge from some ObjectNode or Action vertex.
SubClassOf(ObjectNode ObjectSomeValuesFrom(topEdgeProperty ObjectUnionOf(ObjectNode Action)))
SubClassOf(ObjectNode ObjectSomeValuesFrom(InverseObjectProperty(topEdgeProperty) ObjectUnionOf(
ObjectNode Action)))
Sequential Path Description. GReQL supports the concatenation of path descriptions
to sequential path descriptions. The following constraint specifies that all Initial vertices
are connected v by a path of two outgoing edges.
forall i:V{Initial} @ exists v:V @ i −−>−−> v
10
In OWL, sequential path descriptions are represented by nested class expressions.
We define a super class for Initial that consists of two nested ObjectSomeValuesFrom
class expressions. It defines that from each individual of type Initial there exists some
individual of Vertex reachable via a sequence of two topEdgeProperty object properties:
SubClassOf(Initial ObjectSomeValuesFrom(topEdgeProperty ObjectSomeValuesFrom(topEdgeProperty Vertex)))
Exponentiated Path Description. Exponentiated path descriptions are defined by
some path description followed by a given natural number. The following example
states that for each initial vertex there is an outgoing path of length 2 to some vertex v:
forall i:V{Initial} @ exists v:V @ i −−>ˆ2 v
In OWL, exponentiated path descriptions are defined by nested class expressions. To
restrict the OWL class Initial we define the same superclass as above consisting of two
nested ObjectSomeValuesFrom class expressions. It defines that from each individual
of Initial there is some other individual of type Vertex reachable via 2 topEdgePropertys:
SubClassOf(Initial ObjectSomeValuesFrom(topEdgeProperty ObjectSomeValuesFrom(topEdgeProperty Vertex)))
Optional Path Description. In GReQL a path description can be marked as optional
by surrounding it with brackets. Here we want to define that each ObjectNode has a
path of length one or two to some vertex:
forall o:V{ObjectNode} @ exists v:V @ o −−>[−−>] v
In OWL optional path expressions can be defined by using an ObjectUnionOf ex-
pression to represent the optional path. In the following each individual of ObjectNode
is connected via topEdgeProperty with some further individual of type Vertex. There
can optionally be some further topEdgeProperty to another individual of type Vertex:
SubClassOf(ObjectNode ObjectSomeValuesFrom(topEdgeProperty ObjectUnionOf(ObjectSomeValuesFrom(
topEdgeProperty Vertex) Vertex)))
Alternative Path Description. In GReQL it is possible to define paths as alternatives
by separating them with a pipe. In the following we define that each ObjectNode is
connected to some Action or to some ObjectNode:
forall o:V{ObjectNode} @ exists v:V @ o −−> &{Action}| −−> &{ObjectNode} v
In OWL alternative path expressions are expressed by using the ObjectUnionOf ex-
pression. The following constraint defines that each individual of ObjectNode has some
edge to an ObjectNode individual, or alternatively some edge to an Action individual:
SubClassOf(ObjectNode ObjectUnionOf(ObjectSomeValuesFrom(topEdgeProperty ObjectNode)
ObjectSomeValuesFrom(topEdgeProperty Action)))
11
Iterated Path Description. GReQL supports iteration in path description by the use of
Kleene operators * and +. In the following we define that there exists a path from every
Initial vertex i to some Final vertex f with i and f not being identical:
forall i:V{Initial} @ exists f:V{Final} @ i −−>+ f
In OWL iterated path expressions are realized by transitive object properties. In the
following we define that each individual of Initial is connected via transitiveTopEdge-
Property with some individual of Final. Since transitiveTopEdgeProperty is transitive
the path between Initial individuals and Final individuals can be of arbitrary length.
SubClassOf(Initial ObjectSomeValuesFrom(transitiveTopEdgeProperty ObjectSomeValuesFrom(
transitiveTopEdgeProperty Final)))
If the iterated path description has edges of specific types, a new transitive object
property must be created which is super object property of the chain of the object prop-
erties representing the path.
4 Advantages of the TGraph Approach and OWL
In this section we want to present different benefits of both modeling approaches, thus
allowing to judge which representation is to be chosen for which purpose.
4.1 Using the TGraph Approach
Relying on grUML and GReQL as modeling and constraint languages offer various
advantages not exhibited by the OWL representation, detailed in the following.
Simple syntax. As it is apparent from the examples in section 3, in most cases the
GReQL syntax is more concise. This especially applies to regular path expressions
whose OWL representations involve intricate nested expressions. Consequently, com-
plex GReQL constraints should be more easily graspable than their OWL counterparts.
Expressions over Attribute Values. GReQL offers the possibility to include expres-
sions over attribute values in constraints, incorporating comparative and arithmetic op-
erations, for instance. This goes beyond the mere assurance that a literal has a specific
value or not, which is possible in OWL (exemplified in section 3.3).
Function Library. GReQL provides a function library comprising a variety of func-
tions covering different aspects. The library is extensible, i.e. missing functionality can
be added by users. The predefined functions cover aspects such as logics, arithmetics,
string manipulation, operations on collections, as well as path and graph analysis. In the
following example, the first constraint uses regular expression matching to ensure that
the name of activity nodes does not contain the substring “Activity”. The second
constraint, consisting of a single function call, imposes the acyclicity of the graph.
forall n:V{ActivityNode} @ not reMatch(n.name, ”.∗Activity.∗”)
isAcyclic()
12
Efficiency. Some axioms for object property expressions, e.g. symmetry, transitivity,
and the existence of equivalent or inverse properties potentially result in the population
of ontologies with an abundance of additional object properties during the reasoning
process, i.e. the ontology is complemented by properties inferred from previously exist-
ing properties. In contrast, the automaton-driven evaluation of regular path expressions
by the GReQL evaluator included in the JGraLab API does not require such space-
consuming materialization. As explained in [7], the implementation approach also guar-
antees a time efficient evaluation of constraints and queries. The practical usability of
GReQL has been shown in various real-life applications and projects [2].
4.2 Using OWL
The use of OWL provides the following advantages:
Reasoning on Schema Layer. Designers creating graph schemas are possibly inter-
ested in computing the vertex classes and edge classes which are not satisfiable, i.e.
classes which cannot be instantiated without the graph becoming inconsistent. The fol-
lowing GReQL constraint leads to an unsatisfiable vertex class because it simultane-
ously forbids and requires that Final vertices have a successor.
forall f:V{Final} @ exists v:V @ not(f −−> v) and (f −−> v)
A knowledge base consisting of an OWL ontology provides reasoning on the schema
layer. Here we are able to validate the schema and check its satisfiability. The result of
this check is an OWL class, e.g. Final.
Extending the above functionality, we can further check the consistency of the com-
bination of various constraints. Assume that the following constraints are given:
forall f:V{Final} @ exists v:V @ v −−> f
exists f:V{Final} @ not (exists v:V @ f <−> v)
According to the transformation pattern we have presented in the last section, the fol-
lowing axioms will be created:
SubClassOf(Final ObjectSomeValuesFrom(InverseObjectProperty(topEdgeProperty) Vertex))
EquivalentClasses(FreeStandingFinal ObjectIntersectionOf(Final ObjectComplementOf(ObjectUnionOf(
ObjectSomeValuesFrom(InverseObjectProperty(topEdgeProperty) Vertex) ObjectSomeValuesFrom(
topEdgeProperty Vertex)))))
With ontology reasoning it can be derived that class FreeStandingFinal is unsatisfiable.
Therefore, we know that the two constraints are contradicting.
Reasoning and Expressions covering two layers. OWL allows for defining expres-
sions covering the schema- and instance-layer. The following expressions define that
there must be a specific initial node – initialDataInput – preceding each object node.
Further, each object node has some incoming and some outgoing object flow edge:
Declaration(Individual(initialDataInput))
ClassAssertion(initialDataInput Initial)
EquivalentClasses(ObjectNode ObjectIntersectionOf(ObjectSomeValuesFrom(InverseObjectProperty(fromObjectFlow)
ObjectFlow) ObjectSomeValuesFrom(InverseObjectProperty(toObjectFlow) ObjectFlow) ObjectHasValue(
InverseObjectProperty(transitiveTopEdgeProperty) initialDataInput)))
13
A DL knowledge base allows for joint reasoning on both schema and graph (model),
e.g. for classifying individuals to find their possible types. Below, the individuals initial-
DataInput of type Initial, object1 which has no type and final of type Final are declared.
Declaration(Individual(initialDataInput))
Declaration(Individual(object1))
Declaration(Individual(final))
ClassAssertion(initialDataInput Initial)
ClassAssertion(final Final)
ObjectPropertyAssertion(objectFlowProperty initialDataInput object1)
ObjectPropertyAssertion(objectFlowProperty object1 final)
Using a reasoner we are able to classify the object1 individual to its possible type. The
result is the class ObjectNode, since object1 fulfills all the restrictions defined above.
Open World Assumption. The open world assumption assumes incomplete informa-
tion as default and allows for validating incomplete models. With regard to quantified
expressions, a reasoner by default assumes that a given individual is linked with other
individuals at least or only of a given type. Although an individual is not linked with
a given number (cardinality) of other individuals a reasoner would assume by default
that cardinality restrictions are fulfilled by assumed individuals in the domain. With re-
gard to path expressions, a reasoner assumes incomplete or incorrect paths (e.g. with
violated goal- or start-restriction or a wrong length of a sequence of edges) as correct.
5 Related Languages
Similar to grUML and GReQL, MOF and OCL [4, 5] provide constructs to define cardi-
nalities, quantified expressions and boolean connectives. Regarding regular path expres-
sions, OCL is limited. Although the navigation of links between two objects is possible
and alternative and optional paths can be expressed by boolean connectives, OCL does
not allow for the iteration of paths. Conversely, GReQL does not support OCL’s generic
iterate expression and is unable to define contexts for constraints. In [12], a bridge be-
tween the MOF-based UML and OWL is presented. In principle, the authors transform
UML models to an intermediate representation based on the so-called Ontology Defini-
tion Metamodel and further on to OWL. The reverse direction is also possible.
Alloy is a structural modelling language based on first-order logic supporting struc-
tural and behavioral constraints. In [13], a transformation from OWL to Alloy is pre-
sented. The Alloy Analyzer tool can provide standard reasoning services such as con-
sistency, satisfiability and subsumption checking. In [14], the ontology is transformed
to a Z-specification to prevent automatic assumption of implicit facts to be true. Thus
for open world reasoning, a DL-based reasoner must be used.
6 Conclusion
In this paper we presented a transformation of TGraphs and their schemas together with
GReQL constraints to OWL 2 ontologies. We show how to bridge both modeling ap-
proaches to combine their benefits. The approach features the transformation of graph
14
and schema elements as well as GReQL expressions such as quantified and regular path
expressions to OWL. Further, we have identified individual advantages of both model-
ing approaches to illustrate the usefulness of the bridging approach. While the TGraph
approach provides an efficient implementation and simple usage, OWL 2 allows for
strong expressiveness and reasoning support.
The approach has in part been implemented and applied in the ReDSeeDS project4 ,
where requirements captured as TGraphs, albeit without any GReQL constraints, are
transformed to OWL in order to use reasoning services to determine their similarity
[15]. Future work includes the validation of the whole approach, i.e. including the trans-
formation of GReQL constraints, on the basis of a case study.
References
1. Mellor, S., Clark, A., Futagami, T.: Model-driven development. IEEE Software 20(5) (2003)
14–18
2. Ebert, J., Riediger, V., Winter, A.: Graph Technology in Reverse Engineering, The TGraph
Approach. In: 10th Workshop Software Reengineering (WSR 2008). (2008) 67–81
3. Motik, B., Patel-Schneider, P.F., Parsia, B.: OWL 2 Web Ontology Language: Structural
Specification and Functional-Style Syntax. http://www.w3.org/TR/owl2-syntax
(2009)
4. Object Management Group: Meta Object Facility (MOF) Core Specification, OMG Avail-
able Specification, Version 2.0. (2006) http://www.omg.org/spec/MOF/2.0/PDF.
5. Object Management Group: Object Constraint Language, Version 2.2. (2010) http://
www.omg.org/spec/OCL/2.2/PDF.
6. Bildhauer, D., Horn, T., Riediger, V., Schwarz, H., Strauss, S.: grUML - A UML based
Modeling Language for TGraphs. Technical report, University of Koblenz-Landau (2010)
To appear in Arbeitsberichte Informatik.
7. Ebert, J., Bildhauer, D.: Reverse Engineering Using Graph Queries. In: Graph Transforma-
tions and Model Driven Engineering. Springer (2010) . To appear.
8. Baader, F., Calvanese, D., McGuinness, D., Nardi, D., Patel-Schneider, P.: The Description
Logic Handbook. Cambridge University Press New York, NY, USA (2007)
9. Motik, B., Patel-Schneider, P.F., Grau, B.C.: OWL 2 Web Ontology Language Direct Se-
mantics. http://www.w3.org/TR/owl2-direct-semantics (2009)
10. Motik, B., Horrocks, I., Rosati, R., Sattler, U.: Can OWL and logic programming live to-
gether happily ever after? In: Proc. ISWC-2006. (2006) 501–514
11. Parsia, B., Sirin, E.: Pellet: An OWL DL Reasoner. In: Proc. of the 2004 International
Workshop on Description Logics (DL2004). CEUR Workshop Proceedings (2004)
12. Gas̆ević, D.V., Djurić, D.O., Devedz̆ić, V.B.: Bridging MDA and OWL Ontologies. Journal
of Web Engineering 4(2) (2005) 118–143
13. Wang, H., Dong, J., Sun, J., Sun, J.: Reasoning support for Semantic Web ontology family
languages using Alloy. Multiagent and Grid Systems 2(4) (2006) 455–471
14. Dong, J.S., Lee, C.H., Lee, H.B., Li, Y.F., Wang, H.: A combined approach to checking web
ontologies. In: Proc. of the 13th International World Wide Web Conference. (2004) 714–722
15. Wolter, K., Krebs, T., Bildhauer, D., Nick, M., Hotz, L.: Software Case Similarity Measure.
Project Deliverable D4.2, ReDSeeDS Project (2007)
4 http://www.redseeds.eu
15