Ontology-driven approach towards domain-specific system design … · Ontology-driven approach...

Int. J. Metadata, Semantics and Ontologies, Vol. 11, No. 1, 2016 39

Copyright © 2016 Inderscience Enterprises Ltd.

Ontology-driven approach towards domain-specific system design

Shreya Banerjee* and Anirban Sarkar Department of Computer Applications, National Institute of Technology, Durgapur Durgapur, India Email: [email protected] Email: [email protected] *Corresponding author

Abstract: In practice, domain-specific modelling is intended for improved conceptualisation of a specific domain. Further, distinct parts of a large software system are modelled by different domain-specific modelling languages. This approach sometimes leads to the problem of poor semantics, interoperability and reusability of domain model concepts. However, ontology aids in common understanding of domain conceptualisation by providing enriched semantics. To address these issues, this paper proposes an upper level ontology called Generalised Ontology Modelling (GOM) which aims to facilitate formal realisation of crucial software design aspects such as structural, functional, behavioural and also evolving domain knowledge. In addition, to show the expressiveness of the proposed ontology, a domain-specific ontology for Reference Information Model (RIM) of Health Level 7 (HL7) standard is derived from GOM. Besides, the paper includes verification of several useful properties of the proposed GOM. Moreover, a detailed comparative analysis has been provided towards evaluation of the proposed GOM.

Keywords: domain-specific ontology; upper level ontology; domain independent ontology; domain-specific modelling; meta-meta modelling; functional design semantics; behavioural design semantics; structural design semantics.

Reference to this paper should be made as follows: Banerjee, S. and Sarkar, A. (2016) ‘Ontology-driven approach towards domain-specific system design’, Int. J. Metadata, Semantics and Ontologies, Vol. 11, No. 1, pp.39–60.

Biographical notes: Shreya Banerjee is presently a research fellow in National Institute of Technology, Durgapur, India, since February, 2014. She received her MTech in Software Engineering from same institute in 2013, and BTech in Computer Science and Engineering from West Bengal University of Technology, Kolkata, India in 2008. She is pursuing PhD in the field of Software Engineering. Her main areas of research interests include ontology, mathematical logic, conceptual modelling and requirement engineering.

Anirban Sarkar is presently a faculty member in the Department of Computer Applications, National Institute of Technology, Durgapur, India. He received his PhD degree from National Institute of Technology, Durgapur, India in 2010. Broad areas of his research interests are software engineering, database management system and cloud computing. He is an author or co-author of over 70 publications in numerous refereed journals and conference proceedings.

1 Introduction

Effective design of a domain-specific system depends on corresponding domain analysis. The purpose of domain analysis is to define the domain of focus, collect relevant domain knowledge and integrate it into a coherent domain model (Walter et al., 2014). In general, domain-specific modelling helps designers to accomplish domain analysis and synthesise domain models in terms of distinct concepts, relationships and constraints of domain. It also aids in understanding and analysis of domain-specific systems from different design aspects such as structural (relates with the structural components modelling), functional (concerns with the flow of process control) and behavioural (deals with the way of interaction

between domain and the outside environment through events) (Borgo et al., 2009). Besides, it also assists in modelling inter dependency between different design concerns since sometimes concepts of one design aspect depend on concepts of other design aspects (France and Rumpe, 2007). In addition, domain-specific modelling also facilitates representation of evolving knowledge of domain. Evolving knowledge representation deals with defining in advance the knowledge type which one yet does not know (Krima et al., 2012), such as those produced in the domain either dynamically or when objectives of end users are changed (Happel and Seedorf, 2006).

Different approaches related with domain-specific modelling first create conceptual models and then are systematically transformed towards concrete implementations (France and

40 S. Banerjee and A. Sarkar

Rumpe, 2007). Usually, conceptual models raise levels of abstractions of themselves from models to meta-models and further towards meta-meta models (Brossard et al., 2011). Models are simplified view of a specific application system of a particular domain and specified in a suitable modelling language. A meta-model is an abstract specification of models that allows what can be syntactically expressed in a model and specified in a meta-modelling language. Similarly, a meta-meta model realises domain independent systems, expresses abstract syntactical structure of meta-models and specified in a meta-meta modelling language (Abmann et al., 2006).

In practice, a well-defined domain-specific modelling language should have well-defined forms (syntaxes) and meanings (semantics) which are suitable for automatic interpretation by computer (Kleppe et al., 2003). Beside, those languages should facilitate to share consistent and interoperable knowledge between domains when different domains are communicating with each other. Distinct traditional approaches in domain-specific modelling such as formal, semi-formal or informal specifications provide rigorous syntaxes towards conceptual models. However, those are not suitable for presenting consistent and enriched semantics of those (Happel and Seedorf, 2006). This leads towards different understanding, ambiguous and incomplete specifications of domain, and major reworks after implementation of domain-specific systems. To resolve this problem, shared conceptualisation of the problem domain is required which should be consistent and semantically interoperable.

Ontology seems to be better suited for representing common understanding of domain for providing logical formalism or model theory, automated reasoning and validation (Parreiras et al., 2007). It is defined as an explicit specification of shared conceptualisation in terms of concepts, relationships present between those concepts and related axioms (Guarino et al., 2009). Axioms enable ontology to deliver enriched and interoperable semantics as these constrain knowledge and are expressed in formal logic. Besides, they have formal proof theory and thus aid in automated reasoning (Genesereth and Nilsson, 1987). Further, ontology can also be specified in distinct levels of abstractions. A lower level ontology may provide application specific semantics. It may conform towards middle level ontology which may express domain-specific semantics. Similarly, a middle level ontology may conform to an upper level ontology which delivers most general semantics independent of any domain (Semy et al., 2004). Thus the requirement of providing concise semantics towards conceptual models may be fulfilled by mixing ontology specifications with domain-specific modelling. This practice in literature is known as ontology driven domain-specific modelling.

However, despite of several advantages of existing approaches in ontology driven domain-specific modelling, designers face some challenges when they apply those proposals in domain-specific systems design. Such challenges are as follows.

Ch.1. Lack of a systematic methodology that may blend semantics of ontology specification with syntaxes of domain-specific modelling.

Ch.2. Majority of existing ontology specifications in literature are in low level abstraction. They are confined to certain domains or parts of domain and are not reusable for large numbers of domains. This also leads to the problem of poor semantic interoperability and inconsistency in domain knowledge integration.

Ch.3. Several ontology driven approaches in literature suggest upper level ontology in domain analysis mainly focusing on structural design concerns. Those are not able to provide rigorous conceptualisation of domain from functional and behavioural design concerns. This is a serious drawback of these approaches since domain conceptualisations specified from different design aspects can facilitate design and later phases of domain-specific software development in an efficient way.

Ch.4. Few ontology driven approaches are present in literature that may represent evolving knowledge of domain but not in precise form.

Ch.5. Proper tooling and guidelines are absent that may help designers for specification of ontology driven domain-specific modelling in an organised way.

Ch.6. Traceability is missing between real domain concepts and domain model concepts. This may reveal the problem of wrong instantiation from abstract domain models towards concrete implementations.

Aiming to overcome issues explained in these

aforementioned challenges this paper proposes several objectives. At first, a framework (Figure 1) is proposed that mixes syntaxes of domain-specific modelling with semantics of ontology specification. The proposed framework is multi-level abstraction hierarchy for ontology driven domain-specific modelling. This objective may cover the issue stated in Ch.1. Secondly, the paper proposes an upper level ontology known as Generalised Ontology Modelling (GOM). Proposed GOM represents abstract semantics and syntaxes of domain independent conceptualisation. It is enriched with formal axiom representations of different design aspects and also evolving knowledge. Thus it is applicable towards large numbers of domains. This objective addresses issues described in Ch.2, Ch.3 and Ch.4. Next, this paper suggests guidelines on how to apply general conceptualisation of top level in the proposed framework towards domain-specific and application specific conceptualisation. This purpose deals with problems specified in Ch.5 partially. Besides, a kind of domain-specific ontology for Reference Information Model (RIM) (HL7, 2011) compatible with Health Level 7 (HL7) (Health Level Seven International, 2011) standard is systematically derived from proposed GOM and illustrated using case studies. This objective is related to the problem expressed in Ch.6. In addition, proposed axioms of GOM are initially validated using an ontology editing tool Protégé based on Web Ontology Language (OWL) (Horridge, 2011). Furthermore, several crucial properties of the proposed GOM are formally verified. Moreover, a detailed comparative study has been specified between proposed ontology and other ontology specifications in the related field to show the improved performance of the proposed GOM.

Ontology-driven approach towards domain-specific system design 41

Figure 1 Proposed framework for ontology driven domain specific modelling

Meta-Meta Model Level

Meta Model Level

Model Level

Ontology Driven Generalised Specification of Domain Independent Conceptualisation

Ontology Driven Specification of Domain dependent Conceptualisation (e.g. Healthcare domain)

Ontology Driven Specification of Application specific Conceptualisation (e.g. E-Prescription)

Upper-Level Ontology

Middle-Level Ontology

Lower-Level Ontology

Domain Specific Software Systems (e.g. E-Prescription System)

Level hierarchy in Domain Specific Modelling

(Abmann et al., 2006)

Level hierarchy in Ontology

Specification (Semy et al., 2004)

Realised As

Realised As

Realised As

Provide Semantics

Provide Semantics

Provide Semantics

Conform To

Conform To

Conform To

Restricted To

Restricted To

Restricted To

Conform To

Conform To

Conform To

Restricted To

Restricted To

Restricted To

