3. From Web Services towards Semantic Services - Unik Wiki

walkingceilInternet and Web Development

Oct 22, 2013 (3 years and 10 months ago)

154 views



Semantic Services



WWRF WG2 White Paper


WG2
-
WPxx


Version 0.
4


Josef Noll
1
,

Matthias Wagner
2
,

Erik Lillevold
1
,

Anna V. Zhdanova
3
,

Kashif
Iqbal
4
, Dumitru Roman
5




1

U
niversity Graduate Center, UniK, Kjeller, Norway

2 DoCoMo, EuroLab, Germany

3
CCSR,

University of Surrey, UK

4
DERI, National University of Ireland, Galway
, Ireland

5
DERI

Innsbruck
,
Austria









2

Table of Content


1.

Introduction

................................
................................
................................
..........

3

2.

Objective and Scope

................................
................................
...........................

3

2.1

Objectives

................................
................................
................................
....

3

2.2

Scope

................................
................................
................................
...........

3

2.3

Approach

................................
................................
................................
......

5

2.4

Semantic Service Scenarios
................................
................................
.........

5

3.

From Web Services towards Semantic Services

................................
.................

6

3.1

Evolution to future service provisioning in Business Enterprises

..................

6

3.2

Semantic Web

................................
................................
..............................

7

3.2.1 Semantic support technologies
................................
................................
...

7

3.2.2 Mobile Ontology: Ontology Adoption for Mobile Services

.........................

15

3.3

Semantic Web Serv
ices

................................
................................
.............

21

3.3.1 OWL
-
S (already explained in section 3.2.1)

................................
.............

21

3.3.2 WSMF (WSMO, WSML, WSMX)

................................
..............................

22

3.3.3 WSDL
-
S

................................
................................
................................
...

27

3.3.4 SWSF (SWSO, SWSL)

................................
................................
.............

27

3.3.5 SAWSDL

................................
................................
................................
..

31

4.

Challenges

................................
................................
................................
........

35

4.1

Service Realisation and Expectations

................................
........................

35

4.2

Open issues

................................
................................
...............................

35

4.2.1 Semantic service architecture interfaces

................................
..................

35

4.2.2 Mediation of ontologies

................................
................................
.............

35

4.2.3

Decision making (reasoning, rules)

................................
..........................

35

4.3

Mobile Semantic Services

................................
................................
..........

35

4.3.1 Mobile Service Provision

................................
................................
..........

35

4.3.2 Semantic Web services vs. Mobile services

................................
.............

35

5.

Business Considerations

................................
................................
...................

36

5.1

To
ols and Practical Usage of Semantics in Web Services

.........................

36

5.2

Business evaluation

................................
................................
...................

36

6.

Related Work

................................
................................
................................
.....

36

7.

Conclusions

................................
................................
................................
.......

36

8.

Acknowledgements

................................
................................
...........................

36

9.

References

................................
................................
................................
........

36



3

History:



V0.
5
, added WSMO/L/X parts; needs some clean
-
up
once the document has
content in each sections and becomes clear the scope of the whitepaper



v
0.3, first texts from SPICE (
UniS
)

inserted



v0.2 Text in the current document is just copied, needs to be adapted/edited



v0.1 only TOC

1.

Introduction


The next gene
ration (beyond 3G) of mobile services and applications must offer
ever increasing levels of value and differentiation (i.e. they have to be attractive,
intuitive and easy
-
to
-
use, with personalization and ubiquitous access.). These
services must also be dev
eloped easily, deployed quickly and, if necessary, altered
efficiently.



2.

Objective and Scope

(copy from previous WhitePaper7) with WWRF WG2 architecture



need to be edited

2.1

Objectives

The objective of the WWRF WG2 is to create a technology independent bl
ue print of
next generation service platform architecture as a basis for a discussion with the
different players; this includes the understanding why market participants have come
up with new architectures as well as a clear understanding about the underly
ing
network architectures.

In this context it is intended to elaborate the unique features to be provided in the
corresponding service domains by telecommunication and IT industries. Also, the
requirements of 3
rd

party providers have to be considered serio
usly. Of course, the
impact on today’s’ decisions can not be excluded always guided by the availability of
technologies.

For WWRF WG2 these objectives intend to bring the WG2 results, which are on a
pure functional level so far, to a more system architect
ure level, identifying (high
level) components, their distribution and their interworking (interfaces and protocols)
based on intensive discussions among experts from operators, manufacturers,
content providers, IT/software industry, and academia.

2.2

Scope

A
next generation mobile service network has to establish its own value proposition
between the stakeholders of next generation mobile service provisioning. It has to
place its unique selling points into the overall service centric environment dealing with
a

number of different access systems. Mobile networks have the potential to act in a
central role within this service environment and is therefore required to be capable to
act as
a
service control environment. It is not the intension to copy all successful

internet services but to support them in an efficient and trustworthy way.

The service platform architecture is interfacing to the service and applications at the
upper layer of a communication system.
The Service Platform Architecture

covers
service sup
port components (such as Generic Service Elements), their relationship
and their internal and external interfaces
.
It usually targets the upper system layers

4

as depicted in Figure 1, however some functions or parts of them are residing in
lower system laye
rs, e.g., location or mobility. When considering ubiquitous
communications environments such as sensor networks the layering is diminishing
anyway.



Figure 1: Target area of the WG2 architecture work shown in the reference model

Service Architecture for
future mobile systems must be able to satisfy requirements
from a broad range of services and different kind of service usage. This can be
reflected in the consideration and analysis of various future life scenarios. With this
approach a scenario centred d
esign process
can be
applied.

During requirement analysis, a number of different
scenarios
have been considered.
They have been
obtained from a number of different sources, including project
results, dedicated studies and published literature. The follow
ing list provides their
references:



ISTAG; Scenarios for Ambient Intelligence in 2010; Final Report, Feb 2001, EC
2001. Available at http://www.cordis.lu/ist/istag.htm



The Activities of 4th Generation Mobile Communications Committee (FLYING
CARPET Ver.2.00
), March 2004, available at
http://www.mitf.org/public_e/archives/contents.html



R. Tafazolli (Editor), Technologies for the Wireless Future: Wireless World Research
Forum (WWRF), ISBN 0
-
470
-
01235
-
8, Wiley 2005



ETSI/TIA Project mesa scenarios, Fall 2003.
Av
ailable at http://www.projectmesa.org



MIT Oxygen project scenarios: Pervasive Human
-
centred computing. Available at
http://oxygen.lcs.mit.edu/Overview.html



NTT DoCoMo Vision 2010 scenarios. Multimedia content available at
http://www.nttdocomo.com/vision201
0/



CyPhone Mediaphone Project - Taxi Trip Scenario, 1999. Available at
http://paula.oulu.fi/Publications/Submited/ICAT99.pdf


5



IST
-
SIMPLICITY project scenarios. Available at http://www.ist
-
simplicity.org/



The Vision of ITEA (SOFTEC Project); Technology Roadm
ap on Software Intensive
Systems. Available at http://www.itea
-
office.org/newsroom/publications/itearoadmap.htm



Bo Karlson et al, Wireless Foresight: Scenarios of the Mobile World in 2015, Wiley,
2003

Although there are a lot of scenarios available, their
impact on service architectures
is rarely obvious. The reason might be that service architectures have not been in the
focus

of the scenario creator at all.

Alternatively,

the scenarios
might be

tailored to
specific service architectures, i.e. those activi
ties do not comply
with
the scenario
ce
ntred design process. In cases where scenarios were in fact considered for the
design process, these are often describing very specific aspects and the resulting
service architectures are very much tailored to them.

To gain the desired demands from future life scenarios on service architectures it is
required to evaluate a selection of scenarios

to derive commonalities
and their
specific features.
A first analysis resulted in a number of aspects which can be taken
as
initial input for the service architecture design:

Future Services will be
context
-
sensitive, adaptive and personalized. They will be available in different networks, with
different bandwidth/QoS and for different devices or multimodal UIs respectively.
S
ervice architectures need to support sophisticated charging and billing, security and
privacy,
identity management, DRM, and trust. The complete service lifecycle is to be
reflected: from service creation and composition to service discovery and delivery.

2.3

Approach

example, needs update

WWRF WG2 proposes the following approach to address the above stated objectives
and scope of
future service
architecture
s

in order to avoid unsuccessful investments:



Identify unique selling points as Value Added Services (= h
igh level features)
provided by Mobile Service Platforms



Verify the Value Added Services with service scenarios



Identify a suitable architecture supporting those features and addressing the above
stated scope



Design of an architecture blueprint in terms of

high level components and interfaces



Identify platforms and
software

engineering methods for its realization


2.4

Semantic Service Scenarios



mobile traveller



emergency case



spice project?



6

3.

From Web Services towards
Semantic

Services

3.1


Evolution to

future serv
ice provisioning

in
Business
Enterprises


Personalization is one of the most important characteristics of future
telecommunications. Personalization means tailoring of services and applications to
the very specific needs of a user to a ubiquitous comfortab
le service environment
together with a single bill service independent of the partners involved in the end to
end value chain. Personalization also means to allow fully manual service
configuration, carrier access without any automatic vertical handover pr
ocedures and
individual invoicing of the individual service partners, in case this is required by any
user for any reasons.

Market participants are faced the following trends:



Content and services are distributed across domains including fixed line and m
obile
networks as well as open (e.g., world wide web) and closed service environments.
Business relations might be distributed.



Internet services are mainly used by fixed line access, whereas hotspots just start to



