View Pescado Project's profile on LinkedIn

Pescado in Facebook

 

TOPICS: Node Discovery - Orchestration - Ontology - Decision Support - Interaction Techniques - Information Production - Integration, Demonstration, Delivery - Assessment, Evaluation - Dissemination, Exploitation

Integration, demonstration, delivery

There is a threefold objective:

1) the integration of the individual modules at predefined stages of their development in other WPs into a holistic workbench – with the integration of the last development stage being the final PESCaDO service;
2) the demonstration of the viability of the prototypes and of the final service with representative pilot use cases at hand;
3) the delivery of the showcase at the end of the project.

Requirements
In the first phase the requirements were collected based on the specification of the two pilot use cases and the implementation of the user profiles and user typology.
In Use Case 1, the PESCaDO workbench is used to help a citizen with planning a journey (be it on a regular basis such as commuting between home and place of work or a vacation trip) or an excursion. The Use Case comprises issues which may affect the decision concerning a journey – as e.g. weather, air quality, and pollen. The consideration of these issues, combined with traffic situation, is supposed to make the journey fluent and minimize the exposure to pollutants, sun, etc. These issues are useful in routine journey planning and, for example, in air quality episodes when traffic is restricted in a city center. From that use case we extracted a first scenario which is also the base for the 1st demonstrator: The user wants to travel from a location X to a location Y in the near future and is interested to know whether any health issues might be provoked by environmental conditions, i.e., weather, air quality, pollen, dense traffic or dangerous roads. They might provide further information such as the transportation means of their preference, diagnosed allergies, etc. Another option is that this information is already stored in a user profile. Another scenario from the Use Case 1 concerns Administrative Decision Support. In this scenario the user is a member of an administration responsible for a certain region who wants to know if any of the measurements of air pollutants at a certain time are above or near the limit values.



Specification of the PESCaDO architecture

The architecture specification follows the Reference Model for Open Distributed Processing (RM-ODP), which defines 5 viewpoints: Enterprise Viewpoint, Computational Viewpoint, Information Viewpoint, Technology Viewpoint and the Engineering Viewpoint. The Computational Viewpoint is referred to as the Service Viewpoint in PESCaDO in order to stress that the focus is not on providing a distributed computing support with tightly-coupled components, but on inter-connecting functionalities and information in terms of services (Service Oriented Architecture - SOA). Thus, the Service Viewpoint classifies and specifies the functional requirements in terms of services.

The following services have been identified for the 2nd prototype; follow the links to see the examples:

  1. Answer Service (AS): This service initiates an answer to a request from the field of the PESCaDO topics. To reach this goal, it orchestrates other PESCaDO services in accordance with the established workflow.
  2. Content Selection Service (CSS): Selects the content elements that are to be communicated to the user from the content set provided by the Decision Service in accordance with the profile of the user and other relevance criteria. The expert user is involved in the process of content selection.
  3. Data Retrieval Service (DRS): Responsible for the retrieval of the requested information (i.e. measurements of specific aspects) for the geographical area of interest. The DRS, plays also the role of managing the available environmental data nodes and the Intersection Service in the sense of processing data requests.
  4. Decision Service (DS): The Decision Service retrieves the content that is relevant to the solution of the user’s problem formulated in terms of PESCaDO-PDL statements.
  5. Fusion Service (FS): The general task of the FS is to process the data received from different environmental service nodes via the Data Retrieval Service with the purpose to obtain the best and most complete data set to address the user’s request for information or decision support.
  6. Information Production Service (IPS): The Information Production Service receives as input the Content Plan compiled by the Content Selection Service, the user profile and potentially other contextual setting restrictions and produces user problem targeted multimodal information as text, table and graphic, which is passed to the Answer Service.
  7. Intersection Service (IS): The Intersection Service segments the route of interest into different parts (i.e. areas or smaller routes) based on ground and road condition parameters (e.g. normal traffic, width of roads, etc.). It should be noted that the parameters for segmenting a route are subject to the requirements for fusion.
  8. Knowledge Base Access Service (KBAS): Supports the access to the Knowledge Base on which the whole PESCaDO platform relies to provide user decision support. This service provides, access, manipulation and storage of ontologies (or ontology modules) stored in the Knowledge Base. Besides the common retrieval methods, the interface offers a generic mechanism for retrieval.
  9. Mode Selection Service (MSS): The goal of the Mode Selection Service is to decide on the mode of visualization of the contents in the Knowledge Base (KB). The question is how they shall be shown to the user. It has to be decided whether these contents must be visualized as text and/or visualization.
  10. Problem Description Generation Service (PDGS): The goal of this service is to generate / check a description of the problem in PDL submitted by the user to the PESCaDO platform, according to the information provided by the user via the user interface / third party systems.
  11. Related Aspects Computation Service (RACS): It selects the aspects that need to be considered for delivering an informative answer to the user, given the problem description generated for the users' request.
  12. Route Calculation Service (RCS): Provides a range of services based on (freely) available spatial data, e.g. data provided by Open Street Map.
  13. User Interaction Service (UIS): The User Interaction Service has two main functions. First, it ensures the communication between the expert and end users on the one side and the services that involve the intervention of the user for their optimal functioning on the other side.
  14. User Profile Management Service (UPMS): Manages user profiles. User profiles can be created, written, deleted and queried.

Set up of system platform and development of the second prototype

The initial platform demonstration presented the completion of the data and semantics representation framework evaluation and the setup of the first proof-of-concept local content and data repository.
Skeletons of each module (1. discovery and targeted environmental node search, 2. service confidence assessment, 3. service node orchestration, 4. ontology web search, 5. ontology alignment and learning, 6. content distillation, 7. decision support, 8. visualization and user interaction, 9. information generation) were in place and already interacting.
After that the 1st demonstrator was mainly aimed at the end user. Of course, all the back-end systems have been integrated and working together to make the demonstrator possible, but their various administrative interfaces are not exposed to the public.

The following image displays the user interface of the 2nd prototype:



All skeleton implementations of the services have been replaced with the basic versions to fulfill the goal of the first scenario. The 2nd demonstrator introduces the administrative scenario. The basic versions of the services have been consolidated and new service functionalities have been implemented.

The final PESCaDO workbench will be incorporating the refinements of the techniques developed within our research. Also most of the features specified in the use cases will be implemented.

CONTACT:
Jürgen Mossgraber <juergen.mossgraber@iosb.fraunhofer.de>

PESCaDO Coordinator:
Leo Wanner • leo.wanner@upf.edu
tel.: +34 935 422 241
PESCaDO Scientific & Technical Manager:
Ari Karppinen • ari.karppinen@fmi.fi
tel.:+358(0)9 192 95 453