The paper is structured as follows. Several related works in this field have been specified in Section 2 briefly. Section 3 is about proposed ontology driven domain-specific modelling framework. The proposed upper level ontology (GOM) have been described and formalised in Section 4. Next, guidelines about the way in which the top level ontology can be applied towards domain and application specific conceptualisations have been suggested in Section 5. Further, the proposed GOM have been implemented and visualised using an ontology editorial tool Protégé in Section 6. Following this, Section 7 practically illustrates the proposed work using a suitable case study. Afterwards, existing approaches described in Section 2 have been compared with the new proposed one based on several levels of features in Section 8. Finally, the paper is concluded in Section 9.

2 Related work

Few research works exist in the literatures those are in general upper level ontology and used in ontology driven domain-specific modelling. Guizzardi (2005) provides formal axioms only from structural design concerns. Guizzardi et al. (2013) have stated event semantics, and social and intentional things. But, processes semantics are not differentiated from events by them. Thus functional design concerns are not separated from behavioural design aspects in this approach. Further, semantics related with inter dependency between different designs concerns and evolving domain knowledge are not specified in this approach precisely. Furthermore, in this approach different software designing methods and conceptual perceptions of software designers have not been considered. Beside, this approach is specific towards Object Orient software design paradigm. Hence, software designers

may face several difficulties in applying this proposal towards other software design paradigms. Basic Formal Ontology (BFO) describes entities, events and processes in a course of time and in a particular time instant (Grenon and Smith, 2004). Although, separation between functional and behavioural characteristics have not clearly specified. Further, semantics related to dynamicity of relationships between distinct concepts are not properly expressed. Next, suitable suggestions are not specified in this approach for defining evolving knowledge. Beside, proper tools or guidelines have not been proposed in this approach for software designers in order to make a suitable domain-specific modelling language. Moreover, lack of considerable traceability in this approach may raise the problem of erroneous instantiation of top level concepts. Descriptive Ontology for Linguistic and Cognitive Engineering (DOLCE) proposed in Gangemi et al. (2002) is ontology of particulars and has no direct relationship with universals. It mainly provides semantics towards words or linguistics knowledge base. Thus, this approach may suitable towards Natural Language Processing. Consequently, this approach is not applicable towards large numbers of domain. Beside, proper tooling and guidelines for domain appropriateness have not been present in this approach. General Formal Ontology (GFO) (Herre, 2010) integrates object and process modules. Its main application areas are natural sciences. However, it is also not axiomatically much enriched to imply functional, behavioural design concerns, inter dependencies between different design aspects, dynamic relationships and changing domain knowledge. Further, applicability of the proposed ontology specification towards variety of software designing paradigms is also not advocated in this approach. Walter et al. (2014) proposed a systematic framework that combines ontology semantics with domain-specific modelling. They also suggest tools and guidelines


related with the framework. But their proposals are specific towards mixing of Web Ontology Language (OWL) with Ecore-based meta-meta model. SUMO (Suggested Upper Merged Ontology) and its domain ontology is one of the largest public ontology existing today (Pease et al., 2002). This is a middle-level ontology. However, this ontology do not also specify functional and behavioural characteristics of a domain. Thus, this ontology cannot be applied towards open-domain applications. Sowa’s Ontology (Sowa, 2000) is based on a framework of distinction, from which hierarchy is generated automatically. But this ontology is not included with space, time or property concepts. Hence, this ontology is also not applicable to fulfil the challenges described in introduction. Cyc Ontology (Matuszek et al., 2006) is a large common sense knowledge base. This ontology is used mainly in Natural Language Processing. However, its vocabulary is still lacking in modelling software systems and its functional and behavioural designing.

Various ontologies present in literature provide semantically enriched conceptualisations but restricted to certain domain. Santos et al. (2009) endorse goal based service ontology. It is domain independent functional design aspects presentation of service, service client, service provider, goal and tasks. But this approach is restricted towards service oriented computing. Fox et al. (1998) provide demonstrations of enterprise level domain-specific behaviours like activity, state, causality, time, and the objects they manipulate such as inventory, orders and products. In Su et al. (2003), communications between multiple agents are improved using ontology of dynamic message exchange and interactions. But this approach is specific to agent oriented software design paradigm.

Therefore, large numbers of approaches furnish structural descriptions of entities, events and processes but do not much focus on crucial functional and behavioural features of them. Such features are sequencing and ordering of events occurring and state transitions, participation of entities in processes, message exchange or inter relations between different designs aspects. These knowledge realisations are necessary in the purpose of procurement about attachment of entities with its surrounding dynamic and evolving environment. More importantly, majority of them do not describe how to represent new knowledge appended with a domain dynamically. Few proposals present this knowledge in partial and for a certain domain. Yet certain approaches have proposed systematic methodology, tools and guidelines for ontology driven domain-specific modelling but those are confined towards specific modelling languages. Henceforth, deficiency of major approaches lies in providing a systematic framework for precise interpretation of evolving domain conceptualisation from functional and behavioural design aspects. Further, major works in literature regarding formal upper level ontology have been restricted towards specific software design paradigm. Thus, those proposals are not applicable towards other software design paradigms. Hence, none of existing approaches is appropriate enough to cover the six challenges specified in the introduction section. In this regard, devising of a new upper level ontology is essential

that may resolve the issues addressed in the six challenges and facilitate domain-specific system design.

3 Proposed ontology driven domain-specific modelling framework

Proposed ontology driven domain-specific modelling framework in Figure 1 includes multi-levels of abstractions. This proposed abstraction mechanism mixes semantics of each level of abstraction hierarchy in ontology specification (Upper, Middle and Lower) (Semy et al., 2004) with syntaxes of each level of abstraction hierarchy in domain-specific modelling (Meta-meta model, Meta-model and Model) (Abmann et al., 2006). The proposed framework consists of three levels. Each level represents conceptualisations both syntactically and semantically. The top level is in highest level of abstraction and the bottom level is in lowest level of abstraction.

Every level provide abstract syntaxes and semantics towards immediate lower level. In other words, concrete syntaxes and semantics of every level instantiate their immediate higher level. Further, each level focuses on automated reasoning on the content of adjacent lower level. In this way, the top level uses semantics of upper level ontology and is realised as meta-meta model level in domain-specific modelling. It represents domain independent conceptualisation. Similarly, the intermediate level uses semantics of middle level ontology and realised as meta-model level. It represents conceptualisation of domain dependent systems. Likewise, the bottom level uses semantics of lower level ontology and realised as model level. It represents conceptualisation of application specific systems. A concrete software system further instantiates the bottom level of the proposed framework.

This systematic framework may help to accomplish ontology driven domain-specific modelling in an organised way from highest level abstract models (enriched with both syntaxes and semantics) towards concrete implementations. Consequently, this proposed framework may address the issue described in Ch.1 listed in introduction section.

4 Proposed generalised ontology modelling: GOM

The proposed GOM is about formal representation of concepts and relationships of domain independent conceptualisation. It is an upper level ontology. According to the proposed framework in Figure 1, GOM may be placed in the top level of the proposed level hierarchy. Thus this level mixes semantics of GOM with syntaxes of meta-meta model level in domain-specific modelling and provides abstract syntaxes and semantics towards domain dependent conceptualisation. The reason behind specification of GOM is to resolve problems explained in Ch.2, Ch.3 and Ch. 4.

Theoretically, conceptualisation is an abstract, simplified view of the world (Liu et al., 2005). Any ontology specifications have to commit with some conceptualisation


explicitly or implicitly (Guarino et al., 2009). Say, GOM commits towards conceptualisation C represented as C = {D, R, W}. D is the set of concepts called universe of discourse; W is the set of possible world states; and R is the set of conceptual relations on the domain space <D, W> (Guarino et al., 2009). C is further subsumed by four types of conceptualisations. Let, L be an ontology representation language expressing the axioms of GOM in mathematical logic (First and Higher order) and O is index of axioms.

4.1 Conceptualisation in proposed GOM

Conceptualisation consists of concepts, relationships between concepts and set of world states. Concepts are representative elements of any conceptualisation. The related axioms are

O1: x x D Q Concept D

where Q is a predicate over Concept( D) that returns a concept.

O2: ,r x y r R x D y D S Relation x y

where S is a predicate over Relation (x, y) that returns relationships between concept x and y.

O3: w w W U Worldstate W

where U is a predicate over Worldstate (W) that returns a worldstate.

O4: x y z w C x D y R z W w

Conceptualisation C may be categorised in four groups- Structure Element Conceptualisation (CSE), Activity Element Conceptualisation (CAE), Event Element Conceptualisation (CEE) and Artefact Element Conceptualisation (CAFE). These four groups represent domain independent conceptualisations from different design concerns. CSE is realised from structural design concerns, CAE is realised from functional design concerns, CEE is realised from behavioural design concerns and further, CAFE aids in conceptualisation of evolving domain knowledge.