Technology evolution separates call cont
rol and transport. The directions of centralize
or spread out of the service control are regarded as a chance and a threat for mobile
operators.



Transport charges are dropping tremendously due to excessive IP transport capacities
in back
-
bone networks and
due to increased competition in access networks (flat
rates).



There is a strong impact of IT technologies on telecommunications protocols, system
design and interfaces.



A growing importance of peer to peer services integrates the single user into the group

of service and application providers.



An increasing importance of ubiquitous computing technologies (sensor networks,
RFID, NFC) leads to pervasive interaction with service systems and provide new
possibilities for services based on rich information.



Trus
t in context aware services still suffers from privacy concerns of the users. In
addition legal aspects do also restrict provides in offering rich context aware services.

These aspects lead to following conclusions:



Users will maintain several business rel
ations in different service domains.



Access procedures including authentication and authorization will become more and
more complex and will happen more often.



IP based services will dominate.



Service control is not per definition in the domain of the tele
communication operator.



Telecommunication network operators can hardly survive by providing bit pipes

only.
Value added services are a prerequisite for future business of telecommunication
operators. Mobile network operators have to identify their unique s
elling points and to
force them into the market.



A trustworthy position in the market is important for the acceptance by the users.


7

Figure 2 illustrates our vision of a multi domain network and service environment.
Mobile services platforms of telecommunic
ation providers and mobile operators in
parallel to 3
rd

party service environments provide service through application servers
to the customers. Additional functionalities, e.g., identity manager or billing, are
depicted as separate functions that may be p
rovided also be 3
rd

parties.


3.2

Semantic Web

o

The Semantic Web Stack

o

Ontologies

o

T
ools and practical usage of Semantics in Web services


3.2.1

Semantic support technologies

taken from previous white paper, need to be edited


In order to enable the meaningful commun
ication between different GSEs, developed
by different vendors, a common understanding of used terms and definitions need to
be achieved. But as there is no global common understanding and use of terms this
understanding needs to be established between com
municating parties on the fly. In
order to enable this mechanism, semantic descriptions, using taxonomies and
ontologies need to be used. The following section will introduce the state of the art in
respect to ontologies and taxonomies, describing GSEs, an
d will


Ontologies

Ontologies are for
knowledge sharing

and

reuse
, while languages such as
XML are perfect to
express information

in a
structured and efficient way
. To be
able to discuss with one another, communicating parties need to share a common
termin
ology and meaning of the terms used. Otherwise, profitable communication is
infeasible because of lack of shared understanding. With software systems, this is
especially true

two applications cannot interact with each other without common
understanding of
terms used in the communication. Until now, this common
understanding has been achieved awkwardly by hard
-
coding this information into
applications. This is where ontologies come into the picture. Ontologies describe the
concepts and their relationships

wi
th different levels of formality

in a domain of
discourse.
An ontology is more than just a taxonomy (classification of terms) since it
can include richer relationships between defined terms. For some applications, a
taxonomy can be enough, but without rich

relationships between terms it is not
possible to express domain
-
specific knowledge except by defining new terms.


Ontologies have been an active research area for a long time. The hardest
issue in developing ontologies is the actual conceptualisation of
the domain.
Additionally, to be shared, the ontologies need a representation language.
Languages like XML that define structure of a document, but lacks semantic model,
are not enough for describing ontologies

intuitively an XML document may be clear,
but
computers lack the intuition. In recent years ontology languages based on Web

8

technologies have been introduced. DAML+OIL [2], which is based on RDF Schema
[3], is one such language. It provides a basic infrastructure that allows machines to
make simple in
ferences. Recently, DAML+OIL language was adopted by W3C, which
is developing a Web Ontology Language (OWL) [4] based on DAML+OIL. Like
DAML+OIL, OWL is based on RDF Schema [3], but both of these languages provide
additional vocabulary

for example relation
s between classes, cardinality, equality,
richer typing of properties, characteristics of properties, and enumerated classes

along with a formal semantic to facilitate greater machine readability. The OWL
language has a quite strong industry support, and t
herefore it is expected to become
a dominant ontology language for Semantic Web. In this paper, we use OWL
language when giving examples of ontology encoding.


The following sections tackle different aspects associated with ontologies. They
will provide in

particular a short description of the OWL language, the OWL
-
S
ontology and will then point out critical issues to be deal with as far as ontologies
construction, usage and management & maintenance are concerned.


Ontology construction

This section gives a
n introduction to OWL and OWL
-
S and an overview of the
Protégé tool which provide an ontology editors and tools to access information
available within the ontology.


OWL


The Web Ontology Language


OWL
-

the Web Ontology Language
-

is intended to provide
the explicit meaning
(semantics) of information while languages such as XML mainly focus on the
information structuring.

OWL then facilitates the automatic handling and understanding of information
by computer program (for instance reasoning about this inf
ormation) and then
enhances the level of cooperation between machines. OWL goes far beyond
previous initiatives such as RDF, RDF
-
S (RDF schema) providing extended
capabilities and expressive power. OWL has been built on top of W3C
recommendation stack XML


> XML
-
Schema
-
> RDF
-
> RDF
-
Schema. With respect
to these languages, OWL adds more vocabulary for describing the classes and the
properties that holds between classes and individuals. This enhanced vocabulary
includes set
-
theoretic constructs such as card
inality, intersection, characteristics of
properties and enumerated classes. As far as expressive power is concerned, OWL
is declined into three dialects (from the less expressive but most decidable and
complete) to the most expressive (but less decidable
and complete) that are
respectively OWL
-
lite, OWL
-
DL and OWL
-
FULL.

Very quickly and in addition to the RDFS construct, OWL
-
lite provides
equivalence between classes and properties, equality and inequality between
individuals (member of a class), inverse of

a property. Properties can be stated as
transitive and symmetrical and restrictions can be applied to cardinality and to values
on properties associated to classes. OWL
-
DL and OWL
-
FULL use exactly the same
vocabulary (extending OWL
-
LITE) but some restrict
ions apply to OWL
-
DL (making
the stuff complete and decidable). They provide enumerated classes, classes
disjunction, union, complement and intersection and finally Cardinalities are no more
restricted to 1 or 0. Please refer to OWL Web Ontology Language g
uide for more

9

details about the specifications of these three dialects and full details about their
capabilities.


OWL
-
S


Semantic Mark
-
up Language for Web
-
services


OWL
-
S has been especially designed to allow the definition of (web
-
) service
ontologies.

It is based on the OWL language briefly described above. OWL
-
S is
expected to allow computer software or agent to make intelligent use of web
-
services
and will, non
-
surprisingly focus on



service formal descriptions (aka service profile): or in other word
s: “What the
service does”. Useful for advertising, registering and discovering services;



process model: providing a detailed description of the service operations



grounding: which provides the necessary details to communicate with the
service via exchange

of messages.


These three aspects can be summarised in the following picture.




Figure
1
:
the three concepts of OWL
-
S


This Web Service ontology will then propose a main class
service
. With this
class
are attached three properties (as described above) the name of which are
presents
,
describedBy

and
supports
. Their respective range (as described in
OWL) are respectively the following classes:
serviceProfile
,
serviceModel

and
serviceGrounding
.


Obviously
the ontology defines only the framework


that is the vocabulary


needed to describe the three aspects of a (web
-
) service. The exact content of these
classes will vary from a given service to another. The three following sections
introduce in more detail

the purpose of the three “aspects” of a service description,
which can also be used for describing GSE functionalities:




serviceProfile
: The
serviceProfile

provides three kinds of information that
characterises what the service does:

1)

contact information:
about the entity that provides or operates the service;

2)

functional description: in a nutshell it specifies what are the needed inputs
to run the service, what are the outputs resulting from the service
execution, what is the precondition that has to be va
lid before the service

10

executes and finally what is the effect of the service execution (effect not
captured by the output parameters)

3)

Properties such as category within a classification system, QoS
information, rating, service level agreement information



The purpose of the
serviceProfile

is essentially service selection. It is therefore
well suited to service descriptions located at a repository or registry side. Once
the service has been sought and selected, the profile is of no more use, as all
inform
ation that are to be used for service interaction are found in the
serviceModel
. Obviously maximum consistency has to be ensured between the
formal description of the service as a set of pre
-
post conditions associated with
inputs and outputs and the implem
entation of the service it
-
self, which of course
has to comply with the logical description.


11




processModel
: This class models services as process and builds on a variety of
fields such as Artificial Intelligence (AI), agent communication languages, work o
n

programming languages and distributed systems and so on. The class Process
provides all information about how a given “kind” of service is to be constructed.
These pieces of information relates to inputs, outputs, pre
-
conditions, conditional
post
-
condit
ions (effect) and also how a process can be split into sub
-
processes
and which execution model applies then to the process components (in
sequence, in parallel etc.). A party that volunteers in providing a real
implementation of a given kind of service (ch
aracterised then by an ontology) will
have to make sure that its implementation complies to the process model
described within the service ontology.



Grounding
: The grounding gives all details needed to invoke the service. It
relates about protocols and me
ssage format. It represents the mapping between a
formal specification as described in the ontology to the concrete specification as
implemented by the service provider. It allows then a calling party, a consumer
-

to
build the right messages allowing to in
voke and to make use of the service offered
by the service provider, assuming this service complies with the declared service
characterisation.

Ontology integration

Ontology integration means reusing available ontologies in order to build a new
ontology f
or a given application. Available ontologies may be used only partly, and
further extended, if needed, to better suit the application. Pieces of the reused
ontologies are usually about different domains and subjects in the domains.

