Andreas L Opdahl
email: andreas.opdahl@uib.no

Anatomy of the Unified Enterprise Modelling Ontology

Keywords: Ontology, ontological analysis and evaluation, Unified Enterprise Modelling Language (UEML), Unified Enterprise Modelling Ontology (UEMO), OWL2, description logic

The Unified Enterprise Modelling Language (UEML) aims to become a hub for integrated use of enterprise and information systems (IS) models expressed using different languages. A central part of this hub is an extendible ontology into which modelling languages and their constructs can be mapped, so that precise semantic relations between the languages and constructs can be established by comparing their ontology mappings. The paper presents and discusses ongoing work on reformulating the UEML ontology as an OWL2 DL ontology, the Unified Enterprise Modelling Ontology (UEMO).

Introduction

The Unified Enterprise Modelling Language (UEML) supports precise semantic definition of a wide variety of enterprise and IS-modelling languages. It aims to use the definitions to also facilitate integrated use of models expressed in those languages [START_REF] Anaya | The Unified Enterprise Modelling Language -Overview and Further Work[END_REF]. The aim is an important one because information and software technologies are becoming increasingly driven by models, making interoperability between modelling languages and models a helpful step on the way to achieving interoperability between model-driven information and software systems.

To facilitate integrated use of models expressed in a wide variety of languages, the language definitions must be made semantically interoperable. UEML approaches this problem through a structured approach to describing enterprise and IS-modelling constructs in terms of an evolving ontology [START_REF] Opdahl | A Platform for Interoperable Domain-Specific Enterprise Modelling Based on ISO 15926[END_REF][START_REF] Opdahl | Incorporation UML Class and Activity Constructs into UEML[END_REF]. So far, 130 constructs from a selection of 10 languages have been mapped into the ontology, although with varying degrees of precision. Whereas the idea of using an ontology to describe and integrate modelling languages is not new in itself, UEML describes and integrates the semantics of modelling constructs in a novel way that combines (1) a systematic, finegrained approach to describing the semantics of modelling constructs with (2) a systematic approach to structuring and evolving the underlying ontology. UEML thus goes further than other ontology-based approaches to enterprise model interoperability (e.g., [START_REF] Kappel | Lifting metamodels to ontologies -a step to the semantic integration of modeling languages[END_REF][START_REF] Ziemann | Achieving Enterprise Model Interoperability Applying a Common Enterprise Metamodel[END_REF]) because it is complemented by an extensive framework for systematically describing modelling constructs and because it has been explicitly designed to evolve and grow over time without becoming overly complex.

It is the common ontology at the heart of UEML that is the focus of this paper. On the meta-ontology (or structure) level it distinguishes itself from comparable approaches by simultaneously [START_REF] Anaya | The Unified Enterprise Modelling Language -Overview and Further Work[END_REF] promoting states and transformations to first-order concepts alongside things/classes and their properties, (2) providing better support for complex properties, [START_REF] Opdahl | Incorporation UML Class and Activity Constructs into UEML[END_REF] treating relations between things and classes as a type of mutual (or relational, shared) property of things/classes alongside intrinsic properties and (4) considering laws as another type of property of things/classes. On the ontology (or content) level it is distinct (1) by being the first middle-level ontology dedicated to enterprise and IS modelling in general, (2) by being explicitly grounded in Mario Bunge's philosophical ontology [START_REF] Bunge | Treatise on Basic Philosophy[END_REF][START_REF] Bunge | Treatise on Basic Philosophy[END_REF] and (3) by offering particularly precise and elaborate dynamic and systemic concepts. Because of its grounding in Bunge's ontology and its adaptation to the information systems field (e.g., [START_REF] Wand | On the Ontological Expressiveness of Information Systems Analysis and Design Grammars[END_REF]), the common UEML ontology is ontological in both the philosophical and computer-science senses, although its mathematically formal underpinnings have been less developed so far. A set of OCL-constraints were presented in [START_REF] Opdahl | Template-Based Definition of Information Systems and Enterprise Modelling Constructs[END_REF] and later extended and re-written in Prolog [START_REF] Mahiat | A Validation Tool for the UEML Approach[END_REF][START_REF] Anaya | The Unified Enterprise Modelling Language -Overview and Further Work[END_REF]. But, beyond that, the UEML ontology has not been formalised so far.

This paper therefore presents a first formalisation of UEML's central ontology concepts by reformulating its classes, properties, states and transformations using OWL2 DL [START_REF] Horrocks | The Even More Irresistible SROIQ[END_REF]. The purpose of the resulting Unified Enterprise Modelling Ontology (UEMO) is threefold. Firstly, we want to contribute towards a more precise UEML, to which the formalisation is a direct contribution. Secondly, we want to make UEML supported by formal reasoning approaches and tools. Although the old UEML ontology was represented in OWL, it did not leverage the full potential of OWL DL as a specification and reasoning language and did not explore the stronger expressiveness of OWL2. Thirdly and finally, we want to be able to show that the core of UEML has nice decision problems, i.e., that it is sound, complete and tractable with respect to many of its anticipated uses.

The rest of the paper is organised as follows. Section 2 presents the Unified Enterprise Modelling Language (UEML). Section 3 presents the backbone of the Unified Enterprise Modelling Ontology (UEMO). Section 4 outlines how UEMO can be used to facilitate interoperability between modelling constructs. Section 5 discusses the results. Finally, Section 6 concludes the paper and suggests paths for further work. Of course, a conference-length paper such as this can only explain a selection of UEMO's most important concepts. Several of our definitions have therefore been simplified because they rely on concepts that are not explained in the paper. Development versions of UEMO are available on http://www.uemlwiki.org/ .

Theory

Construct description in UEML: UEML describes a modelling language mainly in terms of its modelling constructs. For each construct, both its syntax and semantics are described. The intended semantics of a modelling construct is described in a structured way according to the following six parts (see, e.g., [START_REF] Opdahl | The UEML Approach to Modelling Construct Description[END_REF]): properties that this or these thing(s)/class(es) possess. The properties may be complex, having other properties as sub-properties. In UEML, some complex properties even constrain their sub-properties and their values. Such properties are called laws [6, pp. 77-80]. 5. States of things: Some behavioural modelling constructs represent particular states in their things or classes. States are defined in terms of a thing's properties by a state constraint that restricts these properties' values. 6. Transformations of things: Behavioural modelling constructs may even represent transformations of things/classes from a pre-to a post-state. Transformations are described by the properties that define the pre-and post-states and by a transformation function that prescribes changes to these properties' values. Instead of mapping modelling constructs one-to-one with concepts in an ontology, UEML thereby describes each modelling construct as a scene of interrelated roles that are played by ontology concepts, so that the roles are either classes/things (item 3 above), their properties (item 4), their states (item 5) or their transformations (item 6). The roles are interrelated so that classes/things possess properties (that characterise the classes); properties define states; transformations have pre-and poststates; state constraints restrict states; transformation functions prescribe transformations; and by taxonomical/hierarchical relations we will explain later. The scene can be described in further detail by cardinality constraints on the relations between roles; by equivalence and/or disjointness axioms on roles; and by other types of constraints [START_REF] Opdahl | Incorporation UML Class and Activity Constructs into UEML[END_REF].

For example, a scene that describes the Class construct in UML would have a "class" role that describes the class of things that UML-Class is intended to represent. Because UML-Class is a very general modelling construct, the "class" role is played by Anything, which we will see is the most general of all classes in UEMO. The scene would also comprise a "name" role that describes the name property that has been assigned to the class and zero or more "attribute" and "operation" properties to describe its attributes and operations, each of them played by a precisely defined ontology property. Further roles would be used to describe associations, including aggregation/composition, and generalization relationships between UML-Classes.

Description logic: Description logic (DL) is a family of knowledge representation languages that are well suited for automated reasoning [START_REF] Donini | Reasoning in Description Logic[END_REF]. The SHOIN and SROIQ [START_REF] Horrocks | The Even More Irresistible SROIQ[END_REF] variants of description logic correspond roughly to the ontology representation languages OWL and OWL2, respectively, so that OWL classes correspond to DL concepts and OWL object properties correspond to DL roles. There are even DL features that correspond to OWL datatype properties, but we will not use them here. Description logics can be considered a fragment of 1. order predicate calculus, but with nicer decision problems. [START_REF] Donini | Reasoning in Description Logic[END_REF] and [START_REF] Nardi | An Introduction to Description Logics[END_REF] offer introductions to basic DL notation and reasoning.

The Unified Enterprise Modelling Ontology (UEMO)

Overall structure: UEMO's concepts are partitioned into classes of things, properties, states and transformations, as in the UEML ontology. In addition, UEMO introduces values of properties. These five types of ontology concepts are disjoint but interrelated, so that classes of things possess properties; properties have values and define states; and transformations have pre-and post-states. Furthermore, state constraints and transformation functions are sub-types of properties that restrict states and prescribe transformations, respectively The resulting ontology structure is shown in Figure 1. Hence, UEMO has the same structure as the scenes that describe individual modelling constructs, so that each scene can be considered an excerpt from UEMO, possibly with added role names, tighter cardinalities and other constraints.

