Primera Diapositiva - PowerPoint PPT Presentation

1 / 72
About This Presentation
Title:

Primera Diapositiva

Description:

gtd SISTEMAS DE INFORMACI N KES-B Project Final Presentation ESRIN, Frascati, 6th April 2005 Agenda I.2 Objectives (2/2) I.3 Initial Added Value I.4 Project ... – PowerPoint PPT presentation

Number of Views:30
Avg rating:3.0/5.0
Slides: 73
Provided by: Lui100
Category:

less

Transcript and Presenter's Notes

Title: Primera Diapositiva


1
gtd SISTEMAS 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
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
II.4. Ontology
Overview of Initial Concepts
19
II.4. Ontology Ontology functions
Functional View System Needs driving to
Ontology needs
20
II.4. Ontology Ontology Models integrated
Ontology Construction Language Ontology Model Need Used by Deployed by
OWL XML Based EO Earth Observation domain knowledge representation. SMS to support search for EO Resources KB Server
OWL XML Based ES Earth Science domain knowledge representation SMS to support search for EO Resources. KB Server
OWL XML Based KES Knowledge Enabled Services knowledge representation. SMS to support search with user adaptation. PMS for Production Resources cataloguing. KB Server
OWL XML Based DC Dublin Core for universal item cataloguing. SMS to support search conducted by using information resource tags. KB Server
OWL XML Based ISO- 19115 Spatial Resources Metadata framework. PMS for Production Operational Resources Cataloguing. FMS for Feature Manager Operational Resources and Metadata Cataloguing. KB Server
OWL XML Based QSR Qualitative Spatial Reasoning (using FL). SMS (through the SRE) for advanced spatial searches over vector feature data stored on the GIS Feature Server. KB Server
OWL XML Based FL Fuzzy Logic for Uncertainty Representation. QSR ontology. KB Server
XML Based BPEL Workflow Definition PMS
XML Based UDDI WSDL SOAP Web Service Registration Web Service Definition Web Service Use MASS Interface
XML Based
XML Based OWL RDF-S RDF Knowledge Repr. (Ontology-based) Knowledge Repr. (Triples Networks with Taxonomy) Knowledge Repr. (Triples Data Networks) KB Server
Non-XML Based WordNet WordNet (WN) Natural Language Processing (NLP) Ontology. Used by SMS.Free Text Query algorithm. SMS
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 base server 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 output of the image information
mining (IIM) production procedure application
workflows. 2. And second, the SMS
contains advanced spatial reasoning engines to
exploit (retrieve, search).
31
II.5. Sub Systems PMS
  1. MIS (MASS Interface System), in order to publish
    KES-B services into MASS.
  2. WMS (Web portal Mngt System), to publish a web
    graphical interface for function management
    (provision of function modules).
  3. FMS (Feature Mngt System), in order to import
    feature data into KES-B GIS feature server
    database,
  4. 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 the Search 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
51
III.2. Ways Forward in the short-term
52
III.2. Ways Forward in the mid-long term
(perspectives)
Knowledge/Experience
Adoption
KES-B results take us here
Confidence in ability to implement
Advocacy
KES-B Initial Days
Positive experiences of the power of OWL
Enthusiasm
People are now asking How questions as opposed
to Why and What.
Curiosity
Skepticism
Increase in attendance at trainings and more
evidence of coverage at conferences
Commitment to Action
53
III.2. Ways Forward in the mid-long term
(perspectives)
54
III.2. Ways Forward in the mid-long term
(perspectives)
55
III.3. Questions and Answers
Thank You
56
IV. Demo
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
57
IV.1 Demo Physical Deployment
Minium platform for full functionality 2 Host
machines. At least 1 with Windows Server
Public access to Internet for MASS/SSE Conectivity
58
IV.1 Demo Physical Deployment Host1
Host 1 muis-dev Server 1/2
Apache Ant 1.6.1
WordNet
Aspell
Application Server Jboss 3.2.3
MySQL Server Port 3306
Application Server Jboss 3.2.3
ESRI ArcSDE Server 8.3 Port 5151
User Adaptation Engine EJB
Protégé RMI Server
Knowledge Base Interface EJB
MS-SQL Server Port 1433
Portal Servlet Container TOMCAT JWSDP 1.4
JetSpeed Port 80
Web Server Publisher
Portal JSP
HW PC Xeon 3.4 GHz RAM 3.5 GB
59
IV.1. Demo Physical Deployment Host2
Host2 muis-c Server
Apache Ant 1.6.1
Processing Machine Interface
Servlet Container TOMCAT JWSDP 1.4
Processing Service Interface WS Port 5001
FTP WS Port 5002
MASS Interface (TOOLBOX) Port 80
GLUE Server
Internet Information Server (IIS) (FTP only)
HW PC Xeon 3.0 GHz RAM 1.0 GB
60
IV.2.Demo Cases
  • Search Demonstration Cases
  • Free text search of EO resources
  • Advanced search of EO resources
  • Features Types source
  • Spatial Query Suspicious ship
  • Production Demonstration Cases
  • Provide Ship Detection Function
  • Ship Detection Service Workflow (Without GIS
    Importer)
  • Ship detection MASS Publication Service