Error! Reference source not found.

depicts the ontology integration process
at a conceptual level. Existing ontologies
O
1
,
O
2
, …,
O
n

about different domains
d
1
,
d
2
, …,
d
k
, respectively, are integrated to build a new ontology
O

about domain

d
. To
illustrate the integration, let us consider three ontologies. The location ontology has
been used in GSM positioning application, where the location


constituted by
longitude and latitude


is used in providing location
-
based applications for mobil
e
phone users. Network ontology is a fragment of the one we presented in [1]. The
device ontology models devices and their relationships with networks. It has been
used in content
-
adaptation application, where content is formatted based on the
characterist
ics of a device.




12


Now, let us assume that there is a need for an application that combines the
features of those previous applications, and we need to integrate the th
ree
ontologies. As we can see in
Error!
Reference source not found.
, there are both
syntactically and semantically overlapping concepts, and one could also find
relationships

between the concepts of the three ontologies. The concepts that we are
highlighting are painted with white background colour. The syntactically and
semantically similar concepts are easier cases; only relation stating that the concepts
are equivalent is n
eeded. This is the case with
Location
,
Network
, and
Phone

concepts. The next thing is to find the concepts that are semantically similar, but
have different names. There are two pairs of these kinds of concepts,
WirelessNetwork
/
Wireles
s and
WirelineNetwork
/
Wireline
. As with the previous case,
it is safe to define that in the integrated ontology these are equivalent. The
syntactically similar but semantically different concepts are more problematic. In our
example the
UMTS

and
GSM

are such concepts. In the n
etwork ontology they refer
to network types, whereas in the device ontology they represent devices capable of
operating in the networks. Therefore, in the integrated ontology we have to state that
although these concepts have the same name, they do not mea
n the same thing.

In the following a complete OWL [4] description for these relationships is given:


<?xml version="1.0" encoding="UTF
-
8"?>

<rdf:RDF


xmlns:rdf="http://www.w3.org/1999/02/22
-
rdf
-
syntax
-
ns#"


xmlns:rdfs="http://www.w3.org/2000/01/rdf
-
sch
ema#"


xmlns:owl="http://www.w3.org/2002/07/owl#"


xmlns:net="http://helluli.com/network#"


xmlns:location="http://helluli.com/location#"


xmlns:device="http://helluli.com/device#"




<owl:Ontology rdf:about="">


<rdfs:comment>An sample integr
ated ontology</rdfs:comment>


Figure
2
: Example ontology fragments for the integration


13


</owl:Ontology>



<owl:Class rdf:ID="&net;WirelessNetwork">


<owl:sameAs rdf:resource="&device;Wireless"/>


</owl:Class>



<owl:Class rdf:ID="&net;WirelineNetwork">


<owl:sameAs rdf:resource="&device;Wireline"/>


</
owl:Class>



<owl:Class rdf:about="&net;GSM">


<owl:disjointWith rdf:resource="&device#GSM"/>


</owl:Class>



<owl:Class rdf:about="&net;UMTS">


<owl:disjointWith rdf:resource="&device#UMTS"/>


</owl:Class>


</rdf:RDF>


There are several benefit
s of having the integrated ontology. Firstly, we have
saved time from not having to build ontologies from the scratch. Secondly, and more
importantly, the integrated ontology is more than a sum of the three ontologies
separately, because using the integrat
ed ontology, we can infer relationships
between the concepts in the three ontologies, thus making the integrated ontology
more general. For instance the following inferences can be done:



Because
Location

is composed of
Latitude

and
Longitude
, the
Network

i
s
available at certain {
latitude
,
longitude
}
-
coordinates.



Because
Phone

has a
Location
, all the
Mobile

phones (e.g., GSM and UMTS
in our ontology) also have a location.



Because all the phones have a location, and the networks are available at
certain locati
ons, in the application we can easily have a functionality that
maps the phones to a certain network based on the location.

In addition to these, we can define new relationships between the concepts between
the integrated ontology, if we have sufficient do
main knowledge. For instance, in our
example we can define a relationship
provides

between the
Positioning

and the
Location
, which means that all the positioning devices are able to provide location.
The fragment of OWL description to be added would be as
follows:



<owl:ObjectProperty rdf:ID="provides">


<rdfs:domain rdf:resource="&device;Positioning"/>


<rdfs:range rdf:resource="&location;Location"/>


</owl:ObjectProperty>

Merge of existing ontologies

Merging ontologies differs from the integratio
n of ontologies in such a way that
in merging the existing ontologies are about the same domain and subjects. Merging
is about unifying ontologies: removing duplicate subjects, and finding the similar
kinds of subjects (and maybe treating them as the same)
. As in the case of
integration, the output of the ontology merge operation is a new unified ontology.

In the ontology merge process existing ontologies
O
1
,
O
2
, …,
O
n

about a
domain
s

are merged together to build a harmonized ontology
O

about the same
doma
in. As an example of the ontology merge process, let us consider a situation,
where a mobile operator operating GSM, GPRS, and UMTS network wants to extend
its operation by providing Internet hotspots in a certain locations, such as hotels and
airports. Th
e mobile operator has been using a wireless ontology for mobile
networks, but now seeks for an ontology for Internet service provider as well.
Error!

14

Reference source not found.

shows the two ontologies: Internet service provider
ontology on the left and mobile operator on the right.


Figure
3
: Example ontology fragments to be merged


To merge these two ontologies, (1) the identical concepts are un
ified, (2) the
identical properties are unified, and (3) the duplicate concepts are removed. Also,
should there be concepts with the same names but denoting different things in the
domain, this must be expressed in the new ontology. In our example, however
, there
are no such concepts. The identical concepts are painted with white background.
These concepts are
Network
,
WirelessNetwork
,
CircuitSwitched
, and
PacketSwitched
. These can be unified using the following OWL description:


<?xml version="1.0" encodin
g="UTF
-
8"?>

<rdf:RDF


xmlns:rdf="http://www.w3.org/1999/02/22
-
rdf
-
syntax
-
ns#"


xmlns:rdfs="http://www.w3.org/2000/01/rdf
-
schema#"


xmlns:owl="http://www.w3.org/2002/07/owl#"


xmlns:mobile="http://helluli.com/mobileoperator#"


xmlns:internet="http:
//helluli.com/internetoperator#"




<owl:Ontology rdf:about="">


<rdfs:comment>A merged ontology</rdfs:comment>


</owl:Ontology>



<owl:Class rdf:ID="&mobile;Network">


<owl:sameAs rdf:resource="&internet;Network"/>


</owl:Class>



<owl:Class
rdf:ID="&mobile;WirelessNetwork">


<owl:sameAs rdf:resource="&internet;WirelessNetwork"/>


</owl:Class>



<owl:Class rdf:ID="&mobile;CircuitSwitched">


<owl:sameAs rdf:resource="&internet;CircuitSwitched"/>


</owl:Class>



<owl:Class rdf:ID="&mob
ile;PacketSwitched">


15


<owl:sameAs rdf:resource="&internet;PacketSwitched"/>


</owl:Class>

</rdf:RDF>

There are also two identical properties:
operatedBy
. Although the domain

Network

is the same, the range is not. In mobile operator’s ontology the range

is
MobileOperator
, whereas in the Internet service provider’s ontology it is
InternetOperator
. However, using the domain knowledge while merging the
ontologies, we can remove the
InternetOperator

concept and the
operatedBy

property associated to it, and k
eeps the
MobileOperator

concept and the
corresponding property. After this, we have a merged ontology for a mobile operator,
which is also depicted in
Error! Reference source not found.
.

Now, the mobile network operator could benefit of this new ontology in several
ways. One clear benefit, as with the integration presented earlier, is that the there is
no need to design the Internet service provider’s part of the ontology from

scratch.
The other thing is that the existing concepts within the mobile operator can be
included in the Internet service provider ontology as well. For instance, the network
identifier, which is used as a unique identifier of a mobile network, can be map
ped to
WLAN hotspot as the operator
-
specific SSID, and to phone number for modem dial
-
up lines.



Figure
4
: Example ontology after the merge


3.2.2

Mobile Ontology: Ontology Adoption for Mobile Services


Mobile environments and the We
b converge forming a shared
Distributed
C
ommunication
S
phere

(DCS)
. This causes
the
appearance of new settings to be
supported, e.g., when the user utilizes mobile and fixed devices to interact with
systems. Interaction and connectivity of mobile applicati
ons with the Internet
increase. To ensure interoperation of mobile and Web
services,
applications and
tools
(
running on
heterogeneous
various
service platforms in such a sphere
),


16

developers need to have a shared specification of objects belonging to the sp
here
and their roles. Certain ontologies have already been developed for
the
mobile
communications
domain by employing
area with employment of
Semantic Web
formalisms [Korpipää et al., 2004; Pfoser et al., 2002]. However, widespread and
global adoption of
such ontologies remains a challenge.


Approaching the problem

of interoperation between
the
Web and mobile service
technologies
,

Mobile ontology,
a comprehensive

“higher
-
level”

on
tology for mobile
communication

domain
, is being developed
.
Currently,

defini
tion and implementation

of the

Mobile ontology
is

managed as a collaborative effort amongst participants

of
the EU IST SPICE Integrated Project
1
.


Mobile Ontology



What's Mobile Ontology for?


Mobile Ontolog
y is

be
ing developed as

a comprehensive

“higher
-
level”

on
tology for
mobile communication

domain.

The ontology

is a machine readable schema intended
for sharing knowledge and exchanging information both across people and across
services/applications
, and it

