ist-511607 mobilife – inter-wp meeting april 28, 2005slide 1 representing services for mobile...

IST-511607

MobiLife – Inter-WP meeting April 28, 2005 Slide 1

Representing Services for Mobile Computing using OWL and OWL-SAn Initial Investigation

Massimo Paolucci, Marko Luther and Matthias Wagner DoCoMo EuroLabs

Alessandra Andreetto, Walter Goix TILab

IST-511607

WSComp 05 September 2005 Slide 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

Ticketing Ticketing ServiceService

StopStopNotificationNotification

LandmarksLandmarks

News/InfoNews/Info

IST-511607


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

IST-511607


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

IST-511607


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

IST-511607


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

IST-511607


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

IST-511607


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 inBusiness taxonomies

Typical inputs

Typical outputConditions that need to be satisfied for the service to run correctly

Conditions that result from the run of the service

IST-511607


MobiLife service ontology

• Explicit representation of service types

• Effective at specifying service specific parameters– Ex Entertainment services need

specification of type of content

IST-511607


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?

IST-511607


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>

<Info_Service rdf:ID=”hotel_info_service”><about rdf:resource=”#Hotel”/>

</Info_Service >

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

IST-511607


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 >

IST-511607


Problem 2:

Service Ontologies and OWL-S

OWL-S at the rootHigh commitment: the whole service

ontology becomes OWL-S based

OWL-S at the leafsService instances are both OWL-S

and of some service typeLower 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

ServiceService

CommerceCommerce CommunicationCommunication EntertainmentEntertainment

MusicMusic VideosVideos

Service ProfileService Profile

my Music Servicemy Music Service

Service ProfileService Profilemy Music Servicemy Music Service

Service ProfileService Profile

Accepted SolutionsOWL-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

IST-511607


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

IST-511607


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>

Type inconsistency

ParameterInconsistency

This service profile is inconsistent but inference engines would not be able to detect the problem

This service profile is inconsistent but inference engines would not be able to detect the problem

IST-511607


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

IST-511607


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>

IST-511607


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

IST-511607


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

… butIt is necessary to remove redundancies in OWL-Sor to avoid representations that use those redundancies

• Hopefully MobilOWL-S will be available soon on semwebcentral.org

ist-511607 mobilife – inter-wp meeting april 28, 2005slide 1 representing services for mobile...

Documents