Case Studies

MIDAS
 


We have tested the MIDAS prototype in various example scenarios:

 
 

The News Discovery Assistant

 

We have tested MIDAS in the design and implementation of a News Discovery Assistant (NDA) that enables mobile users to access information services available on the wired Internet, such as newspaper reading services and radio/television digital broadcasting services.
NDA retrieves information services that are available in the nearby of the current user location and manages access to these services, to provide mobile users with the news they are interested in.

 

Deployment Setting

We have deployed our MIDAS prototype components over a metropolitan area network composed of a fixed computing infrastructure and devices connected via IEEE 802.11 Access Points (APs), which may be located at the airport, at the railway station, in a shopping mall or in other public places.
Each AP defines its network locality that includes NDA service points on local wired hosts and mobile wireless client devices within the AP coverage area.
All server-side NDA components reside on fixed hosts in the metropolitan network.
About client-side MIDAS deployment, mobile terminals only host lightweight stubs capable of forwarding discovery requests to dedicated mobile agent-based proxies running on fixed hosts in the user AP locality. NDA proxies work on behalf of associated clients over the fixed network independently of possible temporary disconnections, maintain a copy of user/device profiles, and access services by coordinating with MIDAS facilities, in particular with dedicated MM, CM, DM, and QPM instances.

NDA Setup

Client-side applications enable users to subscribe to NDA by filling in a form with user profile and to authenticate themselves to the service before starting any NDA session.
When a user first accesses the service, NDA instantiates a shadow proxy in the domain where the user is currently attached. At service provision time, the clients are only in charge of forwarding user requests (and of visualizing the received service results) to (from) their responsible proxies.

Whenever a new user wishes to start a semantic-driven discovery of locally available services, the MIDAS middleware initiates a discovery process by interacting with the user proxy. In particular, the user proxy forwards a request for service to MIDAS, which parses both the query and the candidate services’ profiles. Then, it exploits the acquired information, along with its reasoning capabilities, to find if one or more services fulfill the requested characteristics.

Let us suppose that Alice, while waiting for her train at the railway station, is willing to access a news service using her 802.11b enabled palmtop. In particular, Alice would like to download today’s sport news from available newspapers so that she can read them during her journey.
Once seated in the waiting room, Alice exploits the wireless connectivity provided within the station area in order to access NDA.

As Alice first connects from the station network area, the stub on her device triggers NDA to generate a companion proxy, running on the fixed network infrastructure and possibly migrating to maintain co-locality with Alice. The proxy maintains a copy of user/device profiles and generates its MM, CM, DM, and QPM instances.
DSM is configured to retrieve the list of news services from a pre-defined directory in the AP locality. After that, it coordinates with SME to produce Alice’s initial discovery scope.

Metadata Specification

For the sake of simplicity, in this case study we have only considered static profile data, hence services are searched directly within discovery scope.
For the same reason, we have only taken user profile into account to determine the discovery scope.


To describe services related to information, we have defined appopriate ontologies, to be used in conjunction with the MIDAS Profile Ontology (see Metadata Section for a better visualization).

In particular, we have defined:


Hint: To better visualize the ontologies, you might use the Protégé Ontology Editor by selecting the option: Build an OWL project from existing sources.

 
 

The Zefiro Prototype

 

The MIDAS prototype has been deployed in a harbour scenario in the framework of the national Zefiro research project. In particular, here we describe how MIDAS components interwork during an example of user discovery session where Bob accesses services from a resource-limited device while on board of his docked boat.

 

Deployment Setting

We have deployed our MIDAS prototype components over both a fixed harbour computing infrastructure and devices on boats connected via IEEE 802.11 Access Points (APs). Each AP defines its network locality that includes service/information points on local wired hosts and mobile wireless devices, playing the role of service clients or providers, within the AP coverage area.

