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 subset of WSMO-Standard v.0.1. The reasons for introducing WSMO-Lite are manifold:
WSMO-Lite follows the same structure as WSMO-Standard with the difference that WSMO-Lite is simplified by omitting specific concepts from WSMO-Standard. The remaining sets of concepts are minimal in the context of web service integration.
Fundamentally WSMO-Lite's expressiveness is equivalent to sending a single message to a web service interface from a web service requester. This requires the communication of web service ontologies, message definitions as well as mediation between the ontologies of the web service requester and web service provider.
This minimal subset of WSMO-Standard concepts allows one to formulate the minimal possible useful integration scenario in 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-Standard,
except that the only non functional properties kept from WSMO-Standard 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). Also,
WSMO-Lite does not contain any concept of mediators, so we replace the
mediator-based mechanism used in WSMO for importing ontologies by the simple
property: imported ontologies. Thus, an ontology in WSMO-Lite is
defined as follows:
| ontology[ nonFunctionalProperties => nonFunctionalProperties importedOntologies =>> ontology conceptDefinitions =>> conceptDefinition relationDefinitions =>> relationDefinition instances =>> instance ] |
non functional properties of an ontology consist of
the core properties described in Section 2.Imported ontologies reference other ontologies
containing definitions whose meaning is considered to be part of the
meaning of the ontology which imports them. The solutions to problems
such as mismatching, alignment, etc. between imported ontologies are
left to the tools that implement WSMO-Lite, as opposed to the use of
mediators in WSMO to solve these problems.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.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, the mechanism for importing ontologies is not by
using mediators as in WSMO, but by using a simple property: imported
ontologies, and a concrete grounding is given.
| webService[ nonFunctionalProperties => nonFunctionalProperties importedOntologies =>> ontology capability => capability interfaces =>> interface ] |
non functional properties of a web service consists
of the non functional properties described in Section
2.imported ontologies will provide
concepts and relations needed also in the definitions of the
capability and interfaces.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 errors =>> (errorCode or errorDomainConcept) messageExchange => messageExchangePattern grounding => grounding ] |
non functional properties of an interface consist of
the core properties described in the Section
2.error data: data
indicating problems during the execution. This is represented in terms
of error codes. We classify errors in domain-independent and domain
dependent errors. The domain independent errors are similar to HTTP
errors. The domain dependent errors are considered to be defined in
ontologies (for example a service may return an error Invalid account
number – a domain dependent error, described in a domain
ontology).| messageExchangePattern[ inMessages =>> message outMessages =>> message errorGenerationRule =>errorGenerationRule ] |
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. Feedback that will emerge from the implementation will be fed back into WSMO-Lite and WSMO-Standard.
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 programme.
The editors would like to thank all the members of the WSMO working group for their advice and input to this document.