1 / 19

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. Representing Services for Mobile Computing using OWL and OWL-S An Initial Investigation. Services on the go. Services are ubiquitous in the environment Simple services

jonny
Download Presentation

Representing Services for Mobile Computing using OWL and OWL-S An Initial Investigation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Massimo Paolucci, Marko Luther and Matthias Wagner DoCoMo EuroLabs Alessandra Andreetto, Walter Goix TILab Representing Services for Mobile Computing using OWL and OWL-SAn Initial Investigation

  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 Ticketing Service Here is the ticket I charged your card Stop Notification Landmarks News/Info

  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. 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. 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. 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. 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. OWL-S Service Profile <profile rdf:ID="BravoAir"> <serviceName>BravoAir </serviceName> <contactInformation rdf:resource="#BAco"/> <serviceClassification rdf:resource="#Airline"/> <product rdf:resource="#FlightReserv"/> <serviceCategory rdf:resource="#NAICS_Airline"/> <hasInput rdf:resource="#Dep_Airport"/> <hasInput rdf:resource="#Arr_Airport"/> <hasOutput rdf:resource="#Reservation"/> <preconditions/> <effects/> </profile> Who provides the service Type of service Product 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. MobiLife service ontology • Explicit representation of service types • Effective at specifying service specific parameters • Ex Entertainment services need specification of type of content

  10. Using Service Ontology:two problems • Problems • The representation of services easily moves to OWL Full • Outside the power of many inference engines • Awkward representation • How does the service ontology integrate with OWL-S?

  11. Problem 1: Example of OWL Full <owl:Class rdf:ID=”Info_Service”/> <owl:property rdf:ID=”about”> <owl:domain rdf:resource=”#Info_Service”/> <owl:domain rdf:range=”owl:Thing”/> </owl:property> 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 <Info_Service rdf:ID=”hotel_info_service”> <about rdf:resource=”#Hotel”/> </Info_Service >

  12. Solution Problem 1: Using anyURI type <owl:Class rdf:ID=”Info_Service”/> <owl:DatatypeProperty rdf:ID=”about”> <owl:domain rdf:resource=”#Info_Service”/> <owl:domain rdf:range="&xsd;#anyURI"/> </owl:DatatypeProperty > 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 <Info_Service rdf:ID=”hotel_info_service”> <about rdf:datatype="&xsd;#anyURI"> #Hotel </about> </Info_Service >

  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 my Music Service my Music Service OWL-S Profiles are OWL objects. They can be specialized to include additional service information Accepted Solutions Service Profile Service Communication Entertainment Commerce Service Profile Music Videos Service Profile OWL-S reference to service types OWL-S and service ontology totally disjoint Limited use of OWL reasoning

  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. Inconsistency <newsService rdf:ID=”NewsNow"> … <serviceClassification rdf:resource="#Airline"/> … <communicationMode rdf:resource="#realTime”> … <serviceParameter> <ServiceParameter> <serviceParameterName> communicationMode </serviceParameterName> <sParameter rdf:resource="#NonRealTime"/> </ServiceParameter> </serviceParameter> … </newsService> This service profile is inconsistent but inference engines would not be able to detect the problem Type inconsistency Parameter Inconsistency

  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. An example <MobilOWLS:Profile rdf:ID="a_Location_CP"> <profile:hasInput> <process:Input rdf:ID="user"> <process:parameterType rdf:datatype="&xsd;#anyURI"> &agent;#Person </process:parameterType> </process:Input> </profile:hasInput> <profile:hasOutput> <process:Output rdf:ID="user_location"> <process:parameterType rdf:datatype="&xsd;#anyURI"> &space;#Location </process:parameterType> </process:Output> </profile:hasOutput> <profile:serviceClassification rdf:datatype="&xsd;#anyURI"> &serviceOntology;#Location_Provider </profile:serviceClassification> <LocatinMethod rdf:datatype="&xsd;#anyURI"> http://…/space.owl#cell_id </ LocatinMethod > <Communication_Channel rdf:datatype="&xsd;#anyURI"> http://…/Communication.owl#SMS </ Communication_Channel> </MobilOWLS:Profile>

  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. 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

More Related