UEMO defines each concept as an OWL2 class (or description logic concept) and its interrelations as OWL2 object properties (or description logic roles) as follows:

Anything ≡ possesses.AnyProperty possesses.AnyProperty ∃ ⊓ ∀ AnyProperty ≡ belongsTo.Anything belongsTo.Anything ∃ ⊓ ∀ StateConstraint ≡ AnyProperty restricts.AnyState (=1 restricts) ⊓ ∀ ⊓ TransformationFunction ≡ AnyProperty prescribes.AnyTransformation (=1 prescribes) ⊓ ∀ ⊓ AnyState ≡ ∀restrictedBy.StateConstraint (=1 restrictedBy) ⊓ ⊓ definedBy.ConstrainedProperty ∃ AnyTransformation ≡ prescribed ∀ By.TransformationFunction ⊓ (=1 prescribedBy) ⊓ ∀preState.MutableState (=1 preState) ⊓ ⊓ ∀postState.AnyState (=1 postState) ⊓ AnyValue ≡ valueOf.ValuedProperty ∀ Anything AnyProperty AnyState ⊓ ⊓ ⊓ AnyTransformation AnyValue ⊓ ⊑ ⊥ Figure 1.
High-level OWL2 classes that show the structure of UEMO.

Restrictions like

restricts.AnyState ⋯∀ ⊓ (=1 restricts)⋯ are used instead of the conciser (=1 restricts). ⋯ AnyState⋯ to limit the ontology to SHIN expressiveness (e.g., [START_REF] Horrocks | The Even More Irresistible SROIQ[END_REF], which, however, discuss slightly more powerful DL variants), which is supported by both "OWL1" and OWL2, thus giving access to a broader selection of reasoners and other tools.

Additional taxonomy relations organise the ontology concepts into five taxonomies. (1) Classes may specialise other classes. The root of the class taxonomy is Anything. ( 2) Properties may precede other properties, so all things that possess a property, such as "being-human", necessarily possess its precedents too, such as "being-alive". The root of this taxonomy is AnyProperty. (3) States may refine other states (OR-decomposition), with AnyState at the root of the taxonomy. ( 4) Transformations may elaborate other transformations (OR-decomposition), with AnyTransformation as taxonomical root. ( 5) Values may extend other values. The root of this taxonomy is AnyValue. The five root concepts were shown Figure 1, which also depicted StateConstraint and TransformationFunction as important subtypes of AnyProperty. UEMO comprises several hierarchical relations in addition to the taxonomical ones: properties may be sub-properties of complex ones; states may be regions of composite states (AND-decomposition); transformations may be components of parallel transformations and steps in sequential ones (two ways to AND-decompose transformations). We now present each taxonomy in some detail.

Class taxonomy: According to [START_REF] Wand | On the Ontological Expressiveness of Information Systems Analysis and Design Grammars[END_REF], "[A] class is a set of things that possess a common property", where things and their properties are the most basic concepts in Bunge's ontology [START_REF] Bunge | Treatise on Basic Philosophy[END_REF]. Anything is the root of the class taxonomy, so the Anything class in our OWL2 DL reformulation subsumes all the other class concepts in UEMO. The definitions of Composite and Component illustrate how we introduce sub-roles (through owl:subPropertyOf axioms on object properties), such as possessesAsWhole ⊑ possesses and possessesAsPart ⊑ possesses, of the possesses role to indicate more specific roles that UEML's properties may play in relation to their things/classes. For example, without sub-roles, it would have been difficult to formally distinguish Composite from Component. It would also have been impossible to limit the current UEMO to SHIN expressiveness. We will encounter more sub-roles later.

According to Bunge [START_REF] Bunge | Treatise on Basic Philosophy[END_REF], a CoupledThing is one that interacts with one or more other things so that their histories of states and events depend on one another. Together, these things form a System. Hence, a CoupledThing is both a RelatedThing, a ChangingThing and a Component in a System. In addition, there are LawfulThings (similar to natural kinds [6, p. 143]) that possess law properties, which we will say more about later. We have to omit many other UEMO classes, such as the different types of active and executing things and resources, which have been included in the ontology either because they are needed directly to describe modelling constructs as part of the UEML work or indirectly to make other UEMO concepts clearer.

In addition to the named classes, we can use description logic expressions to introduce anonymous classes (and anonymous properties, states and transformations). Such a class can be used to define modelling constructs just like named classes, but does not contribute to making the ontology unwieldy. If it turns out to be useful over time, it can be named and included in the ontology later. For example: Property taxonomy: In Bunge's ontology [START_REF] Bunge | Treatise on Basic Philosophy[END_REF], properties belong to things and characterise classes. According to [START_REF] Wand | On the Ontological Expressiveness of Information Systems Analysis and Design Grammars[END_REF], "[A] property is modelled via an attribute function that maps the thing into some value." Because AnyProperty is the root of the property taxonomy, the AnyProperty class in our OWL2 DL reformulation subsumes all the other property concepts in UEMO, where subsumption between property concepts has been defined to correspond to Bunge's property precedence, i.e., that all things that possess a property necessarily possess its precedents too [START_REF] Bunge | Treatise on Basic Philosophy[END_REF]. Immediately below AnyProperty in the taxonomy is IntrinsicProperty, Relation and PartWholeRelation (Figure 3). IntrinsicProperty belongs to a single thing only. Relation belongs to more than one thing, but is not a part-whole relation. PartWholeRelation belongs to a whole thing (the Composite) and its part thing (the Component).

IntrinsicProperty ≡ AnyProperty belongsTo.Anything (=1 belongsTo) ⊓ ∀ ⊓ Relation ≡ AnyProperty belongsTo.RelatedThing (≥2 belongsTo) ⊓ ∀ ⊓ ⊓ ¬ belongsToWhole.Composite ¬ belongsToPart.Component ∃ ⊓ ∃ PartWholeRelation ≡ AnyProperty ⊓ belongsToWhole.Composite (=1 belongsToWho ∀ ⊓ le) ⊓ belongsToPart.Component (=1 belongsToPart) ∀ ⊓ ⊓ belongsToPartOrWhole.Component (=2 belongsToPartOrWhole) ∀ ⊓ belongsTo ≡ possesses -1
Here, the belongsToPartOrWhole role is introduced so we can assert that the Component and the Composite are different things. Because OWL2 DL prohibits role disjunction, this role has been derived using SWRL [START_REF] Horrocks | SWRL: A Semantic Web Rule Language Combining OWL and RuleML[END_REF]: belongsToPart(?c1, ?c2) → belongsToPartOrWhole(?c1, ?c2) belongsToWhole(?c1, ?c2) → belongsToPartOrWhole(?c1, ?c2) UEMO thereby circumvents OWL2 DL limitations by using SWRL and its extension SQWRL [START_REF] O'connor | SQWRL: a query language for OWL[END_REF], which allows sets and bags to be used in rules.

These three successors of AnyProperty, i.e., IntrinsicProperty, Relation and PartWholeRelation, are disjoint, or mutually exclusive, in OWL2 terms, so that no property can be preceded by more than one of them. But they are not incompatible, meaning that the same thing can possess several of them at the same time.

An Of course, there are many property concepts we cannot discuss here, including more specific types of behaviours and laws. For example, UEMO has socially assigned properties, such as Name, which is an association between a Namegiver and a NamedThing. Information and SocialLaws are other examples of assigned properties. UEMO also has concepts for Mutable-and ImmutableProperties, which come in both strong (e.g., CompletelyImmutableProperty) and weak (e.g., SomewhatMutable-Property) forms, because a property can change in many different ways, i.e., it can be dropped by its thing, it can have its value changed, it can drop a sub-property if it is complex or be dropped by its superior if it is a sub-property.

State taxonomy: According to [START_REF] Wand | On the Ontological Expressiveness of Information Systems Analysis and Design Grammars[END_REF], a state is "[T]he vector of values for all attribute functions of a thing" at a particular time, where an attribute function describes a property by mapping the thing to some value. AnyState is the root of the state taxonomy. Hence, the AnyState class in our OWL2 DL reformulation subsumes all the other state concepts in UEMO, where subsumption between state concepts has been defined to correspond to OR-decomposition of states.

A Transformation taxonomy: According to [START_REF] Wand | On the Ontological Expressiveness of Information Systems Analysis and Design Grammars[END_REF], a transformation of a thing "is a mapping from a domain comprising states to a co-domain comprising states." AnyTransformation is the root of the transformation taxonomy. The AnyTransformation class in our OWL2 DL reformulation therefore subsumes all the other transformation concepts in UEMO, where subsumption between transformation concepts has been defined to correspond to OR-decomposition of transformations.

A SelfTransformation in a thing only manipulates the thing's own properties, whereas an ExternalTransformation manipulates at least one Relation property that the thing shares (possesses mutually with) another thing. A Destabilising transformation takes the thing from a Stable-to an UnstableState and a Stabilising takes it back. A Destabilising is always an ExternalTransformation, because nothing destabilises itself, i.e., there are no Destabilising SelfTransformations. Value taxonomy: Bunge's ontology [START_REF] Bunge | Treatise on Basic Philosophy[END_REF] does not account for values directly, but treats properties as dichotomous (either possessed by the thing or not). Instead of valued properties such as a "has-age" property that maps to values like "25" and "50", Bunge therefore uses properties such as "has-age-of-25" and "has-age-of-50". UEMO offers valued properties because they are simpler to use. No generality is lost, because valued properties ("property-name" = "value") can trivially be transformed into dichotomous ones ("property-name-of-value").

