1. IST-511607 MobiLife – Inter-WP meeting April 28, 2005Slide 1 Representing Services for Mobile Computing using OWL and OWL-S An Initial Investigation Massimo Paolucci, Marko Luther and Matthias Wagner DoCoMo EuroLabs Alessandra Andreetto, Walter Goix TILab

2. IST-511607 WSComp 05 September 2005Slide 2 Services on the go Services are ubiquitous in the environment Simple services Easy to model: provide a good test case for (S)WS technology I need a ticket, my card # is 1234 Here is the ticket I charged your card TicketingService StopNotification Landmarks News/Info

3. IST-511607 WSComp 05 September 2005Slide 3 Challenges of Mobile Computing Working with services have a number of challenges –Discovery, Composition, Mediation, Security, Management, etc Mobile computing adds its own challenges –Limited resources Small devices, limited screen, limited power –Unreliable network Wireless based networks are less reliable than line-based networks Some networks are limited in scope (bluetooth - WIFI) Multi Media data –Data exchanged is not just XML description of products but it includes: Music -Videos - Photos - Continuous voice and video streams

4. IST-511607 WSComp 05 September 2005Slide 4 Essential Representation of Service Parameters Service parameters essential to the representation of capabilities of service –Service bandwidth –Type of data transmitted –Cost model Requirements on the terminal – Monitor size, CPU … –Software requirements Browser Video viewer Policies and Privacy requirements

5. IST-511607 WSComp 05 September 2005Slide 5 Requirements for Service Representation Represent capabilities of the service –The function that the service computes –Quality of the service provided Represent service requirements –Resources requirements CPU, Screen size, Memory size, Network type and bandwidth –Policies and Privacy requirements –Cost models Use existing standards and emerging proposals –OWL, OWL-S –CC/PP, UAProf Exploit context ontologies for the representation of application context and domain information Effectively computable logics: OWL DL

6. IST-511607 WSComp 05 September 2005Slide 6 Approach Service Functionality –OWL-S Provide general schema to represent services Provide description of functionality of the service –Input/outputs preconditions/effects Service Taxonomies –Provide explicit description of classes of services Information services/ Personal communication services Description of service parameters Service Requirements –CC/PP and UAProf Describe characteristics of the devices –Screen Size / CPU type –Software available Decidable logics: OWL DL

7. IST-511607 WSComp 05 September 2005Slide 7 Methodology for selection of service parameters Extract list of services from Mockups –We extracted ~40 services Use these services to decide the features of the service representation –Test representation ideas on the 40 services (and natural variations) –Relate to context ontologies With extensions when needed

8. IST-511607 WSComp 05 September 2005Slide 8 OWL-S Service Profile BravoAir Who provides the serviceType of serviceProduct of the service Classification in Business taxonomies Typical inputs Typical output Conditions that need to be satisfied for the service to run correctly Conditions that result from the run of the service

9. IST-511607 WSComp 05 September 2005Slide 9 MobiLife service ontology Explicit representation of service types Effective at specifying service specific parameters –Ex Entertainment services need specification of type of content

10. IST-511607 WSComp 05 September 2005Slide 10 Using Service Ontology: two problems Problems 1.The representation of services easily moves to OWL Full Outside the power of many inference engines Awkward representation 2.How does the service ontology integrate with OWL-S?

11. IST-511607 WSComp 05 September 2005Slide 11 Problem 1: Example of OWL Full Problem: about property of an instance of service refers to the class Hotel Mixing reasoning at instance and class level pushes logics to OWL full

12. IST-511607 WSComp 05 September 2005Slide 12 Solution Problem 1: Using anyURI type Solution adopted in MobilOWL-S –Represent ranges as XML Schema URI Advantage: Logic stays in OWL DL Cost: these properties are outside DL reasoning, we need other reasoner –Same solution adopted by OWL-S –Similar to solution adopted by OWL Best practice Working Group #Hotel

13. IST-511607 WSComp 05 September 2005Slide 13 Problem 2: Service Ontologies and OWL-S OWL-S at the root High commitment: the whole service ontology becomes OWL-S based OWL-S at the leafs Service instances are both OWL-S and of some service type Lower commitment, but some services may not be OWL-S based OWL-S reference to service types OWL-S and service ontology totally disjoint Limited use of OWL reasoning Service Commerce CommunicationEntertainment MusicVideos Service Profile my Music Service Service Profile my Music Service Service Profile Accepted Solutions OWL-S Profiles are OWL objects. They can be specialized to include additional service information OWL-S Profiles are OWL objects. They can be specialized to include additional service information

14. IST-511607 WSComp 05 September 2005Slide 14 Problem with OWL-S Service Parameters and Type OWL-S provides two properties: –ServiceParameters: Used to describe additional parameters of the service Redundant with OWL properties –Service parameters can be defined as OWL properties –Type Used to specify service type Redundant with OWL instance specification –Service type can be specified by specializing the instance of OWL-S Profile Redundancies allow inconsistent specifications of OWL-S services

15. IST-511607 WSComp 05 September 2005Slide 15 Inconsistency … … <communicationMode rdf:resource="#realTime”> … communicationMode <sParameter rdf:resource="#NonRealTime"/> … Type inconsistency Parameter Inconsistency This service profile is inconsistent but inference engines would not be able to detect the problem

16. IST-511607 WSComp 05 September 2005Slide 16 Representation Dimensions ( Still in Progress) Some Service parameters extracted –Communication_Channel Real time vs. non-real time/ SMS vs. SIP vs. Http Streaming vs. conversational –Target_Customers/ Content rating Restrictions on the types of customers: who can access the service –Media_Content Video vs. audio vs. text vs. image vs. application –Cost Model Free vs. flat fee vs. per use Specialized Service parameters –Location-mode Parameter Cell-based - GPS based –Natural Language used Specify the language used by the interaction with the servic

17. IST-511607 WSComp 05 September 2005Slide 17 An example &agent;#Person &space;#Location &serviceOntology;#Location_Provider http://…/space.owl#cell_id http://…/Communication.owl#SMS

18. IST-511607 WSComp 05 September 2005Slide 18 Future Work Define mapping to cc/pp UAProf –Cc/pp provides language to specify terminal characteristics –UAProf provides a vocabulary defined on cc/pp for WAP terminals –Exists OWL ontology for cc/pp UAProf, but OWL Full How do we use MobilOWLS? –Define discovery algorithms What about other modules of OWL-S? –Should we change the Process Model? –Should we change the Grounding? Keep user in the loop –Discovery should be automated …but user should be in control of which services are selected …and in control of the whole interaction process

19. IST-511607 WSComp 05 September 2005Slide 19 Conclusions Service Parameters essential to represent services for Mobile Computing OWL-S + OWL provides enough expressivity to represent services –They represent both Functional aspect Service Parameters … but It is necessary to remove redundancies in OWL-S or to avoid representations that use those redundancies Hopefully MobilOWL-S will be available soon on semwebcentral.org