Bringing Semantics to Web Services with OWL-S

. 指導教授：吳秀陽 　報告人：陳建博 學號：69621501

　

2

Outline

2. Overview of OWL-S

3. The service Profile

4. The Process model

7. Conclusion

1. Introduction

5. The Grounding subontology

6. Technology based on OWL-S

3

1. Introduction – Why Semantic Web Services need ?

1) Current Web Services provide a basis for interoperability

between services, and emphasize the specification of

communication technique.

2) Existing program language like Java, PHP, C# can automatically

produce code from its datatypes to their WSDL.

3) Without a semantic description of what happens when a Web

Service is used, a human programmer is still to figure out from

reading the natural-language description.

4) Semantic Web Services is a research field that endeavor to

automation of information use and dynamic interoperability

are the primary objectives.

4

1. Introduction – How Semantic Web Service evolve ?

1) Key steps of the Semantic Web has been the development of

standard languages such as URI, XML(S), RDF(S), OWL …..

2) The central question is : “Can we use Semantic Web

techniques to automate dealing with Web Service?”

3) The following subtask is expected Semantic Web to do in W3C:

Automatic Web service discovery.

Automatic Web service invocation.

Automatic Web service composition and interoperation.

4) OWL-S is an interface between Semantic Web and Web

Service, and provides a framework for describing both the

functions and advertisements for Web Services.

5

2. Overview of OWL-S – Brief

1) OWL-S(“OWL for Services”) is a set of notations based on the

Semantic Web ontology Language OWL.

2) The principal objectives of OWL-S Coalition are:

To provide a general-purpose representational framework in which to describe Web Services.

To support automation of service management and use by software agents.

To build on existing Web Service standards and existing Semantic Web standards.

3) Although some Web infrastructure and reasoning tools for

complete solutions are still ongoing work, one likely have a

form-based interface between human and software agent.

6

2. Overview of OWL-S – Overall structure

1) The OWL-S ontology includes three primary sub-ontologies:

Service Profile – what the service does

Process model – how the service is used

Grounding – how to interact with the service

2) The service profile and process model are thought of as

abstract characterizations of a service.

3) The grounding makes it possible to interact with a service by

providing the necessary concrete details related to message

format, transport protocol, etc.

4) Each service described using OWL-S is represented by an

instance of the OWL class.

7

2. Overview of OWL-S – Top level of the service ontology

Figure 1: Top-level of the service ontology

8

2. Overview of OWL-S – IOPEs mode

1) Inputs: The inputs are the object descriptions that the

service works on.

2) Outputs: The outputs are the object descriptions that it

produces.

3) Preconditions: A precondition is proposition that must be

true in order for the service to operate effectively.

4) Effects: An effect is a proposition that will become true when

the service completes.

Results: Results consist of effect and output specifications.

9

2. Overview of OWL-S – IOPE Illustration

1) For example, a simple on-line transaction service that requires a

user to have an account and a credit card.

2) The Inputs might be User and CreditCard.

3) The Preconditions requires the user to actually have an account

and a valid credit card.

hasAcctID(User, AcctID)

& validity(CreditCard, Valid)

4) The Effects and Outputs vary depending on whether the credit

card is valid or not. If it is valid, then let’s suppose the sevice will

replenish one’s account or no change in account when it’s not valid.

10

2. Overview of OWL-S – IOPE Example (cont.)

5) There are two possible separate results.

Valid = OK |->

output(Outcome <= Success)

& AcctBalance(25)

Valid = Not-OK |->

output(Outcome<=Failure)

6) OK and Not-OK are values defined as elements of an OWL Class

AccoduntValidity.

<owl:Class rdf:ID=“AccountValidity”>

<owl:oneOf rdf:parseType=“Collection”>

<AccountValidity rdf:ID=“OK”/>

<AccountValidity rdf:ID=“Not-OK”/>

</owl:oneOf>

</owl:Class>

11

3. The service Profile – capability-based

1) The OWL-S profile provides a set of concepts to specify

explicit description of services capabilities, with the goal

of supporting capability-based discovery.

2) The OWL-S profile allows providers to advertise their services

do, and requester to specify what capabilities the expect from

the services they need to use.

3) By exploiting the structure of OWL-S profiles and references

to OWL concepts, a discovery process can find those

services that most satisfy the needs of a requester.

4) Inputs, outputs, preconditions, and results are referred to the

Service Profile.

12

3. The service Profile – Describe aspect