covers domains r
elated to mobile communications
,
specifically, addressing

persons, terminals, services, networks.


The added values of Mobile Ontology are:



Providing an easy and formal way to reference objects from the mobile
communications domain (in particular, to serve as an exchange format between
mobile service enablers);



Providing an opportunity to implement enhanced, ontology
-
based reasoning;



Providing a formal representation of the domain to be used in research and
development projects, and for educational purposes.




Mobile Ontology Overview


DCS
-
related

vocabulary terms, grouped in broad categories
, are presented in
Figure
5
.


DCS Basics



CommunicationSphere



AccessMethod



Availability



PhysicalLocation



Modality



InputModality



OutputModality



Cost

Users and

Groups,
Personalization



Person



UserGroup



Mood



UserRule



CurrentActivity



isUserDefaultActivity



isWillingToCommunicate



Recommendation

Devices



Terminal



Device



EmbeddedDevice



SensorNode



MultimodalityDevice



ConfigurationElement



DescriptionElement



DataElement




1

SPICE:
http://www.ist
-
spice.org/



17



Time



AccessParameter



con
sistsOf



associatedWith



characterizedBy



providesAccessTo



hosts



PhysicalSpace



Outdoors



Indoors



Building



Roomspace



Hall



Floor



Stairway



isInsideOf



hasInside



isOnFloor



isPhysicallyConnectedTo



hasAboveFloor



isAboveFloor



isWithinRangeOf



belongsTo



owns




RecommendedItem



Feature



hasWeight



hasRelevanceScore



hasSupport



hasConfidence



hasPreferred



hasMeanRelevanceScore



hasMeanSup
port



hasMeanConfidence



Profile



Subset



hasType



hasDescription



hasSubset





Datastore



Module



TerminalParameter



hasParent



hasModule



hasA
dditionalConfiguration



hasAdditionalParameters



hasAdditionalDescription



hasData



hasDescription



hasConfiguration



hasSize



hasVersion



hasName



hasEncoding



hasTStamp



hasLocation



hasDisplayName



hasCategory



hasMimeType



hasVendor



isEquippedWith



isAvailableAt





Services



Service



QoS



MultimodalityService



InformationService



KnowledgeService



ContextService


Networks



Network



BluetoothNetwork



WiFiNetwork



GSMNetwork



UMTSNetwork



canBeAccessedVia



isConnectedTo



hostedBy




Figure
5
: DCS
-
re
lated Classes and Properties of Mobile Ontology


Mobile Ontology, in particular, its
DCS

Vocabulary [SPICE D 3.1, 2006] definitions
are written using RDF and OWL [RDF, 2006; OWL, 2006] that makes it easy for
software (both Web
-
based and mobile
-
oriented) to

process facts about the terms in
the DCS vocabulary, and consequently about the things described in DCS
documents. A DCS document/instance data can be combined with other DCS
documents to create unified sources of information.


Example


Here is a very bas
ic annotation describing the state of the communication model:


<?xml version="1.0"?>

<rdf:RDF


xmlns:rdf="http://www.w3.org/1999/02/22
-
rdf
-
syntax
-
ns#"


xmlns:xsd="http://www.w3.org/2001/XMLSchema#"


xmlns:rdfs="http://www.w3.org/2000/01/rdf
-
sche
ma#"


xmlns:owl="http://www.w3.org/2002/07/owl#"


xmlns:p1="http://www.owl
-
ontologies.com/assert.owl#"


xmlns="http://www.ist
-
spice.org/mobile_ontology/2006/5/26/mobile_ontology.owl#"


18


xml:base="http://www.ist
-
spice.org/mobile_ontology/2006/5/26/
mobile_ontology.owl">





<Device rdf:ID="BlueSonyEriccson">


<belongsTo>


<Person rdf:ID="AnnaZ">


<owns rdf:resource="#BlueSonyEriccson"/>


<rdfs:comment rdf:datatype="http://www.w3.org/2001/XMLSchema#string"


></rdfs:commen
t>


</Person>


</belongsTo>


</Device>



</rdf:RDF>


RDF/S and OWL have been chosen as formats to represent the
mobile
ontology,

as
they are current recommendation ontology languages of W3C and have a relatively
large tool support for implementati
on of enablers and applications.


Reuse of Schemata and Ontologies


Certain schemata covering the domains of the Mobile ontology exist and have
already acquired significant communities. Such schemata can be either an output of
the standardization bodies or

coming in a “bottom
-
up” manner from companies and
individuals and being widely accepted by the masses. These schemata and
ontologies can be specified in different knowledge representation formalisms. We
address external sources represented via the most po
pular formats, namely OWL,
RDF/S and XML/S.

Relating and mapping these schemata and to the Mobile ontology is mainly beneficial
for interop
eration of the Mobile ontology community

with other mobile communities.
Thus:

-

mobile ontology developers and users be
nefit acquiring additional knowledge
in the mobile communications domain captured in the existing
OWL, RDF,
XML schemas (i.e., reusing the present knowledge);

-

users of

the

related ontologies and

schemas benefit from a straightforward
m
apping of their schem
as to the M
obile ontology that enables a simpler move
to/involvement

or extension

of the Semantic technologies for these
communities.


Technically, two different approaches to combine the Mobile ontology with the
existing common ontologies and schemata wil
l be considered, depending on whether
the data is encoded via an ontology language (such as PDF/S and OWL) or only via
XML.

Approach 1: RDF/S or OWL encoding

The following principles are valid when considering integration of Mobile ontology
with ontologies

of relevant topics expressed via RDF/S or OWL formalisms:


19

-

when necessary
direct
ly reusing the agreed ontologies

or their parts
when
modelling processes;

-

establish
ing and using

the

library of

mapping
s of these ontologies with the
"higher" level Mobile onto
logy classes

and properties that have similar items as
the used external ontology
. Such a mapping

library

would not be re
-
modelling, but
stating
relations between items in a machine readable format. Equivalence, for
example
,
can be stated
using constructio
ns "owl:sameAs" so that
applications
and enablers
can "understand" that
an item
from the M
obile ontology and an
"imported” agreed upon

ontology are the same.

The RDFS and OWL
-
based standard schemata considered for this approach are
listed in
Table
1
.

Ontology name

Ontology Web address

UAProf

http://www.openmobilealliance.org/release_program/uap_v2_0.html

FOAF

http://www.foaf
-
project.org/

vCard

http://www.w3.org/TR/vcard
-
rdf


Table
1
: OWL and RDFS
-
based Relevant Standards


Approa
ch 2: XM
L

encoding

The followin
g principles are valid when considering integration of Mobile ontology
with schemata of relevant topics expressed via XML formalisms:

-

re
-
modelling XML schemata

in OWL and providing the new sub
-
ontologies

as
relatively independent
ontology sub
-
modules under

the umbrella of the Mobile
ontology
;

-

creation of the converters lifting up the

instance

data

represented solely in the
XML format to RDF.


So the ontology work with
the existing XML schemas

would focus

on
ontologizing/considering the knowledge present the
se schemas, and combining it
with the

Mobile ontology, and not extending these schemata.

The XML
-
based standard schemata considered for this approach are listed in
Table
2
.

Schema
name

Schema Web address

Pr
esence
simple
specification

http://www.openmobilealliance.org/release_program/Presence_simple_v1_0.html


20

Basic
Presence
Data model

http://www.ietf.org/rfc/rfc3863.txt

Generic
Presence
Data Model

http://www.rfc
-
editor.org/rfc/rfc4479.txt

Rich
Presence
Information

http://www.rfc
-
editor.org/rfc/rfc4480.txt

Location
Types
Registry

http://www.ietf.org/rfc/rfc4589.txt


A Presence
-
based
GEOPRIV
Location
Object
Format

http://www.ietf.org/rfc/rfc4119.txt


Table
2
: XML
-
based Relevant Standards



21

3.3

Semantic Web Services


3.3.1

OWL
-
S
: Semantic

Markup for Web Services


OWL
-
S has been especially designed to a
llow the definition of (web
-
) service
ontologies. It is based on the OWL language briefly described
in Section 3.
2.
1
. OWL
-
S is expected to allow computer software or agent to make intelligent use of web
-
services and will, non
-
surprisingly focus on



Service

formal descriptions (aka service profile): or in other words: “What the
service does”. Useful for advertising, registering and discovering services;



process model: providing a detailed description of the service operations



Grounding
: which provides the ne
cessary details to communicate with the
service via exchange of messages.


These three aspects can be summarised in the following
figure
.




Figure
6
:
T
he three concepts of OWL
-
S


This Web Service ontolo
gy will then propose a main class
service
. With this class
are attached three properties (as described above) the
names of which are

presents
,
describedBy

and
supports
. Their respective
range (as described in
OWL) is

respectively the following classes:
ser
viceProfile
,
serviceModel

and
serviceGrounding
.


Obviously the ontology defines only the framework


that is the vocabulary


needed
to describe the three aspects of a (web
-
) service. The exact content of these classes
will vary from a given service to ano
ther. The three following sections introduce in
more detail the purpose of the three “aspects” of a service description, which can
also be used for describing GSE functionalities:




serviceProfile
: The
serviceProfile

provides three kinds of information that

characterises what the service does:

1)

contact information: about the entity that provides or operates the service;

2)

functional description: in a nutshell it specifies what are the needed inputs
to run the service, what are the outputs resulting from the se
rvice
execution, what is the precondition that has to be valid before the service

22

executes and finally what is the effect of the service execution (effect not
captured by the output parameters)

3)

