Introduction

The integration of heterogeneous data has first emerged in the database area [26]. However, data integration is a reoccurring problem, not only in the database area, but in different technical spaces [8,11]. With the raise of model-driven engineering (MDE), much effort has been spent in developing dedicated transformation languages and accompanying engines to transform, compare, and synchronize heterogeneous models.

At the same time, ontologies have been proposed in Semantic Web to describe the intension as well as the extension of a domain. While dedicated languages for querying and reasoning with ontologies have been intensively studied (e.g., classification of individuals and consistency checking are provided by standard reasoner), specific support for integration concerns leading to executable transformations is rare.

In order to understand the differences and commonalities between MDE and Semantic Web technologies (SWTs), several studies have investigated about the languages used in both fields to describe the domain of discourse [28]. Thus, bridges are already available between these two worlds for transforming metamodels and corresponding models to ontologies and vice versa. Some studies go also beyond purely structural information [12], but bridges concerning dynamic information are still mostly unexplored. Moreover, for specific domains, such as configuration management [4], both technologies are applied, but mostly in an isolated manner as we currently explore in a recent project 3 .

Based on previous studies which relate metamodels and models to ontologies [5,10], we discuss in this paper synergies between transformation languages of MDE, in particular Triple Graph Grammars (TGGs) [24], and SWTs, namely a combination of OWL/SPARQL. First, we show how TGGs are employed to define correspondences between ontologies visualized as metamodels and how these correspondences are operationalized by a compilation of TGGs to OWL/SPARQL. Second, we show how reasoning support of SWTs is applicable to allow for underspecified model transformation specifications, i.e., the concrete types of instances are assigned in a post-processing step using OWL reasoner. Third, we discuss how switching between the closed world assumption (CWA) to an open world assumption (OWA) is beneficial for particular integration scenarios where only partial knowledge of existing models is present. We demonstrate these aspects by a common case study.

The rest of this paper is structured as follows. In the next section, we introduce the running example for this paper as well as the technological prerequisites. In Section 3, we discuss the mapping between TGGs and OWL/SPARQL in a general form, whereas in Section 4 we demonstrate the compilation of TGGs to OWL/SPARQL by-example and discuss how features of ontologies may be exploited for model transformations. In Section 5 we discuss related work before we conclude in Section 6.

Preliminaries

Motivating Example

As an example we will illustrate how heterogeneous views on computer networks can be joined (cf. Fig. 1). The first view comprises the physical network structure including cables of various types and speed as well as computers. The second view contains the application structure of the network, i.e., various computers are running different services which might require each other. In that case, a connection to a matching service is required. Connections can be modeled by their physical structure, as well as their logical network structure. By using TGGs we are able to define correspondences between both structures, which can be used to either (𝑖) express graph transformation rules to transform individuals from one schema to another or (𝑖𝑖) check whether or not such alignments hold for given models. Extending those correspondence definitions with SWTs, allows even more sophisticated reasoning, inferencing, and querying tasks. TGGs have first been introduced by Andy Schürr [24]. A TGG rule combines elements from a left model (LM), a right model (RM) and a correspondence model (CM). Each TGG rule contains a left hand side graph (LG) conforming to LM, a right hand side graph (RG) conforming to RM and a correspondence graph (CG) conforming to CM which connects elements from LG and RG. Vertices and edges may not be deleted by any rule, they can only be preserved or created. In contrast to usual graph transformation rules, TGG rules are inherently bidirectional. A TGG engine searches for rule applications creating the required input graphs and creates elements of all other graphs during that process. For example, in a transformation scenario an input graph for LM would result in a graph for CM and RM. TGG rules might also have additional constraints, e.g., negative application conditions or attribute constraints, also restricting the value of an attribute depending on attribute values of other objects in the TGG rule. The left-hand side of Fig. 5 shows a simple example of a TGG rule of a computer network that relates connections of the same speed without declaring them equal. Black elements denote elements which have been matched already, green elements are elements which are matched or created then. In this case, the difference between both models is only a syntactical one.

Semantic Web Technologies (SWTs)

RDF & OWL. The Resource Description Framework (RDF) 4 is a framework to describe and represent information about resources and is both human-readable and machine-processable, which enables the possibility to easily exchange information among different applications using RDF triples.