1) functional aspect

describe the information transformation from the inputs,

expects to the outputs it generates, from a set of

preconditions that need to be satisfied, to effects that are

produced. (IOPEs mode)

2) classification aspect

describe the type of service as specified in a taxonomy of

business (or other suitable domain-specified ontologies).

3) non-functional aspect

describe the distinctions between services that do the same

thing but in different ways or with different performance.

13

3. The service Profile – Top-level structure of Profile

Figure 2: Top-level structure of the OWL-S Profile

14

4. The Process model – Process types

1) The process model to give a detailed perspective on how to interact

with a service.

2) It can be viewed as a process like describe what constraints must be

satisfied and what pattern of interactions are required to make use of

the service.

3) Two sorts of processes can be invoked:

atomic process – it corresponds to a single interchange of inputs and

outputs between a consumer and a provider.

composite process – consist of a set of component processes linked

together by control flow and data flow structure.

simple process – abstract type, non-invocable views of atomic or

composite processes.

15

4. The Process model – How to describe process model

1) A process is not a program to be executed. It is a specification

of the ways a client may interact with a service.

2) The concepts used to describe a process are terms in the OWL-S

ontology.

3) The OWL-S definition of Process has a set of associated features

(IOPEs) linked to the concept by OWL properties (hasInput,

hasOutput, etc.).

4) Composite processes are related to their control structure using

the composedOf property, and other properties, are used to

show the relationships between control structure.

5) Some properties that relate to Profile and Grounding.

16

4. The Process model – Top-level structure of Process Model

Figure 3: Top-level structure of the OWL-S process model

17

5. The Grounding subontology

1) The grounding is used to specify how the concrete information

exchanges between service requester and provider.

2) A grounding maps each OWL-S atomic process to a WSDL

operation, and each OWL-S process input/output to

elements of input/output messages of WSDL operation.

3) The purpose is to enable the translation between semantic

I/O descriptions and WSDL I/O messages for transmission.

4) The grounding provides a bridge between syntax- and

protocol-oriented WSDL and semantics-oriented OWL.

18

5. The Grounding subontology (cont.)

6) A grounding can be supplied at runtime, allowed for dynamic

binding to a service provider.

7) An grounding involves a complementary use of the OWL-S and

WSDL languages, because they do not cover the same

conceptual space.

8) WSDL specifies message types using XMLS, whereas OWL-S

allows for the definition of abstract types as OWL classes

based on description logic.

9) The grounding uses OWL classes as the abstract types of

messages declared WSDL , and then relies on WSDL binding

constructs to specify the formatting of the messages.

19

5. The Grounding – relationship between OWL-s & WSDL

Figure 4: Relationship between OWL-S and WSDL

20

5. The Grounding subontology – Partial code

Process

Operation

Input

Message

Output

Message

Grounding

21

6. Technology based on OWL-S – Interaction model

Figure 5: Typical OWL-S Semantic Web Service interaction model

22

6. Technology based on OWL-S – Tools and extensions

1) OWL-S Editor

a plug-in to the popular ontology development tools Protégé.

http://owlseditor.semwebcentral.org/

2) OWL-S development environment (CODE)

supports developers of Semantic Web Services, include

WSDL2OWL-S, editor for creating and editing OWL-S profiles,

process, models and groundings based on Eclipse.

http://projects.semwebcentral.org/projects/owl-s-ide/

3) OWL-S Matchmaker system – extended for policy matching

4) OWL-S Virtual Machine (VM) – extended to enforce policies and

security mechanisms.

23

7. Conclusion

1) OWL-S, a representational framework that provides for more

complete specifications of the capabilities and behavior of Web

Service.

2) OWL-S consists of three parts, service profile (what it does), process

models (how it work), groundings (how to access it).

3) OWL-S has a wide variety of tools, and has been extended by

researchers to support various specific requirements.

4) OWL-S could still be improved in a number of ways:

No way of describing desirable security.

QoS, exception handing …

24

References:

1) “Bringing Semantics to Web Services with OWL-S”,

David Margin, Mark Burstein, Drew Mcdermott, Sheila

Mcllraith, Massimo Paolucci, Katia Sycara, Deborah L,

McGuinness, Evren Sirin, Naveen Srinivasan, July

2007,Springer

2) OWL-S: Semantic Markup for Web Services

http://www.w3.org/Submission/OWL-S/

3) DAML/OWL-S

http://www.daml.org/services/owl-s/