AnyValue is the root of the value taxonomy, so that the AnyValue class in our OWL2 DL reformulation subsumes all the other value concepts in UEMO, where subsumption between value concepts has been defined to cover both regular subsetting and something we call augmentation (adding new components to tuples). A Set has other values as elements, whereas a Tuple has other values as components. We name inverse roles of values by adding the suffix -Of, e.g., valueOf ≡ value -1 , componentOf ≡ component -1 and elementOf ≡ element -1 etc.

AnyValue ≡ valueOf.ValuedProperty ∀ Set ≡ AnyValue element.AnyValue ¬ component.AnyValue ⊓ ∀ ⊓ ∃ Tuple ≡ AnyValue ⊓ component.AnyValue (≥1 component) ¬ element.AnyValue ∀ ⊓ ⊓ ∃
The basic idea is that certain sub-types of values are Constraints that describe States, whereas other sub-types of values are Functions that describe Transformations. However, we have so far only covered transformations that are simple mappings from pre-to post-states, not transformations where inputs arrive and outputs depart at different times, with some outputs possibly being produced before all inputs have been consumed. A fuller definition of transformation functions along the lines discussed, e.g., in [START_REF] Harel | Modelling Languages: Syntax, Semantics and all that Stuff (or, What's the Semantics of[END_REF] has to be left for further work.

Using UEMO

The preceding section has formulated UEMO as an OWL2 DL ontology with SHIN expressiveness (e.g., [START_REF] Horrocks | The Even More Irresistible SROIQ[END_REF]). While using UEMO to facilitate interoperability between models expressed using different languages remains work in progress, this section suggests how UEMO can facilitate describing and comparing modelling constructs semantically.

Describing modelling constructs: To describe modelling constructs in terms of UEMO, the ontology must be extended with an additional OWL class (DL concept) for ModellingConstructs and a new OWL object property (DL role) that map ModellingConstructs to the OntologyConcepts they represent:

OntologyConcept ≡ ¬ represents ∃ ⊓ (Anything AnyProperty AnyState AnyTransformation AnyValue) ⊔ ⊔ ⊔ ⊔ ModellingConstruct ≡ represents.OntologyConcept represents.OntologyConcept ∃ ⊓ ∀
ModellingConstruct formalises the earlier concept of scene, so that each role in the scene is an OntologyConcept that the ModellingConstruct represents. Sub-roles of the represents role are used to distinguish between the different roles of the scene. For example, the "class" role in the scene that describes the Class construct in UML is accounted for by the DL-role representsClass ⊑ represents. In consequence, UML-Class can be described as follows (leaving out association, aggregation/composition, generalisation and a few other details for now):

UMLClass ≡ ModellingConstruct ⊓ representsClass.Anything (=1 representsClass) ∃ ⊓ ⊓ representsName.Name (=1 representsName) ∃ ⊓ ⊓ representsAttribute.(IntrinsicProperty AssignedProperty) ∀ ⊔ ⊓ representsOperation.FiringLaw representsAssociation.Relation ∀ ⊓ ∀ ⊓ ⋯
Further axioms can be introduced for a modelling construct, e.g., to constrain the relations between the roles in its scene or their cardinalities. The internal consistency of a modelling construct description thereby becomes a concept satisfiability problem (e.g., [START_REF] Donini | Reasoning in Description Logic[END_REF]). For UMLClass, this problem has the following form, where T is the set of terminological axioms (the TBox) for ontology concepts and modelling constructs in UEMO:

T ⊭ UMLClass ≡ ⊥
Comparing modelling constructs: We approach detailed comparison of modelling constructs as a sub-role matching problem. The above example introduced UMLClass with the sub-roles representsClass, representsName, representsAttribute etc. We now want to compare UMLClass to another ModellingConstruct, GRLGoal, which has sub-roles such as representsAgent, representsTarget and representsGoal [START_REF] Matulevi Ius | Comparing GRL and KAOS using the č UEML Approach[END_REF]. One possible matching of sub-roles is between representsClass (of UMLClass) and representsGoal (of GRLGoal), which are restricted as follows by their respective modelling constructs:

representsClass.Anyth ⋯ ∃ ing (=1 representsClass) ⊓ ⋯ (by UMLClass) representsGoal.Behaviour ⋯ ∃ ⊓ (=1 representsBehaviour) ⋯ (by GRLGoal)
We match the two sub-roles by giving them the same name (ignoring possible name clashes for now), e.g., representsClassAndGoal. As a result, the conjunction UMLClass' GRLGoal' of the renamed concepts UMLClass' and GRLGoal' ⊓ contains this combined restriction:

representsClassAndBehaviour.(Anything ⋯ ∃ ⊓ Behaviour) ⊓ (=1 representsClassAndBehaviour) ⋯
We compare the UMLClass and GRLGoal constructs by investigating all possible matchings of UMLClass sub-roles with GRLGoal sub-roles, including combinations where some or all sub-roles of either construct remain unmatched. The result will be a large number of candidate matches, each of which combines sub-roles of UMLClass with sub-roles of GRLGoal in a different way. Fortunately, most candidate matches can be immediately discarded, because they contain self-contradictory role restrictions, i.e., restrictions whose conjunction is not satisfiable. In the above example, UMLClass' GRLGoal' can be safely discarded ⊓ because Anything (a UEMO-class concept) and Behaviour (a UEMO-property concept) are disjoint by definition. In other cases, it is the number restrictions or other restrictions on the renamed sub-roles that are self-contradictory. The above test for internal consistency of modelling constructs can be used to eliminate candidate matches too:

T ⊭ UMLClass' GRLGoal' ⊓ ≡ ⊥
We expect that most candidate matches generated by brute-force combination of subroles can be immediately discarded because they are not satisfiable. The much smaller set of satisfiable matches must be considered further by other means, most likely involving human inspection and assessment, which can possibly be aided by automatic ontology classification that arranges the remaining candidates in a more easily explored subsumption hierarchy. The top match of this hierarchy would be the least restrictive candidate, the one that does not match any sub-roles of the two constructs, whereas each leaf would be a candidate that is not restricted further by any other candidate. The search for the best candidate can proceed bottom-up and breadth-first from the leaves of the subsumption hierarchy. The selected best match can be written on the form UMLClass* GRLGoal* ⊓ so that the information represented by UMLClass* and not by GRLGoal* and vice versa can be written

InformationLostFromUMLClassToGRLGoal ≡ UMLClass* ¬GRLGoal* ⊓ InformationMissingFromUMLClassToGRLGoal ≡ ¬UMLClass* GRLGoal* ⊓
These two concepts describe, respectively, the information that will be lost and the information that is missing and must somehow be provided when translating from a UMLClass to a GRLGoal (of course, they also describe the missing/lost information when translating back from GRLGoal to UMLClass).

Comparing modelling languages: Not accounted for here is the complementary problem of aligning modelling languages construct-wise, identifying which constructs or groups of constructs in one language that correspond most closely to the constructs or groups in the other, as a necessary preparation for detailed construct comparison.

Facilitating cross-language interoperability: Further work should explore how to facilitate cross-language model-to-model translations based on the detailed construct matchings described here. One approach is to store model elements expressed in one language as OWL individuals and then use complex SPARQL and/or SQWRL queries to retrieve them as model elements expressed in another language. Another strategy is to use construct matches to generate QVT or other transformations, along the lines suggested in [START_REF] Roser | Automatic Generation and Evolution of Model Transformations Using Ontology Engineering Space[END_REF] which, however, does not build an extensive ontology. To adopt their approach, UEMO must first be extended to account for intended modelling-language and -construct syntax in addition to semantics.

Discussion

UEMO is still evolving and currently comprises 225 OWL classes (or DL concepts), although this number is somewhat inflated because it explicitly defines many anonymous concepts that may not be needed in the production version of the ontology. Most of the OWL classes represent UEMO classes and properties, with fewer representing UEML states and transformations so far. Compared to earlier versions of the UEML ontology, many new UEMO properties have been introduced to more precisely describe mutability and immutability, transients and persistence, assignments, complex properties, behaviours and laws. UEMO restricts the OWL classes with 567 subclass and 42 disjointness axioms and connects them with 96 object properties (or DL roles) that are in turn restricted by 97 sub-property (owl:subPropertyOf, aka Bunge-precedence) and 257 other axioms.

The work has shown that a large part of UEMO can be expressed in OWL2 DL and, so far, even in the relatively inexpressive SHIN sub-language [START_REF] Horrocks | The Even More Irresistible SROIQ[END_REF], making a wider range of reasoners and other tools available, because SHIN is supported by both "OWL1" and OWL2. In addition, S(Q)WRL [START_REF] Horrocks | SWRL: A Semantic Web Rule Language Combining OWL and RuleML[END_REF][START_REF] O'connor | SQWRL: a query language for OWL[END_REF] has been used to express certain additional constraints. Unfortunately, these "externally expressed" restrictions thereby become out of reach for DL-based reasoners, and further work must consider how they can be best used to reason about modelling languages and constructs. Two other groups of very general constraints seem infeasible to express even in S(Q)WRL, because they may require modal and/or temporal axioms. One group comprises UEMO concepts for transients and persistence and for certain types of mutability. Another includes [START_REF] Bunge | Treatise on Basic Philosophy[END_REF] definitions of couplings and of systems. Further work should attempt to describe as many of these constraints as possible "inside" OWL2 DL, investigating, e.g., whether the modal/temporal axioms may at least have implications that can be expressed in DL form.

The present work has contributed both to making UEMO more precise and to supporting it with automatic reasoning tools. It has also indicated that several of the possible uses of UEMO have nice decision problems. UEMO also has the potential to become simpler than the old UEML ontology by exploiting more of OWL's native features. Firstly, it is prepared for using XML-namespaces where the old ontology used elaborate naming schemes. Secondly, where the old ontology introduced "association classes" to account for role names and cardinality constraints. UEMO uses OWL's built-in sub-role and number restrictions to the same effect. Thirdly, whereas the old ontology represented ontology concepts as OWL individuals, UEMO represents its concepts as OWL classes. One advantage is that they are thereby better supported by DL reasoning tools, which tend to solve decision problems on the concept (or class) level. Another is that the ontology is thus prepared for representing the semantics not only of modelling constructs, but also of model elements, which can be mapped either to OWL classes in UEMO (e.g., for a particular UML-Class) or to the OWL individuals that instantiate the classes (e.g., for a particular UML-Object).

Space prevents us from discussing several other important features of UEMO, such as the possibility of parametric definitions that use place holders (such as <Property> and <Value> below) to define powerful generic concepts like these:

Conclusion and Further Work

The paper has outlined the Unified Enterprise Modelling Ontology (UEMO), which supersedes the common ontology of the Unified Enterprise Modelling Language (UEML [START_REF] Anaya | The Unified Enterprise Modelling Language -Overview and Further Work[END_REF]). UEMO goes further than other ontology-based approaches to enterprise model interoperability (e.g., [START_REF] Kappel | Lifting metamodels to ontologies -a step to the semantic integration of modeling languages[END_REF][START_REF] Ziemann | Achieving Enterprise Model Interoperability Applying a Common Enterprise Metamodel[END_REF]) because it offers an extensive framework for systematically describing modelling constructs in fine detail and because it has been explicitly designed to evolve and grow over time without becoming overly complex (through the five taxonomies). It is an ontology in both the philosophical and computer-science senses, and the paper has emphasised the latter side. It has formulated UEMO in OWL2 DL with SHIN expressiveness, meaning that it so far remains also in "OWL1" DL form. The paper has also outlined potential uses of UEMO as a computer-science ontology and discussed its further development. The paper has thereby contributed both to making UEMO more precise and to supporting it with automatic reasoning tools. UEMO has already grown large, and a short paper like this can only present a selection of its concepts and features. Further work must present UEMO in fuller detail as an ontology both in the philosophical sense (e.g., grounding its concepts clearly in Bunge's ontology) and the computer-science sense (e.g., defining its concepts in description logic form and detail their use by automated reasoners and other relevant tools). Further work is also needed to extend the ontology with more precise concepts for states and transformations and to properly validate it. The present version of UEMO has already been extensively validated through iterative development, by using several automated reasoners and by cross-checking with earlier ontology versions. But additional validations are needed that use UEMO to describe and support interoperability between existing modelling languages.

Figure 2 .

 2 Figure 2. Top-level classes in UEMO.

  Association relates (non-coupled) AssociatedThings, whereas a Coupling relates CoupledThings. A SystemPartWholeRelation relates a CoupledThing to its System just like a Component is related to a Composite. A ValuedProperty has a specific value, whereas a ComplexProperty has one or more other properties as subproperties. A Behaviour is a Valued-and ComplexProperty that describes either a state (when it is a StateConstraint) or a transformation (when it is a Transformation-Function). A Behaviour that is naturally or socially enforced is a Law. Hence, StateLaws are enforced StateConstraints and TransformationLaws are enforced TransformationFunctions, defined along these lines:

Figure 3 .

 3 Figure 3. Top-level properties in UEMO.

  1. Instantiation level: A modelling construct may be used to represent either individual things (the instance level), classes of things (the type level) or both levels. 2. Modality: A modelling construct (or part thereof) may represent either a fact about or someone's belief about, knowledge of, obligation within, intention for a domain, and so on (in addition the model itself can have yet another modality, e.g., it may represent a possible or wanted future situation). 3. Classes of things: Regardless of instantiation level and modality, a modelling construct will represent one or more things (if it is instance level) or classes of things (if it is type level). 4. Properties of things: Most modelling constructs will also represent one or more

  state in UEMO is either mutable or immutable. A MutableState is defined in terms of at least one SomewhatMutableProperty, whereas an ImmutableState is defined only by CompletelyImmutableProperties. UEMO states are also either stable or unstable. A StableState is restrictedBy a StateLaw, whereas an UnstableState is restrictedBy a StateViolation property. Like StateLaw, StateViolation is a Behaviour (specifically, a StateConstraint). But, whereas a StateLaw is naturally or socially enforced, a StateViolation is only socially sanctioned. UnstableState refines MutableState, because the thing must eventually return to a stable state.

	MutableState ≡ AnyState ImmutableState ≡ AnyState ⊓ ∃ definedBy.SomewhatMutableProperty definedBy.CompletelyImmutableProperty ⊓ ∀
	StableState ≡ AnyState UnstableState ≡ MutableState ⊓ restrictedBy.StateViolation (=1 restrictedBy) restrictedBy.StateLaw (=1 restrictedBy) ⊓ ∀ ⊓ ∀ ⊓

Acknowledgements. The author is indebted to all the researchers, assistants and students who contributed to the Domain Enterprise Modelling in Interop-NoE, in particular Giuseppe Berio, Mounira Harzallah and Raimundas Matulevi ius. č


Stefan Huber
email: stefan.a.huber@siemens.com

Cyril Carrez
email: cyril.carrez@sintef.no

Hannes Suttner
email: hannes.suttner@siemens.com

Development of Innovative Services Enhancing Interoperability in Cross-organizational Business Processes

Keywords: Cross-organizational business processes, process interoperability, private-to-public transformation, interoperability gap detection, BPMN, SBVR

This paper presents the vision and ongoing results of the COIN (FP7-216256) European project for the development of collaborative and crossorganizational business process interoperability. Services for selectively publishing parts of private business processes are developed which enable the creation of a cross-organizational business process (CBP). Gap detection services provide analysis of the CBP with regards to interoperability gaps like potential deadlocks.

Introduction

COIN (FP7-216256) is an integrated project in the European Commission Seventh Framework Program. According the COIN vision [START_REF] Coin | COIN Home Page[END_REF] by 2020 enterprise collaboration and interoperability services will become an invisible, pervasive and self-adaptive knowledge and business utility at disposal of the European networked enterprises from any industrial sector and domain in order to rapidly set-up, efficiently manage and effectively operate different forms of business collaborations, from the most traditional supply chains to the most advanced and dynamic business ecosystems.

The mission of the Coin IP is to study, design, develop and prototype an open, selfadaptive, generic ICT integrated solution to support the above 2020 vision. COIN is starting from existing research results in the field of Enterprise Collaboration and Enterprise Interoperability.

In this paper we present the vision and ongoing results for the definition and prototypic development of cross-organizational business process interoperability (CBPip) services in the course of the COIN project. The main objective of these services is to ensure a successful business process collaboration of participating enterprises. We concentrate on two main streams: rule-based transformation of private business processes into public processes, and detection of business process interoperability problems at design-time level. The transformation helps an enterprise to extract from its private processes the parts that can be of interest when collaborating with a partner. The detection of interoperability problems helps the enterprises to design the crossorganizational business process and detect some problems at design time. Our previous work [START_REF] Carrez | Towards Cross-organisational Innovative Business Process Interoperability Services[END_REF] is extended by providing more flexible transformations using business rules, and by analyzing the CBP for interoperability gaps. This paper is structured as follows. The general approach of the CBPip services is depicted in section 2. The paper then presents the two services developed in this context: a service providing the private-to-public transformation of the involved business processes (section 3), and a verification service for finding gaps in the crossorganizational business process (section 4). Section 5 describes related work. Conclusions and future work are presented in section 6.

General Approach

In the scope of COIN it is important to distinguish "collaboration" from "interoperability".

According to COIN [START_REF] Coin | COIN Home Page[END_REF], Enterprise Collaboration comes from a business perspective and identifies the process of enterprises -mainly SMEs -to set-up and manage cross-enterprise win-win business relations in response to business opportunities. Enterprise Interoperability originates by the ICT world and identifies a capability of enterprise software and applications to exchange information and to mutually understand the information exchanged at the level of data, applications, processes and enterprise models involved. Enterprise Interoperability (EI) services provide functionality for applying IT solutions that overcome interoperability problems between two or more enterprises, and thus enabling them to set-up and run collaborations.

In this paper, we define business interoperability as the capability of two or more systems to cooperate using exchanged information, and an interoperability gap is a situation when interoperating business processes do not deliver the expected results while each of the business processes does. To be able to cooperate, a network of organizations needs to first define a Cross-Organizational Business Process and analyze it to find interoperability gaps.

Whereas other COIN services deal on collaboration issues, the services described in this paper are focused on interoperability issues only.

Creating a Cross Organizational Business Process (CBP)

Before showing how to create a CBP we first define some terms:

Process: A Process is any activity performed within a company or organization.

Cross-Organizational Business Process (CBP):

A CBP describes a process involving two or more organizations.

Private Process:

A Private Process is an internal process of a partner, and its functionality is invisible to any external entities. Making elements of a private process visible is the precondition of its "interoperability".

Public Process (View):

A Public Process is a published process. Figure 1 shows the workflow for creating the CBP. The starting point is the business process model of a specific company, e.g. "Private Process A" for company A. The company A has already defined a set of "Visibility Rules" which specify the visibility rights to different elements of Private Process A, applied to different kinds of partners. The rules are applied to Private Process A for the company B, hence generating the Public Process A that can be used to model the CBP with company B. Similary, the Public Process B is generated. Under these prerequisites, the CBP can be modelled by using elements of the public processes of the involved companies.

Analyzing a CBP

Once the CBP has been specified, it needs to be analyzed for interoperability gaps.

A Cross-Organizational Business Process Interoperability Gap (CBPip gap) is a condition when two or more collaborating public processes don't deliver the expected business results, although they may work faultlessly under other conditions. In other words, an existing CBPip gap is a condition through which the CBP workflow process execution leads to unsuccessful business collaboration. Gaps can be deadlocks (i.e. the CBPip process possibly will not terminate) or interface mismatch (i.e. the formats of a sent document does not match the format being expected by the receiving organization).

In this paper, we address the potential business process collaboration problems at a technical level, and recognize them as CBPip gaps. Once the CBP is modelled, the CBPip gap detection is invoked and parses the CBP model to detect the CBPip gap patterns. The gap patterns are conceptually defined in classes and types. On detection, the known reason or an assumption of the CBPip gap will be displayed.

The following sections describe the Private2Public transformation and CBPip gaps.

Private-to-Public Transformation

This section presents the transformation from Private Processes to Public Processes and how Visibility Rules are used in such a transformation. The aim of the Private2Public transformation is to produce a public process of a private process of a given company. This public process will hide all the private and critical data of the private process, resulting in a simplified process. Instead of annotating all activities and data with a public/private tag, we aim for the use of a business rule language in order to describe the visibility of different process elements of a private process. We chose SBVR (Semantics of Business Vocabulary and Business Rules [ 5]) for describing visibility rules. As a standard, SBVR offers a strong basis; it also allows a representation of rules in Structured English, and hence is more readable and usable for Business Analysts who will produce Visibility Rules. The main drawback of SBVR is the complexity of its meta-model and the production of a suitable vocabulary; however those drawbacks are taken care of by the technology experts who will develop tools to handle the complexity of the meta-model (end-users will see only the SBVR rules in Structured English) and who will create the vocabulary with the help of business experts.

Principles of the Private to Public Transformation

The SBVR for CBP allows describing how a public process should be produced from a private process, by way of business rules. This is achieved through three principles (Figure 2):

• The SBVR rules are linked to specific elements of Processes, so the transformation service knows which elements are described in the rules. This is done by two ways: First, the elements in a Process (Activities, Data, …) can be annotated with an SBVR vocabulary which describes the purpose of those elements. However, as this may clutter the diagrams, a second possibility is to use the names of the elements in a Process (e.g.: an activity involving some Invoice contains the string "invoice" in its name). • A Vocabulary (in SBVR) which describes the semantic of Process elements, as well as the roles of partners in a CBP. The vocabulary defines noun-concepts related to the modelling of Process elements (Activity, Data) or to their semantics (Sales Department, Customer, etc.), as well as verbconcepts to specify associations ("an activity manipulates some invoice" ). Notably a verb-concept "is visible to" associates elements in Processes with partners in the CBP. 6]). The business rules are based on the verb-concept "is visible to", and tell which element in the process should be visible to which kind of partner. For instance, "An activity that is about management is visible to some strategy department".