In RDF everything is a resource, uniquely identified by its URI and all data is represented as (𝑠𝑢𝑏𝑗𝑒𝑐𝑡, 𝑝𝑟𝑒𝑑𝑖𝑐𝑎𝑡𝑒, 𝑜𝑏𝑗𝑒𝑐𝑡) triples, where subjects and predicates are URIs and objects can either be literals (strings, integers, . . . ) or URIs.

Since RDF itself does not contain sophisticated semantics to express characteristics of concepts or to define more expressive relationships among them, the Web Ontology Language (OWL) 5 was developed. Introducing OWL allows the usage of reasoning systems such as Pellet [27], FaCT++ [29] or HermiT [25] to (𝑖) infer new knowledge and (𝑖𝑖) detect inconsistencies based on the modeled semantics.

SPARQL. The Protocol And RDF Query Language (SPARQL) is basically the standard query language for RDF 6 . Its syntax (cf. Figs. 2-4) is highly influenced by an RDF serialization format called Turtle [1] and SQL. In its current version, SPARQL allows besides basic query operations such as union of queries, filtering, sorting and ordering of results as well as optional query parts, the use of aggregate functions (SUM, AVG, MIN, MAX, COUNT,...), the possibility to use subqueries, perform update actions via SPARQL Update and several other requested features as indicated in [18]. 7Another important feature of SPARQL are CONSTRUCT queries, which allow the construction of new RDF graphs based on a previously matched (against one ore more input graphs) SPARQL graph pattern (cf. Fig. 3). Their main purpose lies in data integration scenarios, where data from one ore more data sources have to be normalized to fit a common schema [19,23].

Aligning TGGs and SWTs

In the following, we map basic TGG rules to SPARQL queries. The TGG rule definition is based on [2] and extended by labels. Advanced features of graph transformations like multi-nodes are not supported. Subsequently, we discuss two benefits of using SWTs: (𝑖) automatic type inference and (𝑖𝑖) reasoning under CWA and OWA.

Definition 1 (E-Graph).

A labeled E-Graph 𝐺 = (𝑉 𝐺 , 𝑉 𝐷 , 𝐸 𝐺 , 𝐸 NA , 𝐸 EA , (src 𝑗 , trg 𝑗 ) 𝑗∈{𝐺,EA,EA} , 𝑙) consists of graph vertices 𝑉 𝐺 , data vertices 𝑉 𝐷 , graph edges, node attribute edges and edge attribute edges 𝐸 𝐺 , 𝐸 NA , 𝐸 EA , source and target edge functions src 𝑗 and trg 𝑗 mapping edges to corresponding vertices and a labeling function 𝑙 defining a label for each vertex and edge. As shorthand we use src(𝑒) and trg(𝑒) to denote source and target edge functions operating on edges of any kind. For the sake of simplicity, we consider application conditions as boolean formulas using ∧ and ∨, over atomic positive application conditions (PACs) and negative application conditions (NACs) defined as triple graphs which might share vertices with each other and SG and TG.

Example 1. The TGG rule r2n = (tr 𝑠 , tr 𝑡 , true) represented in Fig. 5 could be specified as follows: The type graph of both models is derived from the metamodel. For example, a subset of the typegraph for network1 could be specified as

𝐺 n1 = ({𝑑 n1 , 𝑐 n1 }, {double}, {s n1 , 𝑡 n1 }, {b n1 }, {}, {(𝑠 n1 , 𝑐 n1 ), (𝑡 n1 , 𝑐 n1 )}, {(𝑠 n1 , 𝑑 n1 ), (𝑡 n1 , 𝑑 n1 )}), {(𝑏 𝑛1 , 𝑐 n1 )}, {(𝑏 n1 , double)}, {}, {}) combined with a standard double DSIG algebra.

The source graph of TGG rule

