Vrije Universiteit Brussel


Adapting the obtrusiveness of service interactions in dynamically discovered environments

Introduction

This page provides additional information for the submission "Adapting the obtrusiveness of service interactions in dynamically discovered environments" for the Mobiquitous conference (2012). The page lists several service discovery and context-aware scenarios, knowledge models, and details on the user evaluation.

Back to top


Service discovery scenarios

This section provides some example service discovery scenarios, where local services (or applications) discover useful remote services and interact with them. These local services can then act as "proxies", making the remote service's interaction capabilities available on the local device (and thus subject to adaptation).

Scenario 1.

A local tourism application enables remote tourism services to provide the user with information on good nearby hotel deals, and nearby points-of-interest. To discover these kinds of remote services, the application registers a discovery query with the Notification Service, from the environment discovery and management layer.

This query looks for nearby tourism services (msm:Service, es:TourismService), which provides an operation (msm:hasOperation) to get points-of-interest (e.g., es:GetPointsOfInterest) or hotel deals (i.e., es:getHotelDeals), and is currently nearby (pm:isNearby) the user (um:User). It further obtains the contact information for the service and its operations.

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX msm: <http://cms-wg.sti2.org/ns/minimal-service-model#>
PREFIX es: <http://wise.vub.ac.be/namespaces/environment-services#>
PREFIX um: <http://wise.vub.ac.be/namespaces/user-model#>
PREFIX pm: <http://wise.vub.ac.be/namespaces/proximity-model#>
SELECT ?service ?operation ?operationType ?port ?targetNS ?address ?transport
WHERE {
  ?service a msm:Service ;
    a es:TourismService ;
    msm:hasOperation ?operation .
  ?operation a ?operationType .
  FILTER (sameTerm(?operationType, es:GetPointsOfInterest) || sameTerm(?operationType, es:getHotelDeals))

  ?user a um:User ;
    pm:isNearby ?service .

  // contact info
  ?service msm:hasPort ?port ;
    msm:hasTargetNamespace ?targetNS .

  ?port msm:hasBindType ;
    msm:hasLocation ?address ;
    msm:hasTransport ?transport .
}
Query 1. Service discovery scenario 1: Tourism service.

In case a relevant tourism service is encountered, the application is notified, and utilizes the Service Invoker for remote communication. Based on the received data from one of the operations, the application provides notifications, informing the user of good nearby deals and nearby points-of-interest.

Back to top

Scenario 2.

A local movie application enables remote movie ticket services to notify the user, in case the movie theatre plays a movie on the user's "to-watch" list. To discover these kinds of services, the application registers a discovery query with the Notification Service, from the environment discovery and management layer.

This query looks for movie ticket services (msm:Service, es:MovieTicketService), which provides an operation (msm:hasOperation) to obtain information on available movie tickets (es:getMovieTicketInformation), and is located inside (pm:containedIn) a movie theatre (sumo:MovieTheatre) that is currently nearby (pm:isNearby) the user (um:User).

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX msm: <http://cms-wg.sti2.org/ns/minimal-service-model#>
PREFIX es: <http://wise.vub.ac.be/namespaces/environment-services#>
PREFIX pm: <http://wise.vub.ac.be/namespaces/proximity-model#>
PREFIX um: <http://wise.vub.ac.be/namespaces/user-model#>
SELECT ?service ?operation ?port ?targetNS ?address ?transport
WHERE {
  ?service a msm:Service ;
    a es:MovieTicketService ;
    msm:hasOperation ?operation .
  ?operation a es:GetMovieTicketInformation .

  ?service pm:containedIn ?movieTheatre .
  ?movieTheatre a sumo:MovieTheatre .
  ?user a um:User ;
    pm:isNearby ?movieTheatre .

  // contact info
  ?service msm:hasPort ?port ;
    msm:hasTargetNamespace ?targetNS .

  ?port msm:hasBindType ;
    msm:hasLocation ?address ;
    msm:hasTransport ?transport .
}
Query 2. Service discovery scenario 2: Ticket service.

In case a relevant ticket service is encountered, the application is notified. The application utilizes the Service Invoker to communicate remotely with the service. Based on the response received from the es:GetMovieTicketInformation operation, the application determines whether the service sells tickets for movies "to watch". If so, the application notifies the user, informing him of the movie and the movie theatre, and potentially passing on the service's link to the webpage where the movie ticket can be purchased.

Back to top

Context-aware scenarios

This section provides some example context-aware scenarios, where local services (or applications) utilize the environment discovery and management layer to become aware of the user's context and environment, in order to enhance their own functionality.

Scenario 1.

A shopping application maintains a digital shopping list, which the user manually updates each time he is running out of a certain product. This intelligent service is not just an alternative to the traditional paper shopping list; it also notifies the user whenever a shop (e.g., supermarket) becomes nearby that sells one or more products on the list. To achieve this, the shopping service registers a query with the Notification Service of the environment discovery and management layer.

