ESRIN, Frascati, 6 th April 2005

1. gtdSISTEMAS DE INFORMACIÓN KES-B Project Final Presentation ESRIN, Frascati, 6th April 2005

2. Agenda PART 0. ESRIN Presentation PART I. Introduction I.1 Background I.2. Objectives I.3. Added Values I.4. Project Organisation PART II. Technical Presentation II.1. Implementation Approach II.2. Operational Context II.3. Architecture II.4. Ontology II.5. Subsystems PART III. Conclusions III.1. Results III.2. Way Forward III.3. Open Questions PART IV. Demo IV.1. Physical Deployment IV.2. Search Demo IV.3. Production Demo IV.4. Open Questions 2

3. ESRIN Presentation ESRIN Presentation

4. Introduction PART 0. ESRIN Presentation PART 0. ESRIN Presentation PART I. Introduction I.1 Background I.2. Objectives I.3. Added Values I.4. Project Organisation PART II. Technical Presentation II.1. Implementation Approach II.2. Operational Context II.3. Architecture II.4. Ontology II.5. Subsystems PART III. Conclusions III.1. Results III.2. Way Forward III.3. Open Questions PART IV. Demo IV.1. Physical Deployment IV.2. Search Demo IV.3. Production Demo IV.4. Open Questions 2

5. I.1 Background Problems in the EO Data Exploitation Chain: • The gap between EO Data Archives and Information/Services Users • Due to: The complexity and expense of the eminently manual process of mining information from EO data • Resulting in a bottleneck for the exploitation of the petabytes of available and new EO data. • The heterogeneity and incompatibility among formats and tools • Affecting data, information and knowledge. • Results in a number of additional difficulties for shorting the above introduced gap.

6. I.2 Objectives (1/2) KES-B is a (TRP) focussed at demonstrating with a prototype system the feasibility of the application of innovative knowledge-based technologies to provide services for two needs : • Support users in easily identifying and accessing the required information or products by using their own vocabulary, domain knowledge and preferences. • Automate generation of EO products with easy, scheduled and controlled exploitation of EO resources (e.g.: data, algorithms, procedures, ...) These initial goals have been translated in the KES-B prototype as the provision of the two main types of KES-B services: • Search service (also referred to as Product Exploitation or Information Retrieval service), which takes the form of the present web search portal • Production service (also referred to as Information Extraction), which takes the form of a workflow system that is able to integrate Image Information Mining (IIM) processing functions, and that publishes its services to the SSE KES-B Prototype Application domain scenario of test : • Water Quality: Oil –spill detection , HAB detection. • Transport Security: Ship detection, Winds extraction.

7. SSE Distributors Value Adders Data Providers Service Providers Support Infrastructure? Easy / Automate? Transformation (via Knowledge) EO Data/Products Information/Services Archives (PBytes) Users (KBytes) KES-B Platform Non-EO Data Production KES IIM KES Knowledge I.R Search KES KES-B I.2 Objectives (2/2)

8. I.3 Initial Added Value Thus, EO Data exploitation remain unexploited because of: • Manual transformation of Data to Information. • The user does not know about available information KES-B contributes to solve these problems by:

9. I.4 Project Organisation

10. Technical Presentation PART 0. ESRIN Presentation PART I. Introduction I.1. Background I.2. Objectives I.3. Added Values I.4. Project Organisation PART II. Technical Presentation II.1. Implementation Approach II.2. Operational Context II.3. Architecture II.4. Ontology II.5. Subsystems II.6. Physical Deployment PART III. Conclusions III.1. Results III.2. Way Forward III.3. Open Questions PART IV. Demo IV.1. Physical Deployment IV.2. Search Demo IV.3. Production Demo IV.4. Open Questions 2

11. II.1. Implementation Approach

12. II.1. Implementation Approach: OWL Ontologies

13. II.2. Operational Context

14. II.3. Architecture: System Actors and Functions

