This document is also available in non-normative PDF version.
Copyright © 2004 DERI ®, All
Rights Reserved. DERI liability,
trademark, document use, and software licensing rules apply.
This document contains the WSMO-Lite ontology, a minimal yet meaningful subset of WSMO-Standard v.01 [Roman et al., 2004] . WSMO-Standard is a meta-ontology for describing aspects of semantic web services, so that these web services can be automatically discovered and composed to satisfy some user's goal, mediating between all kinds of possible mismatches. WSMO-Standard provides modelling constructs to describe web services, the ontologies they use, goals a user may have and different mediators that can solve integration problems.
WSMO-Standard allows different levels of modelling: firstly, it is possible to extend WSMO-Standard by adding one’s own constructs; secondly, one can decide to model elements with more, or less, detail. WSMO-Lite limits the elements that can be described, and does so for a very simple reason. The goal of WSMO-Lite is to provide a subset of WSMO-Standard that is meaningful (in the context of web service integration), but, for which, an execution environment is easily implementable. This execution environment would satisfy the goals of users by invoking web services; it would use WSMO-compliant definitions of these goals, these web services and the ontologies they are using. Having WSMO-Lite is very important, as it allows WSMO to 'bootstrap' itself into world-wide use: it allows easy implementation of a simple subset of WSMO, showing the viability and potential of WSMO, and thus attracting interested parties. Once such execution environments have been shown to work, the full potential of WSMO can be unleashed, and the execution environments could be extended to support WSMO-Standard.
If one were to try to immediately build such an execution environment based on WSMO-Standard, the environment would easily get quite complex, since WSMO-Standard allows modelling of very complex situations. Of course, since these complex situations are real-world situations, one must provide an execution environment that deals with these situations at some point in time. However, from an implementation point of view, it is not practical to try and build an environment that can completely handle these complex cases from scratch. It is easier (and it will most likely result in better software) to start with a smaller set, making very clear directions for future extensions. Since we expect (and want to stimulate) several implementations of a WSMO execution environment, it is useful to specifically distinguish a consistent subset of WSMO-Standard. By offering this subset, we can make sure that all these different implementations of the WSMO execution environment are based on the same conceptual model.
Therefore, defining WSMO-Lite serves two purposes: to attract people into building a WSMO execution environment, by deliberately keeping simple the WSMO-Lite that they would need to implement; and to ensure that future implementations do not define their own subset, building an environment that is incompatible with that of others.
Let us illustrate this with an example: in WSMO-Standard the communication with a web service follows a certain choreography pattern, defined by the web service. In order to communicate with this service, the requester must comply with the service's choreography. This choreography pattern can be a simple stateless conversation (e.g. request-response), or a more complex statefull conversation, in which the requester possibly has to supply more information. If an execution environment wants to implement WSMO-Standard, it needs to support all possible choreography patterns. Otherwise, it cannot communicate with every WSMO-Standard compliant web service. However, implementing every possible choreography pattern is technically more difficult than only supporting stateless conversations. To enable easy implementation, we restrict these communication patterns in WSMO-Lite, so that the implementation only needs to deal with simple, stateless, conversations.
Another example where WSMO-Lite deliberately simplifies the meta-ontology to ensure swift implementation, is the relation between a goal that a user wants to satisfy, and a capability that a web service offers. To find out which capability (or which composition of web services) could satisfy a user goal, advanced logic reasoning techniques must be employed. While we certainly acknowledge that this is a very important aspect of WSMO and that it is a very promising area of semantic web services, it makes sense to simplify this framework for initial implementation. By hard-wiring a goal to a capability (so a user's goal exactly matches one capability) we deliberately limit the conceptual model for easy implementation. Once WSMO-Lite has shown the viability and possibility of this approach, people could then switch to WSMO-Standard, and employ its more powerful possibilities.
To summarize, WSMO-Lite is a specific, consistent, subset of WSMO-Standard, that is both meaningful and easily implementable. The reasons for introducing WSMO-Lite are:
WSMO-Lite follows the same structure as WSMO-Standard, with the difference being that WSMO-Lite simplifies things by omitting specific concepts from WSMO-Standard. The remaining set of concepts are minimal in the context of web service integration. The expressiveness of WSMO-Lite is defined by exactly that which is necessary to enable sending a single message from a web service requester to a web service provider. This includes establishing the ontologies of the communicating web services, establishing the message formats and providing mediation between the ontologies of the web service requester and the web service provider. This minimal subset of WSMO-Standard allows the formulation of minimal, yet useful, integration scenarios in the context of web services.
Section 2 presents the non functional properties (core properties) of each modeling element of WSMO-Lite. Section 3 presents ontologies in WSMO-Lite. Section 4 presents a minimal set of elements for describing web services and Section 5 presents our conclusions and further intentions.
Non functional properties in WSMO-Lite are defined as in WSMO, except that
the only non functional properties kept from WSMO are title and
identifier:
| nonFunctionalProperties[ title => title identifier => identifier ] |
title will be a
name by which the element is formally known.In order to keep WSMO-Lite as simple as possible, we eliminate the axioms from the definition of the ontology in WSMO-Standard (WSMO hereafter). Thus, an ontology in WSMO-Lite is defined as follows:
| ontology[ nonFunctionalProperties => nonFunctionalProperties usedMediators =>> ooMediators conceptDefinitions =>> conceptDefinition relationDefinitions =>> relationDefinition instances =>> instance ] |
non functional properties of an ontology consist of
the core properties described in Section 2.Concepts in WSMO-Lite are defined in a similar way to the concepts in WSMO-Standard:
| conceptDefintion[ nonFunctionalProperties => nonFunctionalProperties superConcepts =>> simpleLogicalExpression attributes =>> attributeDefintion ] |
non functional properties of a concept consist of
the core properties described in Section 2.super concepts for some concept. The range of a super
concept is a simple logical expression.attributes that represent named slots for data values and
instances that have to be filled at the instance level.
An attribute definition specifies a slot of a concept by fixing the
name of the slot as well as a logical constraint on the possible values
filling that slot.
Hence, this simple logical expression can be interpreted as a typing
constraint, which specifies the extension of some concept in the
ontology in the simplest case;
more sophisticated constraints can be modeled easily.
| attributeDefinition[ nonFunctionalProperties => nonFunctionalProperties rangeDefinition => simpleLogicalExpression ] |
non functional properties of an attribute
consist of the core properties described in Section 2.Relations are defined as in WSMO:
| relationDefinition[ nonFunctionalProperties => nonFunctionalProperties parameters => LIST(parameter) ] |
non functional properties of a relation consist of
the core properties described in Section 2.| parameter[ nonFunctionalProperties => nonFunctionalProperties domainDefinition => simpleLogicalExpression ] |
non functional properties of a parameter
consist of the core properties described in Section 2.Instances in WSMO-Lite are defined in a similar way to the instances in WSMO-Standard:
| instance[ nonFunctionalProperties => nonFunctionalProperties instanceOf =>> logicaExpression attributeValues =>> attributeValueDefinition ] |
non functional properties of an instance consist of
the core properties described in Section 2.| attributeValueDefinition[ nonFunctionalProperties => nonFunctionalProperties valueDefinition => simpleLogicalExpression ] |
non functional properties of an
attributeValueDefinition consist of the core properties described
in Section 2.OO-Mediators in WSMO-Lite are defined in a similar as in WSMO-Standard:
| ooMediator[ nonFunctionalProperties => nonFunctionalProperties sourceComponent =>> (ontology or ooMediator) targetComponent =>> (ontology or webService or ooMediator) mediationService => webService ] |
non functional properties of an ooMediator consist
of the core properties described in Section 2.The elements for describing a web service in WSMO-Lite are basically the
same as in WSMO, except that the non functional properties are
reduced to the non functional properties presented in Section 2, and the interface is simplified to not having a
choreography but instead using simple message exchange patterns. Also, no
orchestration can be specifiied.and
| webService[ nonFunctionalProperties => nonFunctionalProperties usedMediator =>> ooMediator capability => capability interfaces =>> interface ] |
non functional properties of a web service consists
of the non functional properties described in Section
2.capability of a web service is described in Section 4.1.interfaces of a web service are described in Section 4.2.A capability is defined as in WSMO, except that the non
functional properties are reduced to the non functional properties
presented in Section 2.
| capability[ nonFunctionalProperties => nonFunctionalProperties preconditions =>> simpleLogicalExpression postconditions =>> simpleLogicalExpression assumptions =>> simpleLogicalExpression effects =>> simpleLogicalExpression ] |
non functional properties of a capability consist of
the core properties described in the Section 3
(where, in this case, an element in the core properties is equivalent
to a capability).Pre-conditions describe what a web service expects for
enabling it to provide its service. They define conditions over the
input.Post-conditions describe what a web service returns in
response to its input. They define the relation between the input and
the output.Assumptions are similar to pre-conditions, however, also
reference aspects of the state of the world beyond the actual
input.Effects describe the state of the world after the
execution of the service.The properties of an interface in WSMO-Lite are non functional
properties, errors and messages exchange and
grounding.The idea is to allow only simple conversation (message
passing without composition).
| interface[ nonFunctionalProperties => nonFunctionalProperties messageExchange => messageExchangePattern ] |
non functional properties of an interface consist of
the core properties described in the Section
2.| messageExchangePattern[ inMessages =>> message outMessages =>> message errorGenerationRule =>errorGenerationRule ] |
Different instantiations of MEPs can be derived based on the
cardinality of the messages:
As one can see the only elements needed for a direct invocation of the service are the message exchange patterns instances. Being defined in a very similar way to the WSDL 2.0 message patterns, the mapping of MEPs to WSDL 2.0 message patterns is straight forward.
errors may occur:
This document presented WSMO-Lite, the minimal subset of concepts of WSMO-Standard. WSMO-Lite is, as shown, a subset of WSMO-Standard established through elimination or simplification of concepts.
WSMO-Lite will be verified by a corresponding implementation supporting the execution of ontologies thereby achieving mediated web service invocation. Feeback that will emerge from the implementation will be fed back into WSMO-Lite and WSMO-Standard.
[Roman et al., 2004] D. Roman, U. Keller, H. Lausen (eds.): Web Service Modeling Ontology - Standard (WSMO - Standard), version 0.1 available at http://www.wsmo.org/2004/d2/v01/
The work is funded by the European Commission under the projects DIP, Knowledge Web, Ontoweb, SEKT, SWWS, Esperonto, COG and h-TechSight; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate programm.
The editors would like to thank to all the members of the WSMO working group for their advises and inputs to this document.