In this document we define a lightweight set of semantic service descriptions
in RDFS that can be used for annotations of various WSDL elements using the SAWSDL annotation mechanism. These
annotations cover functional, behavioral, nonfunctional and information
semantics of Web services, and are intended to support tasks such as
(semi-)automatic discovery, negotiation, composition and invocation of
services. We exploit RDF and RDFS as well as their various extensions such as
OWL and RIF for semantic service
descriptions.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications can be found in the W3C technical reports index at http://www.w3.org/TR/.
By publishing this document, W3C acknowledges that the Submitting Members have made a formal Submission request 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. A W3C Team Comment has been published in conjunction with this Member Submission. 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.
Existing service description languages, especially WSDL, allow
service providers to describe their service offerings so that a
client can make an up-front decision on whether and how to consume
the service's functionality. Their uptake will lead to environments
where thousands of services will have to be searched, integrated and
mediated, and where automation will be the key enabler of service
provisioning to end-users. In order to fulfill these challenges,
existing service specifications need to be augmented with semantic
descriptions [Studer et al.,
2007]
In 2007, the W3C finished its work on Semantic Annotations for
WSDL and XML Schema
(SAWSDL). SAWSDL defines
simple extensions for WSDL and XML Schema to link WSDL components with
arbitrary semantic descriptions. It thus provides the building blocks
for a bottom-up approach to semantic service modeling: it supports the
piecemeal addition of semantics on top of WSDL, without prescribing a
semantic framework, thereby allowing selected results from various
existing approaches to be adopted in an incremental fashion. As the
basis for bottom-up modeling, SAWSDL is independent of any particular
semantic technology, i.e., it does not define any types, forms or
languages for semantic descriptions.
In this document, we specify the WSMO-Lite service ontology as the
next evolutionary step after SAWSDL, filling the SAWSDL annotations
with concrete semantic service descriptions. With the ultimate goal
to support real-world challenges in intelligent service integration,
WSMO-Lite addresses the following requirements:
- Identify the types and a simple vocabulary for semantic
descriptions of services (a service ontology).
- Define an annotation mechanism for WSDL using this service
ontology.
- Provide the bridge between WSDL, SAWSDL and (existing) domain-specific
ontologies such as classification schemas, domain ontology models, etc.
Even though we adopt the base Web service model from WSDL and
SAWSDL, WSMO-Lite is inspired by
the WSMO ontology,
focusing on a small subset of it to define a limited extension of
SAWSDL.
Our conceptual model for Web Service Descriptions adopts the following general types of service contracts (adapted from [Sheth, 2003]):
- Information Model Descriptions define the data model for input, output, and fault messages, as well as for the data relevant to the other aspects of the service description.
- Functional Descriptions define service functionality, that is, what a service can offer to its clients when it is invoked.
- Nonfunctional Descriptions define any incidental details specific to a service provider or to the service implementation or its running environment. An example nonfunctional property is the price; the functionality of a service is generally not affected by the price, even though the desirability may be. Nonfunctional properties also include Quality of Service (QoS) aspects such as performance, reliability, and so on.
- Behavioral Descriptions define external and internal behavior. The former is the description of a public choreography, the protocol that a client needs to follow when consuming a service's functionality; and the latter is a description of a workflow, i.e., how the functionality of the service is aggregated out of other services.
- Technical Descriptions define messaging details such as message serializations, communication protocols, and physical service access points.
In the following sections, we show how the above general
description types for service contracts are represented at the
syntactic and the semantic level.
In regard to SOA technology developments today, the Semantic Service
Stack represents service contracts at the non-semantic level using the existing standards: WSDL, SAWSDL, and related WS-* specifications. They all use XML as a common flexible data exchange format. Service contracts are represented as follows:
- Information Model Description is represented using XML Schema.
- Functional Description is represented using a
WSDL interface and its operations.
- Nonfunctional Description is represented using various WS-* specifications (WS-Policy, WS-Agreement, WS-Reliability, WS-Security, etc.).
- Behavioral Description is represented using the relevant WS-* specifications, such as WS-BPEL (for the workflow) and WS-CDL (for the choreography).
- Technical Description is represented using WSDL Binding for message serializations and underlying communication protocols, such as SOAP, HTTP; and using WSDL Service for physical endpoint information.
In addition, while SAWSDL does not fall into any of the service
contract descriptions categories listed above, it is an essential
part of the non-semantic level of the stack, providing the
groundwork for the semantic layer. SAWSDL defines a simple extension
layer that allows WSDL components to be annotated with semantics,
using three extension attributes:
- modelReference for pointing to semantic concepts that describe
a WSDL component,
- loweringSchemaMapping and liftingSchemaMapping for
specifying the mappings between the XML data and the semantic information
model.
With the WSMO-Lite service ontology we represent service contracts
at the semantic level as follows (see Section
3 for a detailed description of WSMO-Lite):
- Information Model Descriptions are represented using a domain ontology, along with associated data lifting and lowering transformations.
- Functional Descriptions are represented as capabilities and/or functionality classifications. A capability defines conditions which must hold in a state before a client can invoke the service, and effects which hold in a state after the service invocation. Classifications define the service functionality using some classification ontology (i.e., a hierarchy of categories).
- Nonfunctional Descriptions are represented using an ontology, semantically representing some policy or other nonfunctional properties.
- Behavioral Descriptions are not represented explicitly in WSMO-Lite (see discussion in Section 3).
- Technical Descriptions are not represented semantically in the service ontology, as they are sufficiently covered by the non-semantic description in WSDL.
In order to create or reuse domain-specific service ontologies, a
service engineer can use any RDF-compliant language. This preserves
the choice of language expressivity according to domain-specific
requirements. Such languages may include RDF Schema (RDFS), Web
Ontology Language
(OWL), Rule
Interchange Format (RIF)
or the Web Service Modeling Language
(WSML).
RDFS: On top of RDF, RDF Schema (RDFS) defines constructs that allow the expression of some semantics for the RDF model: RDFS allows the definition of classes describing the terminology of the domain of discourse, properties of those classes as well as class and property hierarchies (i.e. subClassOf and subPropertyOf). Thus, RDFS provides a set of constructs that allow the specification of lightweight ontologies.
OWL, WSML, RIF (on top of RDFS): Where the expressivity of RDFS is not sufficient for modeling of the required knowledge, various specializations of RDFS can be used. Such specializations are being developed both inside and outside of W3C along the lines of knowledge representation paradigms of Description Logic (DL) and Logic Programming (LP).
The Web Ontology Language
(OWL) provides a
vocabulary along with a formalism based on Description Logics. The
Web Service Modeling Language
(WSML) defines
several variants allowing for both paradigms of Description Logics
(WSML-DL)
and Logic Programming
(WSML-Flight, WSML-Rule). All
WSML variants can be represented using RDF syntax and they are
layered on top
of RDFS. While
WSML-DL has a direct mapping to OWL, WSML-Rule is the basis of the
Web Rule Language
(WRL) specification
which served as one input to the
W3C's Rule
Interchange Format recommendations.
SKOS: as a lightweight ontology for simple
knowledge organization systems,
SKOS is well suited for
capturing classifications of service and operation functionalities. As
presented in this submission (in the section
below), WSMO-Lite does not directly support
SKOS functional classifications, but it would be straightforward to
add such support, and the exact specification in the context of
WSMO-Lite is part of our planned future work.
Listing 1 shows the WSMO-Lite service ontology in RDFS, serialized in Notation 3. Below, we explain the semantics of the WSMO-Lite elements.
Listing 1. WSMO-Lite Service Ontology
1 @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
2 @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
3 @prefix wsl: <http://www.wsmo.org/ns/wsmo-lite#> .
4
5 wsl:FunctionalClassificationRoot rdfs:subClassOf rdfs:Class .
6 wsl:NonfunctionalParameter a rdfs:Class .
7 wsl:Condition a rdfs:Class .
8 wsl:Effect a rdfs:Class .
|
- wsl:FunctionalClassificationRoot (line 5) marks a class
that is a root of a classification which also includes all the RDFS
subclasses of the root class (the actual functional categories). A
classification (taxonomy) of service functionalities can be used for
functional description of a service.
- wsl:NonfunctionalParameter (line 6) specifies a placeholder for a concrete domain-specific nonfunctional property.
- wsl:Condition and wsl:Effect (lines 7 and 8)
together form a capability in a functional service
description. Both are expected to use a concrete logical language to
describe the logical expressions for conditions and effects.
WSMO-Lite defines behavioral descriptions through functional
annotations of operations. While it does not have a special construct
for choreography descriptions, the behavioral aspects can be inferred
from functional (capability) annotations of individual service
operations. Such annotations can be transformed into
a WSMO Choreography,
using the algorithm described in [Vitvar et al.,
2008].
In this section, we define the particular types of annotations
supported by WSMO-Lite. For this purpose we define two types of
annotations, namely reference annotations
and transformation annotations. A reference annotation
points from a WSDL component (XML Schema element declaration or type
definition, WSDL interface, operation, service) to a WSMO-Lite
semantic concept. SAWSDL represents this type of annotation using
the modelReference extension attribute. A transformation
annotation specifies a data transformation called lifting
from a component of XML schema to an element of ontology, and a
reverse transformation (from ontology to XML)
called lowering. SAWSDL represents this annotation using
extension attributes liftingSchemaMapping
and loweringSchemaMapping respectively. The actual
expression of concrete lifting or lowering transformations is out of
scope of this specification. Non-normatively, we expect WSMO-Lite to
work well with transformation technologies such
as XSLT,
XQuery, and especially
XSPARQL.
Listing 2 depicts an example ontology which
we use to show various annotations.
Listing 2. Example of domain-specific service ontology
1 # namespaces and prefixes
2 @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
3 @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
4 @prefix wsl: <http://www.wsmo.org/ns/wsmo-lite#> .
5 @prefix ex: <http://example.org/onto#> .
6 @prefix xs: <http://www.w3.org/2001/XMLSchema#> .
7
8 # domain ontology
9 ex:Customer a rdfs:Class .
10 ex:hasService a rdf:Property ;
11 rdfs:domain ex:Customer ; rdfs:range ex:Service .
12 ex:Service a rdfs:Class .
13 ex:hasConnection a rdf:Property ;
14 rdfs:domain ex:Customer ; rdfs:range ex:NetworkConnection .
15 ex:NetworkConnection a rdfs:Class .
16 ex:providesBandwidth a rdf:Property ;
17 rdfs:domain ex:NetworkConnection ; rdfs:range xs:integer .
18 ex:VideoOnDemandService rdfs:subClassOf ex:Service .
19
20 # capability description example
21 ex:VideoOnDemandSubscriptionPrecondition a wsl:Condition ;
22 rdf:value
23 "Prefix (ex <http://example.org/onto#>)
24 Prefix (pred <http://www.w3.org/2007/rif-builtin-predicate#>)
25 And (?Customer#ex:Customer
26 ?Customer[ex:hasConnection->?Connection]
27 ?Connection#ex:NetworkConnection
28 ?Connection[ex:providesBandwith->?Y]
29 External(pred:numeric-greater-than(?Y 1000)))" .
30 ex:VideoOnDemandSubscriptionEffect a wsl:Effect ;
31 rdf:value
32 "Prefix (ex <http://example.org/onto#>)
33 Prefix (pred <http://www.w3.org/2007/rif-builtin-predicate#>)
34 And (?Customer#ex:Customer
35 ?Customer[ex:hasService->?Service]
36 ?Service#ex:VideoOnDemandSubscription)" .
37 # nonfunctional property example
38 ex:PriceSpecification rdfs:subClassOf wsl:NonfunctionalParameter .
39 ex:VideoOnDemandPrice a ex:PriceSpecification ;
40 ex:pricePerChange "30"^^ex:euroAmount ;
41 ex:installationPrice "49"^^ex:euroAmount .
42
43 # classification example
44 ex:SubscriptionService a wsl:FunctionalClassificationRoot .
45 ex:VideoSubscriptionService rdfs:subClassOf ex:SubscriptionService .
46 ex:NewsSubscriptionService rdfs:subClassOf ex:SubscriptionService .
|
The listing defines a simple ontology for a telecommunication
service (lines 9-18); the capability for a concrete Video-on-Demand
subscription service (lines 21-36) for which the condition says that
the customer must have a network connection with some minimal
bandwidth and the effect says that the customer will be subscribed to
the service; a nonfunctional property describing the pricing (lines
38-41); and a simple functionality classification with three
categories (lines 44-46).
In this example, the condition and effect are specified in the W3C's
Rule Interchange Format.
For clarity and brevity, the example uses RIF's presentation syntax,
but in practice RIF rules would be given in the XML serialization
syntax.
Figure 1. Illustration of WSMO-Lite
Annotations
Figure 1 illustrates the positioning of
WSMO-Lite annotations (marked A1...A5), which are defined as
follows:
Annotation A1: Ontological annotations of XML
Schema. The schema used in WSDL to describe messages,
i.e., the element declarations and type definitions (and in WSDL
1.1, messages and their parts), can carry reference annotations
linking to classes from the service information model
ontology.
Annotation A2: Transformation annotations of XML Schema. To be able to communicate with a service, the client needs to transform data between its semantic model and the service-specific XML message structures. The schema may contain transformation annotations (lifting or lowering) which specify the appropriate mappings.
The following listing shows an example of annotations A1
and A2 (the content of the lowering transformation is omitted
for brevity).
Listing 3. Example of annotations A1 and A2
1 <xs:element name="NetworkConnection" type="NetworkConnectionType"
2 sawsdl:modelReference="http://example.org/onto#NetworkConnection"
3 sawsdl:loweringSchemaMapping="http://example.org/NetCn.xslt"/>
|
Annotation A3: Functional annotations of WSDL Interface and Service. Functional descriptions (both capabilities and categories) apply both to concrete Web services and to the reusable and abstract interfaces. A reference annotation points from a service or an interface to its appropriate functional description.
The following listing shows an example of multiple A3
annotations.
Listing 4. Example of annotation A3
1 <wsdl:interface name="NetworkSubscription"
2 sawsdl:modelReference="http://example.org/onto#VideoSubscriptionService
3 http://example.org/onto#VideoOnDemandSubscriptionPrecondition
4 http://example.org/onto#VideoOnDemandSubscriptionEffect">
5 <wsdl:operation name="CheckNetworkConnection" ... />
6 </wsdl:interface>
|
Note that a WSDL interface may be shared by multiple services, therefore the functional description of the interface should be general. A concrete functional description attached to the service then refines the functional description of the interface. Additionally, aggregate interfaces or services (i.e., those that combine multiple potentially independent functionalities) may be annotated with multiple functional descriptions.
Annotation A4: Functional annotations of WSDL Interface operations. Functional descriptions (both capabilities and categories) apply also to interface operations, to indicate their particular functionalities. A reference annotation points from an operation to its appropriate functional description.
Functional annotation of interface operations can be used for services whose functionality has different, separate sub-parts. For example, a network subscription service may offer operations for subscription to a bundle, cancelation of a subscription, or price inquiry. A client will generally only want to use one or two of these operations, not all three. Service invocation will therefore need to select only the operations applicable to the current goal, and invoke them in the correct order, which is also partially implied by the functional operation annotations.
Please note that annotations A3 and A4 apply to
both types of functional descriptions, i.e., a capability made up of
logical conditions, or a category from some functional
classification. It is even possible to combine capabilities and
classification together. However, WSMO-Lite does not define any formal
relationship between capabilities and classifications on the same
component, or between annotations A3 on a service or its
interface, and A4 on the operations of that interface.
Annotation A5: Nonfunctional annotations of WSDL Service. Nonfunctional descriptions apply to a concrete instance of a Web service, that is, a WSDL Service. A reference annotation can point from a service component to a nonfunctional property. The following listing (Listing 5) shows an example of annotation A5, attaching pricing information to a Web service on line 3.
Listing 5. Example of annotation A5
1 <wsdl:service name="ExampleCommLtd"
2 interface="NetworkSubscription"
3 sawsdl:modelReference="http://example.org/onto#VideoOnDemandPrice">
4 <wsdl:endpoint ... />
5 </wsdl:service>
|
Nonfunctional descriptions are always specific to a concrete service, therefore nonfunctional properties should not be expressed on a WSDL interface or on interface operations. In case nonfunctional properties need to be specified on the operations of a service, WSDL binding operation components (which mirror the operations of some interface) may be used to capture these properties.
The major stream of related work is in the frameworks for Semantic
Web services,
including WSMO,
Semantic Markup for Web Services
(OWL-S) and Web
Service Semantics
(WSDL-S).
Recently there has been increased attention given to RESTful
services and Web APIs where, in particular, the work on hRESTS and
MicroWSMO also connects to WSMO-Lite.
WSMO is a top-down conceptual model for SWS that defines four
top-level components: ontologies, mediators, goals and web
services. As we already mentioned, WSMO was the major inspiration for
WSMO-Lite. WSMO-Lite was created to address the need for a lightweight
service ontology that directly builds on the newest W3C standards and
allows bottom-up modeling of services. On the other hand, WSMO is an
established framework for Semantic Web Services representing a
top-down model identifying semantics, useful in a semantics-first
environment. WSMO-Lite adapts the WSMO model and makes its semantics
lighter in the following major aspects:
- Beside Web services, WSMO also defines goals and mediators; these are currently not present in WSMO-Lite which is geared towards only describing services through ontologies.
- Where WSMO expects the functional capabilities of services to
be described using logical expressions framed as preconditions,
assumptions, postconditions, and effects, WSMO-Lite distinguishes
only between preconditions and effects (which may include
assumptions or postconditions, respectively). WSMO-Lite further
specifies a coarser-grained mechanism to describe functionality
using functionality classifications (taxonomies), for which WSMO
does not have direct support.
Earlier, OWL-S was the first major ontology for SWS; it defined
three interlinked ontologies: Service Profile (for the functional and
nonfunctional descriptions), Service Model (for the behavioral
descriptions), and Service Grounding (for physical Web service
access). There was also some work published on OWL-S grounding that
uses SAWSDL [Martin et al.,
2007] [Paolucci et al., 2007]. In
comparison with that work, WSMO-Lite takes the additional step of
simplifying the annotations into a lightweight ontology.
WSDL-S was created in
the METEOR-S
project as a specification of how WSDL can be annotated with semantic
information. WSDL-S itself does not provide a concrete model for SWS,
instead it assumes the concrete model will be expressible as
annotations in WSDL and XML Schema documents. The core parts of WSDL-S
were taken as the basis for SAWSDL. WSDL-S also included WSDL
extensions for attaching preconditions, effects, and categories, but
these were out of scope for SAWSDL, and can be moved out to ontologies
and attached through model references, as we do in WSMO-Lite.
Finally, hRESTS and
MicroWSMO aim to enrich the informal descriptions
of RESTful services, usually available in HTML, with microformat
or RDFa
annotations [Kopecký et al.,
2008]. In effect, hRESTS forms an analogue of WSDL for RESTful
services, and MicroWSMO is analogous to SAWSDL. The WSMO-Lite service
semantics ontology is directly applicable in MicroWSMO and hRESTS
annotations.
The work on WSMO-Lite has been mainly supported by the European
Union project SOA4All. The editors
would like to thank to all the members of the Conceptual Models for
Services Working Group
(CMS WG) for
their advice and input to this document.
[Martin et al., 2007] D. Martin, M. Paolucci, and M. Wagner: Bringing Semantic Annotations to Web Services: OWL-S from the SAWSDL Perspective, in Proc. of 6th International Semantic Web Conference (ISWC/ASWC), pp. 340-352, 2007.
[Kopecký et al., 2008] J. Kopecký, K. Gomadam, and T. Vitvar: hRESTS: An HTML Microformat for Describing RESTful Web Services, in Proc. of IEEE/WIC/ACM International Conference on Web Intelligence and Intelligent Agent Technology (WI-IAT), pp. 619-625, 2008.
[Paolucci et al., 2007] M. Paolucci, M. Wagner, and D. Martin: Grounding OWL-S in SAWSDL, in Proc. of 5th International Conference on Service-Oriented Computing (ICSOC), pp. 416-421, 2007.
[Sheth, 2003] A.P. Sheth: Semantic Web Process Lifecycle: Role of Semantics in Annotation, Discovery, Composition and Orchestration, Invited Talk at
Workshop on E-Services and the Semantic Web, at WWW 2003 (Presentation).
[Studer et al., 2007] R. Studer, S. Grimm, and A. Abecker: Semantic Web Services: Concepts, Technologies, and Applications, Springer-Verlag New York, Inc. Secaucus, NJ, USA. 2007.
[Vitvar et al., 2008] T. Vitvar, J. Kopecký, J. Viskova, and D. Fensel, WSMO-Lite Annotations for Web Services, in Proc. of 5th European Semantic Web Conference (ESWC), pp. 674-689, 2008.