Fig. 2. Principles of visibility rules.

Those principles are illustrated in Figure 2. The private process applies pricing policies in order to create and then send an invoice. The last two activities handle some data which is annotated with the SBVR expression "is about Invoice". A Visibility Rule can then use this information and specify: "An activity that manipulates an Invoice is visible to a Customer", which means that the activities "Create Invoice" and "Send Invoice", which send and receive some data that is about Invoice, are concerned by this rule and will be made visible to a Customer. The other activity "Apply Policies" and the critical data "Policy Prices" will be removed in the public view.

SBVR Vocabulary and rules

In order to build the SBVR Vocabulary, we studied the COIN use case scenarios of healthcare and aeronautics clusters, and business examples which came along with the Enhydra Shark process execution environment 2 Figure 3 . This resulted in a vocabulary summarized in . Facts and concepts related to process models identify abstract concepts that represent elements in BPMN, as well as the most important fact-types for visibility rules, "is visible to". Those terms are specialized with concepts related to roles, activities, control flow and data.

Visibility rules

Visibility Rules specify which elements in the model of the process are to be shown in the public view. They are specified as Advices of Possibilty in SBVR3

Here are some examples of Visibility Rules:

, and are based on the fact type "is visible to", which relates a Process Element with some Role. Visibility rules have two parts: the first one introduces the Process Element (Activity, Data, ControlFlow) in the private process; this Process Element is further characterized ("Activity is about management") in order to address a specific element in the private process. The second part of the rule specifies who is able to see the Process Element at stake ("is visible to some Customer").

