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 WFMO-Lite ontology, a minimal subset of WSMO-Standard v.0.1. The reason for introducing WSMO-Lite are manifold:
WSMO-Lite follows the same structure as WSMO-standard with the difference that WSMO-Lite simplifies by omitting specific concepts from WSMO-standard. The remaining set 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 to establish the communication web services' ontologies, the message definition as well as mediation between the ontologies of the web service requester and web service provider.
This minimal subset of WSMO-Standard concepts allows 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. Section 5 presents the specification language for WSMO-Lite and Section 6 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
dentifier:
| 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 problems to solve the
mismatching, alignment, etc. between imported ontologies is 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 =>> logicalExpression attributes =>> attributeDefintion methods =>> methodDefintion ] |
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 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 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 => logicalExpression ] |
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 => logicalExpression ] |
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 => logicalExpression ] |
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 =>> logicalExpression postconditions =>> logicalExpression assumptions =>> logicalExpression effects =>> logicalExpression ] |
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[ in_messages =>> message out_messages =>> message errorGenerationRule =>errorGenerationRule ] |
errors may occur:
As shown in the previous sections, many properties of ontologies and web
services are considered to be logical expressions. Similar to
WSMO, we consider these logical expressions as being described
in F-Logic [Kifer et al., 1995], by complex formulas.
F-Logic combines the advantages of conceptual high-level approaches typical for frame-based language and the expressiveness, the compact syntax, and the well defined semantics from logics. Features of F-Logic include: object identity, methods, classes, signatures, inheritance and rules.
The reasons for which we choose F-Logic to represent logical expressions are:
For a detailed description of F-Logic refer to [Kifer et al., 1995]. Furthermore, an evaluation of F-Logic and comparison to other languages is given in [Keller et al., to appear].
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.
[Keller et al., to appear] U. Keller, A. Polleres, R. Lara, and Y. Ding: Language Evaluation and Comparison, to appear.
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 to all the members of the WSMO working group for their advises and inputs to this document.