61
IV.2. Search Case 1 Freetext query for EO
resource
Purpose To demo the free textual search
over the KB contents. The system explores the KB
contents ontology, applies the ontology
information structure, synonyms expansion using
Wordnet, misspelling expansion using
Aspell. Inputs On the portal, Introduce in
Free Text query production proceddure. Execut
ion Input text, and press Search button.
Outputs n classes found (x) m instances
found (x) Conclusions kes_Procedure has been
found, and it is possible to prove the behaviour
of textual queries.
62
IV.2. Search Case 2 Advanced Query for EO
resource
Purpose To demo that user can find out
which production procedures process a certain
type of product to generate a specific feature.
Through the advanced search functionality, the
user creates a query to exploit certain relations
between certain classes. Inputs String
logic All words production Target
Filters Domains Oil Spill Domain
Classes KES Procedure Execution Introduce
properly values in advanced search and push
Search button. Outputs n classes found
(x) m instances found (x) Conclusions It
is possible to refine textual searches.
63
IV.2. Search Case 3 Browse EO resources
Purpose To demo that class navigation
feature provided by the search HMI runs
properly. To find out which instrument has
generated the product from which a harmful alga
bloom feature has been extracted.
Inputs Classes gt KES Feature gt ES Feature gt
Harmful Alga Bloom Feature gt HAB Detection gt
MER_FR__1P gt Medium Resolution Imaging
Spectrometer (MERIS) gt ENVISAT Satellite Executio
n Execute previous inputs through
browser. Outputs ENVISAT Satellite
description. Conclusions It is possible to
browse through ontology classes looking for
desired capabilities.
64
IV.2. Search Case 4 Spatial Query (suspicious
ship)
Purpose To demo that it is possible to
build spatial querys. This demo detects ships
which are probably guilty of causing or
originating oil spills according to given model
(model itself just pretends to be
illustrative). Execution Go to Spatial
search. Load Query 6 from KESB
Portal. Select an interest area. Press Search
button. Outputs A set of results. Conclusion
s It is possible to establish spatial searches
between data produced by Production Subsystem.
65
IV.2. Search Case 4 Spatial Query (suspicious
ship)
Purpose To show that it is possible to
build spatial querys. This query detects ships
which are though to be guilty of causing or
originating oil spills according to given
model Inputs (Scenario)
66
IV.2. Search Case 4 Spatial Query (suspicious
ship)
Reasoning of the Query Model If ships are
near oil spills, in time and space, And ships and
oil-spill bear in similar direction, And wind are
blowing in similar direction than oil-spill in
that time, Then, Ship is considered suspicious.
(model itself just pretends to be illustrative).
67
IV.2. Search Case 4 Spatial Query (suspicious
ship)
Execution Go to Spatial search. Load
Query 6 from KESB Portal. Select an interest
area. Press Search button. Outputs A
set of results. Conclusions Spatial Search
engine is able to find instances of feature
objects that meet the query rules constraints,
with a varying degree of certainty (result
strenght), based on a fuzzy logic based spatial
pattern matching similarity measure.
68
IV.3. Production Case 1 Provide Ship Detection
Function
Purpose To demonstrate how the user uploads
the Ship Detect expert function to the KESB-PMS
System. It will be uploaded the IDL module, which
provides the Ship Detection algorithm. Inputs
see figure --gt
Execution Introduce all parameters correctly
and push send button. Outputs Ship Detection
will be deployed like a Web Service. Conclusions
It is possible to add functionalities to the
system through Web Portal, in which expert user
will can add theirs own algorithms.
69
IV.3. Production Case 2 Ship Detection WF Service
Purpose The Ship Detection service detects
ships shape on the sea surface, from ERS-SAR-PRI
or ENVISAT-ASAR-WSM satellite images and for each
detected ship extracts its features. In this way,
this Work Flow will be in charge of proving that
this functionality runs properly. Inputs Set
of files - DAT_01.001 - LEA_01.001
- VDF_DAT.001 Execution Open a browser with
Oracle Bpel Server. Call Work Flow with
following parameters
ltexecutionRequest xmlns"http//acm.org/samples"gt
ltFTPgtfalselt/FTPgt
ltinputDirgtanonymousanonymous_at_kes-b.gtd.es/data/in
put/lt/inputDirgt ltoutputDirgtanonymousano
nymous_at_kes-b.gtd.es/data/output/lt/outputDirgt ltinp
utParamsgtFRPARAMETERS\kesb\feature\extraction\
data\output\UTV_Ship_p_\kesb\feature\extraction\
data\idl\input\DAT_01.001\kesb\feature\extraction
\data\idl\input\LEA_01.001\kesb\feature\extractio
n\data\idl\input\VDF_DAT.001lt/inputParamsgt
lt/executionRequestgt
Outputs A set of shape files with
corresponding ships data extracting of satellite
image. Conclusions It is possible to create
Work Flows combining different algorithms
introduced into KESB system by expert user,
70
IV.3. Production Case
Demo Case 2. Ship Detection Service Workflow
2/2 Outputs A set of shape files with
corresponding ships data extracting of satellite
image. Conclusions It is possible to create
Work Flows combining different algorithms
introduced into KESB system by expert user,
71
IV.3. Production Case 3 Shipt Detection Service
in MASS
Purpose To demonstrate the KES-B
capabilities of acting as a service provider and
publish a ship detection service available to
MASS clients. Therefore involves, publication of
KES-B internal service and execution of the
service through MASS portal. Inputs MASS
registration files TOOLBOX registration
files JSP Connector Execution Loggin
to http//services.eoportal.org and log in using
user gtdprovider and password 318aktn7.
Outputs A Ship Detection service published
into MASS/SSE portal. Conclusions It is
possible to declare public functionality through
MASS/SSE portal.
72
IV.4. Questions and Answers
Thank You
Write a Comment
User Comments (0)
About PowerShow.com