Using Graph Transformation to Support Collaborative Ontology Evolution? Pieter De Leenheer1 and Tom Mens2 1
Vrije Universiteit Brussel, STARLab, Belgium,
[email protected] 2 University of Mons-Hainaut, Belgium,
[email protected]
Abstract. In collaborative ontology engineering, contexts are key to manage the complexity of different dependency types between ontological artefacts. Instead of being frustrated by out-of-control evolution processes, proper context dependency management will allow human experts to focus on the meaning interpretation and negotiation processes. This requires support for the detection and resolution of meaning ambiguities and conflicts. In this article, we explore to which extent the theory of graph transformation can be used to support this activity. More specifically, we propose the use of critical pair analysis as a formal means to analyse conflicts between ontologies that are evolving in parallel. We illustrate this with an example from a realistic case study.
1
Introduction
The World Wide Web caused a shift in the way people collaborate and integrate within and between communities. A community constitutes a social system, where action and discourse is performed within more or less well-established goals, norms, and behaviour [6]. Communication is the primary basis for coordinated action, hence in order to collaborate and integrate between different and diverse communities, it is important to capture and agree on the semantics of the concepts being communicated, and reify them in so-called ontologies. Tools and methods for ontology engineering (e.g., [7, 8, 17]), are rapidly becoming a high priority for many organisations. Particularly, in a collaborative setting, mechanisms that support the detection and resolution of meaning ambiguities and conflicts are urgently needed [3]. In this article we explore to which extent the theory of graph transformation can be used to support this activity. More specifically, we propose the use of critical pair analysis [10] as a formal means to analyse conflicts between ontologies that are evolving in parallel. We will illustrate this by providing a proof-ofconcept through a running example, the ideas of which are based on a realistic case study on competency-driven vocational education that forms part of the European CoDrive project3 . ?
3
The research described in this paper was partially sponsored by the EU Leonardo da Vinci CODRIVE project (B/04/B/F/PP-144.339) and the EU FP6 IST PROLIX project. An EU Leonardo da Vinci Project: http://www.codrive.org
2
Context dependency management
Contexts are key to explicate the relevant commonalities and differences during real-world, gradual ontology elicitation and application efforts. Context dependencies [15] are constructs that constrain the possible relations between the entity and its context. Many different types of context dependencies exist, within and between knowledge artefacts of various levels of granularity, ranging from individual concept definitions to full ontologies. These dependencies can be used to drive ontology engineering processes tailored to the specific requirements of collaborative communities. Figure 1 shows an instance of a context dependency type: the interpretation of the terms that are applied in the template context (on the right-hand side) is dependent on their articulation (concept definition) and categorisation in the taxonomy on the left-hand side. Hence, this context dependency type is called an application (APP) context dependency.
TEMPLATE
TAXONOMY exhibiting / exhibited by
Educational Task
ROOT Quality is an application of (APP)
Process
Quality
Actor Actor
performed by / performing Competence
requiring / required for
Educational Task
GLOSS = "a required work that students must master" SYNSET= {educational work}
Competence
GLOSS = "a person who acts and gets things done" SYNSET= {doer, worker}
Fig. 1. An instance of an application context dependency.
In [15], we showed that, when managed consistently and effectively, tracing context dependencies provides a better understanding of the whereabouts of ontological artefacts and their inter-dependencies, and consequently makes negotiation and application less vulnerable to ambiguity, hence more useful in practice. Instead of being frustrated by out-of-control change processes, proper context dependency management support will allow human experts to focus on the much more interesting meaning interpretation and negotiation processes. Automated support for detecting and resolving meaning ambiguities and conflicts within and between contexts plays a crucial role here.
3
Running example: Vocational Competency Ontology
Our running example is based on a realistic case study on competency-driven vocational education of the European CoDrive project. Competencies describe the skills and knowledge individuals should have in order to be fit for particular jobs. In the domain of vocational education, having a central shared and commonly used competency model is becoming crucial in order to achieve the necessary level of interoperability and exchange of information, and in order to integrate and align the existing information systems of competency stakeholders like schools, job providers, or public employment agencies. The CoDrive project contributes to this goal by using an ontology methodology and infrastructure in order to develop a conceptual, shared and formal knowledge representation of competence domains. Stakeholders include educational institutes and public employment organisations from various European countries. The resulting shared “Vocational Competency Ontology” (VCO) will be used by all partners to build interoperable competency models. Constructing the VCO is not a sinecure: first, one has to determine what competency concepts are relevant for the VCO; and second, different stakeholders usually have overlapping or even contradicting opinions about the intended meaning and use (read: conceptualisation) of particular concepts. Hence, diverging conceptualisations should be anticipated in the ontology engineering methodology. In [4, 16], we developed such a methodology and system for communitybased ontology engineering. One key principle is to bootstrap the ontology elicitation process in a template that describes the relevant properties of the concept in general, abstract terms. In this template context, the abstract terms are taken from an extendible repository of reusable competence definitions (RCDs). We adopt here the definition proposed by the HR-XML consortium: an RCD is a specific, identifiable, definable, and measurable knowledge, skill, ability and/or other deployment-related characteristic (e.g. attitude, behavior, physical ability) which a human resource may possess and which is necessary for, or material to, the performance of an activity within a specific business context.4 . In a constructivist fashion, the template is specialised independently by all participating stakeholders, by replacing the general terms, by one or more concrete terms. Conflicts can easily arise when the template starts to evolve in a way that is incompatible with at least one of the specialisations. Let us illustrate these ideas by means of an example fragment of the VCO. Fig. 2 shows an excerpt from the RCD taxonomy. It shows, among others, that Deliver is some kind of Educational Task, and that Skill is some kind of Competence which, in its turn, is considered to be some kind of Quality. Figure 3 illustrates the process of using template contexts that can be specialised according to the needs of different stakeholders (only one such specialisation is shown, from an educational institute). The template explains how to define an Educational Task, the specialisation refines this to the subtask Deliver. The relations between terms in the template and the specialisation are 4
See http://ns.hr-xml.org/2 5/HR-XML-2 5/CPO/Competencies.html
ROOT
Process
Actor
Educational Task
Student
Quality
Punctual
Deliver
Competence
Skill
Attitude
Fig. 2. Taxonomy of reusable competence definitions (RCD).
denoted by a specialisation (SPE) context dependency in Fig. 3. These context dependencies constrain the use of concepts, and definition of relations between concepts. In particular, SPE -dependencies are allowed only between terms that are in the correct (transitive) taxonomical relationship according to Fig. 2.
EDUCATIONAL INSTITUTE TEMPLATE
exhibiting / exhibited by Deliver
Skill
Student performed by / performing
exhibiting / exhibited by is a specialisation of (SPE)
Educational Task
Quality
Actor Attitude
performed by / performing
requiring / required for
Competence
Skill
requiring / required for
requiring / required for
Fig. 3. Example of an ontology, constrained by the RCD taxonomy in Fig. 2. There is a specialisation context dependency between the template context and the educational institute context.
Now consider the scenario, depicted in Fig. 4, where two parallel evolutions occur between the template and (one of) its specialisation(s). Along the horizontal direction, the knowledge engineer administering the templates decides to specialise a relationship (differentia) in the template. This boils down to replacing Quality with one of its subconcepts Competence (according to the taxonomy of Fig. 2). In the vertical direction, the domain expert who created the specialisation decides to revise it: the task Deliver is no longer exhibiting a Skill,
but rather another subtype of Quality, namely Punctual. These two parallel evolutions result in a conflict when trying to combine them: as depicted on the bottom-right of Fig. 4, Punctual is not a subtype of Competence (as is required by the SPE -dependency). In the next section, we argue how graph transformation theory can be used to detect and analyse such conflicts.
TEMPLATE
TEMPLATE
exhibiting / exhibited by Educational Quality Task
exhibiting / exhibited by Educational Competence Task
SPECIALISATION
SPE specialiseDifferentia
exhibiting / exhibited by Deliver
Skill
SPECIALISATION
SPE
exhibiting / exhibited by Deliver
Skill
changeDifferentiaToSibling
TEMPLATE
TEMPLATE
exhibiting / exhibited by Educational Quality Task
exhibiting / exhibited by Educational Competence Task
SPECIALISATION
SPE
SPECIALISATION
exhibiting / exhibited by Deliver
SPE
exhibiting / exhibited by Punctual
Deliver
Punctual
Fig. 4. Example of a conflict.
4
Formal representation
In [18, 19], we proposed to use graph transformation as a domain-independent formalism for detecting and resolving merge conflicts during parallel evolution of formal artefacts in general, and software in particular. The advantage is that graph transformations provide a domain-independent and formal foundation for both descriptive and operational aspects. The formalism allows to describe a possibly infinite collection of graphs in a finite way: by stating a set of initial graphs and a set of graph transformation rules. Through repeated application of these rules, starting from one of the initial graphs, new graphs can be generated. In this article, we apply this idea to the evolution of collaborative ontologies. Formalising ontology transformations in this way has several advantages: (i) the ontology engineer does not need to specify this sequence of rules explicitly: he
only needs to specify what the new ontology should look like; (ii) we can rely on the concrete graphical syntax to which the users are accustomed to; (iii) we can provide a precise and unambiguous definition of complex context dependency operators; and (iv) we can formally analyse and reason about meaning conflicts between multiple parallel contextualisations of the same original ontology. The main goal of this article is to explore points (iii) and (iv) above, the remaining claims will be explored in future work. For our experiments, we have used version 1.6.2 of AGG, a general-purpose graph transformation tool [27, 28]. 4.1
Representing ontologies
Fig. 5. Type graph representing the metamodel for ontologies.
The metamodel that we use for representing ontologies has been formalised by relying on the notion of a type graph [1]. It is given in Fig. 5. The ontologies themselves are then specified as attributed graphs that conform to this type graph. An example of such a graph is given in Fig. 7. It provides the abstract syntax representation of the ontology that we visualised in Fig. 3. The taxonomy of Fig. 2 is also formally represented as a graph, depicted in Fig. 6. One can see that this abstract graph representation looks considerably more complex than the concrete syntax. In particular, we observe the use of lexons, an essential notion that is introduced in the DOGMA methodology and framework for ontology engineering [15]. Lexons are collected in a lexon base, a reusable pool of possible vocabularies. A lexon is a 5-tuple declaring either (in some context C): 1. a taxonomical relationship (genus), for example hC, punctual, is a, subsumes, qualityi 2. a non-taxonomical relationship (differentia), for example hC, educational task, exhibiting, exhibited by, qualityi
Fig. 6. Graph representing part of the taxonomy of Figure 2.
Fig. 7. Graph representing part of the ontology used as our running example.
When trying to formalise this definition of lexon in AGG, we were confronted with several design choices. Rather than defining a lexon (5-tuple) as a node with 5 outgoing edges, we decided to use three edges only: two hasTerm-edges point to the Terms involved in the lexon, and a hasType-edge points to a node collecting the other relevant information (type of relationship, role, and co-role). To achieve this, we needed to introduce a node type Genus and Differentia in order to express the fact that lexons represent either a taxonomical relationship or a non-taxonomical one. To increase genericity of the graph transformation rules, we wanted to rely on the mechanism of type graph inheritance. As illustrated in Fig. 8, one can use the generic abstract supertype LexonType if the type of relationship is not relevant for the rule. Unfortunately, we could not use this solution, because we also wanted to exploit AGG’s critical pair analysis functionality (see section 4.3), and this is currently not supported in combination with type graph inheritance. Therefore, our adopted solution was to implement a mutual exclusion between node types Genus and Differentia. In Fig. 5 it has been expressed as an xor constraint, which we implemented by defining two additional graph constraints on the type graph.
Fig. 8. Part of the type graph showing the use of inheritance for expressing the type of a lexon.
4.2
Representing context dependency operators
To express context dependency operators as graph transformation rules, we only need to specify the situation before (left-hand-side or LHS) and after (right-handside or RHS) applying the rule. Because AGG supports conditional graph transformation, we may additionally specify positive application conditions (PAC), or negative application conditions (NAC) [9]. A PAC indicates the obligatory presence of a given graph structure (i.e., a certain combination of nodes and edges) in order for the rule to be applicable. Similarly, a NAC indicates the required absence of a graph structure. Figure 9 provides the formal definition of the two operators used in our running example of Sec. 3. Both graph transformation rules, specialiseDiff and changeDiffToSibling have been expressed by using a PAC, because this avoids redundancy between the LHS and RHS, hence making the rules more readable and less complex. We also specified a third operator dropChildTerm (not mentioned in the running example) that can be used to remove terms that are not related to any other term in the taxonomy. This operator, shown in Figure 10, requires the use of a NAC. 4.3
Detecting conflicts
As explained in section 3, in the context of collaborative ontology engineering we are confronted with a situation where a given ontology template is specialised and used by many different organisations. Both the template and the specialisations can evolve in parallel, which gives rise to many sources of meaning conflicts. With the mechanism of critical pair analysis, all potential sources of conflicts can be detected automatically, for each pair of transformation rules. This was the main motivating reason why we decided to use graph transformation theory for our experiments. As far as we know, AGG is the only available tool that implements critical pair analysis. The use of critical pair analysis proved to be a real iterative “trial and error” process. The first time we ran the critical pair analysis algorithm on our transformation rules, we were confronted with severe performance problems. After a couple of hours the algorithm stopped with a sudden out of memory error.
PAC
LHS
PAC
RHS
LHS
RHS
Fig. 9. Two context dependency operators for evolving ontologies, expressed as graph transformation rules with positive application condition (PAC).
NAC
LHS
RHS
Fig. 10. DropChildTerm, another context dependency operator, expressed as graph transformation rule with NAC.
As a first improvement, we computed “essential” critical pairs only, an experimental feature of AGG. This allowed us to obtain some first results, but the computation still took a very long time, and there was a too large number of detected critical pairs, making the manual interpretation of the results nearly impossible. Therefore, as a second improvement we simplified the underlying
graph representation, by replacing all lexons representing a genus (taxonomical relationship) by a directed genus-edge from the source term to the target term. This simplified the graph and the graph transformation rules considerably, since for each occurrence we replaced 2 nodes (Lexon and Genus) and 3 edges (all outgoing edges from Lexon) by a single genus-edge. We also avoided the use of PACs in our new version of the transformation rules, since they had a small negative impact on the computation time of critical pairs.5 The number of detected critical pairs was now reduced to a manageable number, but manual analysis of the results still reveiled many unnecessary duplicates. Therefore, as another improvement, we added some additional graph constraints to express the absence of cyclic structures in the genus or SPE edges. This, finally, led us to the results summarised in Fig. 11. For every pair of transformation rules that was compared, at most one critical situation was reported, and all such critical pairs corresponded to what we intuitively expected.
Fig. 11. Results of running AGG’s critical pair analysis algorithm on our transformation rules.
As a first example, consider the critical pair between ChangeDiffToSibling (first rule) and SpecialiseDiff (second rule). The critical pair reported between both rules is displayed in Fig. 12.6 The figure shows a delete-use-conflict for the SPE -edge with number 7. It arises because both graph transformations modify this SPE -edge in incompatible ways. ChangeDiffToSibling redirects its source edge, while SpecialiseDiff redirects its target edge. This conflict corresponds exactly to the situation that we encountered in our running example of Fig. 4. A second, and different, example of a critical pair occurs between rules DropChildTerm (first rule) and SpecialiseDiff (second rule). It is displayed in Fig. 13. This time, there is a delete-use-conflict for the Term-edge with number 1. It arises because DropTerm attempts to remove a Term-node, whereas SpecialiseDiff requires the presence of this node for its proper functioning. Although not explained in Section 3, it is another typical example of a conflicting situation that can arise when modifying a template ontology and one of its specialisations in parallel. 5 6
Note that all of these optimisations can be done in an automated way. Observe the use of genus-edges that significantly simplifies the representation of the graphs and graph transformations.
Fig. 12. Conflict between the rule ChangeDiffToSibling (first rule) and SpecialiseDiff. The critical situation is displayed on the left, and the green SPE -edge (number 7) indicates the source of the problem.
Fig. 13. Conflict between the rule DropChildTerm (first rule) and SpecialiseDiff. The critical situation is displayed on the left, and the green Term-node (number 1) indicates the source of the problem.
For our current “proof-of-concept” experiment, one could argue that the use of critical pair analysis is overkill since one could identify all potential conflict situations by hand. While this may be true, the point is that the automated analysis allows us to start using the approach on a much more elaborate set of transformation rules. More importantly, the automated approach allows us to identify all conflicting situations in any given source graph, by finding a match of the critical pair in the source graph. Given the size of the ontology models that one encounters in practice, this is something for which the “manual” approach would be unfeasible.
5
Related and Future Work
Heer et al. [11] also apply graph transformation technology to support the integration of ontologies. Their approach differs from ours in various ways. First of all, they adopt a considerably more restricted notion of ontologies. Their so-called “lightweight ontologies” only express taxonomical relationships between concept labels, while ours can handle any other type of relationship.7 Another, and more important, difference is that their approach seems to hard-code the conflicts that can arise during the ontology merging approach, whereas we rely on the generic technique of critical pair analysis. This makes our approach more generic and more tool-independent. Another example of the use of graph transformation that can be reused for ontology engineering is [14], where graph transformation is applied for conducting quality assurance in business-driven development. For a comprehensive survey on ontology evolution state of the art and future directions, we refer to [3]. In [18, 19], we claimed that graph transformation theory could be used as a domain-independent formalism for detecting and resolving merge conflicts during parallel evolution of formal artefacts. These claims seem to correct, since we have already been able to apply the ideas of critical pair analysis in various domains. In [21] we applied it to software refactoring, in [23] we applied it to UML models, and in this article we applied it to ontologies. In [23, 22] we even used the mechanism to detect sequential dependencies between transformations, and to provide semi-automated support for conflict resolution. The same results can also be achieved in the domain of ontology engineering. This is a topic of future work. In order to make the proposed approach acceptable to our user community, we need to offer support using the representation that the users are familiar with. This means that our tools need to make use of the concrete syntax instead of an abstract graph-based syntax. More in particular, we want to be able to detect, report and manage conflicts using the concrete syntax of ontologies. We will work on this aspect in the future. It is worthwhile to note that a lot of progress in this direction has been made by the graph transformation community. Indeed, many different researchers have proposed solutions for trying to combine the virtues of a concrete domain-specific graphical syntax with the underlying mechanism of graph transformation. Examples of this are Tiger [29], DiaGen [25], DiaMeta [24], and ATOM3 [2]. The second requirement to make the theory acceptable to our user community is by integrating it in a seamless manner into the ontology engineering tools that they are currently using. In particular, we envisage integration of the graph transformation approach into the DOGMA tool [4]. A natural way to achieve such integration is by relying on a common underlying development platform. Given that DOGMA is implemented as an Eclipse plug-in, Eclipse seems to be 7
In this article, we only showed the non-taxonomical relationship differentia, but our approach can be extended in a straightforward way to other types of relationships as well.
the platform of choice. Also for AGG, the graph transformation tool that we have used for our experiments, various Eclipse plug-ins exist. ROOTS [13] is an Eclipse plug-in that replaced the default GUI of AGG by an Eclipse-based one. The Tiger EMF transformation project [5] is another Eclipse plug-in for AGG that allows to generate domain-specific visual editors. By combining all of these plug-ins, we aim to develop a domain-specific tool whose underlying foundation of graph transformation is transparent to the user. Our running example, although using only a few simple context dependency operators, already demonstrates the usefulness of graph rewriting for context dependency management emerging in a typical case of collaborative ontology engineering. When introducing additional context dependency operators and types, complexity only grows. Furthermore, we did not consider all primitive constructs of an ontology. For example, axioms constraining the possible use of concepts and relationships makes context dependency management even more difficult. Finally, we also plan to consider other relevant applications of graph transformation. For example, in [22], we did a formal and static analysis of mutual exclusion relationships and causal dependencies between different alternative resolutions for model inconsistencies that can be expressed in a graph-based way. Currently, we are adopting these results for the DOGMA meta schema in particular. Doing so, this analysis can be exploited to further improve the conflict resolution process, e.g., by detecting possible cycles in the resolution process, by proposing a preferred order in which to apply certain resolution rules, and so on.
6
Conclusion
One of the goals of our work was to bring the research communities of software evolution [20] and ontology engineering [12] closer together. It turns out that both research domains can benefit from the same underlying foundation, in casu graph transformation theory. Graph transformation rules can be used to formally represent the evolution operators, and critical pair analysis can be used to automate the detection of merge conflicts between these operators. In this article, we relied on graph transformation theory for supporting context dependency evolution processes, based on the DOGMA framework and methodology for scalable ontology engineering. Key notions are a set of transformation rules expressing context dependency operators, that can be combined to manage complex context dependencies like SPE -dependencies, which in turn can be used in context-driven ontology engineering processes tailored to the specific requirements of collaborative communities. The detection of conflicts during ontology evolution was supported by the technique of critical pair analysis. A proof-of-concept experiment of this technique has been carried out with AGG, based on a running example of collaborative ontologies for vocational education taken from a European project. While the results are encouraging, further work is needed to integrate the approach in contemporary ontology engineering tools (such as DOGMA Studio WorkBench
[26]), and to extend the idea to provide formally founded automated support for conflict resolution as well. We also need to validate the scalability of our approach on full-fledged industrial case studies.
References 1. Andrea Corradini, Ugo Montanari, and F. Rossi. Graph processes. Fundamenta Informaticae, 26(3 and 4):241–265, 1996. 2. J. de Lara and Hans Vangheluwe. ATOM3 : A tool for multi-formalism and metamodelling. In Proc. Fundamental Approaches to Software Engineering (FASE), volume 2306 of LNCS, pages 174–188, April 2002. 3. Pieter De Leenheer and Tom Mens. Ontology Management for the Semantic Web, Semantic Web Services, and Business Applications, chapter Ontology Evolution: State of the Art and Future Directions. Springer, 2008. 4. Aldo de Moor, Pieter De Leenheer, and Robert Meersman. DOGMA-MESS: A meaning evolution support system for interorganizational ontology engineering. In Proc. ICCS 2006, volume 4068 of LNAI, pages 189–203. Springer-Verlag, 2006. 5. Claudia Ermel, Karsten Ehrig, Gabriele Taentzer, and E. Weiss. Object-oriented and rule-based design of visual languages using tiger. In Proc. workshop on GraphBased Tools (GraBaTs), volume 1 of Electronic Communications of the EASST, 2006. 6. E.D. Falkenberg. Frisco : A framework of information system concepts. Technical report, IFIP WG 8.1 Task Group, 1998. 7. T. Gruber. Cyc: a translation approach to portable ontologies. Knowledge Acquisition, 5(2):199–220, 1993. 8. N. Guarino. Formal ontology and information systems. In Proc. of FOIS 1998, pages 3–15. IOS Press, 1998. 9. Reiko Heckel. Algebraic graph transformations with application conditions. Master’s thesis, Technische Universit¨ at Berlin, 1995. 10. Reiko Heckel, Jochen Malte K¨ uster, and Gabriele Taentzer. Confluence of typed attributed graph transformation systems. In Proc. Int’l Conf. Graph Transformation (ICGT), volume 2505 of Lecture Notes in Computer Science, pages 161–176. Springer-Verlag, 2002. 11. Thomas Heer, Daniel Retkowitz, and Bodo Kraft. Algorithm and tool for ontology integration based on graph rewriting. In Proc. Applications of Graph Transformations with Industrial Relevance (AGTIVE), pages 484–490, Wilhelmsh¨ ohe, Kassel, Germany, 2007. 12. Martin Hepp, Pieter De Leenheer, Aldo de Moor, and York Sure, editors. Ontology Management for the Semantic Web, Semantic Web Services, and Business Applications. Springer, 2008. 13. Stefan Jurack and Gabriele Taentzer. ROOTS: An Eclipse plug-in for graph transformation systems based on AGG. In Proc. Applications of Graph Transformations with Industrial Relevance (AGTIVE), pages 491–496, 2007. 14. J. Koehler, T. Gschwind, and J. K¨ uster. Combining quality assurance and model transformations in business-driven development. In Proc.of Agtive2007. Springer, 2007. 15. Pieter De Leenheer, Aldo de Moor, and Robert Meersman. Context dependency management in ontology engineering: a formal approach. LNCS Journal on Data Semantics, 8:26–56, 2007.
16. Pieter De Leenheer and Robert Meersman. Towards community-based evolution of knowledge-intensive systems. In Proc.of ODBASE2007. Springer, 2007. 17. Robert Meersman. The use of lexicons and other computer-linguistic tools in semantics, design and cooperation of database systems. In Proc.of CODAS 1999, pages 1–14. Springer, 1999. 18. Tom Mens. A Formal Foundation for Object-Oriented Software Evolution. PhD thesis, Department of Computer Science, Vrije Universiteit Brussel, Belgium, September 1999. 19. Tom Mens. Conditional graph rewriting as a domain-independent formalism for software evolution. In Proc. Applications of Graph Transformations with Industrial Relevance (AGTIVE), volume 1779 of Lecture Notes in Computer Science, pages 127–143. Springer-Verlag, 2000. 20. Tom Mens and Serge Demeyer, editors. Software Evolution. Springer-Verlag, 2008. 21. Tom Mens, Gabriele Taentzer, and Olga Runge. Analyzing refactoring dependencies using graph transformation. Software and Systems Modeling, 2007. 22. Tom Mens and Ragnhild Van Der Straeten. Incremental resolution of model inconsistencies. In Jos´e Luiz Fiadeiro and Pierre-Yves Schobbens, editors, Algebraic Description Techniques, volume 4409 of Lecture Notes in Computer Science, pages 111–127. Springer-Verlag, 2007. 23. Tom Mens, Ragnhild Van Der Straeten, and Maja D’Hondt. Detecting and resolving model inconsistencies using transformation dependency analysis. In Oscar Nierstrasz, John Whittle, David Harel, and Gianna Reggio, editors, Model Driven Engineering Languages and Systems, volume 4199 of Lecture Notes in Computer Science, pages 200–214. Springer-Verlag, October 2006. 24. Mark Minas. Generating meta-model-based freehand editors. In Proc. Int’l Workshop Graph-Based Tools (GraBaTs), Electronic Communications of the EASST, Natal, Brazil, September 2006. 25. Mark Minas and G. Viehstaedt. DiaGen: A generator for diagram editors providing direct manipulation and execution of diagrams. In Proc. IEEE Symp. Visual Languages, pages 203–210, 1995. 26. Vrije Universiteit Brussel STAR.Lab. DOGMA Studio WorkBench. http://www.starlab.vub.ac.be/website/dogmastudio, 2007. 27. Gabriele Taentzer. AGG: A graph transformation environment for modeling and validation of software. In Proc. Applications of Graph Transformations with Industrial Relevance (AGTIVE), volume 3062 of Lecture Notes in Computer Science, pages 446–453. Springer-Verlag, 2004. 28. Gabriele Taentzer. AGG. http://tfs.cs.tu-berlin.de/agg, November 2007. 29. Gabriele Taentzer, Ren´e Schmutzler, and Claudia Ermel. Generating domainspecific model editors with complex editing commands. In Andy Sch¨ urr, Manfred Nagl, and Albert Z¨ undorf, editors, Proceedings of AGTIVE 2007: Applications of Graph Transformations with Industrial Relevance, Wilhelmsh¨ ohe, Kassel, Germany, October 2007.
