A Process and a Tool for Creating Service Descriptions based on DAML-S

1. 4th VLDB Workshop on Technologies for E-Services (TES'03)Berlin, September 8th, 2003 A Process and a Tool for Creating Service Descriptions based on DAML-S Michael Klein, Birgitta König-RiesInstitute for Program Structures and Data Organization Chair: Prof. Peter C. Lockemann Universität Karlsruhe, Germany DFG SPP 1140 DIANE Project

2. 1. Send simple query keywords, boolean constraints 2. Receive advertisements Set of WSDL files 4. Invoke service SOAP Today’s Service Discovery Service catalogue Human user UDDI 3. Choose & Configure Look through set understand meaning choose appropriate service configure service Service provider

3. Computer Agent 1. Send complex query declarative 2. Receive matchingadvertisement Single description 4. Invoke service Tomorrow’s Service Discovery Service catalogue Human user ontology-based matcher 3. Configure set parameters Service provider

4. Automatic Service Discovery REQUIREMENT 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 METHOD

5. Profile declarative, blackbox, what? presents describes Model procedural, glassbox, how? supports Grounding technical access details 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

6. Parameter Description Parameter Description input output Parameter Description Parameter Description precond. effect non-functional parameters name, description, QoS, … DAML-S Profile Profile Allows to integrate additional ontologies for real-world knowledge  flexible and extensible

7. 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. Approach of the Paper APPROACH Layer ontologies dynamically. • 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. Overview over the Layering I. Upper Service Ontology • Task: Set up general structure of a service description • unique, commonly accepted, small • DAML-S Service II. Service Category Ontologies • Task 1: Restrict types of the IOPEs • Task 2: Defines these types exactly • few (5-10) • Example: InformationService Prec Effect InfoState InfoState Document Author Title Topic III. Domain Ontologies • Task: Define vocabulary to describe domain specific parts • thousands, distributed • Examples: shoes, databases, locations… Rel. Model Rel. Algebra SQL SELECT UPDATE IV. Instantiation According to the ontology but adds/omits attributes

10. Data Data input output State State precond. effect Approach Use DAML-S and adapt Profile Profile I. Upper Service Ontology GOAL Set up a general structure of a service description.

11. 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. Document entity Information State loc Location Available Unavailable LocallyAv RemotelyAv OfflineAv StoredInRAM StoredOnHD Printed Displayed II. Service Category Ontologies – Task 1 Task 1: Specialize abstract IOPE ranges into concrete types Approach: Taxonomical ontology of states Example: State

13. 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. <bw> COLOR color <col> Printed resolution xsd:integer II. Service Category Ontology – Task 2, Example Document Information Topic contains dealsWith dc:Subject dc:Format dc:Title FORMAT xsd:String Keyword <pdf> <ps> <doc> Location

15. III. Domain Ontologies GOAL Provide domain-specific vocabulary to describe abstract (real-world) parts of the description. Examples Seats in a certain cinema Learning Topics in Databases Locations on the Campus of the University of Karlsruhe Concrete Tasks (1) Define the schema of the domain (2) Define concrete instances of the domain (3) Define domain specific comparison functions

16. n buildingA: Building buildingB: Building 1) Location 2) w w w Campus Location room335: Room room337: Room room14: Room n Room within Building isNeighboredTo isNeighboredTo III. Domain Ontologies – Example Simple Example: Locations on the Campus of the University of Karlsruhe 3) sim(Room r1, r2) sim(Building b1, b2) dist(Room r1, r2)

17. 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. 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. Complete Description Instance Example myService: Service 600 <bw> presents color res. :InfoServiceProfile :Locally Available :Printed precondition effect location :Document entity entity dc:Format <pdf> room335 :Room

20. Tool: DINST

21. 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. 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. Thanks for your attention! Do you have any questions? Further information: http://www.ipd.uni-karlsruhe.de/DIANE

24. APPENDIX

25. DAML-S: Overview ServiceProfile