Properties such as category within a classification system, Qo
S
information, rating, service level agreement information



The purpose of the
serviceProfile

is essentially service selection. It is therefore
well suited to service descriptions located at a repository or registry side. Once
the service has been sought

and selected, the profile is of no more use, as all
information that are to be used for service interaction are found in the
serviceModel
. Obviously maximum consistency has to be ensured between the
formal description of the service as a set of pre
-
post c
onditions associated with
inputs and outputs and the implementation of the service it
-
self, which of course
has to comply with the logical description.



processModel
: This class models services as process and builds on a variety of
fields such as Artificial

Intelligence (AI), agent communication languages, work on

programming languages and distributed systems and so on. The class Process
provides all information about how a given “kind” of service is to be constructed.
These pieces of information relates to

inputs, outputs, pre
-
conditions, conditional
post
-
conditions (effect) and also how a process can be split into sub
-
processes
and which execution model applies then to the process components (in
sequence, in parallel etc.). A party that volunteers in provi
ding a real
implementation of a given kind of service (characterised then by an ontology) will
have to make sure that its implementation complies to the process model
described within the service ontology.



Grounding
: The grounding gives all details needed

to invoke the service. It
relates about protocols and message format. It represents the mapping between a
formal specification as described in the ontology to the concrete specification as
implemented by the service provider. It allows then a calling part
y, a consumer
-

to
build the right messages allowing to invoke and to make use of the service offered
by the service provider, assuming this service complies with the declared service
characterisation.


OWL
-
S specification has the status of W3C submission.



3.3.2

WSMF

(WSMO, WSML, WSMX)



The WSMO initiative
2

is the major initiative in the area of SWS in Europe and has the
aim of standardizing a unifying framework for SWS which provides support for
conceptual modelling and formally representing services, as well

as for automatic
execution of services. In this Section we provide a general overview of the elements
that are part of the WSMO approach to SWS (see
Figure below
): the Web service
Modeling Ontology (WSMO)


a conceptual model for Semantic Web Services
, th
e
Web Service Modeling Language (WSML)
-

a language which provides a formal
syntax and semantics for WSMO, and the Web Service Modeling Execution
Environment (WSMX)
-

an execution environment, which is a reference



2

http://www.wsmo.org


23

implementation for WSMO, offering support
for interacting with Semantic Web
Services.



Figure X. The WSMO Approach to SWS.


The Conceptual Model


The Web Services Modeling Ontology (WSMO)

Web Service Modeling Ontology (WSMO)

provides a conceptual model for

structuring the semantic annotation of

services; it defines ontological specifications

for the core elements of SWS. Appropriate frameworks for SWS, need to

integrate
the basic Web design principles, those defined for the Semantic Web,

as well as
design principles for distributed, service
-
orie
ntated computing of the

Web. WSMO is
therefore based on the following design principles:
Web Compliance

(i.e. uses Web
technologies),
Ontology
-
Based
(i.e. uses ontologies as data

model),
Strict
Decoupling
(i.e. elements are defined independently from each

others),
Centrality of
Mediation
(i.e. handling of heterogeneities that naturally

arise in open environments),
Ontological Role Separation
(i.e. distinction between

the desires of users or clients
and available services),
Description versus Implementation

(i.e. differentiation
between the descriptions of SWS elements and

executable technologies),
Execution
Semantics
(i.e. formal execution semantics

of reference implementations), and
Service versus Web service
(i.e. differentiation

between Web services as a
computational entity which is able to achieve a

users goal, and services as the actual
value provided Web services).


The elements of the WSMO ontology are defined in a meta
-
meta
-
model
language

based on the Meta Object Facility (MOF)
1
. Since WSMO is meant
to be a

meta
-
m
odel for Semantic Web services, MOF was identified as the most suitable

language/framework for defining theWSMO elements. In terms of the four MOF

layers (meta
-
meta
-
model, meta
-
model, model layer, and information layer), the

language defining

WSMO corresponds to the meta
-
meta model layer, WSMO itself

constitutes the meta
-
model layer, the actual ontologies, Web services, goals,

and
mediators specifications constitute the model layer, and the actual data described

by
the ontologies and exchanged

between Web services constitute the

information layer
(the information layer in this context is actually related to the

to the notion of
grounding of the semantic descriptions). WSMO provides three

main categories to
structure semantic descriptions. First
, it provides means to

describe
Web services
;
second, it provides means to describe
user goals
referring

to the problem
-
solving
aspect of our framework; and third, it provides means to

ensure interoperability between the various semantic descriptions of he
terogeneous


24

environments: ontologies and mediators. For complete item descriptions,

every
WSMO element is described by a set of non
-
functional properties.

Goals provide
means to characterize user requests in terms of functional and

non
-
functional
requireme
nts. For the former, a standard notion of pre
-

and postconditions

has been
chosen and the later provides a predefined ontology of generic

properties.

Web service descriptions enrich this by an interface definition that defines

access patterns of a service
(its choreography) as well as means to express services

as being composed from other services (its orchestration). More concretely, a

Web
service presents: a capability which is a functional description of a Web

service
describing constraints on the input
and output of a service through the

notions of
preconditions, assumptions, post conditions, and effects, and interfaces

that specify
how the service behaves in order to achieve its functionality. A

service interface
consists of a choreography which describ
es the interface for the

client
-
service
interaction required for service consumption, and an orchestration

which describes
how the functionality of aWeb service is achieved by aggregating

other Web services.

Ontologies provide a first and important means t
o achieve interoperability
between

goals and services as well as between various services themselves. By

reusing standard terminologies different elements can be either linked directly

or
indirectly via predefined mapping and alignments.
The core elements
of an ontolog
y

include: concepts (the basic elements of the agreed terminology for some

problem
domain), relations (model interdependencies between several concepts,

respectively
instances of these concepts), instances (are either defined explicitly

or by
a link to an
instance store), and axioms (define complex logical relations

between the other
elements defined in the ontologies).

Mediators provide additional procedural elements to specify further mappings

that cannot directly be captured through the usag
e of ontologies. Using ontologies

provides real
-
world semantics to our description elements as well as machine

processable formal semantics through the formal language used to specify them.

The
concept of mediation in WSMO addresses the handling of heterog
eneities

occurring
between elements that shall interoperate by resolving mismatches between

different
used terminologies (data level), communicative behavior between

services (protocol
level), and on the business process level. A WSMO mediator

connects the

WSMO
elements in a loosely coupled manner, and provides mediation

facilities for resolving
mismatches that might arise in the process of connecting

different elements defined
by WSMO. More specifically WSMO defines

four types of mediators for connecting
W
SMO elements: OO Mediators connect

and mediate heterogeneous ontologies, GG
Mediators connect Goals, WG Mediators

link Web services to Goals, and WW
Mediators connect interoperating

Web services resolving mismatches between them.


Web Service Modeling Lang
uage (WSML)

The Web
Service Modeling Language WSML
is a language for the specification

of
different aspects of SWS; it takes into account all aspects identified by

WSMO.WSML
comprises different formalisms, most notably Description Logics

and Logic
Programm
ing, in order to investigate their applicability in the context

of ontologies
and Web services. Three main areas can benefit from the use of

formal methods in
service descriptions: ontology description, Declarative functional

description of goals
and Web s
ervices, and description of dynamics. So far,

WSML defines a syntax and
semantics for ontology descriptions. The underlying

formalisms which were
mentioned earlier are used to give a formal meaning to

ontology descriptions in
WSML, resulting in different v
ariants of the language,

which differ in logical

25

expressiveness and in the underlying language paradigms,

and allow users to make
the trade
-
off between provided expressiveness and the

implied complexity for
ontology modeling on a per
-
application basis. We
briefly

describe these variants in
the following:



WSML
-
Core is based on the intersection of the Description Logic SHIQ and

Horn Logic (which is based on Description Logic Programs). It has the least

expressive power of all the WSML variants. The main featu
res of the language

are concepts, attributes, binary relations and instances, as well as

concept and

r
elation hierarchies and datatype support.




WSML
-
DL captures the Description Logic SHIQ(D), which is a major part

of
the (DL species of) OWL.

WSML
-
Flight
is an extension of WSML
-
Core which
provides a powerful rule

language. It adds features such as meta
-
modeling,
constraints and nonmonotonic

negation.



WSML
-
Flight is based on a logic programming variant of FLogic

and is
semantically equivalent to Datalog wi
th inequality and (locally)

stratified
negation. WSML
-
Flight is a direct syntactic extension of WSMLCore

and it is a
semantic extension in the sense that the WSML
-
Core subset

of WSML
-
Flight
agrees with WSML
-
Core on ground entailments).



WSML
-
Rule extends

WS
ML
-
Flight with further features from Logic
Programming,

namely the use of function symbols, unsafe rules and
unstratified negation

under the Well
-
Founded semantics.

WSML
-
Full
unifiesWSML
-
DL andWSML
-
Rule under a First
-
Order umbrella

with extensions
to suppo
rt the nonmonotonic negation of WSML
-
Rule.


Several features make WSML unique from other language proposals for the

SW and
SWS. Amongst them the most important are: one syntactic framework

for a set of
layered languages (no single language paradigm will be

sufficient for

all SWS use
cases, thus different language variants of different expressivenessare needed);
normative, human readable syntax (allows for easier adoption of

the language by the
users); separation of conceptual and logical modeling (the

conce
ptual syntax allows
for easy modeling of ontologies, Web services, goals,

and mediators, and the logical
expression syntax allows expert users to refine

definitions on the conceptual syntax),
semantics based on well known formalisms