O5: (SE AE EE AFEx C x C x C x C x C

4.1.1 Structure element conceptualisation (CSE)

CSE deals with structural concepts (SE), related relationships RSE and world states. Structure Elements (SE) are representative concepts of CSE and these have properties or attributes denoted as a set P. Let, i be a relation attaching properties with the structure elements (Guizzardi et al., 2002). The related axioms are

O6: p p P V Prop P

where V is a predicate over Prop (P) that returns Properties of a Structural Element (SE).

O7: ,x SE x p p P i x p

O8: ,p p P x SE x i x p

O9: , ,SEr R r r R r SE SE r SE AE r

, ,SE EE r SE AFE i

O10: 1 2 1 2x y z t t t SE x t TM t TM t TM

( , 1 , 2 , 1, 2existence x t existence x t existence x duration t t

, 1 ,lessthan t t existence t x , 2greaterthan t t

,existence t x

where TM specifies the set of times; existence() is a predicate implying that a specific instance is exit in that time; duration() is a function returning interval time between two time instances; lessthan() is a predicate implying first argument is smaller than the second argument; and greaterthan() is a predicate implying first argument is greater than the second argument.

O11: w W w w W

O12: SE SEx C x d r w SE d R r W w

4.1.2 Activity element conceptualisation (CAE)

CAE conceptualises Activity Element (AE) related relations RAE and relevant world states. Activity Elements (AE) are representative concepts of CAE. One AE may be attached with some basic tasks T. A single task executes as a whole in a specific time without any interruption. Let, h is a relation connecting basic tasks to its counterpart AE. Every AE has some existing time duration. The related axioms are

O13: t t T K task T

where K is a predicate over task (T) that returns basic low level tasks.

O14: ,x AE x y y T h x y

O15: ,t t T x AE x h x t

O16: , ,AEr R r r R r AE AE r SE AE r

, ,AE EE r AE AFE h i

O17: 1 2 1 2 2x y z t t t AE x t TM t TM t TM

( , 1 , 2t TM existence x t existence x t existence

, 1, 2 , 1 ,x duration t t lessthan t t existence t x

, 2 ,greaterthan t t existence t x

O18: w W w w W


O19: AE AEx C x d r w AE d R r W w

4.1.3 Event element conceptualisation (CEE)

CEE is conceptualisation of Event Elements (EE), relationships REE and world states. EE initiates AE, interrupts AE, stops AE and initiates interactions between AE according with constraints present in the domain. Let, CO is a set of constraints, f is a member of CO, Constraint() is a function returning constraints, and g is a relation connecting constraints to an instance of EE. EE may follow ordering sequences and exist in a time-interval. The related axioms are

O20: f f CO Q Constraint CO

where Q is a predicate over Constraint(CO) that returns Constraints.

O21: ,x EE x f f CO g x f

O22: ,g x f EE x f CO g x f y AE y

O23: (x y z EE x EE y EE z a b c

, , ( , , ( ( , ,order a b c order a b c order b a c order

, , , , , , , ,b c a order c a b order c b a order a c b

, , ,order a b order b c order a c

where order() is a predicate which implies that its instances are in an order

O24: 1 2 1 2x y z t t t EE x t TM t TM t TM

( , 1 , 2 , 1, 2existence x t existence x t existence x duration t t

, 1 , , 2lessthan t t existence t x greaterthan t t

,existence t x

O25: , ,EEr R r r R r EE EE r SE EE r

, ,AE EE r EE AFE g

O26: w W w w W

O27: EE EEx C x d r w EE d R r W w

4.1.4 Artefact element conceptualisation (CAFE)

Artefact Elements (AFE) are representative concepts of CAFE. They produce more consistent knowledge regarding SE, AE and EE in useful and comprehensive way. Examples of artefact elements are properties, tasks, roles, message, constraints, time, space and state. New kinds of useful knowledge, whose semantics are not similar like SE, AE, or EE, and existing

member of AFE, may be append as artefact elements with GOM. Thus GOM may extend itself and recognise new kind of knowledge that may come in the domain as objectives of end users has been changed. Artefact elements may differentiate SE, AE and EE. For example, constraints are directly connected with EE. These may not be directly connected with AE or SE. Related axioms of properties, tasks, and constraints are O6, O15, and O21. Similarly, axioms of Role (RL), message (MSG), time (TM), space (SP) and state (ST) are as follows.

O28: r r RL Q Role RL

where Q is a predicate over Role(RL) that returns roles played by SE.

O29: m m MSG L msg MSG

where L is a predicate over msg(MSG) that returns messages.

O30: t t TM Q Time TM

where Q is a predicate over Time(TM) that returns time stamps and ‘Q’ is a predicate.

O31: sp sp SP L space SP

where L is a predicate over space(SP) that returns spaces.

O32: st st ST L state ST

where L is a predicate over state(ST) that returning states. To sum up, axioms of Artefact Element Conceptualisation

(CAFE) are

O33: x AFE x x RL x P x T x CO

x MSG

O34: ( , ,AFEr R r r R r AFE SE r AFE AE

, ,r AFE EE r AFE AFE

Finally, each type of concepts is represented with respect to the set D

O35: x x D SE x CE x EE x AFE x

4.2 Relations in proposed GOM

Relation establishes connections between the concepts. All relations of GOM are in two groups – Inter Concept kind relationships (RCI) and Intra Concept kind relationships (RIC). Inter Concept kind relationships may present between different categories of concepts like between structural element concept (SE) and activity element concept (AE). These relationships may assist to realise inter connectivity between distinct design aspects. On the other hand, Intra Concept kind relationships may present within the same kind of concepts like between two different instances of structural


elements (SE). These are the relationships within same design aspect. In addition, inverse of some relationships can be grouped under another category – Inverse Relationships (IRL). This category includes - (i) Inverse of Has Attribute (IHA), (ii) Inverse of Has Task (IHT), (iii) Inverse of Has Constraint (IHC), (iv) Inverse of Has Role (IHR), (v) Inverse of Has Concepts (IHCN), (vi) Inverse of Has World (IHW) and (vii) received message (IMS). Proposed GOM may realise dynamically included knowledge using these inverse relationships. Two more relationships may exist - one is between conceptualisation and concepts (HCN and IHCN) and another is between conceptualisation and world states (HW and IHW).

O36: CI ICr r R R r R r HW r HCN r

IHW r IHCN r

O37: SE AE EE AFEr R r R r R r R r r r R

O38: r IRL r IHA r IHC r IHT r IHW r IHCN

r IHR r IMS r

4.2.1 Intra concept kind relationship (RIC)

Intra concept kind relationships are of five types - Intra Inheritance, Intra Collaboration, Intra Containment, Intra Data flow and Intra State Transition.

Intra Inheritance (IHSE): Intra Inheritance is the relation, through which a structure element concept derive another structure element concept. Inheritance assists reusability. Let, the parent elements and the child elements of SE category are SEDP and SEDC respectively; PSEDP and PSEDC

are the set of properties of SEDP and SEDC correspondingly; Subset() is a function specifying whether property of any parent structural element concept DC is subset of a child concept DP and i is a relationship connecting one instance of SE towards its relevant properties. The axiom is

O39: SE DP DPx a ih IH ih SE x y y PSE

, ( ,DC DCi x y SE a b b PSE i a b

, ,DP DCSubset PSE PSE ih x a

Intra Collaboration (CR): This relationship is present between two structural elements (SE) based on roles of them in a particular context. This context may be several activity elements (AE) and its related SE and EE. Collaboration identifies key players in certain context and their specific objectives. Let, context() is a predicate implying a specific situation and d is a relationship connecting a particular SE with its relevant roles.

O40: s z y a b l d CR s z RL y RL SE a

( , , ,SE b context l d a z d b y s a b

Intra Containment (CTS): This relation assists in encapsulation of one concept within similar kinds of concept. CTSSE, CTSAE,

and CTSAE symbolise intra containment relationships between SE, AE and EE respectively. This realises part-whole containment between elements.

O41: 2 3 ( 2 3SE SEl r r CTS l IH r CR r

( ,a c SE a SE c l a c

O42: ,AEk CTS k a c AE a AE c k a c

O43: ( , EEn CTS n a c EE a EE c n a c

O44: SE AE EEr CTS r CTS r CTS r CTS r

where l, k and n are relationships connecting two instances of SE, AE and EE respectively.

Intra Data flow (RICD): Intra Data flow relationships convey messages between AE and interacts with each other by passing data in the form of SE to accomplish their specific functionality.

O45: 1 ( 1ICDK R K a b c AE a SE b AE c

1 , ,a c K a b c

Intra State Transition (RICS): It denotes transition from one state of SE to another state. EE triggers SE. Subsequently, SE participates in AE and changes its state. Let, State1 and State2 are two states of SE in a specific world state and World1 and World2 are two world states. State transition may follow some ordering sequence.

O46: [ ICS SE EE SE AEr R r l m CTD l CTD m

1, 2 1, 2r State State r World World

O47: ICS ICS ICSa b c R a R b R c a b c

, , ( , , , ,order a b c order a b c order b a c order

, , , , , , , ,b c a order c a b order c b a order a c b

, , ,order a b order b c order a c

Altogether, intra concept kind relationships can be represented as

O48: (IC ICS SEr R r R r IH r CTS r CR r

ICD ICSR r R r

4.2.2 Inter concept kind relationship (RCI)

Inter Concept kind relationships (RCI) are of three types –Inter Containment, Inter Interaction and Inter Artefacts Relations.

Inter Containment (CTD): Inter Containment Relation (CTD) exist when one group of concept encapsulates another group of concept. CTDSE-AE and CTDSE-EE characterise Inter Containment relationships between SE and AE and


between SE and EE respectively. However, these kinds of relationships between SE and AE realises participation of SE in AE.

O49: ,SE AEld CTD ld a b rl SE a AE b ld a b

, ( ,rl RL d a rl ld a b rl

◊ is a possibility operator (Fitting, 2000) and d is a relationship that connects role rl with a structural element instance.

O50: [ ,SE EEmd CTD md a b SE a EE b md a b

O51: SE AE SE EEr CTD r CTD r CTD r

Inter Interaction (IR): Inter Interaction is communication between AE and SE through which SE executes one or multiple low level tasks of AE or pass messages towards AE. When a collaborative SE interacts with an AE, it may be collaboration based interaction. Inter Interactions may be happened in sequence and maintains some orders. IR provide knowledge about activities, participate entities, sequence of tasks and message passing.

O52: q a b m t h IR q SE a AE b m MSG

( , ( , ,t T HT h q a b q a b execute t a

, , ,h t b q a b pass m b

where execute() is a predicate that implies SE executes tasks; h is a relationship connecting task t towards its related AE and pass() is a predicate that implies message m is passed by b.

O53: (a b c IR a IR b IR c a b c

, , ( , , ( ( , ,order a b c order a b c order b a c

, , , , , ,order b c a order c a b order c b a order

, , , , ,a c b order a b order b c order a c

Inter Artefacts Relations: Inter Artefacts Relations are connections of various artefacts with SE, AE and EE. SE has relations with properties, roles and states. AE has relation with task and EE has relations with constraints. Based on this, a number of artefact relations may present –(i) Has Attribute (HA),(ii) Has Task (HT),(iii) Has Constraint (HC), (iv) Has Role (HR), (v) Inverse of Has Attribute (IHA), (vi) Inverse of Has Task (IHT), (vii) Inverse of Has Constraint (IHC), (viii) Inverse of Has Role (IHR), (ix) Has Time (HTM), (x) Has Space (HSP), (xi) Send Message(SM), (xii) receive message (RM). As an example of Inter Artefacts Relations, axioms of HA and IHA are as follows.

O54: [ ,i HA i p x p P SE x i x p

O55: [ ,Ii IHA Ii p x p P SE x Ii p x

O56: a b HA a IHA b a b range a domain b

domain a range b

where IHA is linking from property artefact to corresponding SE; HA is the connection from SE to its properties; range() is a function returning the range value of a relation; and domain() is a function returning the domain value of the relation. Axiom O56 expresses the fact that relations HA and IHA are not same since the range of the former relation is the domain of the later and vice-versa.

4.2.3 Has World (HW), Has Concept (HCN) and their inverse relations

Has Concept (HCN) and Inverse of Has Concept (IHCN) exist between conceptualisation and concepts where Has World (HW) and Inverse of Has World (IHW) exist between conceptualisation and world states. Axioms of Has Concept (HCN) and Inverse of Has Concept (IHCN) are

O57: c ,i HCN i c x C D x i c x

O58: C c ,Ii IHCN Ii c x D x Ii x c

O59: a b HCN a IHCN b a b range a

domain b domain a range b

HW and IHW have same axioms as O57, O58, and O59, except HW replace HCN, and IHW replace IHCN.

4.3 Functional and behavioural design aspects

Proposed GOM is strongly enriched to represent structural, functional and behavioural design aspects. Distinct structural entities are supported by proposed GOM efficiently and exhibited in the previous section. Efficiency of GOM towards representation of functional and behavioural design aspects are demonstrated in this sub-section.

Functional design aspects: Functional design aspect is allied with processes, and control in addition data flow between processes. Proposed GOM represent processes and its characteristics using Activity Elements (AE). Processes may perform several lower level tasks. This is interpreted in GOM using tasks (t). Related axioms of AE and its corresponding tasks are expressed in O13-O19. The data flow between processes is the way that how data is moved between communicating processes. It is recognised in proposed GOM using Intra Data flow (RICD) relationship. Related axioms regarding RICD have been expressed in O45. However, control flow defines the ordering sequence of process executions. This may be represented in GOM using ordering of Activity Element (AE) execution (Axiom O53). Further, different types of ordering constraints (like sequence, parallel, branching) may be expressed using order() predicate as given in axiom O53.


Let an example of communication between different processes in Plant Healthcare Monitoring. In plant healthcare monitoring, plants are identified first. Then those plants are carefully inspected for discovering presence of any pests in the plant. Next, if pests are present, then they are classified. Sequentially, the injury level in plants is recognised. Based on this, specific pest management methods are selected.

Hence, several processes are present in this example. Those processes may be Identification_of_Plants, Inspection_ of_Plants, Identify_Pest, Identify_injury_level and Selection_ of_Pest_Management_Method. Each process is comprising of lower level tasks. Such as the process Identification_ of_Plants is consisting of tasks like identify_leaves, identify_ species. Further, these processes communicate with each other in the same order in which those are specified in the last paragraph. For example, Identification_of_Plant communicate with the next process Inspection_of_Plants by passing data about Plant.

Consequently, these processes are identified as AE in GOM. Corresponding tasks are identified as tasks. Beside, those sequential relationships between AE are exposed as Intra Data flow (RICD) relationships in GOM. Further, Plant is recognised as a Structural Element (SE). Moreover, the control flow between the processes in this case is accomplished in serial order.

In order to demonstrate the said case study, the example of Inter Data flow between AE Identification_of_Plants and Inspection_of_Plants have been formalised. Formalisation of Inter Data flow is based on axiom O45. The example is instantiated below based on that axiom as

1 ( _ _

_ _

1 , ,

ICDR K a b c Identification of Plant a

Plant b Inspection of Plants c a c

K a b c

where Identification_of_Plant() and Inspection_of_Plants() are predicates identifying first two AE respectively. Plant() is a predicate implying SE Plant.

Behavioural design aspects: Behavioural design aspects deal with the way of interaction between the domain and the outside environment through events. Proposed GOM represents events with the aid of Event Element (EE) conceptualisation. Event may be related with conditions. Conditions are identified using Constraints (CO) in GOM. Related axioms of EE and CO are expressed in O20-O27. The interaction between a system and its environment is recognised in several ways. Firstly, a structural component, triggered by a particular event, may take part in a process execution. Secondly, a structural component may change its state, since it may take participation in several processes. Thirdly, two structural components may communicate with each other based on certain roles played by them. Proposed GOM support the first characteristics using Inter Interaction (IR) relationship (Axiom O52). Further, the second characteristic

is represented using Intra State Transition (RICS) relationship (Axiom O46 and O47). Moreover, the third characteristic is denoted using Intra Collaboration (CR) relationship (Axiom O40). Beside, roles played by structural component are specified using Role (RL) Artefact Element (AFE) (Axiom O28) and its corresponding Has Role (IHR) relationship. Moreover, states are interpreted in GOM using state (ST) Artefact Element (AFE) (Axiom O32).

Let the example specified in section Functional design aspects once more. In Plant Healthcare Monitoring, a plant’s state is changed after affected by pests. For instance, discoloration or distortions of leaves is an example of state changing of a plant. Thus, a plant may have normal coloured leaves. But after presence of a specific pest in the plant, leaves of the plant become discoloured.

Hence, in this example Presence_of_Pests is an event. Beside, Plant and pest take participate in the process Identify_Pest when the event Presence_of_Pests trigger on Plant. In this case Plant may play the role of victim and pest may play the role of attacker. Further, Normal_coloured_ leave is a state of Plant before affected by pests. Discoloured_Leave is the state of Plant after affected by pests.

Consequently, Presence_of_Pests may be identified as an EE in proposed GOM. The Constraint related with this EE will be presence of pests. Identify_Pest may be an AE. Further, victim and attacker may be Roles played by Plant and pest correspondingly. Plant and pest will be SE. Beside, Normal_coloured_leave and Discoloured_Leave will be states in GOM. EE Presence_of_Pests is the reason for which SE Plant and pest interact with a specific AE Identify_Pest. In this way, state1 of Plant which is Normal_ coloured_leave may change towards state2 Discoloured_ Leave. Thus, using Intra State Transition (RICS) relationship the state transition of Plant can be recognised. Further, using Inter Interaction (IR) relationship the participation of Plants and pests in AE Identify_Pest may be identified. Next, using Intra Collaboration (CR) relationship the communication between Plant, and pest based on their roles will be established.

In order to demonstrate the abovementioned case study, the example of Inter State Transition (RICS) have been formalised based on Axiom O46. The example is instantiated below based on this axiom.

_ _

_ _ _ ,

_

ICS Plant Presence of Pests

Plant Identify Pest

R r l m CTD l

CTD m r Normal coloured leave

Discoloured Leave

Thus, GOM is able to express functional and behavioural design aspects. Beside, GOM also be able to capture dynamic characteristics of relationships. Such as sequence of state transitions (Axiom O47) or sequence of events occurring (Axiom O23). Hence, GOM is capable to resolve problems stated in Ch.2 and Ch.3.


4.4 Crucial properties of proposed GOM

Several crucial properties of proposed GOM are proved in this section to exhibit the usefulness of GOM. Those properties are identity, rigidity, unity, dependence, traceability and consistency. Guarino and Welty (2009) proposed identity, rigidity, unity and dependence in order to provide meta-descriptions of distinct properties. Objective of these four aforementioned meta-properties is to make clear the logical consequences of certain ontological choices (Guarino and Welty, 2009). Raban and Garner (2001) formalise them from conceptual modelling perspective. This paper demonstrates those properties using resolution method to show that GOM has supported these properties.

Identity: It refers to the characteristic of GOM that may recognise instances of its distinct concepts individually.

To represent the identity for instances of structural elements (SE), it is essential to establish the fact that there exists at least one property which only belongs to that instance of SE. So, SE has certain properties as Identity criteria. Similarly, AE has certain tasks and EE has certain constraints as Identity criteria. Hypotheses are specified below in order to prove Identity criteria for instances of SE using resolution methods.

The first hypothesis is - Every instance of SE has particular properties and those are not same for two instances of SE.

p1 p2 1 2

, 1 , 2 1 2

x y SE x SE y p P p P

HA x p HA y p p p

This hypothesis drops and and takes form of clause 1.

(1) ,SE x SE y c P b P HA x c

,HA y b c b

The second hypothesis is - If certain properties of two instances are not same, then those instances are instances of SE and they are not same.

1 2 1 2 , 1

, 2 1 2

x y p p p P p P HA x p

HA y p p p SE x SE y x y

This expression drops and and takes form of clause 2.

(2) 1 2 , 1 , 2p P p P HA x p HA y p

1 2 1 1 1p p SE x SE y x y

The third hypothesis is - If two instances of SE are not same then they have their own identity.

x y SE x SE y x y

identity x identity y

where Identity() is a predicate which implies instances (x or y ) have identity.

This expression drops and and takes form of clause 3.

(3) SE x SE y x y identity x

identity y

The fourth hypothesis is that X1 and X2 are two structural elements (SE). The equivalent clause is

(4) 1 2SE X SE X

Now it is to be proved that x and y has identity criteria. In order to prove this, let, disprove that x and y has no identity criteria. The equivalent clause is

(5) identity x identity y

The proof of identity criteria for SE concepts of GOM using resolution method is in Figure 2. This proof method disproves that x and y have no identity as null clause appears at the end. In similar way, one may prove identity of different concepts, conceptualisations and relations.

Figure 2 The proof of identity criteria for SE concept of proposed GOM using resolution method

Clause 5 Clause 3

∧ ∧ Clause 2

/ 1 , / 1

1 ∈ ∧ 2 ∈ ∧ , 1 ∧ , 2 ∧ 1 2 Clause 1

1/ , 2/

∧Clause 4

/ 1 , / 1

Null Clause


Rigidity: A rigid universal is one that applies to all instances necessarily in every possible world (Guarino and Welty, 2009).

All concepts of GOM will be rigid, if those concepts may map to all their instances in all possible worlds. For example, concept AE will be rigid if it maps to its instances in all possible worlds. This can be accomplished if a specific instance of AE carries all tasks attached with it in all possible world states. Rigidity criteria of activity element AE may be expressed as

,x w t AE x rigidity x t T HT x t W w

where rigidity() is a predicate implying that its instances have rigidity property.

Unity: Unity refers to capability of recognising all the parts that form an individual concept.

All concepts of GOM have unity if it recognises all concepts with all its parts. For example, GOM achieves unity of an instance of EE if it recognises EE together with all its constraints, all relationships and all possible worlds related with that EE. Unity criterion of EE may be as

( EEx f r w EE x unity x f CO RL r W w

This expresses the fact if several EE persist then certain constraints, relationships and world states related with those EE are also persist. Let, unity() be a predicate implying that its instances have unity property.

Dependence: Dependence refers to the fact when instances of one concepts require instances of other concepts in order to survive.

All concepts of GOM have dependence property. For example, all members of AFE are in existence only when their corresponding related concepts like SE, AE and EE exist. An instance of Role is in existence only if an instance of SE, which plays that role, persists. Similarly SE exists when some Property related with SE exist. Beside, all relationships of GOM have dependence property as they are in existence when their end points, those are concepts of GOM, are in existence. Dependence criterion of Role(RL) is

,r x r RL dependance r HR x r SE x

where dependence() is a predicate implying that its instances have dependence property.

This statement states the fact, if there are specific Roles then certain SE should play those Roles. Otherwise those Roles have no existence.

Consistency: GOM is consistent in the order that two different concepts cannot be applied towards the same instance.

For example, AE cannot represent instances of SE since AE have no such provisions of representing those semantics of SE like properties, roles etc. Consistency criteria of SE is

1 1 1

1 ( ( , ,

,

SE

x p rl r SE x consistency x p P

rl RL R r r x t t T r x f

f CO r x m m MSG

This axiom expresses if there is an instance of SE then that instance should have corresponding properties. They may play several roles. They have relations with other concepts like AE, EE. But they have no direct relations with tasks, constraints and messages. In this axiom, consistency() is a predicate implying that its instances have consistency property.

Traceability: Traceability implies that certain concepts of proposed GOM (domain independent conceptualisation) can trace towards related concepts of domain-specific or application specific conceptualisation and vice versa.

The main condition of traceability from GOM towards application and domain-specific system constructs or vice versa is that every concept of GOM should support rigidity and consistency. Traceability criterion of SE is

( x SE x traceability x rigidity x consistency x

where traceability() is a predicate implying that its instances have traceability property.

Further, like Identity criteria resolution method may be used to prove Rigidity, Unity, Dependency, Consistency and traceability property formally. Besides, in this section proposed GOM addresses the challenging issue described in Ch.6 by supporting Traceability property.

5 Proposed guidelines for devising ontology driven domain and application specific conceptualisation from proposed GOM

This section proposes guidelines of mapping process from the top-most level of the proposed framework towards middle and bottom-most level. This mapping method consists of two phases. Proposed guidelines meet the deficiency of proper instructions for ontology driven domain-specific modelling which is a part of Ch.5. However, another part of this challenge, which refers to absence of adequate tooling for ontology driven domain-specific modelling, can be overcome by automation of the proposed framework in the Figure 1 based on this proposed guidelines.

5.1 Phase 1 – mapping from proposed GOM towards ontology driven domain-specific conceptualisation

In this phase, guidelines are provided to identify domain-specific concepts and relationships based on GOM. This phase consists of sub phases as follows –

Identification of domain-specific SE and its relationships: In a domain, specific constructs have relevant properties such as name, height. They may play roles such as student, provider. Besides, they may participate in activities such as treatment, sell and may encapsulate structural elements (part-whole relationship) and also activities and event elements. These constructs are domain-specific SE. They may inherit other SE. Further, they also have collaboration relations between each other based on roles playing by them.


Identification of domain-specific AE and its relationships: In a domain, several constructs have low level uninterrupted tasks such as catch, move. They can communicate with each other through message or data passing. These are domain-specific AE. These constructs may contain sub functions. However, those functions cannot be executable until related structural elements interact with them.

Identification of domain-specific EE and its relationships: Particular constructs of domain may help SE to interact with outside environment and impose constraints on domain. These constructs are domain-specific EE. They may be occurred in a specific order. Further, they may trigger SE to take participation in activities.

Identification of domain-specific AFE and its relationships: Semantics of several domain constructs may be different from semantics of SE, AE and EE. These constructs can be realised either as AFE and its existing components like time, role, space, constraints, message etc. or as new kinds of components of extended AFE.

Inspection of traceability: A domain-specific ontology may trace back relevant concepts of GOM by representing all concepts of the domain based on GOM. Thus GOM preserve consistency and rigidity property when it is mapped towards domain-specific ontology.

5.2 Phase 2 – mapping from ontology driven domain-specific conceptualisation towards ontology driven application specific conceptualisation

In this phase, application specific concepts and relationships are identified based on ontology driven domain-specific conceptualisation achieved in phase 1. All domains specific

SE, AE, AFE and EE are restricted towards application specific SE, AE, AFE and EE respectively along with their relationships. This phase may refine itself continuously to represent more low level specifications of application systems. Application specific ontology also should trace back towards corresponding domain-specific ontology and further GOM.

6 Protégé implementation of proposed GOM

Protégé (Horridge, 2011) may practically implement the proposed GOM by specifying the axiom set of GOM in OWL (Web Ontology Language) logic. Using this logic, Protégé generates valid ontological graphs of GOM with the aid of plug-ins OWLViz and OntoGraf. These ontological graphs can present vocabularies of the proposed ontology visually. Hence, Protégé may initially validate GOM. Table 1 and Table 2 summarise different categorisation of GOM and corresponding facets in Protégé.

The graph in Figure 3, obtained through OWLViz, exhibits only “is-a” relationship between classes in Protégé. Circles depict Protégé classes of respective GOM concepts, conceptualisations and world states. However, the graph in Figure 4, obtained through OntoGraf plug-in, display all relationships (both intra concept kind and inter concept kind relationships) of GOM. Beside, “is-a” relationships of Figure 3 are equivalent to “has subclass” relationships of Figure 4. Moreover, in Figure 4 intra concept kind relationships create loops as their domains and ranges are same. In addition, several relationships are in reverse directions of each other. These are inverse relationships of each other. Figure 4 represents classes as square.

Table 1 Superclass subclass description of class hierarchy in Protégé and corresponding constructs in proposed GOM

Mapped Super classes in Protégé Mapped Subclasses in Protégé Corresponding constructs in proposed GOM

Conceptualisation

Cae CAE

Cee CEE

Cse CSE

Cafe CAFE

D

AE Activity Element (AE)

SE Structural Element (SE)

EE Event Element (EE)

AFE Artefact Element (AFE)

W WorldStates Worldstate (w)

AFE

Property Properties (P)

Task Task (T)

Constraint Constraint(CO)

Role Role (RL)

Message Message (MSG)

Time Time (TM)

Space Space (SP)


Table 2 Distinct relationships of the proposed GOM in Protégé

Mapped Super-Object Properties in Protégé Mapped Sub-Object Properties in Protégé Corresponding Constructs in proposed GOM

hasInterConceptRelation

hasContainmentD Inter Containment(CTD)

hasInteraction Inter Interaction (IR)

hasProperty Has Attribute (HA)

hasConstraint Has Constraint (HC)

hasTask Has Task (HT)

sendmessage Send Message (SM)

hastime Has Time (HTM)

hasspace Has Space (HSP)

hasRole Has Role (HR)

IsRelationship

isWorldOf Inverse of Has World (IHW)

isConceptOf Inverse of Has Concept (IHCN)

isPropertyOf Inverse of Has Attribute (IHA)

isConstraitOf Inverse of Has Constraint (IHC)

isRoleOf Inverse of Has Role (IHR)

isTaskOf Inverse of Has Task (IHT)

receivemessage Receive Message (IMS)

HasIntraConceptRelation

hasCollaborationSame Intra Collaboration (CR)

hasContainmentS Intra Containment (CTS)

hasInheritance Intra Inheritance (IH)

hasDataflow Intra Data flow (RICD)

hasStateTransition Intra State Transition (RICD)

Figure 3 Ontology driven domain independent conceptualisation of proposed GOM obtained through OWLViz plug-in of Protégé


Figure 4 Ontology graph of generalised ontology modelling (Proposed GOM) obtained through OntoGraf plug-in of Protégé

List of Relationships Has Subclass Has ConceptIs Concept ofHas WorldIs World ofCollaborationContainment SameState Transition

List of Relationships Has Data Flow Interaction

Inheritance Has Constraint

Containment Different

7 Realising healthcare reference information model using proposed GOM – a case study

In this section, an ontology driven domain dependent conceptualisation is derived from proposed GOM according to the proposed guidelines to demonstrate the fact that GOM is efficient towards formal analysis and modelling of different domain-specific systems. Reference Information model (RIM) (HL7, 2011) is such a domain-specific conceptualisation based on Health Level 7 standard (HL7) (Health Level Seven International, 2011) in the domain of healthcare. GOM is useful to define abstract syntaxes and semantics of RIM which can be a meta-model of healthcare domain-specific application systems.

HL7 is a standards setting organisation on healthcare domain accredited by American National Standards Institute (ANSI) (Health Level Seven International, 2011). Its main mission is to provide protocols of standards for the exchange, management and integration of data which support clinical patient care and the management of healthcare services. RIM is a shared information model that is belongs to HL7 version 3 family. All products of HL7 version 3 semantically conform to HL7-RIM (Dolin et al., 2006). It has mainly six subject areas- Entity, Role, Act, RoleLink, ActRelationship and Participation. All of these subject areas have subclasses; for example, Entity has subclasses like Organisation, living beings (HL7, 2011).

Table 3 RIM subject areas (Main) and its corresponding proposed GOM and Protégé constructs

RIM Subject Area

Corresponding Proposed GOM Constructs

Corresponding Mapped Protégé Constructs

Entity SE Entity

Act AE Act

Role AFE RIMRole

Participation Inter Interaction Participation

ActRelationship Inter Data Flow ActRelationship

RoleLink Inter Collaboration Role Link

7.1 Mapping of proposed GOM constructs towards RIM constructs and corresponding Protégé visualisation

Proposed GOM may serve as high level abstract definition of main subject areas and their subclasses of RIM. Concepts of GOM such as SE, AE and Role may be applicable towards Entity, Act and Role of RIM. Likewise, distinct relationships of GOM are manifest in several subject areas namely RoleLink, ActRelationship and Participation. Table 3 is summary of this mapping. Figure 5 is representation of GOM based ontology graph of RIM obtained using Protégé. This graph displays main facets of RIM such as Entity, Act, Role, Parameter, Attention line, transmission, Acknowledgement, Acknowledgement Detail, Query event and distinct subclasses of these facets. It can be


verified that all of these aforementioned constructs of RIM trace back towards corresponding GOM facets as no orphan nodes are present in the graph. On the other hand, Figure 6 reveals Role Link, Act Relationship, and Participation as relationships between distinct nodes. These two graphs indicates that GOM can define all concepts of RIM precisely.

7.2 Mapping of ontology driven conceptualisation of RIM towards application specific systems on healthcare domain

Ontology driven conceptualisation of RIM may provide abstract syntaxes and semantics towards application specific systems on healthcare domain. To illustrate this argument, this paper uses an application specific ontology on healthcare

domain about healthcare Kiosk Management System. The main objectives of such a system are (1) to manage present and past health condition records of patients, diagnosis reports and lab test reports, (2) to send reports towards doctors and get advices from them, and (3) give medication, diet, and exercise suggestions towards patients.

This healthcare kiosk management case study has structural entities such as Persons. These entities may play several roles such as Patient, Doctor, and Kiosk Coordinator. They have several properties such as Name, Patient Identification Number. Besides, the case study has some activities like Diagnosis, Examine Patients. In addition, it may have some events like Get Data, Modify Data etc. Besides, one person may append with role lab assistant when some patients have been advised for lab-test.

Figure 5 Ontology driven domain independent conceptualization of proposed GOM and a domain dependent conceptualisation of RIM in Healthcare Domain obtained through OWLViz plug-in of Protégé

Generalised Ontology

Modelling (GOM)

[Upper Level Ontology

and Meta‐Meta Model

Level in Conceptual

Healthcare Domain Specific Ontology of RIM-

HL7 [Middle Level Ontology and Meta Model Level in Conceptual Modelling]

Figure 6 Ontology graph of RIM obtained through OntoGraf plug-in of Protégé

List of Relationships

Has World Has Constraint

Is Property Of

Has Property Has Role Is Role Of

Inter Containment SE-EE

Send Message

Received Message

Participation

Inter Containment SE-AE

Act Relationship

Role Link


Consequently, distinct activities of the Kiosk Management System may instantiate Act subject area of RIM. Subject area Entity represents persons and Roles represents kiosk coordinator, patient and doctor. Further, one person, who has Role kiosk coordinator, may change Role towards lab assistant when participating in lab test activity. Table 4 summarises Kiosk Management constructs. Table 5 specifies kiosk management system constructs and its corresponding RIM and Protégé constructs.

Table 4 Kiosk management system constructs

RIM Constructs Application Constructs

Roles Patient, Doctor, Kiosk Coordinator, Lab Assistant

Entities Person 1, Person 2, Person 3, Person 4

Acts Mediation ,Surgery, Advice, Treatment, Lab-test, On-Examination, Patient-History-record, Symptom-Checking, Send-report, Diagonesis_Test

QueryEvents Get_Data, Send_Data

The ontology driven conceptualisation of Kiosk Management application system uses semantics of lower level ontology and realises as model level abstraction in domain-specific modelling. This lower level can refine itself in more levels and generate more low level abstractions. This application specific ontology can be derived from ontology driven conceptualisation of RIM based on proposed GOM using the proposed guidelines in this paper. The graph in Figure 7 is the lower level ontology graph of the case study displaying all relationships and constructs which are present in Kiosk Management System. Dynamically inserted Role of Person 3 is specified using isRoleOf relationship in Protégé equivalent with Inverse of Has Role relationship of proposed GOM.

However, no corresponding construct of Inverse of Has Role relationship is present in RIM, since RIM is static model. The graph in Figure 8 demonstrates the relationships between GOM, ontology driven conceptualisation of RIM and kiosk management application system. From this graph it can be proved that GOM can be traceable from the application specific ontology of Kiosk Management through RIM or vice-versa since there are no orphan nodes in the part of the application specific level ontology. It also demonstrates the fact that GOM may reusable towards large numbers of domains.

Table 5 Kiosk management system constructs, its corresponding RIM constructs and Protégé representation

Kiosk Management System Constructs

Corresponding RIM Constructs

Corresponding Protégé Representation

Person 1, Person 2, Person 3

Entity Entity

Various Activities Act Act

Various Events Query Event Query Event

Various Roles Role Rim Role

Various message passes between activities

Acknowledgement, Acknowledge Detail, Attention Line, Transmission

Rim Messages

Relationships between entities and activities

Participation Participation

Relationships between different activities

ActRelationship Act Relationship

Relationships between Roles

Role Link Role Link

Figure 7 Ontology graph of healthcare kiosk management application system obtained through OntoGraf plug-in of Protégé

List of Relationships

Has Subclass Has Role

Role Link Is Role Of Has Property Participation Act Relationship


Figure 8 Ontology driven domain independent, domain dependent and application specific conceptualisation obtained through OWLViz plug-in of Protégé

Generalised Ontology Modelling (GOM)

[Upper Level Ontology and Meta-Meta Model Level in

Conceptual Modelling]

Healthcare Domain Specific Ontology of RIM-HL7

[Middle Level Ontology and Meta Model Level in

Conceptual Modelling]

Healthcare Kiosk

Management Application

System [Lower Level Ontology and

Model Level in Conceptual Modelling]


Figure 9 (a) Part of ontology graph expressing distinct properties of person 1, (b) Part of ontology graph expressing distinct relationships between person 1 and person 2

(a) (b)

The graph in Figure 9(a) is partial specification of Kiosk Management System. This graph shows distinct properties of person 1 in Kiosk Management Application system. Likewise, Figure 9(b) is also a partial specification expressing relationships between person 1 and person 2 in Kiosk Management System.

Figures 6 and 7 exhibit the fact that state of the art approaches specified in related work section are limited in capability to represent the specified case study in an appropriate way. Semantics of different relationships of RIM such as RoleLink, relationships between Entity and Property, Participation, ActRelationship and dynamically appended knowledge towards RIM have not been precisely exhibited by those approaches. For example, RoleLink is a type of collaborative relationship through which Roles played by two or more Entities are connected with each other. When Entities have played several roles, those may or may not take participation in some Act. This relationship is the example of behavioural aspects of domain. However, existing approaches in this field have no provision to represent this kind of relationship between structural, process and role. Only Sowa (2000) among existing upper level ontology has suggested about this relationship using ‘Correlative’ relationship. However, this (Sowa, 2000) has not specified the formal semantics and dynamicity of this relationship. Besides, in the specific case study of healthcare kiosk management system, Role lab-assistant is included with Entity person2 dynamically when

person 2 has taken Participation in Act Lab-test. Proposed GOM is capable to represent formal semantics and syntaxes of this dynamically appended knowledge. Figure 7 demonstrates this argument. However, other state of the art approaches have not the provision to represent these types of knowledge.

Further, through formal semantics of proposed GOM the formalisation of RIM can be applied towards distinct software design paradigms such as service oriented, object oriented. Moreover, applications on RIM can be designed in both top-down and bottom-up way. Existing state of the art approaches have not specified these for any kind of domain.

8 Comparative studies

Several approaches (Grenon and Smith, 2004; Gangemi et al., 2002; Herre, 2010; Guizzardi, 2005; Guizzardi et al., 2013; Pease et al., 2002; Matuszek et al., 2006; Sowa, 2000) in the literature are upper level ontology and applied in domain analysis. All of these approaches use formal logic for representation of ontology specifications. However, the proposed GOM is distinct from others for possessing various significant characteristics, summarised in Tables 6, 7 and 8. This section accomplishes a comparative study of those approaches with proposed GOM to demonstrate the improved performance of GOM.

Table 6 Comparison table based on conceptualisation level features

Approaches Conceptualization Level Feature

(a) (b) (c) (d) (e) (f) (g) (h) (i) (j)

UFO-A(Guizzardi, 2005); UFO-B & UFO-C (Guizzardi et al., 2013)

Y P P – – – Y Y UML CLASS DIAGRAM Y

BFO (Grenon and Smith, 2004) Y P P – – – Y – – –

DOLCE (Gangemi et al., 2002) Y P P – – – Y Y – –

GFO (Herre, 2010) Y Y Y – – P Y Y – –

SUMO (Pease et al., 2002) Y Y - – – – Y P – P

Sowa’s Ontology (Sowa, 2000) Y Y P – – – Y - – –

Cyc Ontology (Matuszek et al., 2006) Y Y Y – – – Y - – P

Proposed GOM Y Y Y Y Y Y Y Y Protégé Visualisation Y


Table 7 Comparison table based on relationships level features

Approaches Relationship Level Feature

(a) (b) (c) (d) (e) (f) (g) (h)

UFO-A (Guizzardi, 2005); UFO-B & UFO-C (Guizzardi et al., 2013)

P – – Y – – – P

BFO (Grenon and Smith, 2004) – – – – – – – –

DOLCE (Gangemi et al., 2002) – – – Y – – – –

GFO (Herre, 2010) P P – – – P – P

SUMO (Pease et al., 2002) Y – P – – – – –

Sowa’s Ontology ( Sowa, 2000) Y P – – P – – –

Cyc Ontology (Matuszek et al., 2006) P P P Y – Y – –

Proposed GOM Y Y Y Y Y Y Y Y

Notes: P: Partially support; Y: Fully support; –: Not Mentioned.

Table 8 Comparison table based on system level features

Approaches System Level Feature

(a) (b) (c) (d) (e) (f) (g) (h)

UFO-A (Guizzardi, 2005); UFO-B & UFO-C (Guizzardi et al., 2013)

Y Y P P Y – – –

BFO (Grenon and Smith, 2004) Y Y P – Y – – –

DOLCE (Gangemi et al., 2002) P P P – Y – – –

GFO (Herre, 2010) Y Y P P Y – – P

SUMO (Pease et al., 2002) Y Y P – Y – – –

Sowa’s Ontology (Sowa, 2000) Y P P P Y – – –

Cyc Ontology (Matuszek et al., 2006) Y P P – Y P – –

Proposed GOM Y Y Y Y Y Y P P

Notes: P: Partially support; Y: Fully support; –: Not Mentioned. 8.1 Conceptualisation level features

Conceptualisation level features refer to the characteristics of various types of conceptualisations. The set of features belonging to this level are

(a) Structural Conceptualisation: This feature is about structural concepts and their relationships with other concepts.

(b) Activity Conceptualisation: This is about activity concepts and their relationships with other concepts.

(c) Event Conceptualisation: It is about various event elements present in the domain and relationships of them with other types of concepts.

(d) Artefact Conceptualisation: This is about various elements that are present from beginning or dynamically produced and useful for precise and unambiguous knowledge procuring about structural, activity and event concepts of the domain.

(e) Flexibility towards software designing methods: Three types of software designing methods are persisting in literature – top-down, bottom-up, and middle-out. With this in mind, ontology driven domain analysis should achieve

sufficient flexibility to provide choices towards designers for these three methods.

(f) Flexibility towards various conceptual perceptions and design concerns: Software designers perceive a domain from different views of conceptualisation and design concerns. With this intention, ontology driven domain analysis should support all types of conceptual and designing perceptions of software designers.

(g)Representation of Axioms: Axioms are logical statements of ontology description which should express the intended meaning of constructs, relationships and constraints on them in an efficient way.

(h) Representation of meta-properties: A top level domain independent ontology should hold distinct meta-properties such as rigidity, unity, identity, dependence in order to inspect significance of it towards lower level.

(i) Visual Representation: Visual representation is a useful way to realise ontology driven specification.

(j) Extendibility: Domain independent ontology description should extend itself in order to represent evolving knowledge.


8.2 Relationship level features

These features are about distinct relationships. The set of features are as follows.

(a)Containment: This feature is about characteristics of part-whole relations.

(b) Interaction: Interaction is the communication between two activity elements sharing messages or events.

(c)Relations with Artefact: This specifies the fact that precise knowledge of entity, activities and events depends on different artefacts.

(d)Inheritance: Inheritance is a relationship that represents reusability of concepts.

(e) Collaboration: Two structural concepts may relate with each other based on some roles.

(f) State Transition: This feature specifies state transition of structural elements.

(g) Dataflow: This is the communication of between two activity elements by passing data.

(h)Inter and intra dependency between different design concerns: Concepts of one design aspect depend on concepts of other design concerns and also of itself.

8.3 System level features

System level features are various characteristics related to a software system and these are

(a) Abstraction: Abstraction exhibits low level complexity in representation of various domain-specific system facets.

(b) Modularity: Modularity refers to the degree to which a system component can separate or recombine.

(c) Domain Appropriateness: This feature states that a domain independent ontology should map towards a large numbers of domains in reality.

(d) Behaviour of various constructs: Behaviour represents the feature of how various concepts of a domain-specific software system can behave with the external environment and each other.

(e) Reusability: This indicates reuse of characteristics of several concepts in other concepts. It also states instantiation of abstract facets of domain independent ontology by subsequent domain and application specific model.

(f) Dynamicity: This recognises dynamic features of a domain. A domain can achieve dynamicity for several issues such as dynamic addition of new knowledge, sequencing in relationships, changes in objectives of end users and change in conceptualisation of designers about domain.

(g)Support towards multiple software paradigms and system architecture: This represents the fact whether the ontology description can map towards multiple software designing paradigms such as object oriented, agent oriented, procedure

oriented, service oriented, and further, software system architectures such as modular, layered, centralised, distributed etc.

(h) Providing tooling and guidelines towards designers: This represents the fact whether they provide suitable tool set and guidelines for helping software designers in domain analysis.

Table 6, 7 and 8 are the comparison tables based on the abovementioned features. Table 6 summarises the fact that existing approaches represent structural design aspects of domain in efficient way. However, they cannot recognise functional and behavioural knowledge in competent way. Further, these approaches cannot represent new type of knowledge and may not in the position for extendable towards representation of evolving domain knowledge. Moreover, majority of approaches are not much flexible to map towards both bottom-up and top-down software design methods and various conceptual perceptions of software designers. Nevertheless, GOM is useful towards representation of structural, functional and behavioural design concerns with a number of conceptualisations.

Proposed GOM is also applicable to represent evolving knowledge partially using Artefact Elements and Inverse Relationships. Artefact Elements may aid GOM to be extendable towards representation of new knowledge. Beside, using Inverse Relationships dynamically inserted knowledge is supported by GOM. However, deriving new domain knowledge from existing knowledge representation is also a kind of evolving knowledge and this can be achieved using a reasoner. At present, GOM has not derived new domain knowledge as there is no binding of devising of a suitable and customised reasoner in this paper. Hence, building of a suitable reasoner for GOM is identified as a prime future work. Thus GOM is capable to resolve the issue specified in Ch.4 partially.

Further, GOM realises conceptual perceptions of individual software designers using world states. Since, one world state may represent conceptual perception of an individual software designer. Besides, it is flexible to map towards both software designing approaches using relationships Has Concepts (HCN), and Inverse of Has Concepts (IHCN), because these two relationships express the links from a composite type to an atomic type and vice-versa.

Table 7 concludes that majority of the approaches do not manifest distinct inter dependencies and also intra dependencies between structural, functional and behavioural module. Table 8 shows that hardly any approaches are capable to represent dynamically inserted knowledge in a domain. However, proposed GOM is pertinent to depict dynamically inserted knowledge using inverse relationships. In addition, GOM provides guidelines for designers to identify domain concepts using proper semantics and syntaxes, although presently GOM does not provide any toolset. But in future it can facilitate designers using proper toolset for identifying, debugging, and automatic validation of domain analysis based on proposed guidelines in this paper. Moreover, as the proposed ontology represents domain


analysis from different design view-points it will be also be applicable to distinct software design paradigms and software systems architectures. However, regarding this issue the detailed semantic specification is not explicitly represented in this paper but is identified as a future work. Thus, GOM has outperformed the existing state of the art works and demonstrated the necessity of devising a new one.

9 Conclusions

This paper proposes ontology driven domain-specific modelling framework for efficient design of domain-specific systems. Proposed framework blends semantics of ontology specification (upper level, middle level and lower level) abstraction mechanism with syntaxes in domain-specific modelling (meta-meta model, meta-model and model) abstraction mechanism. Thus the paper fulfils the deficiency of a systematic methodology in ontology driven domain-specific modelling. In addition, this paper proposes a formal upper level ontology called Generalised Ontology Modelling (GOM) in terms of concepts, relations and axioms for domain independent systems. It provides abstract syntaxes and semantics towards domain dependent systems. The top-most level of the proposed framework uses the semantics of GOM. Further, ontology driven conceptualisation of RIM is derived from GOM and illustrated using a case study in an ontology editing tool Protégé. Moreover, several crucial properties of GOM are proved to show the expressiveness of the proposed ontology.

The benefits of the proposed work are manifold. It provides support towards (1) representation of precise knowledge of domain independent conceptualisation from structural, functional and behavioural design concerns with enriched semantics and syntaxes, (2) realisation of proposed GOM in meta-meta model level, (3) a systematic methodology in ontology driven domain-specific modelling that pave the way of transforming domain analysis from high level abstract models towards concrete implementation of domain-specific systems, (4) providing guidelines for the purpose of mapping from domain independent conceptualisation to application specific conceptualisation, (5) traceability and consistent applicability of high-level abstraction models towards lower level abstractions (6) designers by providing them flexible choices of bottom-up or top-down design methods and (7) designers to design domain-specific systems from different conceptual views. Further, evolving knowledge of domain also can be specified partially using dynamically inserted knowledge through Inverse Relationships and artefact elements through Artefact Conceptualisation. Although, a proper reasoner is necessary for deriving new evolving domain knowledge from the existing knowledge base provided by proposed GOM. However, there is no binding on devising a tailored reasoner for the proposed GOM.

Future work includes building of tools that may facilitate designers for automatic identification of domain-specific and application specific constructs based on the proposed ontology, inconsistency checking, debugging and

automatic validation of domain specifications. Further, devising of an appropriate reasoner for deriving new domain knowledge from current one is another important requirement in future. Moreover, suitable rules generation is also a prime objective for automated matching between different ontology specifications of same domain based on proposed GOM.

References

Abmann, U., Zschaler, S. and Wagner, G. (2006) ‘Ontologies, meta-models, and the model-driven paradigm’, in Calero, C., Ruiz, F. and Piattini, M. (Eds): Ontologies for Software Engineering and Software Technology, Springer, Berlin, Heidelberg, Germany, pp.249–273.

Borgo, S., Carrara, M., Garbacz, P. and Vermaas, P.E. (2009) ‘A formal ontological perspective on the behaviors and functions of technical artifacts’, Artificial Intelligence for Engineering Design, Analysis, and Manufacturing, Vol. 23, No. 1, pp.3–21.

Brossard, A., Abed, M. and Kolski, C. (2011) ‘Taking context into account in conceptual models using a model driven engineering approach’, Information and Software Technology, Vol. 53, No. 12, pp.1349–1369.

Dolin, R.H., Alshuler, L., Beebe, C., Biron, P.V., Boyer, M.S.L., Essin, D., Kimber, E., Lincon, T. and Mattison, J.E. (2006) ‘The HL7 Clinical Document Architecture, Release 2’, Journal of the American Medical Informatics Association, Vol. 8, No. 6, pp.552–569.

France, R. and Rumpe, B. (2007) ‘Model-driven development of complex software: a research roadmap’, Proceedings of the Workshop on the Future of Software Engineering (FOSE), IEEE Computer Society, Washington, DC, USA, pp.37–54.

Fitting, M.C. (2000) ‘Modality and databases’, in Dyckhoff, R. (Ed.): Automated Reasoning with Analytic Tableaux and Related Methods: Proceedings of International Conference, TABLEAUX 2000 (LNCS), Vol. 1847, Springer, Berlin, Germany, pp.19–39.

Fox, M.S., Barbuceanu, M., Gruninger, M. and Lin, J. (1998) ‘An organizational ontology for enterprise modelling’, in Prietula, M.J., Carley, K.M. and Gasser, L. (Eds): Simulating Organizations, MIT Press, Cambridge, MA, pp.131–152.

Gangemi, A., Guarino, N., Masolo, C., Oltramari, A. and Schneider, L. (2002) ‘Sweetening ontologies with DOLCE’, in Gome-Perz, A. and Benjamins, V.R. (Eds): Proceedings of 13th International Conference, Knowledge Engineering and Knowledge Management. Ontologies and the Semantic Web (EKAW) (LNCS), Vol. 2473, Springer, Berlin, Heidelberg, Germany, pp.166–181.

Genesereth, M.R. and Nilsson, N.J. (1987) Logical Foundations of Artificial Intelligence, Morgan Kaufmann Publishers Inc., Los Altos, CA.

Grenon, P. and Smith, B. (2004) ‘SNAP and SPAN: towards dynamic spatial ontology’, Spatial Cognition and Computation, Vol. 4, No. 1, pp.69–104.

Guarino, N. and Welty, C.A. (2009) ‘An overview of OntoClean’, in Staab, S. and Studer, R. (Eds): Handbook on Ontologies, 2nd ed., Springer-Verlag, Berlin Heidelberg, Germany, pp.201–220.

Guarino, N., Oberle, D. and Staab, S. (2009b) ‘What is an Ontology?’ in Staab, S. and Studer, R. (Eds): Handbook on Ontologies, 2nd ed., Springer-Verlag, Berlin Heidelberg, Germany, pp.1–17.


Guizzardi, G. (2005) Ontological foundations for structural conceptual models, PhD Thesis, CTIT, Centre for Telematics and Information Technology, Netherlands.

Guizzardi, G., Herre, H. and Wagner, G. (2002) ‘On the general ontological foundations of conceptual modeling’, in Spaccapietra, S., March, S.T. and Kambayaashi, Y. (Eds): Proceeding of 21st International Conference on Conceptual Modeling Tampere, ER 2002, (LNCS), Vol. 2503, Springer, Berlin Heidelberg, Germany, pp.65–78.

Guizzardi, G., Wagner, G., Falbo, R.D.A., Guizzardi, R.S.S., Paulo, J. and Almeida, A. (2013) ‘Towards ontological foundations for the conceptual modeling of events’, in Ng, W., Storey, V.C. and Trujilo, J.C. (Eds): Proceedings of 32nd International Conference on Conceptual Modeling (ER 2013), (LNCS), Vol. 8217, Springer, Berlin Heidelberg, Germany, pp.327–341.

Happel, H.J. and Seedorf, S. (2006) ‘Applications of ontologies in software engineering’, Paper presented in 2nd International Workshop on Semantic Web Enabled Software Engineering (SWESE 2006), 5th International Semantic Web Conference (ISWC 2006), 6 November, Athens, GA, USA.

Health Level Seven International (2011) Available online at: http://www.hl7.org (accessed on 10 September 2015).

Herre, H. (2010) ‘General Formal Ontology (GFO): a foundational ontology for conceptual modelling’, in Poli, R. and Obrst, L. (Eds): Handbook of Theory and Applications of Ontologies, Vol. 2, Springer, Netherlands, pp.297–345.

HL7 (2011) Health informatics: HL7 version 3 – Reference information model - Release 4, Document: ISO/HL7 21731, Version: 0236 (ANSI/HL7 RIM R4-2011), pp.1–220. Available online at: http://standardsproposals.bsigroup.com/ Home/getPDF/1361 (accessed on 9 September 2015).

Horridge, M. (2011) A Practical Guide to Building OWL Ontologies Using Protégé 4 and COODETools. Edition 1.3, The University of Manchester. Available online at: https://mariaiulianadascalu.files.wordpress.com/2014/02/owl-cs-manchester-ac-uk_eowltutorialp4_v1_3.pdf (accessed on 12 September 2015).

Kleppe, A., Warmer, S. and Bast, W. (2003) MDA Explained: The Model Driven Architecture: Practice and Promise, Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.

Krima, S., Feeney, A.B. and Foufou, S. (2012) ‘Dynamic customization and validation of product data models using semantic web tools’, in Rivest, L., Bouras, A. and Louhichi, B. (Eds): Product Lifecycle Management. Towards Knowledge-Rich Enterprises: IFIP Advances in Information and Communication Technology, Vol. 388, Springer, Berlin, Germany, pp.569–577.

Liu, J., He, K., Li, B. and He, F. (2005) ‘A perspective of fusing ontology and metamodeling architecture in interconnection environment’, Paper presented in International Conference on Semantics, Knowledge and Grid, SKG’05, IEEE, 27–29 November, Beijing, China.

Matuszek, C., Cabral, J., Witbrock, M. and Deoliveria, J. (2006) ‘An introduction to the syntax and content of Cyc’, Proceedings of the 21st National Conference on Artificial Intelligence (AAAI-2006) Spring Symposium on Formalizing and Compiling Background Knowledge and Its Applications to Knowledge Representation and Question Answering, 16–20 July, Boston, Massachusetts, pp.44–49.

Parreiras, F.S., Stabb, S. and Winter, A. (2007) ‘On marrying ontological and metamodeling technical spaces’, Paper presented in 6th Joint Meeting on European Software Engineering Conference, 3–7 September, Dubrovnik, Croatia, pp.439–448.

Pease, A., Niles, I. and Li, J. (2002) ‘The suggested upper merged ontology: a large ontology for the semantic web and its applications’, Paper presented in Working Notes of the 18th National Conference on Artificial Intelligence (AAAI-2002) workshop on ontologies and semantic web, 28 July, Alberta, Canada, Vol. 28.

Raban, R. and Garner, B. (2001) ‘Ontological engineering for conceptual modeling’, Paper presented in ONTO-2001 Workshop on Ontologies, 18 September, Vienna, Austria.

Santos, S., Olavo, L., Guizzardi, G., Pires, L.F. and Sinderen, M.V. (2009) ‘From user goals to service discovery and composition’, in Heuser, C.A. and Pernul, G. (Eds): Advances in Conceptual Modeling – Challenging Perspectives: Proceedings of the ER 2009 Workshops (LNCS), Vol. 5833, Springer, Berlin Heidelberg, Germany, pp.265–274.

Semy, S.K., Pulvermacher, M.K. and Obrst, L.J. (2004) Toward the use of an upper ontology for U.S. government and U.S. military domains: An evaluation, Technical Report MTR-04B0000063 2004, The MITRE Corporation, Bedford, Massachusetts.

Sowa, J.F. (2000) Knowledge Representation: Logical, Philosophical, and Computational Foundations, Brooks Cole Publishing CO., Pacific Grove, CA, USA.

Su, X., Matskin, M. and Rao, J. (2003) ‘Implementing explanation ontology for agent system’, Paper presented in IEEE/ WIC International Conference on Web Intelligence (WI’03), 13–16 October, Halifex, Canada, pp.330–336.

Walter, T., Parrieiras, F.S. and Staab, S. (2014) ‘An ontology-based framework for domain specific modeling’, Software & Systems Modeling, Vol. 13, No. 1, pp.83–108.

Ontology-driven approach towards domain-specific system design … · Ontology-driven approach...

Documents

Transcript of Ontology-driven approach towards domain-specific system design … · Ontology-driven approach...