tr 𝑠 = (LG 𝑠 𝑚𝑠𝑠 ←−− CG 𝑠 𝑚𝑡𝑠 −−→ TG 𝑠 ) with LG 𝑠 = ({𝑑 1 , 𝑑 2 }, ∅, . . . , ∅), CG 𝑠 = ({g2c 1 , g2c 2 }, ∅, . . . , ∅), TG 𝑠 = ({cb 1 , cb 2 }, ∅, . . . , {}), 𝑚 𝑠𝑠 = ∅, 𝑚 𝑡𝑠 = ∅. The target graph tr 𝑡 = (LG 𝑡 𝑚𝑠𝑡 ←−− CG 𝑡 𝑚𝑡𝑡 −−→ TG 𝑡 ) with LG 𝑡 = LG 𝑠 ∪ ({𝑐 1 }, {𝑛}, {𝑠 1 , 𝑡 1 }, {𝑏 1 }, ∅, {(𝑠 1 , 𝑐 1 ), (𝑡 1 , 𝑐 1 )}, {(𝑠 1 , 𝑑 1 ), (𝑡 1 , 𝑑 2 )}, {(𝑏, 𝑐 1 )}, {(𝑏, 𝑛)}, ∅, ∅), CG 𝑡 = CG 𝑠 ∪ ({}, ∅, . . . , ∅), RG 𝑡 = RG 𝑠 ∪ ({𝑐 1 }, {𝑛}, {𝑠 1 , 𝑡 1 }, {𝑏 1 }, ∅, {(𝑠 1 , 𝑐 1 ), (𝑡 1 , 𝑐 1 )}, {(𝑠 1 , cb 1 ), (𝑡 1 , cb 2 )}, {(sp, 𝑐 1 )}, {(sp, 𝑛)}, ∅, ∅).

The labeling function assigns the type names from the metamodel in Fig. 1 to elements of the type graph and lables equal to variable name to elements of other graphs.

Mapping TGG rules to SPARQL queries. Both transformation and correspondence construction can be expressed using SPARQL queries in the merged ontology using the labeling function. If a model should be synchronized, at first the maximum correspondence is searched, then for the unmatched elements a transformation might be conducted. Each vertex and edge in a TGG rule can be used as context, matched or created element, depending on the use of the TGG rule. In every case, the context nodes are exactly those occurring in the source model, but not in the target one. In a transformation, elements of source model of the transformation in the target rule, but not in the source, are used as matched elements while the others are used as created elements. In a corresponding search scenario, only the elements of the correspondence graph are created, all others are matched. According to [7], an attribute hasMatch is introduced to specify which elements have been matched already. For elements, it is initially unset and may be set to true. For edges, it has the same domain and range as the edge to match, but hasMatch_ as prefix to the original name. Thus, it is not necessary to modify the ontology prior to using the converted TGG rules.

In many cases, TGG rules as defined previously can be transformed to corresponding SPARQL queries. Table 1 1. SPARQL patterns occuring in the WHERE (W) and CONSTRUCT (C) part for context (c), matching (m) and created (cr) elements result in c1 a computer., which is placed in the CONSTRUCT part of the SPARQL query for context nodes and nodes to be matched and in the WHERE part for created nodes.

The helper function dom returns the graph for an element. It returns o1 for elements of the left graph, o2 for elements of the right graph and c for elements of the correspondence graph. The helper function gn assigns a unique name to each atomic application condition.

Many current TGG implementations allow the use of functions to set values for attributes. Existing approaches for converting OCL into SPARQL, could be used for functions requiring matched nodes, context nodes and, for created nodes, (other) created nodes. The result then can be assigned using BIND. Some constraints on created nodes might be formulated using SWRL expressions, e.g., the subset of OCL defined in [12]. In this case, the specific match of vertices in a TGG rule has to be stored to be able to subsequently apply the constraint. Thus, attributes :hasSwrlRule_name_index might be set true to specify that an element is used as element nr. index in the SWRL rule name. In such a way, not only conditions in the TGG can be formulated, but also invariants of each individual model or the merged model. Simple invariants may also be modeled directly in OWL. In the following, we will show an example to illustrate how this may help reducing the complexity of TGG rules significantly.

Automatic Type Inference. Considering the two views on an imaginary network, one might distinguish the creation of Coppercables and Glassfibrecables based on the speed of a correlating Connection between two previously aligned Devices and Connectables (e.g. creating a Glassfibrecable if the speed exceeds a certain threshold or a Coppercable otherwise). Although such distinctions can be modeled with TGGs, at least two TGG rules (in our case; one matching Coppercable and one matching Glassfibrecable) would be necessary.