(WSML captures well
-
kno
wn logical
formalisms in a unifying syntactical framework,

while maintaining the established
computational properties of the original

formalisms); and a frame
-
based syntax (it
allows the user to work directly on

the level of concepts, attributes, instances

and
attribute values, instead of at the

level of predicates).


These above mentioned features are mainly due to the two pillars of WSML,

namely
a language independent conceptual model for ontologies, Web services,

goals and
mediators, based on WSMO, and r
euse of several well
-
known logical

language
paradigms in one syntactical framework.


Web Service Execution Environment (WSMX)


Web Service Execution Environment (WSMX) is an execution environment which
enables discovery, selection, mediation, composition a
nd invocation ofSWS. WSMX
is based on the conceptual model provided by WSMO, being at the same time its
reference implementation. WSMX’s scope is to provide

a testbed for WSMO and to
prove its viability as a mean to achieve dynamic

interoperability of SWS.

In this

26

section aspects of WSMX functionality and

WSMX external behavior are briefly
presented.

WSMX functionalities can be classified in two main categories: first is the

functionality required to support the operations (e.g. discovery or invocation)

on

SWS
and second, the additional functionality coming from the enterprise system

features
of the framework. In the first case, the overall WSMX functionality

can be seen as an
aggregation of the components’ functionalities, which are part

of the WSMX
archit
ecture. In the second case, WSMX offers features such as a

plugging in
mechanism that allows the integration of various distributed components,

an internal
workflow engine capable of executing formal descriptions of

the components
behavior or a resource ma
nager that enables the persistency of

WSMX external
behavior is described in terms of so
-
called entry points which

represents standard
interfaces that enable communication with external entities.

There are four mandatory entry points that have to be availa
ble in each
working

instance of the system. Each of these entry points triggers a particular
execution

semantics which on its turn, selects the set of components to be used for
that

particular scenario:



One
-
way goal execution. This entry point allows the r
ealization of
goal without any back and forth interactions. In this simplistic scenario the
requester

has to provide a formal description of its goal in WSML and the data

required for the invocation and the system will select and execute the service

on beh
alf of the requester. The requester might receive a final confirmation,

but this step is optional.



Web Service discovery. A more complex (and realistic) scenario
is to only

consult WSMX about the set of Web services that satisfy a given goal
(the

selection

might take place later, e.g. at the requester side). This entry
point

implies an synchronous call, the requester provides a goal andWSMX
return

a set of matching Web services.



Send message. After the decision on which service to use was
already made,

a co
nversation involving back and forth messages between the
requester and

WSMX can start. The input parameter is a WSML message that
contains

a set of ontology instances and references to the Web service to be
invoked

and to the targeted choreography (if it i
s available).



Store entity in the registry. This entry point provide an interface
for storing

WSMO entities (described in WSML) in the repository.



It is important to note that all the incoming and outgoing messages are
represented
in WSML and they are ei
ther fragments of WSMO ontologies or WSMO

entities (Web
services, goals, mediators, or ontologies). That is, only WSML is

used as WSMX
internal data representation, and all the necessary adaptations

operations to and
from other representation formats are h
andled by an adapters

framework.

WSMX architecture consists of a set of loosely decoupled components

andfollows the fundamental principles of a Service Oriented Architecture (SOA).

Even if WSMX provides default implementations for all the components in the

architecture, self
-
contained components with well defined functionalities can be

easily
plugged
-
in and plugged
-
out at any time.


27

SWSF (SWSO, SWSL)

The Semantic Web Serv
ices Framework
[
SWSF
]

specification
aims to define

a
representational framework
for Web

Services
that spans the full range of service
-
related concepts.


SWSF defines
an ontology

i.e.

Semantic Web Services Ontology
[
SWSO
]

and
a language

i.e.

Semantic Web Services Language
[
SWSL
]

for
richer
semantic specification
s

of
Web Services
.

SWSF (SWSO,
SWSL) specifications have

the status of W3C submission
.


Semantic Web Services Ontology (SWSO)

is expressed in two forms: FLOWS, the
First
-
order Logic Ontology for Web Services; and ROWS, the Rules Ontology for
Web Services, produced by a systematic transl
ation of FLOWS axioms into the
SWSL
-
Rules language. FLOWS has been specified in SWSL
-
FOL, the first
-
order
logic language developed by SWSL effort.


The goal of
FLOWS

is to enable reasoning
about
essential aspects of Web service
behaviour e.g. descriptions
of Web services that enable automated discovery,
composition and verification
.
The
F
LOWS

allow
s

creation of declarative descriptions
of a W
eb
service that

can be mapped
either automatically or through a systematic
proces
s

to executable specifications
.

FLOW
S can
also
support variety of c
ontexts
including:


1.

black box modelling of a service, where on
ly the messaging is observable;

2.

modelling the internal atomic processes that a service performs, along with the
impact these process
es have on the real world (e.g.

inventories, financial
accounts);

3.

modelling
other

properties of a service, including all message APIs, all or
some of the internal processing, and some or all of the internal process and
data flows.



The
FLOWS represents

an attempt to extend the OWL
-
S e
ffort

in
following

ways
.
Firstly, OWL
-
S was not focused on interoperating with or providing semantics for
industry process
modelling

formalisms such as BPEL. Indeed, FLOWS provides the
ability to model in an abstract, semantically motivated manner, several

key Web
services standards, including WSDL, BPEL, and WS
-
Choreography. A second
difference is that FLOWS strives to explicitly model more aspects of Web services
than OWL
-
S. This includes primarily the fact that FLOWS can readily model
:

process
models usi
ng a variety o
f different paradigms

and
data flow between services

(
either
through message passing or access to shared
data
)
.

FLOWS is based on first
-
order
logic, which means that it can express considerably more than can be expressed
using OWL
-
DL (upon wh
ich OWL
-
S is based).

The use of first
-
order logic enables a
more refined approach than possible in OWL
-
S to representing different forms of data
flow that can arise in Web services.


Following the high
-
level structure of OWL
-
S, FLOWS has three major compon
ents:
Service Descriptors, Process Model, and Grounding.


Service descriptors

provide basic information about a Web service. This
descriptive information may include non
-
functional meta
-
information and/or
provenance information. Service descriptors are of
ten used to support
automated Web service discovery. The Service Descriptors include Service
Name, Service Author, Service Contract Information, Service Contributor,

28