It is possible that an activity that is about validation is visible to some strategy department.

It is possible that an activity that manipulates some feedback is visible to some customer. It is possible that a data that is about some reclamation is visible to some sales department.

It is possible that a sequence flow that follows a public activity is visible to some role.

Principles of the Transformation

The principle of the transformation is shown in Figure 4: each public activity will be put in its own workflow, to allow an easy composition of the public views in the CBP. This is illustrated in the top part of the figure, where the activities "Request Invoice" and "Send Invoice" are public 4 , and the private process is transformed into two Workflows, one for each activity. The lower part of the figure presents a special case in the transformation. In case the private process presents a sequence of public activities, then those activities are put in the same workflow. The sequence must be linear, meaning that no gateways (fork / join) between the activities are permitted, and only one transition is allowed between the activities. For instance, if "Order" and "Request Invoice" are public activities, they will be put in a single workflow, as shown in the figure.

Interoperability Gap Detection

Once the CBP has been created by using elements of the Public Processes of the involved organizations, the CBP can be analyzed for interoperability gaps.

Business process collaboration is seen as given, i.e. already agreed business collaboration between the partners of a specific CBP is a pre-condition for the CBPip. Although gaps on business collaboration level are not explicit subject of our consid- 4 For the sake of clarity we removed the Visibility Rules and colored the activities instead (red/dark grey=private, green/light grey=public). Note that design-time is a phase where the process will be considered during its specification, e.g. during modelling in a business process modelling tool. Contrarily, run-time is a phase where a process or the automated parts of a process will be considered during its execution on a process execution engine. We first give a short example of a CBPip Gap before describing the classification of those gaps. The detection service is presented in the end.

Description of an Exemplary CBPip Gap

As an introductory example a company A models a private business process BP Travel reporting . Company A publishes activity "Create expense report" as a public process VP Report Creation (see upper left part of Figure 5). Company B does very much the like and publishes VP Report Confirmation (see upper right part of Figure 5). Both public processes are then used as parts of a Cross-organizational Business Process CBP Travelman- agement (grey activities in the bottom part of Figure 5).

Each company uses its own set of rules to transform (parts of) the private business process into public processes. In the example above, the transformation of activity "Create expense report" to VP Report creation works correctly. At company B the used rule-set implies that condition 2, which is attached to the activity "Confirm expenses", will not be published (take notice of the yellow note and the red highlighted arrow in Figure 5).

This transformation is also valid, but in the composed CBP Travelmanagement the missing condition might lead to a multiple source deadlock: when the upper part of the CBP Travelmanagement starts and follows the activity workflow, it might happen that this stream finishes before a "Send Report" message (from the activity VP Report creation in the lower part of the CBP Travelmanagement ) arrives at activity VP Report confirmation . As a consequence this results in the following deadlock situation: when the lower part of the CBP Travelmanagement starts and reaches the activity VP Report creation the process will -due to the condition 1 "Do not continue before expenses are confirmed" -hold and wait until a "Confirm Report" message arrives. Because of the fact that the upper part of the CBP Travelmanagement has already finished, this waiting position will never be left and the final result is a multiple source deadlock, i.e. parts of the CBP Travelmanagement will never be executed (dashed activity in the CBP Travelmanagement ), and the process itself will starve and never finish. The example above illustrates that although the transformation of each private process works correctly, interoperability gaps in a resulting CBP might occur. The challenge of scenarios as such lies in detecting interoperability gaps between partners and improving the support to bridge the gaps.