15. II.3. Architecture: System Components and Interfaces

16. II.3. Architecture: Production Collaboration Sequence

17. II.3. Architecture: Search Collaboration Sequence

18. Overview of Initial Concepts II.4. Ontology:

19. II.4. Ontology: Ontology functions Functional View: System Needs driving to Ontology needs

20. II.4. Ontology: Ontology Models integrated

21. II.4. Ontology: Deployment of Ontology Components

22. II.4. Ontology: KES ontology: kes_Resources taxonomy

23. II.4. Ontology: KES ontology: relations between resources Two kes_Resources can be related with a kes_Relation class. This enables the construction of a semantic networks of resources. Each relations bears weights, to each user and to each domain. These weights are modified when the user browse the knowledge base navigating through the semantic network.

24. II.4. Ontology: KES ontology: instanciating eoDomains

25. II.4. Ontology: Spatial Reasoning Engine Model SRE ontology: 3 main parts: • Search Model • Fusion Model • Report Model Search Model are rulesets of relations between features. Relations can be geo-spatial and attributive. Fusion Model are definition of topological operations (e.g. union, envelop), and atribute operations. Both models combine represent in a a Data Fusion model working on a GIS feature level.

26. II.4. Ontology: Fuzzy Logic Ontolody Model Enables to define Fuzzy Logic terms: • Fuzzy Sets (e.g. distance) • Fuzzy Terms (e.g. near, close) Supports the Qualitative Spatial Reasoning (QSR) Ontology, so users can define queries using fuzzy terms, (i.e. semantic terms)

27. II.5. Sub Systems: KMS Knowledge Base Server Components Architecture Diagram The knowledge baseserver keeps all the system information in a knowledge enabled manner using Protégé. The Protégé project is based on OWL and it is supported by a MySQL database backend. The OWL based elements are served by the Protégé RMI Server included in protégé distribution.

28. II.5. Sub Systems: KMS Knowledge Base Server Components Architecture Diagram Above picture shows the KBS architecture. It is based on three main components: • MySQL Database (COTS). • Protégé RMI Server (COTS). • KBI EJB Application (specifically developed KESB component). The KBI EJB application implements the “Put data” and “Get data”.

29. II.5. Sub Systems: FMS Feature Server component The FMS represents the KES-B system responsible to handle (in an operational basis) the spatial feature data. Thus, it supports the feature data information production, and also the feature data information exploitation (retrieval).

30. II.5. Sub Systems: FMS Feature Server component In the context of the KES-B system architecture, the FMS represents the backend system to handle feature data, and providing services to the KES-B Production (PMS) and Search (SMS) systems : 1. First, the PMS imports the feature data generated as outputof the image information mining (IIM) production procedure applicationworkflows. 2. And second, the SMS contains advanced spatial reasoning engines to exploit (retrieve, search).

31. II.5. Sub Systems: PMS • MIS (MASS Interface System), in order to publish KES-B services into MASS. • WMS (Web portal Mngt System), to publish a web graphical interface for function management (provision of function modules). • FMS (Feature Mngt System), in order to import feature data into KES-B GIS feature server database, • KMS (Knowledge Mngt System), in order to get and put metadata contents in the knowledge base.

32. II.5. Sub Systems: PMS

33. II.5. Sub Systems - PMS PMS aims to provide the following main functionalities  A Processing Machine Cluster (PMC), which is a variable set of Processing Machine (PM), each one including: o A Processing Machine WS Interface, to handle the requests coming from the Production Server. o A temporal Data Repository Server, to handle the operational products flow. o The actual processing engines (IDL, JAVA…) that are able to run the Function executable module provided by the expert.  A set of Processing Management Applications (PMA), for the production Expert and system administrator : o PMA1: the WFD tool (Collaxa BPEL Designer) o PMA2: the WFE console (Collaxa BPEL Server portal), to control the execution status of the WF. o PMA3: the Function Provision tool (a custom KES-B development). This tool provides a web-based interface for the expert to catalogue and submit Function packages, and a server side logic to generate the FuncionWS-Interface.