A more convenient way to model such a behavior can be achieved by out-sourcing the type inference to OWL reasoners and only define one TGG rule, which describes the more general Cable and Connection correspondence as depicted in Figure 5 (with its corresponding SPARQL CONSTRUCT query). The constraints itself (i.e., defining the concept Glassfibrecable to be equivalent to an anonymous concept which is defined as Cable having a speed with a value over 17) can be directly modeled within the ontology using OWL axioms8 and were generated during the initial model to ontology transformation . Reasoning under Open and Closed World Assumption. One of the major benefits of SWTs for integration scenarios are their well defined semantics and the extensive reasoner support as already discussed previously. With OWL and OWL reasoners it is e.g., possible to describe cardinality constraints, perform automatic type inferencing as discussed above and to check for inconsistency in the given models.

While Semantic Web languages are based on OWA (i.e., if a statement is not explicitly stated, it does not mean that it does not exist), software engineering languages are mostly based on CWA (i.e., if a statement is not present, it does not exist) [20]. To deal with this issue, we translate parts 9 of the constraints expressed as OWL axioms into SPARQL queries and query for the presence of individuals which violate those constraints. E.g., consider the cardinality constraint computers exactly 2 Computer for concept System expressed in OWL Manchester Syntax 10 . The answer to the question whether or not a particular System has the right amount of Computers, would not be directly decidable for the OWA but for the CWA with the support of SPARQL as depicted in Listing 1.

ASK WHERE

Related Work

We discuss three lines of related work: (𝑖) approaches for bridging models and ontologies, (𝑖𝑖) approaches for transforming transformations to SWTs, and (𝑖𝑖𝑖), approaches directly using SWTs to encode model transformations.

Bridging models and ontologies. Combining modeling approaches steaming from MDE with ontologies has been studied in the last decade [5]. There are several approaches to transform Ecore-based models to OWL and back, e.g., cf. [9,31]. In addition, there exist approaches that allow for the definition of ontologies in software modeling languages such as UML by using dedicated profiles [13]. Moreover, there are also approaches which combine the benefits of models and ontologies such as done in [14,16]. Not only the purely structural part of UML is considered, but some works also target the translations of constraints between these two technical spaces by using an intermediate format [3]. We build on these mentioned approaches, but we focus on correspondence definitions and their execution as transformations.

Transforming transformations to SWTs. Concerning the definition and execution of model transformations based on SWTs, we are aware of two approaches. First, [15] propose the usage of an ATL-inspired language for defining mappings between ontologies. Thus, uni-directional transformations are implementable for ontologies as it is known from model transformations. Another approach is presented in [30] which translates parts of ATL transformations to ontologies for checking the consistency of transformation rules, e.g., overlaps between rules in terms of overlapping matches. In our work, we follow this line of research, but we consider bi-directional transformations specified in TGGs. Thus, in our translations to ontologies we have to consider not only source to target transformations, but we have to encode comparison and synchronization transformations as well in SPARQL.

Specifying transformations with SWTs. Finally, there are approaches which shift the definition of the model transformations to the SWTs. For instance, in [21] it is proposed to use SWRL to define the correspondences between models to allow for model synchronization. In [10], ontology matching tools are applied to search for correspondences between metamodels and to derive from these correspondences model transformations. In the context of this work, we have the assumption that correspondences are defined based on models using TGGs, but at the same time we explored which benefits from ontology reasoning may be transferred to model transformation approaches.

Conclusion and Further Work

In this paper we have outlined an initial mapping between TGGs and OWL/SPARQL. Especially, new features of the latest SPARQL version helped in defining a comprehensive mapping between these languages. Moreover, we also explored how reasoning capabilities can be leveraged for underspecified model transformations.

While the initial results of applying our approach seem promising, both from a mapping point of view and usage of reasoning capabilities for model transformations, further investigation are planned such as considering a mapping between TGGs and SWRL. Empirical studies are planned as well in the area of configuration management together with our industry partner Siemens AG Österreich. In particular, for performing distributed configuration management [4] where several different models and reasoners have to be connected, we plan to apply our approach to provide the necessary integration means.