This query looks for shops (sumo:RetailStore) that are currently nearby (pm:isNearby) the user (um:User), and that sell a certain product (region:sells) on the user's digital shopping list (um:shoppingList, sl:entry) (kept as part of the User Model). The query also returns the shop's and product's label (rdfs:label), as well as the shop's absolute location (pm:lastKnownLocation, geo:xyCoordinates).

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX sumo: <http://www.ontologyportal.org/SUMO.owl#>
PREFIX um: <http://wise.vub.ac.be/namespaces/user-model#>
PREFIX pm: <http://wise.vub.ac.be/namespaces/proximity-model#>
PREFIX region: <http://wise.vub.ac.be/region/>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX geo: <http://www.mindswap.org/2003/owl/geo/geoFeatures20040307.owl#>
PREFIX sl: <http://wise.vub.ac.be/namespaces/shopping-list#>
SELECT ?shop ?shopLabel ?shopCoords ?product ?productLabel
WHERE {
  ?shop a sumo:RetailStore .
  ?user a um:User ;
    pm:isNearby ?shop .

  ?shop region:sells ?product .
  ?product rdfs:label ?productLabel .
  ?shop rdfs:label ?shopLabel ;
    pm:lastKnownLocation ?shopLocation .
  ?loc geo:xyCoordinates ?shopCoords .

  ?user um:shoppingList ?list .
  ?list sl:entry ?product .
}
Query 3. Context-aware scenario 1: Shopping service.

Each time the user is nearby a shop selling a product on the user's shopping list (kept as part of the User Model), the shopping service is notified, passing along some useful information (e.g., shop label and coordinates, product label). The shopping service then presents this information to the user (e.g., on a map view).

Back to top

Context-aware scenario 2.

A restaurant application notifies the user when he is nearby a restaurant that serves one of his favorite cuisines, around dinner time. The user can also indicate he is a tourist and enter his current hotel. In that case, the service gives preference to restaurants nearby a metro station, on a line leading back to his hotel. To realize this, the restaurant service registers a query with the Notification Service of the environment discovery and management layer.

This query looks for restaurants (resto:Restaurant) that are currently nearby (pm:isNearby) the user (um:User), and that serve a cuisine (resto:typeOfCuisine) preferred by the user (um:prefersCuisine). Optionally, the query checks whether the restaurant is nearby (pm:isNearby) a metro station (space:Tube_Station) that is connected via a route to another metro station (?route space:connects), which is nearby (pm:isNearby) the hotel (space:Hotel) the user is currently staying at (um:stayingAt).

PREFIX pm: <http://wise.vub.ac.be/namespaces/proximity-model#>
PREFIX um: <http://wise.vub.ac.be/namespaces/user-model#>
PREFIX resto: <>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX space: <>
SELECT ?restaurant ?restaurantLabel ?restaurantCoords ?cuisine ?station1 ?station2 ?route
WHERE {
  ?restaurant a resto:Restaurant .
  ?user a um:User ;
    pm:isNearby ?restaurant .

  ?user um:prefersCuisine ?cuisine .
  ?restaurant resto:typeOfCuisine ?cuisine ;
    pm:lastKnownLocation ?restaurantLocation .
  ?restaurantLocation geo:xyCoordinates ?restaurantCoords .

  OPTIONAL {
    ?restaurant pm:isNearby ?station1 .
    ?station1 rdf:type space:Tube_Station .
    ?route space:connects ?station1 .
    ?route space:connects ?station2 .
    ?station2 rdf:type space:Tube_Station .
      pm:isNearby ?hotel .

    ?user um:stayingAt ?hotel .
    ?hotel rdf:type space:Hotel .
  }
}
Query 4. Context-aware scenario 2: Restaurant service.

Each time the user is nearby a restaurant serving one of his favorite cuisines, the restaurant service is notified, passing along some useful information (e.g., restaurant label and coordinates, preferred cuisine; optionally, the connecting stations and route back to the user's hotel). The restaurant service then presents this information to the user (e.g., on a map view).

Back to top

Knowledge models

This section provides examples of obtrusiveness and interaction models, represented in the XML Metadata Interchange format (XMI).

Obtrusiveness models.

Below, you can find some example obtrusiveness models:

Back to top

Interaction models.

Below, you can find some example interaction models, which define interaction configurations to be used in a certain obtrusiveness level:

Back to top

User evaluation details

This section provides additional information on the user evaluation. Firstly, we elaborate on the tasks the users had to perform. Secondly, we provide the complete dataset for the PSSUQ questionnaire results.

Tasks

The user had to specify six situations of varying complexity, using the definition and capturing options. Below, you can find the list of situations. Note that, since "capturing" the first five situations proved trivial, the users only had to use the capture option for the sixth, most complex situation.

  • @work (1): You are inside the "DSIC" building (an educational building, with URI http://dsic.upv.es), during working hours (9AM – 18PM, from Monday to Friday).
  • @meeting: You are inside a meeting room during work hours (9AM – 18PM).
  • @quiet-place:You are inside a movie theatre or a theatre (time independent)
  • @teaching:You are inside a classroom, during 13-17h on Monday, 11-13h on Tuesday, and 13-17h on Friday.
  • @free-time:The current time on weekdays is from 18PM to 8AM, and the whole day during the weekend.
  • @work (2):You are inside your office (which is linked to you via the housesPerson property), during working hours (9AM – 18PM). You can assume that http://you.upv.es is your personal URI. You will have to utilize the free-form method to express this situation.

Back to top

Questionnaire dataset

The complete dataset for the PSSUQ questionnaire can be found here (scale from 1 (strongly agree) to 7 (strongly disagree)).

Back to top

©2004 • Vrije Universiteit Brussel • Pleinlaan 2 • 1050 Elsene • Tel.: 02/629.21.11 • info@vub.ac.be