Classification of CBPip Gaps

The gap classes that have been identified so far on Business Level are:

-Deadlocks -Interface Mismatches Although this list is far from being exhaustive, the classification of CBPip-Gaps on Business Level, as well as the first set of identified CBPip Gap class types is depicted in Figure 6. Each class is further detailed hereafter.

Deadlocks

As stated in [START_REF] Awad | Structural Detection of Deadlocks in Business Process Models[END_REF]: A deadlock in a process model is given if a certain instance of the model (but not necessarily all) cannot continue working, while it has not yet reached its end. The research by [START_REF] Rospocher | Collaborative Specification of Semantically Annotated Business Processes[END_REF] also points out that CBPip deadlocks can be clustered in structural types such as:

-Loop Deadlock -Multiple Source Deadlock and -Improper Structuring Deadlock A Loop Deadlock occurs when there is an execution path from the output of an AND join back to a subset of its input points. If this path contains an XOR-split, deadlock occurs only when the branch leading to the loop is chosen. In case there is a path that does not contain XOR-splits deadlock occurrence is certain. See Figure 8 for an example.

A Multiple Source Deadlock occurs when an AND-join has input points which are at some point in the process up-stream originate from two different sources. Assuming that none of the source nodes is the AND-Join itself, we can see that the multiple-source pattern can occur (distinctly from other pattern) only when the process structure is one of the following:

-One of the two sources is an XOR-split.

-The process has multiple start points that are later on synchronized. In case of models specified in BPMN, multiple starts are permissible. Actually, multiple start points resemble an AND-split between the start events, hence we can deduce that there is reachability between two or more sources (start events) to the AND-join node. See Figure 8 for an example. An Improper Structuring Deadlock occurs, when an AND-join receives input that early started from an XOR-split. See Figure 7 for an example. Detection of deadlocks is done via path analysis considering flows and gateways in the BPMN model. [START_REF] Awad | Structural Detection of Deadlocks in Business Process Models[END_REF] proposes queries to detect such deadlocks. Because of the prototypic nature of the gap detection service a straightforward approach based on those queries was chosen.

Interface Mismatches

An interface mismatch in a CBP model is a serious impediment that prevents two separately-modelled business processes of successful interoperation due to different design assumptions.

A main difficulty of interoperable CBPs interacting with one another in ways not necessarily foreseen is to have interfaces that are generic enough so that they ensure easy and dynamic CBP interface adaption. It addresses a sub-problem of CBP mediation that arises when the interface that a CBP provides does not match the interface that it is expected to provide in a given interaction.

CBPip interface mismatches can be clustered in structural types such as:

-

Number of Messages Interface Mismatch and -

Message Types Interface Mismatch

A Number of Messages Mismatch occurs when the number of messages provided differs from the number of messages expected. This gap applies to both directions:

-The business process provider provides a number of messages -the business process consumer expects a different amount of messages.

-The business process consumer provides a number of messages -the business process provider expects a different amount of messages. A Message Types Mismatch occurs when the message format provided differs from the message format expected (e.g. the business process provider provides an email -the business process consumer expects an SMS). This gap again applies to the consumption as well as to the provision scenario, like in the prior gap.

A Format Mismatch occurs when a message flow involves exchange of data or documents across organizations and the sending organization uses a different format than the receiving organization expects for this message flow.

CBPip Gap Detection Service

In general the process in providing innovative services that allow to bridge interoperability gaps falls into two steps: The first is to detect the CBPip Gaps, while the second is to eliminate CBPip Gaps -or at least to propose primitive courses of action to surmount the CBPip Gaps. Since each gap class has its own characteristics it was decided to follow a step by step strategy and start with the investigation on the basis of CBPip Gaps of type Deadlock.

The principal idea to detect deadlocks is to analyze the xPDL representation of a CBP model and to try to detect the deadlocks within the model. The approach described in [START_REF] Rospocher | Collaborative Specification of Semantically Annotated Business Processes[END_REF] is adapted by COIN providing a web service relying on a set of so called deadlock patterns whose occurrence in process models usually leads to deadlocks. The WebService takes as request parameters the xPDL representation of a CBP model, and the name of the workflow to be verified. It delivers the number of detected deadlocks in the workflow with a short description for each deadlock as well as a suggestion for the deadlock elimination. The suggestion represents a primitive solution to bridge each interoperability gap.

Related Work

As a predecessor of COIN, the ATHENA IP Project [START_REF]Specification of a Cross-Organisational Business Process Model[END_REF] proposed a CBP framework, with three levels of modelling: private, public ("view") and abstract process modelling. Public and private processes are linked together at companies' sites, and are executable in a BPEL engine, in order to achieve collaborative processes between enterprises. Finally, the abstract process is an abstract view of the public process with only input/output operations. Abstract processes are not executable (or not meant to be), and are composed in the CBP. The CBP is also not executable, but can be used to monitor the choreography of public processes.

The business rule based private-to-public transformation is a very significant improvement against the private-to-public transformation concept as described in ATHENA. We are using SBVR (Semantic Business Vocabulary Rules) [ 5] to define business collaboration rules. Note also that we can produce several public views from the private process, by changing only the Visibility Rules, as they specify what process elements are visible to which partner. Visibility Rules are specified in a separate file, and can apply to any number of private processes. The idea of annotating business process element to provide semantics has also been used by Rospocher et al. [START_REF] Rospocher | Collaborative Specification of Semantically Annotated Business Processes[END_REF]: the authors provide mechanisms for semantically annotate business processes, using text-annotations (like we do) and ontologies.

Concerning deadlock detection in SOA protocols, several approaches exist. Seguel et al. [START_REF] Seguel | An Overview on Protocol Adaptors for Service Component Integration[END_REF] for instance describe approaches for creating protocol adaptors for service component integration. This work also covers some deadlock situations, but is merely based on SOA protocol and not at BPMN cross-organizational business process aspects. Other work relating to gap detection exists based on Petri Nets. Dijkman et al. [START_REF] Remco | Formal Semantics and Analysis of BPMN Process Models using Petri Nets[END_REF] try to map BPMN on Petri Nets (by the way finding some deficiencies in the BPMN definition) and then perform static checks on the resulting Petri Net like finding dead tasks or deadlocks. Anyway, this work does not put a focus on issues concerning mismatches occurring in cross-organizational business processes. Bonet et al. [START_REF] Bonet | Ramon Puigjaner: PIPE v2.5: a Petri Net Tool for Performance Modeling[END_REF] do not consider BPMN directly, but provide some interesting static analysis approaches on Petri Nets. In this work focus is more on performance issues, additionally covering some deadlock situations.

Fig. 3 .

 3 Fig. 3. Fact types and main concepts in the CBP Vocabulary.

  process element role processElement is visible to role department, supplier, customer General Concept: role sales department, strategy department, … General Concept: department data is about datakind product, shipment, critical data, exchanged document, … General Concept: data kind expense report, invoice , … General Concept: exchanged document activity behaviour validation, management General Concept: activity behaviour datakind activity is about activityBehaviour activity creates datakind activity checks dataKind activity manipulates datakindFact and concepts related to the process models Fact and concepts related to the activity & its behaviour Fact and concepts related to the roles (will view the public process) public activity General Concept: activity control flow follows public activity control flow leads to public activity Fact and concepts related to the control flow Fact and concepts related to the data travel expenses General Concept: expense report

Fig. 4 .

 4 Fig. 4. Results of the transformation.

Fig. 5 .

 5 Fig. 5. Example: Erroneous Transformation leading to an Interoperability Gap (Multiple Source Deadlock).

Fig. 6 .

 6 Fig. 6. Classification of CBPip Gaps.

Fig. 7 .

 7 Fig. 7. Exemplary Improper Structure Deadlock at cross-organizational business process CBPc integrating public processes BP1 and BP2.

Fig. 8 .

 8 Fig. 8. Exemplary Multiple Source Deadlock and Loop Deadlock.

Company A Company B CBP Designer Define / retrieve private business process Apply P2P transformation Public Process A Define / retrieve private business process Apply P2P transformation Public Process B Create CBP Analyze interoperability gaps Adjust CBP Private Process A Private Process B CBP Visibility Rules Visibility Rules

	It is a specific view on a Private
	Process of a partner. Via the Public Process, the collaborating partners may
	invoke specific functionality of the corresponding internal process.
	Private2Public transformation
	A Private2Public transformation is a model-to-model transformation, which
	generates public views for specific partners. It is based on Visibility Rules.
	Visibility Rules:
	Visibility rules are business rules that define which process elements are
	shown to which partner. They are defined in SBVR (Semantics of Business
	Vocabulary and Business Rules [ 5]).
	Fig. 1. Creating and Analyzing the Cross-Organizational Business Process (CBP).

  1

In this paper we show the Visibility Rules in Structured English, with four font styles for term, Name, verb and keyword, as documented in the SBVR specification [ 5, pp237-238].

SBVR specifies Rules, which remove some freedom, and Advices which add some freedom. The transformation is such that everything is private (removes all freedom), and the Visibility Rule tells what should be shown (add some freedom), the choice of Advice was preferred.

Conclusions and Future Work