At MIDAS deployment time, it is necessary to decide where to allocate middleware components. In the above scenario, we have decided to distribute all non-client MIDAS components on fixed hosts in the harbour network: there is one centralised directory for service registration, while one instance of any other server-side middleware component is allocated on fixed hosts in each AP locality.
The used directory provides lease-based publishing with the event-based Java Naming and Directory Interface, which allows interested parties to subscribe and be notified of new service registrations.
About client-side MIDAS deployment, resource-rich devices have all MIDAS client facilities installed, whereas resource-constrained terminals only host lightweight stubs capable of forwarding discovery/service requests to dedicated mobile agent-based proxies running on fixed hosts in the user AP locality.
MIDAS proxies work on behalf of associated clients over the fixed network independently of possible temporary disconnections, maintain a copy of user/device profiles, and access services by coordinating with MIDAS facilities, in particular with dedicated MM, CM, DM, and QPM instances.

Metadata Specification

Service profiles are specified with the MIDAS Profile ontologies.
It is worth noting that each capability has a type property, which may assume two possible values:

  • core means that the capability regards the main activity of the service
  • functional means that the capability describes the way the service achieves its specific functonalities.

In addition, we have created a testbed service ontology. The requirement/capabilities ontology is derived from the UNSPSC standard taxonomy. In particular, we have developed a "Travel, Food, Lodging and Entertainment" ontology that is derived from the corresponding UNSPSPC taxonomy (starting from code 90.00.00.00).
Basically, the ontology in its current form resolves to a taxonomy, but we plan to move to a real ontology featuring more expressive relations.
At the current stage, the ontology tree depth (maximum degree of requirement/capability specialization) is 4 and the average number of sons for each node (multiplicity of requirement/capability related concepts) is 3.

We have also developed a Management and Business Professionals and Administrative Systems ontology (UNSPSC 80.00.00.00) with similar criteria.

See the TFLE Ontology [HyperOWL] [HyperONT]

Basing on the developed ontologies, we have defined a bundle of about 120 services, each one exhibiting one or two capabilities. In particular:

  • Services with only one capability have a core capability
  • Services with two capabilities have one core and one functional capability. This allows to evaluate the precision of our metadata model and matchmaking algorithm

The Zefiro Offer ontology defines a capability for each instance defined in the TFLE Ontology and some example services exhibiting each one capability.

See the Zefiro Offer ontology [HyperOWL] [HyperONT]

Queries have been then tested on the whole set of services defined as above.

The whole set of service instance ontologies is available on request.

We are currently evaluating the usability of the eCl@assOWL service ontology as a real-world service ontology within our testbed. The biggest issue seems to be the huge dimension of OWL service ontologies.

Discovery Scope and Service View Creation

After docking his boat, Bob starts a discovery session. The stub on his device triggers MIDAS to generate a companion proxy, running on the fixed network infrastructure and possibly migrating to maintain co-locality with Bob. The proxy maintains a copy of user/device profiles and generates its MM, CM, DM, and QPM instances.
DSM is configured to retrieve the list of services (provided by either harbour information points or docked users) in the AP locality. After that, it coordinates with SME to produce Bob’s initial discovery scope.

Then, DSM commands SVM to start its work: SVM analyses dynamic context conditions and creates the two tables for services included in/excluded from the view. For instance, when checking whether the island tour service is included in the view, SVM verifies the relevant static and dynamic conditions in Bob’s/device/service requirements and capabilities, e.g., whether the service provides island information in English or French (static), whether the current date is between July and August (dynamic), and whether his device supports the visualization format for the service results that the proxy will forward to the stub (static).

Discovery Scope and Service View Update

Let us suppose that another boat, e.g., Greg’s yacht, is approaching the harbour with an on-board PC providing additional services, such as a shared repository offering high-resolution pictures and a blackboard service with indications/suggestions about visited bays.
Via the registration facility locally installed, Greg’s yacht registers the offered services in the MIDAS directory. The CM instance of Bob’s proxy is notified of the new registration and Bob’s DSM updates the personalized view accordingly.
Then, via SME, Bob’s SVM finds out that Greg’s photo repository is not compatible with Bob’s dynamic device capabilities because the device battery level is currently too low to sustain the possibly long downloading of high-resolution pictures. Therefore, SVM inserts Greg’s repository in the table of services excluded from the view and annotates the dynamic requirement causing the exclusion. When Bob re-charges his device, CM senses the user context change and notifies SVM that re-evaluates the dynamic conditions associated with battery level.

 


Last updated 16-02-2006