34. II.5. Sub Systems - SMS The SMS is the core part of the KES-B platform that implements theSearch capabilities. The SMS is conceived as the part of the KES-B system that enables the user to search, by query and browse actions, the relevant information available within the KES-B platform. Searches provided by the SMS can be summarized in the following: • Queries and browsing, • Free text query, ontology based query, spatial reasoning based query. The contents object of search are any resource stored on platform data backend components: • The Knowledge Base Server (KBS). • The Feature Server (FS)

35. II.5. Sub Systems - SRE Main characteristic for this engine remains on being the basis of a decision-making support system, being it possible due to:  • Possibility of expressing complex query models, composed by a number of relations involving an arbitrary number of features. The relations can be spatial relations (proximity, intersection, overlapping, orientation,…), and also relations between attributes of the related features (temporal proximity, other attributes conditions, etc.). The defined complex query can be saved in the system (in the user account) for later use. • Fuzzy Logic based evaluation for almost all the relations (spatial predicates as well as attribute relation predicates) offered by the engine. It is interesting to know if two feature objects accomplish or not a relation between them, but moreover it is interesting to know the degree in that the relation is being accomplished (0,0 to 1,0 or percentage). • The Query Results are ordered in base of the approximation strength to the Query Model. This strength may be also known as Certainty Factor. This means that in a query, all the relation evaluations are combined in order to obtain a value (0.0 to 1.0 or percentage) that will indicate how good are the matches resulting from the query.

36. II.5. Sub Systems: SRE (Spatial Reasoning Engine)

37. II.5. Sub Systems - UMS Added value in user oriented systems resides in the capabilities that system has towards user adaptation. The user interacts with the system constantly. The system ‘learns’ from those actions and updates user preferences. After this learning process, the system is able to present information adapted to user preferences. KES-B user knowledge must be feed from following subjects: User browsing: the navigation sequence exploitation produces a frequently navigation map. Portal map can be adapted to user preferences in this way to present most visited sections and short cuts to pages of interest.

38. II.5. Sub Systems - MIS The KES-B system has to publish its KES capabilities as a webservice into the MASS/SSE Environment. For this purpose, the MASS/SSE environment provides a MASS Toolbox (hereinafter MTB), as a component to be integrated in the service provider platform, enabling this publication and interfacing. MIS is a KES_B component that contains all the connectors between MASS portal and KES-B system. The components of MIS described in the following chapters are: • Toolbox application, • Services containing the name of the KES-B web service to be executed and the operations that the web service is capable to carry out, • JSP files transform the Toolbox request into a KES-B service request, • Definition files describing the service operations.

39. II.5. Sub Systems - MIS

40. II.5. Sub Systems - WMS The Web Management System is the KESB Web Portal. It represents a dynamic web content delivery.

41. Conclusions PART 0. ESRIN Presentation PART 0. ESRIN Presentation PART I. Introduction I.1 Background I.2. Objectives I.3. Added Values I.4. Project Organisation PART II. Technical Presentation II.1. Implementation Approach II.2. Operational Context II.3. Architecture II.4. Ontology II.5. Subsystems PART III. Conclusions III.1. Results III.2. Way Forward III.3. Open Questions PART IV. Demo IV.1. Physical Deployment IV.2. Search Demo IV.3. Production Demo IV.4. Open Questions 2

42. III.1. Conclusions: Structure

43. III.1. RL1 – Results on Technology

44. III.1. RL2: Results on System Design

45. III.1. Results on Ontology Architecture

46. III.1. Results on System Architecture

47. III.1. RL3: Results on System Functions

48. III.1. Results on Search Functions

49. III.1. Results on Production Functions

50. III.1. Results on Knowledge Management Functions