We described a way of creating and analyzing a cross-organizational business process consisting of a model transformation of private to public business processes, creating a cross-organizational business process (CBP) by using the elements of the published process elements and analyzing the resulting CBP for interoperability gaps.

An eclectic diversification of interoperability gaps is currently not available in standard literature. Interoperability problems have been marginally addressed e.g. in the ATHENA project [ 2] or by Awad and Puhlmann [ 7]. But neither business process interoperability gaps within the enterprise, nor gaps of cross-organizational business processes have been the subject of a thorough analysis.

As the automated gap detection is based on the information being captured in BPMN and xPDL models, the degree automated gap detection is limited to information being captured in those models. Other gaps, like gaps in the quality of service required/offered in interactions between organizations cannot be detected in such models.

Future work will focus on extending the CBPip gap categorization and classification and improving the implementation of the business interoperability services. The number of identified CBPip Gap classes is far from being exhaustive. There is still room left to proceed with the initiated research to detect more gap problems, classify the gaps and describe them in more detail. Whereas currently all gaps are considered of same priority, defining different priorities for different gap kinds can also be part of future work.

Aiming at (semi-)automated resolution of CBP interoperability gaps is also a topic for further research, especially of the gap classes "interface mismatch" where a combination of other COIN services concerning ontology reconciliation can be leveraged.

The vocabulary for visibility rules we presented in this article is only a first version. We are currently working on an extension for health-care. The visibility rules we have presented should also not be overlapping, which is a shortcoming of the current implementation. We are planning to enhance the visibility rules with priorities (e.g. in case of conflicts, some rules will have precedence). Finally, as SBVR and ontologies are based on the Common Logic [ 12], it would be interesting to look for possible synergies with similar approaches for semantically annotating business processes using ontologies, like the shared workspace presented in [ 8].


Cuiling Liu

Chengwei Yang
email: yangchengwei2006@163.comlsj

Shijun Liu

Lei Wu

Xiangxu Meng

A Process Interoperability Method for SMEs

Keywords: Enterprise interoperability, SMEs, process interoperability

This paper starting with the present status of enterprise interoperability, focuses on enterprise interoperability of SMEs (Small and Medium-sized Enterprises), and based on a SMEs oriented framework of enterprise interoperability proposes an approach of process level interoperability. The approach appropriate for SMEs mainly solves two types of interoperability involving processes' interior in the process level. Life cycle of process level interoperability is redesigned and reorganized. In each phase of the life cycle a comprehensive solution is given. In final, this paper gives a case study to describe and enhance the approach.

Introduction

In modern enterprise computing environments, interoperability is a common issue caused by many factors such as heterogeneous systems, different organizational forms and diverse business processes. To gain more benefits and reach a common enterprise goal, enterprise interoperability has become a significant strategy for enterprises. In this context, many investigations concerning enterprise interoperability are done. The LISI (levels of information systems interoperability) approach with the goal of providing a maturity model and a process for detecting joint interoperability needs, evaluating the capability of the systems to meet those needs, and selecting pragmatic solutions and a transition path for achieving higher states of capability and interoperability for the US Department of Defense (DoD), was developed by C4ISR Architecture Working Group (AWG) during 1997 [START_REF]The C4ISR Architecture Working Group (AWG) (CAWG): Levels of Information Systems Interoperability (LISI)[END_REF]. Other frameworks such as the IDEAS interoperability framework [START_REF]IDEAS: Interoperability Development for Enterprise Application and Software-Roadmaps[END_REF], the European Interoperability Framework (EIF) [START_REF]EIF: European Interoperability Framework[END_REF] and the ATHENA interoperability framework (AIF) [START_REF] Guglielmina | ATHENA[END_REF] also have deep influence. But, a maturity framework particularly focusing on SMEs is still needed. All over the world, the proportion of SMEs in the whole enterprises is quite large. In this complex context, this paper reviews a SMEs oriented framework of enterprise interoperability. Based on the SMEs oriented framework, the main work of process level interoperability is elaborated, and an application about the traditional textile industry in China is given in this level as a case study.

The rest paper is organized as follows. Section 2 explains several related definitions and works about the thesis in this paper. Section 3 reviews the idea of a SMEs oriented framework of enterprise interoperability. According to the framework and relationships between levels, an approach of SMEs oriented process level interoperability is proposed in section 4. Then, the process level interoperability is designed at the background of the SMEs cluster as a case study in section 5. Finally, section 6 concludes the whole paper and looks forward to the future work.

Related Works

Before entering the main topic, we have the need of interpreting some concepts and definitions about interoperability and process interoperability. Generally speaking, according to [START_REF] Konstantas | Object oriented interoperability[END_REF][START_REF] Chen | Enterprise interoperability: a standardization view[END_REF], the ability of multiple system entities to understand each other and to use functionalities of each other by properly communicating and exchanging information is seen as interoperability. In the procedure of interoperability, the incompatible and heterogeneous features of multiple entities are covered, which becomes the goal of interoperability research. When interoperability is proposed in the enterprise computing environments, with the background of enterprise, it evolves enterprise interoperability.

Interoperability or the capability to interact and collaborate can be identified into three forms from [START_REF]ISO: ISO 14258 -Concepts and rules for enterprise models[END_REF][START_REF] Chen | Francois Vernadat: Architectures for enterprise integration and interoperability: past, present and future[END_REF]. The three forms are respectively named as integrated, unified and federated interoperability, which depends on the location of the information used for reaching interoperability. In the integrated form, interoperability methods concern the internal implementation of software components. For the unified form of interoperability, a common meta-information entity is shared by each participant of interoperability. One kind of meta-information entity called standards has applied in the traditional industry for interoperability. However, the ambiguity and slow development of standardization make it unsuccessful in modern software engineering. The other kind of meta-information entity is explicitly shared meta-information which uses a specific modeling language to be defined and uses computing platform independent notations to illustrate components' features and interrelations. Compared with the previous two interoperability forms, federated interoperability form makes use of negotiation mechanisms, model verification and monitoring of service behavior referring on interoperability contract to work. The property of no common metainformation entity decides the necessity of a shared meta-model and meta-information management.

A process describes the collaboration of mutual or automated activities which have a common blueprint [START_REF] Conradi | Towards a Reference Framework for Process Concepts[END_REF]. A process uses a meta-model to define the concepts and notations about process description and activities expression. Besides, a process model limits detailed process steps which a process instance relies on in execution. Process interoperability should contain control and synchronization to make sure that processes can interwork with other ones.

Considering process level interoperability for SMEs, an approach using E-mails communication to realize process interoperability is given in [START_REF] Burkhart | Realizing process interoperability using E-Mail communication[END_REF][START_REF] Burkhart | Process interoperability through proactive e-mail annotations[END_REF]. In this approach, process interoperability is subdivided into one Build-Time component and four Run-Time components. The Build-Time component is a process of configuration, which requires that each SME must initialize its own processes based on the Reference Model Directory and store the processes in the Enterprise Process Repository. The four Run-Time components include detecting, tracking, assisting and advising. But, the approach uses a same process meta-model to define all the process models in SMEs and takes more attention to the composite application of processes. The authors in [START_REF] Estublier | Interoperability and distribution of process-sensitive systems[END_REF] propose a solution in interoperability of Process-Sensitive Systems (PSSs). The main idea of the solution is a virtual PSS independent of PSSs used to guarantee interoperability. The solution is efficient but costs much. In this paper, the sufficient use of existing resources and low cost are taken into consideration. Based on an integral SMEs oriented interoperability framework, a method of the process level taking more attention to interoperation involving processes' interior is proposed. As shown in Fig. 1, a five levels' framework of enterprise interoperability is proposed for SMEs. It contains data level, service level, process level, business level and presentation level. Based on the former fundamental interoperability forms, interoperability of each aspect in each level resorts to appropriate fundamental interoperability form, which we name as a mixed interoperability method used in the framework.

SMEs Oriented Interoperability Framework

In the data level, interoperability commits to solving the incompatibility of different data models and query languages. Data from various heterogeneous data sources which may be established on different DBMS even OS will be used to exchange by the guarantee of data interoperability. Participants of interoperability can remain the differences, but a shared meta-model is needed. Service Data Objects (SDO) [START_REF]Service Data Objects Specifications[END_REF][START_REF]SDO Resources[END_REF] is a specification for a programming model that unifies data programming across data source types, provides robust support for common application patterns, and enables applications, tools, and frameworks to more easily query, view, bind, update, and introspect data. In the procedure of implementing data interoperability, combination with SDO is a good selection in technology. Data interoperability is established with a mechanism supporting data transformation between senders and receivers, which provides convenience for other levels efficiently.

