Reference Ontology for Semantic Service Oriented Architectures_Public_Review_1

1 Reference Ontology for Semantic 3Service Oriented Architectures 4Public Review 1, 5th November 2008 5Artifact Identifier: see-semanticsoaro-pr1 7Location: Current: http://www.oasis-open.org/apps/org/workgroup/semantic-ex/document.php? document_id=27923 10 Previous Version: http://www.oasis-open.org/apps/org/workgroup/semantic11 ex/download.php/29090/Reference%20Ontology%20for%20Semantic%20Service%20Oriented 12 %20Architectures_20080818_RC9.doc 13Artifact Type: 14 semanticsoaro 15Technical Committee: 16 OASIS SEE TC 17Chair(s): 18 John Domingue, Open University, 19 Michal Zaremba, STI, 20Editor(s): 21 Mick Kerrigan, STI, 22 Barry Norton, Open University, 23 Adrian Mocan, STI, 24Contributing Authors: 25 Alessio Carenini, CEFRIEL, 26 Emilia Cimpian, STI, 27 Marc Haines, Individual 28 James Scicluna, STI, 29 Michal Zaremba, STI, 30OASIS Conceptual Model topic area: 31 SOA 32Related work: 33 OASIS Reference Model for Service Oriented Architecture V 1.0 34 Semantic-ex Background and Related Work 35Abstract: 36 This Reference Ontology for Semantic Service Oriented Architectures is an abstract 37 framework for understanding significant entities and relationships between them 38 within a Semantically-enabled Service-Oriented environment It may be leveraged for 39 the development of related standards or specifications supporting that environment, 40 as well as guiding efforts to realize concrete solutions 1see-semanticsoaro-pr1 3Copyright © OASIS Open 2008 All Rights Reserved November 2008 Page of 38 41 This Reference Ontology builds on the OASIS Reference Model for Service Oriented 42 Architecture (SOA-RM) and combines it with the key concepts of semantics that are 43 relevant for Semantically-enabling Service Oriented Architectures 44 A reference model is not directly tied to any standards, technologies or other 45 concrete implementation details It does seek to provide a common understanding 46 that can be used unambiguously across and between different implementations The 47 relationship between this Reference Ontology, the SOA Reference Model, and 48 particular architectures, technologies and other aspects of SOA is illustrated in Figure 49 50 Just as the SOA-RM, this reference ontology focuses on the field of software 51 architecture The concepts and relationships described may apply to other "service" 52 environments; however, this specification makes no attempt to completely account 53 for use outside of the software domain 54Status: 55 This document is currently a working draft and will be update as necessary to bring it up to public 56 review draft status in the coming weeks/months Please send all comments to the editors 57 58 59 60 Technical Committee members should send comments on this specification to the Technical Committee’s email list Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at www.oasisopen.org/committees/semantic-ex 6see-semanticsoaro-pr1 8Copyright © OASIS Open 2008 All Rights Reserved November 2008 Page of 38 61Notices 62Copyright â OASISđ 2007 All Rights Reserved 63All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual 64Property Rights Policy (the "OASIS IPR Policy") The full Policy may be found at the OASIS website 65This document and translations of it may be copied and furnished to others, and derivative works that 66comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, 67and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice 68and this section are included on all such copies and derivative works However, this document itself may 69not be modified in any way, including by removing the copyright notice or references to OASIS, except as 70needed for the purpose of developing any document or deliverable produced by an OASIS Technical 71Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be 72followed) or as required to translate it into languages other than English 73The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors 74or assigns 75This document and the information contained herein is provided on an "AS IS" basis and OASIS 76DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 77WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 78OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 79PARTICULAR PURPOSE 80OASIS requests that any OASIS Party or any other party that believes it has patent claims that would 81necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, 82to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to 83such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that 84produced this specification 85OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of 86any patent claims that would necessarily be infringed by implementations of this specification by a patent 87holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR 88Mode of the OASIS Technical Committee that produced this specification OASIS may include such 89claims on its website, but disclaims any obligation to so 90OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 91might be claimed to pertain to the implementation or use of the technology described in this document or 92the extent to which any license under such rights might or might not be available; neither does it represent 93that it has made any effort to identify any such rights Information on OASIS' procedures with respect to 94rights in any document or deliverable produced by an OASIS Technical Committee can be found on the 95OASIS website Copies of claims of rights made available for publication and any assurances of licenses 96to be made available, or the result of an attempt made to obtain a general license or permission for the 97use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS 98Standard, can be obtained from the OASIS TC Administrator OASIS makes no representation that any 99information or list of intellectual property rights will at any time be complete, or that any claims in such list 100are, in fact, Essential Claims 101The names "OASIS", [insert specific trademarked names and abbreviations here] are trademarks of 102OASIS, the owner and developer of this specification, and should be used only to refer to the organization 103and its official outputs OASIS welcomes reference to, and implementation and use of, specifications, 104while reserving the right to enforce its marks against misleading uses Please see http://www.oasis105open.org/who/trademark.php for above guidance 11see-semanticsoaro-pr1 12 13Copyright © OASIS Open 2008 All Rights Reserved 14 November 2008 Page of 38 106Table of Contents 1071 Introduction .5 108 1.1 Motivation and Scope 109 1.2 Audience .6 110 1.3 Guide to this Document .7 111 1.4 Notational Conventions 112 1.4.1 Concept Maps .7 113 1.4.2 Ontologies .8 114 Concepts .8 115 Subsumption .9 116 Attributes .9 1172 Semantics and SOA .11 118 2.1 Semantics 11 119 2.2 Applying Semantics to SOA .12 1203 Overview of SOA-RM .13 121 3.1 What is a service? 13 122 3.2 Dynamics of Services 13 123 3.3 Service Related Concepts 15 1244 Reference Ontology for Semantic Service Oriented Architectures 18 125 4.1 Visibility .19 126 4.1.1 Ontologies 19 127 4.1.2 Concepts .20 128 4.1.3 Instances .20 129 4.1.4 Axioms and Logical Expressions .20 130 4.2 Service Description 20 131 4.3 Goal Description 20 132 4.4 Capability Description 21 133 4.4.1 Functionality 21 134 4.4.2 Real World Effect 21 135 4.5 Interface 22 136 4.5.1 Information Model .22 137 4.5.2 Behavioral Model 23 138 4.6 Mediation 24 139 4.7 Complete Reference Ontology 25 1405 References .27 141A Glossary 28 142B WSML Formalization of Reference Ontology 31 143C Acknowledgements 34 144D Revision History 35 145 146 16see-semanticsoaro-pr1 17 18Copyright © OASIS Open 2008 All Rights Reserved 19 November 2008 Page of 38 1471 Introduction 148Although Service Oriented Architectures (SOAs) have gathered a lot of attention within business 149organizations, for a long time there was no clear understanding of what an SOA precisely is As a result 150reference models have been published to define SOA; we note particularly the OASIS SOA Reference 151Model [1] However, with the emergence of Semantic Web technologies, in particular Semantic Web 152Services (SWSs), new breeds of SOAs are being developed, namely Semantic Service Oriented 153Architectures (SSOAs) SSOAs use semantic technologies to advance solutions to problems by which 154SOAs are limited They provide a means for further automation for service consumers’ tasks, particularly 155service discovery, selection, composition and execution, as well as easing general interoperability issues 156between services 157In order to use the semantic descriptions present in a SSOA to automate such SOA features, a set of 158platform services that provide this automation functionality are required within the SSOA These services 159are collectively termed a Semantic Execution Environment (SEE) for Semantic Web Services, with a 160SEE being at the core of a SSOA There are a number of different implementations of SEEs currently 161under development in the research community, which have some common features Thus the purpose of 162this document is to define an extended reference model for SSOAs, as supported by SEEs This model 163will be defined formally using an ontology The aim of this ontology is to provide a point of reference 164formally specified so that it can support the definition and development of SSOAs 165 166 167 Figure Introduction- – Relationship of the Reference Ontology to Other SOA Specifications and Standards 168Figure Introduction-1 depicts how the Reference Ontology relates to other pieces of work within the SOA 169community The figure is derived from Figure in the SOA Reference Model document [1] and introduces 170the Reference Ontology alongside the Reference Model element The Reference Ontology presented in 171this document is a further step towards formalization of the Reference Model but also accommodates the 172extensions associated with Semantic Web Services resulting in Semantic SOAs Since the start of this 173work, the SOA-RM committee have also started work on a Reference Architecture, which also aims at 174further formalisation of the reference model, but we consider ontologisation central to the semantics175based approach and diverge Indeed when we say Reference Architecture we shall refer to a reference 21see-semanticsoaro-pr1 22 23Copyright © OASIS Open 2008 All Rights Reserved 24 November 2008 Page of 38 176architecture for SEEs, not to the SOA Reference Architecture Furthermore when we say Concrete 177Architectures we refer to implementations of semantics-enabled SOAs such as WSMX [2] , IRS III [3] and 178METEOR-S [4] 179The Related Models in Figure include, for us, the Web Service Modeling Ontology (WSMO) [5] , 180Semantic Annotations for WSDL and XML Schema (SAWSDL) [8] the Web Ontology Language for 181Services (OWL-S)1 [9] and the Semantic Web Services Ontology (SWSO) [10] Patterns fulfill the same 182role in Semantic- as in pre-Semantic- SOA, which is to say that they define more specific categories of 183service-oriented designs The Protocols and Profiles (those considered as part of the related work) are 184the same as for classical SOAs However, with respect to Specifications and Standards, we further take 185into account emerging Semantic Web Languages such as the OWL, RDF and RIF standards from W3C, 186and the WSML and SWSL de facto standards These “standards” play a very important role since they are 187the pillars of Semantic Technologies The Input features (Requirements, Motivation and Goals) are the 188same as for SOAs, with the addition that we have more emphasis on automation, as stated earlier 189Motivation and Scope 190With the term “Semantic” we mean the formal (and thus unambiguous) description of some particular 191object (more in section 2), which is subject to automated ontology-based reasoning Within the context of 192the Reference Ontology, these objects are mainly the data handled by the services and the services 193themselves Semantic descriptions within SOAs allow reasoning tools to automate tasks More 194specifically, semantics help in the following ways: 195  196 197 198   199 200  Formally and unambiguously define the data models and processes underlying the system; Allow automated discovery and composition of services; Automatically resolve data and process mismatches, easing integration and improving interoperability; Ease the process of service ranking, negotiation and contracting 201The scope of this document is therefore to provide an ontology that formally describes the different 202elements comprising a SSOA in order to achieve the above objectives 203Audience 204The target audience for this document extends that of the SOA RM; however we provide an exhaustive 205list in order to keep the document self-contained: 206 207  Architects and developers designing, identifying or developing a system based on the 208 Service Oriented Architectures; 209  Standards architects and analysts developing specifications that rely on Service 210 Oriented Architecture concepts; 211  Decision makers seeking a "consistent and common" understanding of Service 212 Oriented Architectures; 213  Users who need a better understanding of the concepts and benefits of Service 214 Oriented Architectures; 215  Academics and researchers that are researching within the Semantic Web and 216 Semantic Web Service communities; 217  I.T consultants that provide businesses with support on Semantic technologies and 218 SOAs in general 261 It may be noted that no unified Semantic Execution Environments exist for OWL-S; a list of the major, 27but separate, OWL-S tools is available as http://www.daml.org/services/owl-s/tools.html, which includes 28the OWL-S VM 29see-semanticsoaro-pr1 30 31Copyright © OASIS Open 2008 All Rights Reserved 32 November 2008 Page of 38 219Guide to this Document 220It is assumed that readers who are not familiar with SOA concepts and terminologies read first the SOA 221Reference Model [1] document since this document builds on top of its concepts Furthermore, readers 222who are new to the concept of Semantic Technologies are encouraged to read this document in its 223entirety 224Section introduces the Semantic SOA Reference Ontology and how it relates to other work (in particular 225the SOA RM) It defines the audience and also provides a description of the notational conventions used 226in this document Both of these elements are important in order for the reader to understand the content 227of the rest of the document 228Section provides an overview of Semantics and how they interrelate with SOAs It starts by describing 229the deficiencies of the classical SOA and the problems in building them It then continues with examples 230and situations of how Semantic Technologies can help to overcome these deficiencies Section 231strengthens the motivations and objectives already described in this section 232Section describes the SOA Reference Model [1] and builds on top of this by introducing new key 233concepts required for SSOAs It first describes what we understand by a service followed by the dynamics 234of a service – how the service is perceived by the real world Other related concepts are also described 235(including, for example, the behavior of the Web service) Section shows the differences between the 236classical SOA RM and the SSOA RM and provides the necessary building blocks for specifying the 237Reference Ontology 238Section defines the Reference Ontology for SSOAs The ontology is first described using Concept Maps 239and UML Diagrams (notation described in Section below) It is then formally described using WSML [7] in 240Appendix as explained in Section 241The glossary provides definitions of terms that are relied upon within the document Terms that are 242defined in the glossary are marked in bold at their first occurrence in the document 243Note that while the concepts and relationships described in this document may apply to other “service” 244environments, the definitions and descriptions contained herein focus on the field of software 245architectures and make no attempt to completely account for their use outside of the software domain 246Examples included in this document, which are taken from a variety of domains, are used strictly for 247illustrative purposes 248Notational Conventions 249Throughout this document we use both Concept Map and UML Class Diagram notations to illustrate 250models, this is due to the derivation from – and preservation of links to – the SOA RM specification, which 251uses the former, together with the need to provide an accessible representation of the ontology-based 252model For clarity these two notations are distinguished in the caption of the figures throughout the 253document; figures whose caption end with [Concept Map] conform to the Concept Map notation, while 254figures whose caption end with [UML] conform to the representation of ontologies in the UML Class 255Diagram notation, as described below This document does not use the notation from RFC2119 [6] , for 256example MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, 257RECOMMENDED, MAY, and OPTIONAL as cardinality constraints are present within the UML diagrams 258Concept Maps 259The Concept Map notation used in this document is the same as for that in the SOA RM; however we give 260a brief description here to keep the document self-contained 261There is no normative convention for interpreting Concept Maps and other than described in this section, 262no detailed information can be derived from the Concept Maps 263 34see-semanticsoaro-pr1 35 36Copyright © OASIS Open 2008 All Rights Reserved 37 November 2008 Page of 38 264 Figure Introduction-2 - A basic Concept Map [Concept Map] 265 266As used in this document, a line between two concepts represents a relationship whereby the relationship 267is not labeled but rather is described in the text immediately preceding or following the figure The arrow 268on a line indicates an asymmetrical relationship, where the concept to which the arrow points can be 269interpreted as depending in some way on the concept from which the line originates The text 270accompanying each figure describes the nature of each relationship 271Ontologies 272Within this document we use UML Class Diagrams to illustrate the Reference Ontology; the underlying 273formal definitions are made in WSML This is for two reasons: first, we must use a language with well274founded semantics, capable of machine reasoning – the general motivation of work in the Semantic Web 275that has produced several ontology languages For this purpose we could equally use OWL or (to a more 276limited degree) RDFS for the definitions Secondly, for the purposes of the SEE Reference Architecture, 277we need a language that allows us to attach elements of this model to SWS elements, including goals 278and mediators, and WSML is the only language that allows this 279This document sticks to the ontology definition facilities of WSML and does not define (meta-) service 280objects, and hence the Reference Ontology itself could be defined using OWL The Reference 281Architecture will attach Reference Ontology concepts to goal descriptions to allow the characterization of 282the components of a Semantic Execution Environment (the core services of a SSOA) The Execution 283Scenarios will attach Reference Ontology concepts, and Reference Architecture goals, to service 284descriptions to illustrate how the SEE components can work together to achieve common tasks Finally, 285concrete architectures may be defined by linking concrete services to the goals from the Reference 286Architecture For this reason, and due to the deficiency of the OWL-S and other service models, the 287Reference Architecture must be defined in WSML and it is therefore easiest to define the Reference 288Ontology in which it is based on the same language 289In the remainder of this section we sketch the relationship between UML Class Diagrams, as used within 290the text, to WSML descriptions In the following section we reproduce these definitions 291Concepts 292The fundamental feature of Class Diagrams – and indeed Object-oriented design (OOD), which is the real 293target of UML – are classes, which are shown as square boxes with their identifier listed inside We use 294UML classes to represent WSML concepts Where the namespace into which concepts are defined is 295clear, we allow ourselves to omit this information in the Class Diagram Where different namespaces are 296used, we use the notation for packages to make the namespace clear 297Figure Introduction-3 hence corresponds with Listing 298 299 300 301 302 concept A concept _”http://www.example.com/ontologies/ns1#B” Listing 1: Example Concepts in WSML 303 39see-semanticsoaro-pr1 40 41Copyright © OASIS Open 2008 All Rights Reserved 42 November 2008 Page of 38 A http://www.example.org/ontologies/ns1# B 304 305 Figure Introduction-3: Representation of WSML Example Concepts in UML Class Diagram [UML] 306 307While UML Class Diagrams allow the definition of operations and attributes within classes, we choose not 308to use these and always show classes with an undivided box Regarding the representation of attributes 309of WSML concepts, see below 310Subsumption 311The fundamental relationship between concepts in WSML, as with many ontology languages, is 312subsumption This is represented by inheritance in UML Class Diagrams Since we declare no operations 313there are thus no unwanted side-effects due to UML/OOD semantics; in particular there are no 314complications in the use of multiple parents for a given concept 315Figure Introduction-4 hence corresponds with Listing 316 317 318 319 320 321 322 323 concept A concept B subConceptOf A concept C concept D subConceptOf {A, C} Listing 2: Example of Subsumption between Concepts in WSML 324 325 A C B D 326 327 Figure Introduction-4: Representation of Subsumption Example in UML Class Diagram [UML] 328Attributes 329The other explicit relationship between concepts in WSML is via attributes These are represented by 330(directed) associations in UML Class Diagrams, which is to say associations with a one-way navigability, 331so that the innavigable side of the association (or, more correctly, the end of unspecified navigability) is 332the concept whose definition includes the attribute, and the other side the attribute range The name of 333the association will be the name of the attribute; where the attribute name is the default ‘hasE’, where ‘E’ 44see-semanticsoaro-pr1 45 46Copyright © OASIS Open 2008 All Rights Reserved 47 November 2008 Page of 38 334is the name of the concept that is the attribute range, we shall often omit this Cardinality constraints – 335i.e., restrictions on the number of values the attribute may take for any given instance – are represented, 336where possible, by a constraint on the association Figure Introduction-5 hence corresponds with Listing 3373 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 concept E concept F hasE ofType (0 1) E concept G hasEorF ofType EorF concept EorF axiom anEisEorF definedBy ?e memberOf E implies ?e memberOf EorF axiom anFisEorF definedBy ?f memberOf F implies ?f memberOf EorF Listing 3: Example of Attributes between WSML Concepts 358 E EorF hasE F hasEorF G 359 360 Figure Introduction-5: Representation of Attributes Example in UML Class Diagram [UML] 361We also make use of disjunctive attribute ranges by way of an intentionally-defined union class, as shown 362by hasEorH of concept G 49see-semanticsoaro-pr1 50 51Copyright © OASIS Open 2008 All Rights Reserved 52 November 2008 Page 10 of 38 714In the Semantic SOA Reference Ontology the semantic part of information model is based on 715an ontological description, but this needs to be considered both by the capability and the 716interface, so this is attached directly to the service (or goal) description, as described in 717Section The structural part of the information model needs to be considered only by the 718communicated information and therefore is represented, via groundings to a schema 719representation of the appropriate semantic concepts, in the action model, as described in ServiceDescription GoalDescription Interface 1 Orchestration Choreography BehavioralModel ActionModel out in ProcessModel shared Communicable 720 721 -grounding : _iri Figure Reference Ontology for Semantic Service Oriented Architectures- 17 - The Structure of an Interface [UML] 722For the Semantic SOA Reference Ontology, the notion of behavioural model is specialised 723into two different concepts, representing different perspectives: 724  Service requester perspective - the information that is needed for service execution by the service 725 requester, specified as Choreography; 726  Communication with other services – information on how the service can coordinate the 727 cooperation between other services in order to fulfill its functionality, specified as the 728 Orchestration 729Information Model 730”The information model of a service is a characterization of the information that may be 731exchanged with the service” As previously described, for Semantic SOA this information is 732provided by the domain ontology of the service; this ontology specifies all the information 733needed for the service execution and for its communication with other services or with the 734requestors 120see-semanticsoaro-pr1 121 122Copyright © OASIS Open 2008 All Rights Reserved 123 November 2008 Page 24 of 38 imports imports Ontology imports imports ServiceDescription Mediator GoalDescription 735 736 737 Figure Reference Ontology for Semantic Service Oriented Architectures- 18 Ontologies as Semantic Information Model [UML] 738Semantics 739The parties involved in a communication need to have a common understanding of the semantic of the 740exchanged messages When the parties use ontologies for describing their information model, this 741common understanding implies either a previous agreement regarding what ontologies are used, or the 742existence of a mediator for solving any heterogeneity problems This will ensure a high degree of 743automation for the communication 744Structure 745As described above, some of the concepts (and relations) from the Semantic Information Model will 746actually be communicated by the service The structural definition of these components will be 747represented by the groundings in the Action Model, described in Section 748Behavioral Model 749The SOA RM defines the Behavioral Model as “knowledge of the actions invoked against the 750service and the process or temporal aspects of interacting with the service” For Semantic 751SOA this knowledge is encapsulated by the definition of what information needs to be exchanged 752during the communication, the concepts and relations of an ontology being marked to support a particular 753role (or mode) Furthermore, the order in which the messages are exchanged needs to be unambiguously 754specified 755Action Model 756For specifying what information needs to be exchanged during the communication the concepts and 757relations of an ontology are marked to support a particular role (or mode) There are five modes defined in 758the state signature: 759 760   761 762  763 764  765 766  static - meaning that the extension of the concept cannot be changed; in - meaning that the extension of the concept or relation can only be changed by the environment and read by the service; out - meaning that the extension of the concept or relation can only be changed by the service and read by the environment; shared - meaning that the extension of the concept or relation can be changed and read by the service and the environment; controlled - meaning that the extension of the concept is changed and read only by the service 125see-semanticsoaro-pr1 126 127Copyright © OASIS Open 2008 All Rights Reserved 128 November 2008 Page 25 of 38 767Process Model 768For using the modes defined in the state signature a grounding mechanism needs to be provided for 769allowing the environment (i.e the communication partner) to read or to write information in the services 770ontology For each mode except static and controlled, a different grounding mechanism needs to be 771provided as follows: 772 773 774   775 776 777  in - a grounding mechanism for the in items, that implements write access for the environment, must be provided; out - a grounding mechanism for the out items, that implements read access for the environment, must be provided; shared - a grounding mechanism for the shared items, that implements read/write access for the environment and the service, must be provided 778For the static and controlled items a grounding mechanism is not needed, as these items can either be 779changed only by the service or remain unchanged for the duration of the communication 780The Semantic SOA Reference Ontology is not prescriptive about what form the behavioural description 781should take, except that it should take account of these modes These rules could, for instance, be 782specified using the Abstract State Machine methodology, each rule evaluating some conditions on the 783current state of the service, and prescribing what activities should be performed if the conditions are 784fulfilled 785Mediation 786SOA RM defines Visibility as "the relationship between service consumers and providers that is satisfied 787when they are able to interact with each other" Visibility itself subsists in the publication of Service and 788Goal Descriptions, but a prerequisite of Visibility is represented by Reachability, and when two entities are 789aware of each other and willing to interact in order to fulfill a need, heterogeneity can be a barrier that 790prevents this prerequisite to be fulfilled Given two heterogeneous entities, mediation enables 791Reachability by resolving mismatches between them 792A mediator is described in terms of the entities it is able to connect and states how it will resolve 793mismatches Ontology to Ontology mediators (OO-Mediators) connect ontologies and resolve 794terminological and representational mismatches, Service Description to Service Description mediators 795(SS-Mediators) connect service descriptions resolving mismatches between the representation of their 796functionality and/or in the means by which they are accessed (i.e., between their capabilities and/or 797interfaces), Goal Description to Goal Description mediators (GG-Mediators) connect Goal descriptions 798resolving mismatches in the requirements of the service requestor, again either in capability or interface 799terms, and Service Description to Goal Description (SG-Mediators) connect Service descriptions and goal 800descriptions, mediating between the consumer’s and provider’s viewpoint of the functionality and/or its 801access By using a Mediation Service, a Mediator explicitly describes the link to a concrete solution to 802perform mediation This mechanism allows Mediators to be used to describe pieces of functionality 803offered by complex services that are able to perform concrete mediation scenarios A mediation service 804can either be a Goal or a Service Description The former links to a Goal that is to be used in the 805discovery process to find a Service offering the functionality described by the Mediator, while the latter 806directly links to a Service that is able to offer the functionality described by the Mediator 807By publishing the description of the Mediator and all its needed Ontologies, Goal and Service 808Descriptions, the requirements for Visibility are met, thus allowing a Goal to interact with the Service 130see-semanticsoaro-pr1 131 132Copyright © OASIS Open 2008 All Rights Reserved 133 November 2008 Page 26 of 38 imports Ontology imports imports uses hasSource imports OOMediator hasMediationService ServiceDescription hasMediationService Mediator uses {hasSource, hasTarget} {hasSource, hasTarget} SSMediator {hasSource, hasTarget} GoalDescription GGMediator SGMediator {hasSource, hasTarget} 809 810 811 Figure Reference Ontology for Semantic Service Oriented Architectures- 19 – Mediators and their Connection of other RO Concepts [UML] 812Complete Reference Ontology 813In Figure Reference Ontology for Semantic Service Oriented Architectures-20 shows complete UML 814diagram for the Reference Ontology, which combines all the information from Figure Reference Ontology 815for Semantic Service Oriented Architectures-13 to Figure Reference Ontology for Semantic Service 816Oriented Architectures-19 The formalization of this ontology in WSML is presented in Appendix B 135see-semanticsoaro-pr1 136 137Copyright © OASIS Open 2008 All Rights Reserved 138 November 2008 Page 27 of 38 memberOf Attribute Parameter Concept memberOf Relation Value Instance Axiom -definedBy : LogicalExpression imports Ontology imports hasSource imports OOMediator hasMediationService ServiceDescription imports uses hasMediationService Mediator GoalDescription uses {hasSource, hasTarget} SSMediator GGMediator {hasSource, hasTarget} SGMediator CapabilityDescription -assumption : LogicalExpression -precondition : LogicalExpression -postcondition : LogicalExpression -effect : LogicalExpression Interface Orchestration 1 Choreography BehavioralModel ActionModel in out ProcessModel shared Communicable 817 -grounding : _iri 140see-semanticsoaro-pr1 141 142Copyright © OASIS Open 2008 All Rights Reserved 143 November 2008 Page 28 of 38 818 819 Figure Reference Ontology for Semantic Service Oriented Architectures- 20 - The Complete Reference Ontology [UML] 145see-semanticsoaro-pr1 146 147Copyright © OASIS Open 2008 All Rights Reserved 148 November 2008 Page 29 of 38 8205 References 821[1] C M MacKenzie, K Laskey, F McCabe, P F Brown, R Metz (eds.): Reference Model for Service 822 Oriented Architecture 1.0, OASIS SOA-RM Technical Committee Specification, August, 2006, 823 available at: http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf 824[2] A Haller, E Cimpian, A Mocan, E Oren, C Bussler: WSMX: A Semantic Service-Oriented 825 Architecture In Proceedings of the International Conference on Web Services (ICWS 2005), 826 Orlando, Florida 827[3] J Domingue, L Cabral, S Galizia, V Tanasescu, A Gugliotta, B Norton, and C Pedrinaci IRS-III: A 828 broker-based Approach to Semantic Web Services, Journal of Web Semantics, 6, 2, pp 109-132, 829 Elsevier, 2008 830[4] World Wide Web, 6(2):109–132, 2008.K Verma, K Gomadam, A.P Sheth, J.A Miller, Z Wu: The 831 METEOR-S Approach for Configuring and Executing dynamic Web Processes LSDIS Technical 832 Report, 24 June, 2005, available at: http://lsdis.cs.uga.edu/projects/meteor-s/techRep6-24-05.pdf 833[5] J de Bruijn, C Bussler, J Domingue, D Fensel, M Hepp, M Kifer, B König-Ries, J Kopecky, R 834 Lara, E Oren, A Polleres, J Scicluna, M Stollberg: The Web Service Modeling Ontology WSMO 835 Forschungsinstitut at the University of Innsbruck Technical Report, 16 February 2007, available at: 836 http://www.wsmo.org/TR/d2/v1.4/ 837[6] S Bradner, RFC2119 – Keywords 838 http://www.rfc.net/rfc2119.html for use in RFCs to indicate Requirement Levels, 839[7] H Lausen and J de Bruijn, A Polleres and D Fensel, WSML – A Language Framework for Semantic 840 Web Services, Proceedings of the W3C workshop on Rule Languages for Interoperability, April 841 2005 842[8] J Farrell, H Lausen: Semantic Annotations for WSDL and XML Schema W3C Recommendation, 28 843 August 2007, available at: http://www.w3.org/TR/sawsdl/ 844[9] D Martin, M Burstein, J Hobbs, O Lassila, D McDermott, S McIlraith, S Narayanan, M Paolucci, 845 B Parsia, T Payne, E Sirinin, N Srinivasan, K Sycara: OWL-S: Semantic Markup for Web 846 Services DARPA DAML Program Technical Report, available at: 847 http://www.ai.sri.com/daml/services/owl-s/1.2/overview/ 848[10] 849 850 S Battle, A Bernstein, H Boley, B Grosof, G Kruninger, R Hull, M Kifer, D Martin, S McIlraith, D McGuinness, J Su, S Tabet: Semantic Web Services Ontology (SWSO) DARPA DAML Program Technical Report, May 2005, available at: http://www.daml.org/services/swsf/1.0/swso/ 851[11] 852 D Fensel, M Kerrigan, M Zaremba (eds.): Implementing Semantic Web Services - The SESA Framework, (Springer), 2008 150see-semanticsoaro-pr1 151 152Copyright © OASIS Open 2008 All Rights Reserved 153 November 2008 Page 30 of 38 853A Glossary 854This section extends the terminology described in Glossary (Appendix A) of the “Reference Model for 855Service Oriented Architecture, Public Review Draft 1.0” and introduces any new terms needed by the 856Semantic SOA Reference The two glossaries are intended to be used together, therefore terms from the 857other glossary will not be repeated here 858 859Goal Description-to-Goal Description Mediator (GG-Mediator) 860 861 Connects Goal descriptions resolving mismatches in the requirements of the service requestor in terms of the requested functionality and/or in the means by which they wish to access the service 862 863Internet Reasoning Service (IRS III) 864 865 A framework and infrastructure that supports the creation of Semantic Web Services according to the WSMO ontology 866 867Managing End-To-End OpeRations for Semantic Web Services and Processes (METEOR-S) 868 869 Project that aims to extend Web service –related standards with Semantic Web technologies to achieve greater dynamism and scalability for Service-oriented Architectures 870 871Object-oriented Design (OOD) 872 873 Object-oriented design is part of OO methodology and it forces programmers to think in terms of objects, rather than procedures, when they plan their code 874 875Ontology-to-Ontology Mediator (OO-Mediator) 876 Connects ontology and resolves terminology as well as representation or protocol mismatches 877 878Resource Description Framework (RDF) 879 880 881 Resource Description Framework (RDF) is a family of World Wide Web Consortium (W3C) specifications originally designed as a metadata model but which has come to be used as a general method of modeling information, through a variety of syntax formats 882 883Rule Interchange Format (RIF) 884 885 886 The Rule Interchange Format (RIF) is a W3C recommendation-track effort to develop a format for interchange of rules in rule-based systems on the semantic web The goal is to create an interchange format for different rule languages and inference engines 887 888Semantic Annotations for WSDL (SAWSDL) 889 890 The Semantic Annotations for WSDL and XML Schema (SAWSDL) W3C Recommendation defines mechanisms using which semantic annotations can be added to WSDL components 891 892Semantic Execution Environment (SEE) 893 894 Execution environment capable to consume semantic messages, discover semantically described Web services, and invoke and compose them for the end-user benefit 155see-semanticsoaro-pr1 156 157Copyright © OASIS Open 2008 All Rights Reserved 158 November 2008 Page 31 of 38 895 896Semantic Web 897 898 899 The Semantic Web is an evolving extension of the World Wide Web in which the semantics of information and services on the web is defined, making it possible for the web to understand and satisfy the requests of people and machines to use the web content [cite: Wikipedia] 900 901Semantic Service Oriented Architecture (SSOA) 902 903 904 905 906 A Semantic Service Oriented Architecture (SSOA) is a computer architecture that allows for scalable and controlled Enterprise Application Integration solutions SSOA describes a sophisticated approach to enterprise scale IT infrastructure It leverages rich, machineinterpretable descriptions of data, services, and processes to enable software agents to autonomously interact to perform critical mission functions [cite: Wikipedia] 907 908Semantic Web Services (SWS) 909 910 911 912 Semantic Web Services are self-contained, self-describing, semantically marked-up software resources that can be published, discovered, composed and executed across the Web in a task driven semi-automatic way Semantic Web Services can be defined as the dynamic part of the semantic web 913 914Semantic Web Service Ontology (SWSO) 915 916 917 An ontology for Semantic Web Services, which is expressed in two forms: FLOWS, the First-order Logic Ontology for Web services; and ROWS, the Rules Ontology for Web services, produced by a systematic translation of FLOWS axioms into the SWSL-Rules language 918 919Service-oriented Architecture (SOA) 920 Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed 128 921 capabilities that may be under the control of different ownership domains 922 923Unified Modeling Language (UML) 924 925 926 The Unified Modeling Language (UML) is a standardized visual specification language for object modeling UML is a general-purpose modeling language that includes a graphical notation used to create an abstract model of a system, referred to as a UML model 927 928Web Ontology Language for Services (OWL-S) 929 930 OWL-S is an ontology built on top of Web Ontology Language (OWL) by the DARPA DAML program It replaces the former DAML-S ontology 931 932Web Service Description Language (WSDL) 933 934 The Web Services Description Language is an XML-based language that provides a model for describing Web services 935 936Service Description-to-Goal Description Mediator (WG-Mediator) 937 938 Connects service descriptions and goal descriptions, mediating between the consumer’s and provider’s viewpoint of the functionality and/or its access 939 160see-semanticsoaro-pr1 161 162Copyright © OASIS Open 2008 All Rights Reserved 163 November 2008 Page 32 of 38 940Service Description-to-Service Description Mediator (WW-Mediator) 941 942 Connects service descriptions resolving mismatches between the representation of their functionality and/or in the means by which they are accessed 943 944Web Service Modeling eXecution environment (WSMX) 945 946 947 An execution environment for business application integration where enhanced Web services are integrated for various business applications It is the reference implementation of WSMO (Web Service Modeling Ontology) 948 949Web Service Modeling Language (WSML) 950 A language that formalizes the Web Service Modeling Ontology (WSMO) 951 952Web Service Modeling Ontology (WSMO) 953 954 WSMO or Web Service Modeling Ontology is an ontology currently developed to support the deployment and interoperability of Semantic Web Services 165see-semanticsoaro-pr1 166 167Copyright © OASIS Open 2008 All Rights Reserved 168 November 2008 Page 33 of 38 955B WSML Formalization of Reference Ontology 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 wsmlVariant _"http://www.wsmo.org/wsml/wsml-syntax/wsml-flight" namespace { _"http://www.semantic-soa.org/ReferenceOntology#", dc _"http://purl.org/dc/elements/1.1/" } ontology _"http://www.semantic-soa.org/ReferenceOntology#" concept Ontology imports ofType Ontology hasConcept ofType Concept hasRelation ofType Relation hasInstance ofType Instance hasAxiom ofType Axiom uses ofType OOMediator concept Concept has Attribute ofType ConceptOrRelation concept ConceptOrRelation nfp dc#relation hasValue { aConcept, aRelation} endnfp axiom aConcept definedBy ?x memberOf Concept implies ?x memberOf ConceptOrRelation axiom aRelation definedBy ?x memberOf Relation implies ?x memberOf ConceptOrRelation concept Instance memberOf hasValue ConceptOrRelation hasValue hasValue Instance concept Axiom hasLogicalExpression ofType _"http://www.wsmo.org/wsml/wsmlsyntax#logicalExpression" concept ServiceDescription imports ofType Ontology offersCapability ofType (0 1) Capability hasInterface ofType Interface concept GoalDescription imports ofType Ontology requiresCapability ofType (0 1) Capability 170see-semanticsoaro-pr1 171 172Copyright © OASIS Open 2008 All Rights Reserved 173 November 2008 Page 34 of 38 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 hasInterface ofType Interface concept Capability hasPrecondition ofType _"http://www.wsmo.org/wsml/wsmlsyntax#logicalExpression" hasAssumption ofType _"http://www.wsmo.org/wsml/wsmlsyntax#logicalExpression" hasPostcondition ofType _"http://www.wsmo.org/wsml/wsmlsyntax#logicalExpression" hasEffect ofType _"http://www.wsmo.org/wsml/wsmlsyntax#logicalExpression" concept Interface hasChoreography ofType (0 1) Choreography hasOrchestration ofType (0 1) Orchestration concept Choreography subConceptOf BehaviourModel concept Orchestration subConceptOf BehaviourModel concept BehaviourModel hasActionModel ofType (1) ActionModel hasProcessModel ofType (0 1) ProcessModel concept ActionModel hasInAction ofType (1) Communicable hasOutAction ofType (1) Communicable hasSharedAction ofType (1) Communicable concept Communicable grounding ofType (0 1) _iri concept MediationService nfp dc#relation hasValue { aServiceIsAPotentialMediationService, aGoalIsAPotentialMediationService} endnfp axiom aServiceIsAPotentialMediationService definedBy ?m memberOf ServiceDescription implies ?m memberOf MediationService axiom aGoalIsAPotentialMediationService definedBy ?m memberOf GoalDescription implies ?m memberOf MediationService concept Mediator imports ofType Ontology hasMediationService ofType (0 1) MediationService concept SGMediator subConceptOf Mediator hasSource ofType (1) SGMediatorSource hasTarget ofType (1) SGMediatorTarget RO#usesMediator ofType (1) OOMediator 175see-semanticsoaro-pr1 176 177Copyright © OASIS Open 2008 All Rights Reserved 178 November 2008 Page 35 of 38 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 concept SGMediatorSource nfp dc#relation hasValue { aServiceIsAPotentialSGMediatorSource, aGoalIsAPotentialSGMediatorSource, anSGMediatorIsAPotentialSGMediatorSource} endnfp axiom aServiceIsAPotentialSGMediatorSource definedBy ?x memberOf ServiceDescription implies ?x memberOf SGMediatorSource axiom aGoalIsAPotentialSGMediatorSource definedBy ?x memberOf GoalDescription implies ?x memberOf SGMediatorSource axiom anSGMediatorIsAPotentialSGMediatorSource definedBy ?x memberOf SGMediator implies ?x memberOf SGMediatorSource concept SGMediatorTarget nfp dc#relation hasValue { aServiceIsAPotentialSGMediatorTarget, aGoalIsAPotentialSGMediatorTarget, anSGMediatorIsAPotentialSGMediatorTarget} endnfp axiom aServiceIsAPotentialSGMediatorTarget definedBy ?x memberOf ServiceDescription implies ?x memberOf SGMediatorTarget axiom aGoalIsAPotentialSGMediatorTarget definedBy ?x memberOf GoalDescription implies ?x memberOf SGMediatorTarget axiom anSGMediatorIsAPotentialSGMediatorTarget definedBy ?x memberOf SGMediator implies ?x memberOf SGMediatorTarget concept OOMediator subConceptOf Mediator hasSource ofType OOMediatorSource concept OOMediatorSource nfp dc#relation hasValue { anOntologyIsAPotentialOOMediatorSource, anOOMediatorIsAPotentialOOMediatorSource} endnfp axiom anOntologyIsAPotentialOOMediatorSource definedBy ?x memberOf Ontology 180see-semanticsoaro-pr1 181 182Copyright © OASIS Open 2008 All Rights Reserved 183 November 2008 Page 36 of 38 1118 1119 1120 1121 1122 1123 1124 1125 1126 implies ?x memberOf OOMediatorSource axiom anOOMediatorIsAPotentialOOMediatorSource definedBy ?x memberOf OOMediator implies ?x memberOf OOMediatorSource Listing 4: Semantic SOA Reference Ontology Expressed in WSML 185see-semanticsoaro-pr1 186 187Copyright © OASIS Open 2008 All Rights Reserved 188 November 2008 Page 37 of 38 1127C Acknowledgements 1128The chairs of the TC would like to acknowledge the following individuals who where members of the TC 1129during this specification and aided in its completion: 1130 1131Raghu Anantharangachar, Hewlett-Packard 1132Alessio Carenini, CEFRIEL 1133Dario Cerizza, CEFRIEL 1134Emilia Cimpian, Semantic Technology Institute Innsbruck 1135Emanuele Della Valle, CEFRIEL 1136Federico Facca, Semantic Technology Institute Innsbruck 1137Dieter Fensel, Semantic Technology Institute Innsbruck 1138Marc Haines, Individual 1139Thomas Haselwanter, Semantic Technology Institute Innsbruck 1140Graham Hench, Semantic Technology Institute Innsbruck 1141Mick Kerrigan, Semantic Technology Institute Innsbruck 1142Srdjan Komazec, Semantic Technology Institute Innsbruck 1143Peter Matthews, CA 1144Adrian Mocan, Semantic Technology Institute Innsbruck 1145Matthew Moran, Semantic Technology Institute Innsbruck 1146Barry Norton, The Open University 1147Carlos Pedrinaci, The Open University 1148James Scicluna, Semantic Technology Institute Innsbruck 1149Omair Shafiq, Semantic Technology Institute Innsbruck 1150Zhixian Yan, Semantic Technology Institute Innsbruck 1151Maciej Zaremba, Digital Enterprise Research Institute Galway 190see-semanticsoaro-pr1 191 192Copyright © OASIS Open 2008 All Rights Reserved 193 November 2008 Page 38 of 38 ... for Semantic Service Oriented Architectures-20 shows complete UML 814diagram for the Reference Ontology, which combines all the information from Figure Reference Ontology 81 5for Semantic Service. .. Reference Ontology for Semantic Service Oriented Architectures- 19 – Mediators and their Connection of other RO Concepts [UML] 812Complete Reference Ontology 813In Figure Reference Ontology for. .. 721 -grounding : _iri Figure Reference Ontology for Semantic Service Oriented Architectures- 17 - The Structure of an Interface [UML] 72 2For the Semantic SOA Reference Ontology, the notion of behavioural