Service Description, Service URL, Service Identifier, Service Version, Service
Release Dat
e, Service Language, Service Trust, Service Subject, Service
Reliability, and Service Cost. The set is expected to be extended with
properties that are domain specific such as those contained in the OWL
-
S
appendices and those in WSMO's [
Bruijn05
] coverage service descriptor (or
"non
-
functional property" as it is called in their proposed specification). The set
may also be expanded with properties commonly used in other standards su
ch
as those found in Dublin Core.


Process Model:

Since
Process Specification Language

[PSL]

is used as a
generic ontology for processes, extensions need to be specified to provide
concepts useful in context of Web Services. In particular, the FLOWS proces
s
model adds two fundamental elements to PSL:

1.

The structured notion of a
tomic process as found in OWL
-
S
.


2.

Infrastructure for specifying various forms of data flow.


FLOWS currently consists of six ontology modules that specify core intuitions
about the ac
tivities associated with a service together with classes of
composite activities that are used to express different constraints on the
occurrence of services and their subactivities.



FLOWS
-
Core

introduces the basic notions of services as activities
compose
d of atomic activities.



Control Constraints

axiomatize the basic constructs common to
workflow
-
style process models. In particular, the Control Constraints in
FLOWS include the concepts from the process model of OWL
-
S.



Ordering Constraint

allows the spec
ification of activities defined by
sequencing properties of atomic processes.



Occurrence Constraints

support the specification of nondeterministic
activities within services.



State Constraints

support the specification of activities whose activities
are
triggered by states (of an overall system) that satisfy a given
condition.



Exception Constraints

provide some basic infrastructure for modelling
exceptions.


Grounding:
The SWSO concepts for service description and the instantiations
of these concepts th
at describe a particular service, are
abstract

specifications, in the sense that they do not specify the details of particular
message formats, transport protocols, and network addresses by which a Web
service is accessed. The role of the
grounding

is to p
rovide these more
concrete

details. The Web Services Description Language (WSDL) provides a
well developed means of specifying these kinds of details. Therefore,
a SWSO
service description

can be grounded

by defining mappings from certain SWSO
concepts to
WSDL constructs that describe the concrete realizations of these
concepts. SWSO groundings are deliberately decoupled from SWSO abstract
service descriptions, so as to enable reusability.


29


ROWS

is a (partial) translation of FLOWS into SWSL
-
Rules. The inten
t of each
ROWS axiom is identical to what is explained above for the corresponding axioms of
FLOWS. However, because SWSL
-
Rules is inherently less expressive than SWSL
-
FOL, some axioms in ROWS are weakened with respect to the corresponding axiom
in SWSL
-
FO
L.


Semantic Web Services Language (SWSL)

can be used to specify the Semantic
Web Services Ontology (SWSO) as well as individual Web services. SWSL is a logic
-
based language for specifying formal characterizations of Web service concepts and
descriptions o
f individual services. It includes two sublanguages:

SWSL
-
FOL
, a full first
-
order logic language, which is used to specify the service
ontology (SWSO) and is intended to provide interoperability with other first
-
order
based process models and service onto
logies. First
-
order logic is found more suitable
for

specifying process ontologies

e.g. s
ame approach is taken by
PSL
. Since SWSL
-
FOL is intended largely as a specification language for SWSO, specialized reasoners
will be used to reason with the service on
tology. In addition SWSL
-
FOL will serve as
a common platform to support semantic interoperability among the different first
-
order
based service ontologies, such as OWL
-
S [
OWL
-
S 1.1
].

The

SWSL
-
Rules

is a rule
-
based sublanguage, which can be used both as a
specification and an implementation language. SWSL
-
Rules is designed to be an
actual language for service specification. As a language, SWSL
is domain
-
independent and
does not

include any constructs specific to services. Those
constructs are defined by the Semantic Web Service Ontology. SWSL
-
Rules is a
rule
-
based language with non
-
monotonic semantics. Such languages are better
suited for tasks
that have programming flavor and that naturally rely on default
information and inheritance. These tasks include service discovery, contracting,
policy specification etc. For reasoning purposes almost all of the features of SWSL
-
Rules have been implemented

in FLORA
-
2 [
Yang04
], SweetRules [
Grosof2004b
]
, or
the commercial Ontobroker [
Ontobroker
] system.


3.3.3

WSDL
-
S

The current WSDL standard operates at the syntactic level and lacks the semantic
expressivity n
eeded to represent the requirements and capabilities of Web Services.
Semantics can improve software reuse and discovery, significantly facilitate
composition of Web services and enable integration of legacy applications as part of
business process integra
tion.

The Web Service Semantics

[
WSDL
-
S
]

document
defines a mechanism to associate semantic annotations

(via WSDL extensibility
elements)

with Web services that are described using Web Service Description
Language (WSDL).

Web Service Semantics proposal ass
umes that formal semantic
models relevant to the services already exist.

The type of semantic information that
would be useful in describing a Web Service encompass the concepts defined by the
semantic Web community in OWL
-
S [
OWL
-
S
] and other efforts [
METEOR
-
S
,
WSMO

and
SWSF
]. The semantic information s
pecified in
WSDL
-
S

document includes
definitions of the precondition, input, output and effects of Web service operations.


A quick summary of the extensibility elements and attributes provided in
WSDL
-
S

proposal are given below:


30



modelReference
: An extensi
on attribute

to specify the association between a
WSDL entity and a concept in some semantic model. It can be added to a
complex type, element, operation, as well as the extension elements
-

precondition

and
effect
.



schemaMapping

is an extension attribute

which is added to XSD elements
and complex types, for handling structural differences between the schema
elements of a Web service and their corresponding semantic model concepts.



precondition

and
effect

are
two new extension attributes which are
specifi
ed
as child elements of the
operation

element. Preconditions and effects are
primarily used in service discovery, and are not necessarily req
uired to invoke
a given service
.



C
ategory

is a
n extension attribute on the
interface

element
. It consists of
servic
e categorization information that could be used when publishing a
service in a Web Services registry such as UDDI. Semantic categorization of
UDDI registries using ontologies was proposed in [
SVS04
,
MWSDI
]

In th
e

sample

below
, a simple Web service for an item purchase order

is
described using WSDL
-
S extensi
bility attributes
.

The semantic concepts and their
relationship
s
are modelled in an OWL ontology
,
PurchaseOrder.owl.

The inputs,
outputs and operations of the ProcessPurchaseOrder service are annotated with
semantics. Two new elements namely preconditions and effects are introduced as
extensibility elements to the ope
ration construct in WSDL, and an extensibility
element called category is added to the interface construct.

<?xml version="1.0" encoding="iso
-
8859
-
1"?>

<definitions name="PurchaseOrder"


targetNamespace="http://lsdis.cs.uga.edu/projects/meteor
-
s/wsdl
-
s/exa
mples/purchaseOrder.wsdl"


xmlns="http://www.w3.org/2004/08/wsdl"


xmlns:tns="http://lsdis.cs.uga.edu/projects/meteor
-
s/wsdl
-
s/examples/purchaseOrder.wsdl"


xmlns:xs="http://www.w3.org/2001/XMLSchema"


xmlns:xsd1="http://lsdis.cs.uga.edu/projects/meteor
-
s/
wsdl
-
s/examples/purchaseOrder.wsdl"


xmlns:wssem="http://lsdis.cs.uga.edu/projects/meteor
-
s/wsdl
-
s/examples/purchaseOrder.wsdl"


xmlns:POOntology="http://lsdis.cs.uga.edu/projects/meteor
-
s/wsdl
-
s/ontologies/PurchaseOrder.owl"


xmlns:Rosetta="http://lsdis.c
s.uga.edu/projects/meteor
-
s/wsdl
-
s/ontologies/rosetta.owl">


<types>


<xs:import namespace="http://lsdis.cs.uga.edu/projects/meteor
-
s/wsdl
-
s/examples/purchaseOrder.wsdl"


schemaLocation="http://lsdis.cs.uga.edu/projects/meteor
-
s/wsdl
-
s/example
s/WSSemantics.xsd"/>


<xs:import namespace="http://lsdis.cs.uga.edu/projects/meteor
-
s/wsdl
-
s/examples/purchaseOrder.wsdl"


schemaLocation="http://lsdis.cs.uga.edu/projects/meteor
-
s/wsdl
-
s/examples/POBilling.xsd" />


<xs:import namespace="http
://lsdis.cs.uga.edu/projects/meteor
-
s/wsdl
-
s/examples/purchaseOrder.wsdl"


schemaLocation="http://lsdis.cs.uga.edu/projects/meteor
-
s/wsdl
-
s/examples/POItem.xsd" />


<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"


31


targetNamespace
="http://lsdis.cs.uga.edu/projects/meteor
-
s/wsdl
-
s/examples/purchaseOrder.wsdl"


xmlns="http://lsdis.cs.uga.edu/projects/meteor
-
s/wsdl
-
s/examples/purchaseOrder.wsdl">


<!
--
Semantic annotations for these complex types are given in
their res
pective type

definitions
--
>


<xs:complexType name="processPurchaseOrderRequest">


<xs:all>


<xs:element name="billingInfo" type="xsd1:POBilling"/>


<xs:element name="orderItem" type="xsd1:POItem"/>


</xs:a
ll>


</xs:complexType>




<!
--
Semantic annotation is added directly to leaf element
--
>


<xs:element name="processPurchaseOrderResponse"
type="xs:string"


wssem:modelReference
="POOntology#OrderConfirmation"/>


</xs
:schema>


</types>


<!

Annotating input and output elements
--
>



<interface name="PurchaseOrder">


<!
--
Category is added as an extensible element of an
interface
--
>


<
wssem:category

name="Electronics"
taxonomyURI="http://www.naic
s.com/" taxonomyCode="443112" />


<operation name="processPurchaseOrder" pattern="wsdl:in
-
out"


wssem:modelReference
="Rosetta:RequestPurchaseOrder" >


<input messageLabel ="processPurchaseOrderRequest"



element="tns:processPurchaseOrderRequest"/>


<output messageLabel ="processPurchaseOrderResponse"


element="processPurchaseOrderResponse"/>



<!
--
Precondition and effect are added as extensible elements
on an operation
--
>


<
wssem:precondition

name="ExistingAcctPrecond"


wssem:modelReference
="POOntology#AccountExists"/>


<
wssem:effect

name="ItemReservedEffect"


wssem:modelReference
="POOntology#ItemReserved"/>


</operation>



</interface>

</definitions>



An important aspect that WSDL
-
S does not currently consider is the
behavioural

aspect of a Web service, which among other things specifies the order in which the
services operations should be invoked. This has been referred
to as (
WSMO

-
choreography
, METEOR
-
S



interaction protocol
,
BPEL



abstract process
,
WSCL
-

conversation

language
)

in other related work
. Currently, the ordering of constraints
can be captured using preconditions by specifying the operations that are to be

invoked before invoking an operation.

WSDL
-
S specification has the status of W3C member submission.


3.3.4

SAWSDL

SAWSDL

(Semantic Annotations for WSDL) specification

[
SAWSDL
]

defines a set
of extension attributes for the Web Services Description Language [
WSDL 2.0
]
,


32

that allow to describe additional semantics of WSDL components

such as input
and output message structures, interfaces and operations
.

This specification does
not address the annotation o
f WSDL components that deal with service
implementations e.g. binding, service and endpoint.


SAWSDL

specification defines how semantic annotation is accomplished using
references to semantic models, e.g. ontologies. SAWSDL does not specify a
language for
representing the semantic models. Instead it provides mechanisms
by which concepts from the semantic models, typically defined outside the WSDL
document, can be referenced from within WSDL components using annotations.

To accomplish semantic annotation, SA
WSDL defines extension attributes that
can be applied both to WSDL elements and to XML Schema elements.

The
annotations on schema types can be used during Web service discovery and
composition. In addition, SAWSDL defines an annotation mechanism for
specif
ying the structural mapping of XML Schema types to and from an ontology
such mappings could be used during invocation, particularly when mediation is
required.


A summary of the extension attributes defined by SAWSDL is given below:



modelReference

is an ex
tension attribute

to specify the association
between a WSDL components and a concept in som
e semantic model. It is
used
to annotate XSD complex type definitions, simple type definitions,
element declarations, and attribute declarations as well as WSDL
inte
rfaces, operations, and faults.



Two

extension attributes, named
liftingSchemaMapping

and
loweringSchemaMapping

that are added to XML Schema element
declarations, complex type definitions and simple type definitions for
specifying mappings between semantic

data and XML. The mappings can
be used during service invocation.

The semantic annotation mechanism defined by this specification does not rely on
any particular semantic modeling language. It only requires that the semantic
concepts defined in it be ide
ntifiable via URI references.


In order to illustrate the concepts of SAWSDL,
a
Web service

interface is
annotated

using
SA
WSDL

extension attributes
.
The WSDL including semantic annotations for
this service is given below.

<wsdl:description


targetNamespa
ce="http://www.w3.org/2002/ws/sawsdl/spec/wsdl/order#"


xmlns="http://www.w3.org/2002/ws/sawsdl/spec/wsdl/order#"


xmlns:wsdl="http://www.w3.org/2006/01/wsdl"


xmlns:xs="http://www.w3.org/2001/XMLSchema"


xmlns:sawsdl="http://www.w3.org/2002/ws/sawsdl/
spec/sawsdl#">



<wsdl:types>


<xs:schema
targetNamespace="http://www.w3.org/2002/ws/sawsdl/spec/wsdl/order#"


elementFormDefault="qualified">



<xs:element name="OrderRequest"


33


sawsdl:modelReference="http://www.w3.org/2002/ws/sawsdl
/spec/ontology/p
urchaseorder#OrderRequest"



<!

SAWSDL Schema
Mapping
--
>


sawsdl:loweringSchemaMapping="http://www.w3.org/2002/ws/sawsdl/spec/map
ping/RDFOnt2Request.xml">


<xs:complexType>


<xs:sequence>


<xs:element na
me="customerNo" type="xs:integer" />


<xs:element name="orderItem" type="item" minOccurs="1"
maxOccurs="unbounded" />


</xs:sequence>


</xs:complexType>


</xs:element>


<xs:complexType name="item">


<xs:all>



<xs:element name="UPC" type="xs:string" />


</xs:all>


<xs:attribute name="quantity" type="xs:integer" />


</xs:complexType>


<xs:element name="OrderResponse" type="confirmation" />


<!
--

Annotating Simple Types With Model Ref
erence
--
>



<xs:simpleType name="confirmation"


sawsdl:modelReference="http://www.w3.org/2002/ws/sawsdl/spec/ontology/p
urchaseorder#OrderConfirmation">


<xs:restriction base="xs:string">


<xs:enumeration value="Confirmed" />


<xs:enumeration value="Pending" />


<xs:enumeration value="Rejected" />


</xs:restriction>


</xs:simpleType>


</xs:schema>


</wsdl:types>


<!
--

Annotating Interfaces With Model Reference
--
>



<wsdl:interface name="Order
"


sawsdl:modelReference="http://example.org/categorization/products/elect
ronics">


<wsdl:operation name="order"
pattern=
http://www.w3.org/2006/01/wsdl/in
-
out


<!
--

Annotating Operations With M
odel Reference
--
>


sawsdl:modelReference="http://www.w3.org/2002/ws/sawsdl/spec/ontology/p
urchaseorder#RequestPurchaseOrder">


<wsdl:input element="OrderRequest" />


<wsdl:output element="OrderResponse" />


</wsdl:operation>


</wsdl:i
nterface>

</wsdl: description>



SAWSDL specification is currently a W3C working draft.


34







35

4.

Challenges


-

Semantic service provisioning


-

Mobile Semantic Servi
ces


-

Service grounding in the user context


-

Etc.


4.1

Service Realisation
and Expectations

describe how some of the scenarios have been realised, e.g. in ASG
-
platform.org



4.2

Open issues

4.2.1

Semantic service architecture interfaces

4.2.2

Mediation of o
ntologies

4.2.3

Decision making (reasoning, rules)

taken from previous white paper, to be edited

Reasoning is the general process of inferring new knowledge from a base of
existing knowledge. The production of this new knowledge is made possible by
applying “rul
es” over the set of existing knowledge also called classically “base of
facts”.


4.3

Mobile
Semantic Services


4.3.1

Mobile Service Provision

some lines about which technologies to use



4.3.2

Semantic Web services vs. Mobile

services




H
ow do these two technologies combin
e?



Relation of Semantic Web services to ontologies from

a mobile communications
domain



OWL based mobile services



36

5.

Business Considerations

5.1

Tools and Practical Usage of Semantics in Web Services


5.2

Business evaluation


take mobile/roaming example


6.

Related Wor
k

JosefNoll: not sure if we need this chapter, or if it should be moved to chapter on
Semantic Web Services

(chapter 3.3)
?


KashifIqbal: I think there is no need for this chapter.

-

SAWSDL


-

OWL
-
S


-

Etc.


7.

Conclusions

bla, bla
.


8.

Acknowledgements


This work has
been partly supported by European Commission under IP SPICE (IST
-
2006
-
027617).


9.

References


FOAF, 2006.
http://foaf
-
project.org/



[
Korpipää et al., 2004
]
P. Korpipää, J. Häkkilä, J. Kela, S. Ronkainen, and I. Käns
älä,
“Utilising context ontology in mobile device application personalization,” ACM
International Conference Proceeding Series; Vol. 83 Proceedings of the 3
rd

international conference on Mobile and ubiquitous multimedia, ACM Press, 2004, pp.
133
-
140.


OWL,

2006.
http://www.w3.org/2004/OWL/



[Pfoser et al., 2002]
D. Pfoser, E. Pitoura, and N. Tryfona, “Metadata Modeling in a
Global Computing Environment,” GIS’02, November 8
-
9, 2002, McLean, Virginia,
USA., ACM Pr
ess, 2002.



37

RDF, 2006.
http://www.w3.org/RDF/


[
SPICE D 3.1, 2006.
]

Zhdanova, A.V.,
Boussard, M.,
Cesar, P., Clavi
er, E.,
Gessler,

S.,
Hesselman, C.,
Kernchen, R.,

Le Berre, O.,

Melpignano, D.,
Nani, R.,

Patrini, L.,

R
ä
ck, C.,

Strohbach, M.,

Sutterer, M.,

van Kranenburg, H.,
Villalonga, C.,
Vitale, A
.

Ontology Definition for the DCS and DCS Resource Description, User Rules
”,
EU
IST SPICE IP deliverable

(D3.1), 2006.


[SWSF]

Semantic Web Services Framework,
http://www.w3.org/Submission/SWSF/

[OWL
-
S 1.1]

OWL
-
S: Semantic Markup for Web Services
. David Martin, editor. Technical
Overview (associated with O
WL
-
S Release 1.1).

[Yang04]

FLORA
-
2

User's Manual
. G. Yang, M. Kifer, C. Zhao, V. Chowdhary. 2004.

[
Grosof2004b]

SweetRules: Tools for Semantic Web Rules and Ontologies, including
Translation, Inferencing, A
nalysis, and Authoring
. B.N. Grosof, M. Dean, S.
Ganjugunte, S. Tabet, C. Neogy, and D. Kolas.
http://sweetrules.projects.semwebcentral.org
. Software toolkit and
documentation. Version 2.0, Dec.
2004.

[Ontobroker]

Ontobroker 3.8
. Ontoprise, GmbH.

[Bruijn05]

Web Service Modeling Ontology (WSMO)
. J. de Bruijn, C. Bussler, J.
Domingue, D. Fensel, M. Hepp, M. Kifer, B. Kaenig
-
Ri
es, J. Kopecky, R. Lara,
E. Oren, A. Polleres, J. Scicluna, M. Stollberg.
DERI Technical Report.

[PSL]


Process Specification Language,
http://www.mel.nist.gov/psl/

[SWSL]


Semantic Web Services Language,
http://www.w3.org/Submission/2005/SUBM
-
SWSF
-
SWSL
-
20050909/

[SWSO]


Semantic Web Services Ontology,
http://www.w3.org/Submission/2005/SUBM
-
SWSF
-
SWSO
-
20050909/

[WSDL
-
S]

WSDL
-
S: Adding

semantics to WSDL
-

White paper,
http://lsdis.cs.uga.edu/library/download/wsdl
-
s.pdf


[OWL
-
S]

Web Ontology Language for Web Services,

http://
www.daml.org/services/


[
WSDL 2.0
]

Web Services Description Language (WSDL) Version 2.0 Part 1: Core
Language
, R. Chinnici, J
-
J. M
oreau, A. Ryman, S. Weerawarana, Editors. World
Wide Web Consortium, 27 March 2006. This version of the "Web Services
Description Language (WSDL) Version 2.0 Part 1: Core Language" Specification is
available is available at http://www.w3.org/TR/2006/CR
-
wsd
l20
-
20060327. The
latest
version of "Web Services Description Language (WSDL) Version 2.0 Part 1: Core
Language"

is available at http://www.w3.org/TR/wsdl20.

[WSMO]

Web Service Modeling Ontology,
http://www.wsmo.org/



38

[MWSDI]

K. Verma, K. Sivashanmugam, A. Sheth, A. Patil, S. Oundhakar and J. Miller,
METEOR
-
S WSDI: A Scalable Infrastructure of
Registries for Semantic
Publication and Discovery of Web Services
, Journal of Information Technology
and Management, Special Issue on Universal Global Integration, Vol. 6, No. 1
(2005) pp. 17
-
39. Kluwer Academic Publishers.

SVS04]

K. Sivashanmugam, K. V
erma, A. P. Sheth,
Discovery of Web Services in a
Federated Registry Environment
, Proceedings of IEEE Second International
Conference on Web Services, June, 2004, pp. 270
-
278

[MET
EOR
-
S]

METEOR
-
S: Semantic Web Services and Processes,
http://lsdis.cs.uga.edu/projects/meteor
-
s/


[SAWSDL]

Semantic Annotation of WSDL,
http://www.w3.
org/TR/sawsdl/