Service level interoperability refers to discover, composite different kinds of application functions or services for well collaborative work. SCA (Service Component Architecture) provides model for both service composition and service encapsulation, including reuse of existent function in SCA composite component [15,[START_REF]SCA Resources[END_REF]. So, SCA can be selected as the service level interoperability technology.

The goal of interoperability in the process level is to make various processes work together. Interoperability of the process level is classified into two types in accordance with the interoperability scope. One is interoperability between processes independent of each other, which can be considered as interoperability between activity nodes not belonging to a common process. The other is interoperability between processes and their sub processes, and the interoperation points locate processes' abstract activity nodes which are related to the start and end activity nodes of sub processes. The details of process interoperability will be discussed in section 4.

Interoperability for the business level is on the standpoint of organization and company, and it deals with the interoperation barriers causing by diverse business rules, policies, strategies, legislation and culture. Business level interoperability is established by negotiation mechanism and monitoring facilities, which makes use of a federated analogous interoperability form. Considering interoperability of the business level, the circumstance of virtual enterprise and dynamic alliance can be considered. Due to the framework based on SMEs cluster, a domain ontology can be modeled by UML according to [START_REF] Che | A Method for Inter-organizational Business Process Management[END_REF].

In interoperability, it needs flexibility, adaptability and agility in the presentation aspect to own well designed and harmonious presentation. In the light of the significance of presentation, interoperability of presentation is listed independently as the top level. Interoperability in this level emphasizes on integration more, especially a type of loosely coupled integration. Referring to [START_REF] Ma | Change propagation algorithm in a unified feature modeling scheme[END_REF], Widget Model can be used as a reference solution in technology. But Widget can't invoke remote resource. A modified Widget uses both local resource and remote resource in the process of across enterprise interoperability.

The process level's relationships with other levels will be explained explicitly. Firstly, the data level provides a comprehensive support for all the interoperation in the process level. Exchanging message meaningfully of processes is contributed to the incompatible data processing in the data level. Secondly, a process can be seen as a sequence of services. So processes have the ability of controlling multiple services work together for one common aim, and services are instantiation of process activities. In final, relationship with business level is discussed. Frankly speaking, the relationship is obvious. Business can directly impose constraints on process modeling. In this way, process models perform as business's formalization. Something still needing to be elaborated is that generally interoperability in any level or between any levels can't lack the support of the data level. So the data level can be seen as a basic level. However, the presentation level plays a role of showing all the understood information and can be considered as an encapsulation of other levels.

SMEs Oriented Process Interoperability

In this paper, we divide activity nodes of a process model into two types: abstract activity nodes and detailed activity nodes. Abstract activity nodes mean that they do not directly control activity services and they must be instantiated by other processes. In contrary to abstract activity nodes, detailed activity nodes must straightly invoke and control activity services.

To implement interoperability of the process level, a SMEs oriented process interoperability tool across enterprises is needed. It should contain process metamodel ontology, process activity analysis, interoperability point testing/sub process detecting and interoperability connection control. Here, the definition of interoperability point is limited to process activity nodes. Life cycle of SMEs oriented process interoperability includes two phases: Built-Time and Run-Time. In the Built-Time phase, the main task is finding interoperability points. Compared with the Built-Time phase, the Run-Time one mainly deals with establishing interoperation connection, interoperation and releasing interoperation. The following subsections will give a detailed description of the two phases.

Built-Time

Process meta-model ontology, process activity analysis and interoperability point testing/sub process detecting will perform in the phase. The information used in the whole process level generally can be divided into two types: requested information and responded information. Process activity analysis is used to identify requested and responded information for all the activity nodes including start and end of process models. For two activity nodes, if one's requested information is corresponding to the other's responded information partly or completely, interoperability point testing can decide that interoperability exists between them. Sub process detecting also makes use of relation about requested and responded information. If one abstract activity node's requested and responded information of a process are consistent with start node's requested information and end node' responded information of a common process, the latter process can be use as a sub process to instantiate the abstract activity node of the former process. Besides, decisions of information consistency need the semantic support of the data level. Process meta-model ontology is used in the mapping of process meta-models in diverse process definition languages and engines. With the help of process meta-model ontology, the quantity of nodes in interoperability points testing reduces largely, and the efficiency of interoperability points testing improves.

In interoperability between processes independent of each other, essentially finding interoperability point is a procedure of process activity analysis and interoperability point testing. Considering process interoperability with sub process, an abstract activity node using a sub process should detect, activate and monitor an appropriate sub process. When the selected sub process could not execute activities for the abstract activity node, the abstract activity node has the capability of finding a substitute solution. Sub process detecting is used in this kind of interoperability with respect to process activity analysis.

4.2

Run-Time Fig. 2. Process Level Interoperability.

Interoperability connection control is used in the Run-Time phase for establishing interoperation connection, interoperation and releasing interoperation connection. In interoperability between processes independent of each other, two partners wanting to establish business relation respectively submit own process model to the process interoperability tool for interoperability point testing. After obtaining results, the two partners confirm the interoperability to establish a special interoperability connection. The meaning of the connection is to open process engine's certain function to each other for certain process instances in certain activity nodes. For example, in certain process instances A' (relying on process A) and B' (relying on process B) which belong to two different enterprises, activity A'.a of A' can use remote process engine function to signal an activity B'.b of B' in a special situation. Process instances end and the corresponding interoperability connection is released. Process interoperability with sub process is similar to the former one. Nevertheless, the abstract activity starts a certain instance of the selected sub process, and the instance's ending of the selected sub process signals the abstract activity. The method of process interoperability for SMEs is illustrated by the Fig. 2. In Fig. 2, process A and process B in the top level denote the interoperability between processes independent of each other, and process A and process C in two diverse levels denote the interoperability between processes and sub processes. Finally, in order to improve efficiency, process activity analysis is done only one time before a new process model executing in process engine and the analysis results are saved for all the use.

Case Study and Analysis

Nowadays, there are many small and medium enterprises in the textile industry of China. These enterprises limited by scale and funds are still in the primary stage of information, which makes them at the disadvantage in the competition. The original purpose of this research is to help these enterprises in the textile industry of China improve efficiency in enterprise management and collaboration.

Fig. 3. Process Model of Enterprise A.

A business scene is described as follows. When a textile enterprise A receives a new order, it firstly does a checkup for the new order. If the new order does not pass the checkup, the enterprise will send a refusal to the source of the order and the process is ended. Otherwise, the enterprise will send an acceptable reply to the order source and then contract with it. After the contract becomes effective, enterprise A begins to produce. Before producing products, the number of cloth in storage is checked. If cloth used in this order is enough, the cloth can be removed from the storage and be made into products. When the products are finished, they will be stored into the storage and then be sent. Later, enterprise A receives a goods arrival reply and goes into the phase of financial settlement. After financial settlement, the whole process comes to a finished end. There is also another situation that the cloth is not enough for the order. In this situation, enterprise A will decide to whether the cloth is produced by itself according to its own production capability and assignment quantity. If it can finish the cloth producing by itself, materials out of storage will be weaved into cloth. Then the cloth is stored in the storage for the use of producing products. If enterprise A can't finish the preparation of the cloth, it will send a cloth order to an enterprise B which is eager to producing cloth for A. After receiving an acceptable reply, enterprise A reaches a cloth agreement with enterprise B. When the cloth produced by enterprise B arrives, the production will be continued. Besides, the procedure of producing products in enterprise A includes five phases: cutting, sewing, testing, packaging and boxing. Compared to enterprise A, enterprise B has a simple way of business. After contracts become effective, enterprise B will directly begin to produce and then send goods. Finally, enterprise B does financial settlements. Based on the illustration of business scene, the global business of enterprise A can be modeled as a process model A shown in Fig. 3. In the same way, the business of producing product for enterprise A can be modeled as a sub process model A.1 shown in Fig. 4 (left), and the business of enterprise B can be modeled as a process model B shown in Fig. 4 (right). From the perspective of the process level, interoperability between process A' (relying on process model A) and process B' (relying on process model B) is interoperability between processes independent of each other; interoperability between process A' and sub process A.1' (relying on process model A.1) belongs to process interoperability with sub process used. The application implementation is based on a modified JBPM engine. Though a common process engine is used, process A', sub process A.1' and process B' use different versions to be modeled. After making process model A and B as input of process interoperability tool for interoperability point testing, confirm interoperability in certain instance A'-1 and B'-1. Then interoperability configuration in A' and B' can be showed like below.

Conclusion

In this paper, we have reviewed a five levels SMEs oriented framework of enterprise interoperability. Interoperability of data level, service level, business level and presentation level is described in summary. Based on the whole framework, a process interoperability method for SMEs is proposed, and it focuses on two types of process interoperability. One is interoperability between processes independent of each other. The other is interoperability between processes and their sub processes. To cover the two type process interoperability, a SMEs oriented process interoperability tool across enterprises is designed and partly implemented. Moreover, an application of the textile industry in China is supported by the tool. However, both the approach and the application decrease the processing of semantic interoperability. So, in the future, we want to do some work about semantic interoperability for supporting SMEs oriented process level interoperability. Besides, the SMEs oriented process interoperability tool still have many disadvantages in design and implementation, which needs a long term hard work.

Fig. 1 .

 1 Fig. 1. Five Levels' SMEs Oriented Interoperability Framework.

Fig. 4 .

 4 Fig. 4. Sub Process Model of Enterprise A (left) and Process Model of Enterprise B (right).

Acknowledgments

. The authors would like to acknowledge the support provided for the project by the National Natural Science Foundation of China (60703027), the National High Technology Research and Development Program of China (2009AA043506), the China Postdoctoral Science Foundation (20090451313) and the Natural Science Foundation of Shandong Province (ZR2009GM028).