Copyright © 2005 DERI Innsbruck at the
Leopold-Franzens-Universität Innsbruck, Austria, DERI Galway at the National
University of Ireland, Galway, Ireland, BT, The Open University, and
SAP AG. All rights reserved.
This document is available under the W3C Document License. See the W3C Intellectual Rights Notice and Legal Disclaimers for additional information.
This document contains brief descriptions of the relationship between WSMO and other selected relevant technologies.
This document is a part of the WSMO Submission.
By publishing this document, W3C acknowledges that DERI Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria, DERI Galway at the National University of Ireland, Galway, Ireland, BT, The Open University, and SAP AG have made a formal submission to W3C for discussion. Publication of this document by W3C indicates no endorsement of its content by W3C, nor that W3C has, is, or will be allocating any resources to the issues addressed by it. This document is not the product of a chartered W3C group, but is published as potential input to the W3C Process. Publication of acknowledged Member Submissions at the W3C site is one of the benefits of W3C Membership. Please consult the requirements associated with Member Submissions of section 3.3 of the W3C Patent Policy. Please consult the complete list of acknowledged W3C Member Submissions.
The Web Services Description Language [WSDL] is used to describe the message formats and simple message exchanges (operations) provided by Web services. A WSDL description of a Web service has the following three layers:
A WSDL description of a Web service can be seen as a syntactical contract - it specifies what formats of messages can be sent to (or by) the Web Service and what formats of messages, if any, can be sent as replies or faults. On the other hand, WSMO describes functional and behavioral aspects of Web services. Specifically, where WSDL talks about what kind of data can be exchanged, WSMO specifies what the results of those message exchanges will be. In this regard, WSMO and WSDL are fully complementary specifications.
Work is currently ongoing on specifying the grounding of WSMO in WSDL. The grounding will describe the concrete relationships between a WSMO description and a WSDL description of a Web service. In particular, we envisage that WSMO descriptions will be used for discovering and automatic composition of Web Services, and when a Web service is discovered, the grounding to the WSDL description will specify which WSDL interface and operation(s) will provide the requested service and where the Web service is physically located. WSMO grounding will also specify how an invoking agent working on the semantic level of ontology instances should construct the XML messages described in WSDL, so that they can be sent to the service. Similarly, the grounding will specify the reverse process of interpreting the XML messages coming from the service as ontology instances on the semantical level.
Future work in the WSMO family of specifications, describing semantically the choreography interface of a Web service, will also be grounded to WSDL and thus specify the possible ordering(s) or operation invocations on one or more Web services.
Universal Description, Discovery and Integration [UDDI] is the name of a group of Web-based registries that contain information about a business or other entity and its technical interfaces (or APIs). UDDI registries are used for publishing and discovery of Web services.
The core component of UDDI is the UDDI business registration, an XML document used to describe a business entity and its Web services. Conceptually, the information provided in a UDDI business registration consists of three components: "white pages" including address, contact, and known identifiers; "yellow pages" including industrial categorizations based on standard taxonomies; and "green pages", the technical information about services that are advertised by the business. Green pages include references to Web service descriptions, as well as support for pointers to various file and URL based discovery mechanisms if required. [UDDIWP]
UDDI discovery is based on keywords or fixed standard taxonomies, whereas WSMO discovery uses any of the semantics included in the WSMO description of a web service. It may be possible to register and query WSMO descriptions in UDDI registries or it may prove advantageous that a specific WSMO repository is created with more natural querying capabilities. This question is yet to be investigated. Currently WSMO does not impose any registry type.
Web Services Policy Framework [WSPolicy] allows the description of specific Web services metadata (so-called policies) used for expressing the capabilities, requirements, and general characteristics of Web Services.
In our position paper for the W3C Workshop on Constraints and Capabilities for Web Services [Arroyo et al. 2004], we introduce a classification for capabilities and constraints on Web services, most importantly the application-dependent distinction between functional and non-functional properties. For a meaningful use, the authors would constrain policy assertions to describe only non-functional capabilities, constraints/requirements and other general characteristics, i.e. policies should not be used to describe the functional aspects.
The WS-Policy specification suite defines policies for simple general purposes like indicating languages and specifying general message preconditions, and more importantly an accompanying WS-Security Policy specification also defines policies for security requirements. Because many major companies of the IT industry either authored or support WS-Policy, we expect to see many more practical policy assertions being published. While it is expected that Semantic Web services will ultimately represent such policy assertions as logical conditions, even in their XML form they can usefully complement the Dublin Core non-functional properties currently used by WSMO.
Web Services Business Process Execution Language [WSBPEL] is a language and metamodel for specifying business process behavior based on Web services. Processes in WS-BPEL export and import functionality by using Web service interfaces or using extensions that point to other programming interfaces. WS-BPEL is meant to be used to model the behavior of both so-called executable and abstract processes. Executable business processes model actual behavior of a participant in a business interaction. Business protocols, in contrast, use process descriptions (called abstract processes) that specify the mutually visible message exchange behavior of each of the parties involved in the protocol, without revealing their internal behavior.
Web Services Choreography Description Language [WSCDL] is an XML-based language that describes peer-to-peer collaborations of parties by defining, from a global viewpoint, their common and complementary observable behavior; where ordered message exchanges result in accomplishing a common business goal. The Web Services Choreography specification is targeted for composing interoperable, peer-to-peer collaborations between any type of party regardless of the supporting platform or programming model used by the implementation of the hosting environment.
WSMO complements the orchestration and choreography specifications: using semantic technologies Web services can more easily be discovered and composed into the various processes; and one step further, semantically described placeholders can be put in the processes, for automatic discovery of suitable Web services.
Grid computing aims to provide the computational power and data management infrastructure necessary to support the collaboration of people, together with data, tools and computational resources. [Foster and Kesselman, 1999] The most common problems that Grid addresses are computationally hard and data intensive problems in science and engineering, along with resource sharing and virtualization in complex networks.
A closer look at Grid computing shows that it has a many points in common with Web services. Basically both Web services and Grid computing use the concept of service and both architectures have the same underlying design principles provided by Service Oriented Architecture (SOA). Latest directions in Grid and Web services (like WS-Resource Framework - WSRF) try to provide a common base for building Web services in Grid environments. We expect that this convergence will continue and will result in Semantic Web Services for Grids.
Semantic Web services promise to solve the remaining problem of proper support for machine processable semantics, as currently human intervention is needed to actually discover, combine, and execute services. Semantic Web Services technologies will provide a fully mechanized infrastructure for using domain-specific Grid services.
The relationship between WSMO and OWL, including a mapping between them, is covered extensively in the document on Web Service Modeling Language.
The Semantic Web Rule Language [SWRL] is an extension of OWL which adds support for Datalog-style rules over OWL DL ontologies. Instead of arbitrary predicates, SWRL allows arbitrary OWL DL descriptions in both the head and the body of Horn rules, where a unary predicate corresponds with an OWL class and a binary predicate corresponds with an OWL property.
While a subset of SWRL falls inside standard Logic Programming, a SWRL knowledge base easily goes beyond this fragment, because the straightforward combination of rules with OWL DL axioms leads to immediate undecidability of the language.
On the one hand, this means different expressivity than standard rule languages restricted to Horn rules only. The advantages of common rule languages like Datalog which provide a fragment of first order logic where efficient reasoning support for certain tasks like query answering is the focus are lost. Thus, SWRL is not implementable on top of efficient rule engines and does not allow for efficient query answering.
On the other hand, the strict use of OWL atoms in SWRL rules imposes unnecessary syntactical restrictions on first order logic which are not motivated by computational aspects; it is not possible to use predicates with an arity higher than 2 and function symbols are disallowed.
In contrast, WSML aims at defining strict syntactical variants: On the lower end the intersection of a Description Logic and Horn rules is marked by the WSML-Core variant whereas full freedom of a first order language is available in WSML-Full on the upper end. In between, WSML-Flight and WSML-Rule mark syntactic variants which are efficiently implementable on top of existing deductive database and logic programming engines.
WSMO and OWL-S are the two major efforts whose purpose is to specify semantic information for Web services in order to enable automatic service discovery, composition and execution. However, there are substantial differences between these approaches (cf. [Polleres & Lara, 2005]).
WSMO is based on the Web Service Modeling Framework (WSMF) which separates the elements needed to describe services into Ontologies, Web services, Goals and Mediators. WSML is the language used to describe all of these elements. OWL-S facilitates the description of services in terms of four different ontologies. The upper Service ontology links to the Profile, Service Model and Grounding ontologies. The Profile defines some non-functional properties of the service and exposes some of the functionality by referencing Inputs, Preconditions and Results from the Service Model. The Service Model describes the behaviour of the Service in terms of processes and control constructs. The Grounding binds processes, inputs and outputs in the process model to some transport protocol described in a WSDL document. The major concrete differences are explained in the following paragraphs.
A first significant difference between the two approaches is that OWL-S does not separate what the user wants from what the service provides. The Profile ontology is used as both an advertisement for the service and as a request to find a service. In WSMO, a Goal specifies what the user wants and the Web service description defines what the service provides through its capability.
In OWL-S, the non-functional properties in the Profile ontology (such as the service name, human-readable description and contact information) are not explicitly based on standard metadata specifications. WSMO recommends the use of widely accepted vocabularies such as Dublin Core [DublinCore] and Friend of a Friend vocabulary [FOAF] metadata. Also, non-functional properties can be expressed in any element in WSMO, whereas in OWL-S this is restricted to the Profile ontology.
In OWL-S, the Service Model does not make a clear distinction between choreography and orchestration. It is not (at least explicitly) based on any formal model, albeit that there are external works defining the formal semantics of OWL-S processes. The Process ontology defines Atomic, Composite and Simple processes. In Composite processes, control constructs such as decisions, forks and loops can be used to model a workflow. OWL-S defines only one Service Model per service, hence there is only one way to interact with the service. In WSMO, the choreography and orchestration are specified in the interface of the Web service description. A choreography describes the external visible behaviour of the service and an orchestration describes how other services are composed in order to achieve the required functionality of a service. Because we expect that there could be more than one way of interacting with a particular service, WSMO allows the definition of multiple interfaces for a single service.
To define logical expressions, OWL-S provides the choice between SWRL, DRS and KIF. By leaving the choice of the language to be used to the user, OWL-S contributes to the interoperability problem, rather than solving it. Furthermore, the interaction between the inputs and outputs, which have been specified as OWL classes, and the logical expressions in the respective languages, is not clear. Furthermore, DRS does not have a semantics associated with it and KIF is not web-compliant. WSMO provides a family of layered logical languages (see Web Service Modeling Language) which enables us to combine conceptual modeling with rules on only the required expressibility level, allowing descriptions to stay more explicitly within efficiently computable fragments.
To facilitate linkage of heterogeneous resources between one another, various kinds of mediation are required. For example, a service might need to make use of an ontology specified in OWL rather than WSML, requiring mediation (in this case ontology mapping) for the purpose of describing this service in WSMO. In our opinion mediators are a key element in describing Web services and therefore WSMO explicitly defines them in the conceptual model. OWL-S does not explicitly address the issue of mediation: it is considered to be handled by the underlying infrastructure.
To summarize, OWL-S is clearly more mature in certain aspects, including the choreography and grounding specifications. However, WSMO provides a more complete conceptual model as it addresses aspects such as goals and mediators.
SWSL is another recent proposal for a language for describing Semantic Web Services. SWSL has two parts, a rules language and a process ontology. The SWSL-Rules sublanguage is closely related to WSML-Rules. Both languages are largely based on F-logic and they mostly share the logical expression syntax. However, the two groups have pursued complementary goals. WSMO was focused on the end user and developed a "conceptual syntax" for top-level descriptions of services, which we believe might make the specifications easier to read. WSMO also paid special attention to the issue of OWL compatibility. To this end, we defined WSML-Core as a subset of both OWL and WSML, which will serve as a common ground for ontology interoperability. In contrast, SWSL's focus was on extending the functionality of their rule-based language. In particular, SWSL-Rules supports meta-reasoning with its HiLog and reification extensions. It also supports prioritized defaults and classical negation by incorporating Courteous Logic Programming.
On the process description front, WSMO and SWSL are more divergent, but they nonetheless cover complementary parts of the problem space. WSMO has focused on describing Web service choreography through ECA rules, which are viewed as abstract state machines. In contrast, SWSL has developed a first-order PSL-based process ontology, which allows the description of process orchestration as well as message exchange among processes. Further work is needed to determine to what extent the two approaches can be combined.
The first version of the Web Service Execution Environment (WSMX) which is part of this submission has been available since June 2004 at the SourceForge portal. Apart from WSMX which marks a reference architecture and implementation for a WSMO compliant execution environment there already exist several other ready-to-use implementations and tools for WSMO to be briefly introduced here.
The Internet Reasoning Service (IRS-III) is an infrastructure for publishing, locating, executing and composing Semantic Web services, organized according to the WSMO framework, developed at the Knowledge Media Institute of the Open University, UK, within the DIP project.
WSMO Studio is a Semantic Web Service editor compliant with WSMO and based on SWWS Studio. The WSMO Studio will be available as a set of Eclipse plug-ins that will allow easy reusability and extension from 3rd parties. WSMO Studio is being developed jointly by OntoText Lab and DERI Innsbruck within the DIP project.
wsmo4j is a Java API and a reference implementation for building Semantic Web services applications compliant with WSMO. Like WSMX, it is also being developed as an Open Source project jointly by OntoText Lab and DERI Innsbruck.
The WSML Validator is an online service (also available as a SOAP Web service) able to validate WSML documents in the normative syntax. It is developed by DERI Innsbruck.
The work is funded by the European Commission under the projects DIP, Knowledge Web, InfraWebs, SEKT, SWWS, ASG and Esperonto; by Science Foundation Ireland under the DERI-Lion project; by the FIT-IT (Forschung, Innovation, Technologie - Informationstechnologie) under the projects RW² and TSC.
The editor would like to thank to all the members of the WSMO, WSML, and WSMX working groups for their advice and input into this document.
The authors would further like to thank Frank Leymann for his valuable input.
[Arroyo et al. 2004] S. Arroyo et al.: Web Service Capabilities and Constraints in WSMO, position paper for W3C Workshop on Constraints and Capabilities for Web Services, 2004, available at http://www.w3.org/2004/08/ws-cc/wsmo-20040903
[DublinCore] S. Weibel, J. Kunze, C. Lagoze, and M. Wolf: RFC 2413 - Dublin Core Metadata for Resource Discovery, September 1998, available at http://www.isi.edu/in-notes/rfc2413.txt.
[FOAF] D. Brickley, L. Miller: FOAF Vocabulary Specification, available at http://xmlns.com/foaf/0.1/
[Foster and Kesselman, 1999] I. Foster and C. Kesselman: The Grid: Blueprint for a New Computing Infrastructure, published by Morgan Kaufmann, 1999.
[Polleres & Lara, 2005] A. Polleres, R. Lara (editors): A Conceptual Comparison between WSMO and OWL-S, WSMO Working Group working draft, 2005, available at http://www.wsmo.org/2004/d4/d4.1/v0.1/.
[SWRL] I. Horrocks, P.F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, M. Dean: SWRL: A Semantic Web Rule Language Combining OWL and RuleML, 2004, available at http://www.w3.org/Submission/2004/SUBM-SWRL-20040521/
[UDDI] T. Bellwood (editor): UDDI Version 2.04 API specification, OASIS standard available at http://uddi.org/pubs/ProgrammersAPI-V2.04-Published-20020719.htm
[UDDIWP] UDDI Technical White Paper available at http://www.uddi.org/pubs/Iru_UDDI_Technical_White_Paper.pdf
[WSBPEL] Web Services Business Process Execution Language, specification developed in OASIS WSBPEL Technical Committee at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
[WSCDL] N. Kavantzas, D. Burdett, G. Ritzinger, T. Fletcher, Y. Lafon (editors): Web Services Choreography Description Language, W3C Last Call Working Draft available at http://www.w3.org/TR/ws-cdl-10/
[WSDL] R. Chinnici, M. Gudgin, J-J. Moreau, J. Schlimmer, S. Weerawarana (editors): Web Services Description Language Part 1: Core Language, W3C Last Call Working Draft available at http://www.w3.org/TR/wsdl20/
[WSPolicy] J. Schlimmer (editor): Web Services Policy Framework, available at http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-policy.asp
[XMLSchema] H. Thompson, D. Beech, M. Maloney, N. Mendelsohn (editors): XML Schema part 1: Structures, W3C Recommendation, 2001, available at http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/