1/23 Michael Klein Universität Karlsruhe A Process and a Tool for Creating Service Descriptions...

1/23

Michael KleinUniversität Karlsruhe

A Process and a Tool for Creating Service Descriptions based on

DAML-S

4th VLDB Workshop on Technologies for E-Services (TES'03)

Berlin, September 8th, 2003

Michael Klein, Birgitta König-RiesInstitute for Program Structures and Data Organization

Chair: Prof. Peter C. LockemannUniversität Karlsruhe, Germany

DFG SPP 1140 DIANE Project

2/23


Today’s Service Discovery

1. Send simple query

keywords, boolean constraints

Service catalogue

2. Receive advertisements

Set of WSDL files

3. Choose & Configure Look through set understand meaning choose appropriate

service configure service

Human user

4. Invoke service

SOAP

UDDI

Service provider

3/23


Tomorrow’s Service Discovery

1. Send complex query

declarative

Service catalogue

2. Receive matchingadvertisement

Single description

3. Configure set parameters

4. Invoke service

Service provider

ontology-based

matcher

Human user

ComputerAgent

4/23


Automatic Service Discovery

Enrich service description with computer-interpretable semantics by

basing describing concepts on well-defined semantics (logics)

clearly expressing functional semantics

including real world knowledge into the description

Matcher has to understand the meaning description

REQUIREMENT

METHOD

5/23


Possible Technology: DAML-S

DAML-S Language to describe services semantically Based on DAML, frame-based ontology language

(with formal semantics from description logics)

Service

Profile declarative, blackbox, what?

prese

nts

Model procedural, glassbox, how?describes

Grounding technical access details

supports

6/23


DAML-S Profile

Profile

ParameterDescription


input output



precond. effect

non-functional parameters name, description, QoS, …

Allows to integrate additional ontologies for real-world knowledge flexible and extensible

7/23


Problem with DAML-S Profile

MAIN PROBLEM

Types of the IOPEs too generic: type “ParameterDescription” structure unclear and not unified

not automatically comparable not creatable by humans

8/23


Approach of the Paper

Layer ontologies dynamically.

APPROACH

preserve flexibility and extensibility by additional ontologies

AND: produce descriptions that have roughly the same structure

Details Use three layers Define tasks of each layer Support by process and tool

9/23


Overview over the Layering

III. Domain Ontologies Task: Define vocabulary to

describe domain specific parts thousands, distributed Examples: shoes, databases,

locations…

SQL

SELECT

Rel. Model

Rel. Algebra

UPDATE

II. Service Category Ontologies Task 1: Restrict types of the IOPEs Task 2: Defines these types exactly few (5-10) Example: InformationService

InfoState InfoState

Author TopicTitle

Document

I. Upper Service Ontology Task: Set up general structure of a

service description unique, commonly accepted, small DAML-S

Service

Prec Effect

IV. Instantiation According to the ontology but adds/omits attributes

10/23


I. Upper Service Ontology

GOAL

Set up a general structure of a service description.

Approach Use DAML-S and adapt Profile

Profile

Data Datainput output

State Stateprecond. effect

11/23


II. Service Category Ontology

GOAL

Divide space of services into categories of services with similar state transformations.

Examples InformationService:

Changes the (availability) state of a document KnowledgeService:

Changes the state concerning a piece of knowledge RealObjectService:

Changes the (possession) state of an object in the real world

Concrete Tasks (1) Specialize abstract IOPE ranges into concrete types (2) Define these types exactly

12/23


II. Service Category Ontologies – Task 1

Task 1: Specialize abstract IOPE ranges into concrete typesApproach: Taxonomical ontology of statesExample:

State

InformationState

Available Unavailable

LocallyAv RemotelyAv OfflineAv

StoredInRAM StoredOnHD Printed Displayed

Document entity

Locationloc

13/23


II. Service Category Ontology – Task 2

Task 2: Exactly define used types

Approach: For each new type, choose set to atomic type (not recommended) set to enumeration type and list instances set to concrete class type and recursively define

structure (for example by separating aspects) set to abstract class type and leave definition open for

concrete domain ontology

14/23


II. Service Category Ontology – Task 2, Example

Document

FORMAT

Information Topiccontains dealsWith

xsd:String Keyword

Location

dc:Format dc:Title dc:Subject

<pdf> <ps> <doc>

Printed

COLOR

xsd:integer

color

resolution

<bw>

<col>

15/23


III. Domain Ontologies

GOAL

Provide domain-specific vocabulary to describe abstract (real-world) parts of the description.

Concrete Tasks (1) Define the schema of the domain (2) Define concrete instances of the domain (3) Define domain specific comparison functions

Examples Seats in a certain cinema Learning Topics in Databases Locations on the Campus of the University of Karlsruhe

16/23


III. Domain Ontologies – Example

Simple Example: Locations on the Campus of the University of Karlsruhe

Location

CampusLocation

Room Buildingwithin

isNeighboredTo isNeighboredTo

1) 2) buildingA:Building

buildingB:Building

room335:Room

room337:Room

room14:Room

ww w

n

n

3) sim(Room r1, r2)

sim(Building b1, b2)

dist(Room r1, r2)

17/23


IV. Instantiating

Instantiate according to type:

atomic type enter value

enumeration type pick value from list

concrete class type pick predefined instance create new instance and instantiate the range types of

all properties abstract class type

not possible

free instantiation instantiate additional properties with unspecified domain

18/23


Overview of the Process

(1) Acquiring the upper ontology

(2) Choosing a category

(3) Choosing concrete states

(4) Instantiating atomic/enum. types

(5) Instantiating concrete class types

(6) Instantiating freely

(7) Concreting abstract class types if not ready

19/23


Complete Description Instance Example

myService:Service

:InfoServiceProfile :Printed:Locally

Available

:Document

presents

precondition effect

entity entity

dc:Format

<pdf>

color

<bw>

res.

600

location

room335:Room

20/23


Tool: DINST

21/23


Improvements of this Approach

Comparability: Description follows a common structure Still possibility to adapt to all kinds of services

category domain

Basic comparison algorithm: graph matching Special treatment

Domain specific comparision functions Declarative parts and conditions in queries

Editability: 7 steps guide user through creating process tool DINST supports this process graphically

22/23


Summary & Future Work

Summary DAML-S is promising description language for tomorrow’s automatic

service discovery BUT: Unusable

Structure of the IOPEs is unclear and not unified APPROACH: Layering of ontologies

3 layers, each well-defined tasks preserve flexibility/extensibility, enhance structure automatic comparison becomes possible

SUPPORT: Process and Tool

Future Configurable Service Descriptions

(submitted to SOC 2003 in Italy)

23/23


Thanks for your attention!

Do you have any questions?

Further information:http://www.ipd.uni-karlsruhe.de/DIANE

24/23


APPENDIX

25/23


DAML-S: Overview ServiceProfile

1/23 Michael Klein Universität Karlsruhe A Process and a Tool for Creating Service Descriptions...

Documents

Transcript of 1/23 Michael Klein Universität Karlsruhe A Process and a Tool for Creating Service Descriptions...