NEMO Technical Document 2012-05011-1 Nathan Dunn NEMO ...

groanaberrantInternet and Web Development

Feb 2, 2013 (4 years and 5 months ago)

202 views


1

NEMO Technical Document 2012
-
05011
-
1






Nathan Dunn



NEMO

Portal


Ontology Integration

Created: 5/11/2012

Last Updated: 5/11/2012



1. INTRODUCTION



Goals

This is a proposal for
improvements to NEMO. Aims can be split into short (~2 months) and long (~2
year) periods.


1. A
ccess RDF files and run the queries/reasoning through web
-
based GUI
.

2. S
tore both RDF contents and results of classification in database (in such a way that

these data can
later be queried).

3.
I
ntegrate the toolkit within the web
Portal

such that ERF’s can be submitted directly to the
Portal

and processed without direct interaction with Matlab
.

4. Performance enhancements to the query engine.



Aims 1 and 2 are both to be done in the short
-
term with an estimated timeframe of 2 months with a
N

FTE.
Create Estimate


Aim 3 is a longer
-
term goal that integrates
the
Portal

with the Matlab backend. This will be a 1
-
2 year
project and is not feature
complete.

Aim 4 may possibly be resolved in course of one of the other
aims.





2

2.
Short
-
Term Goals


To meet short
-
term goals of
we will create another server that will be built upon an onto
logy
framework, most likely
OWL. It will pull RDF’s from the
Portal (or have them pushed to it) (4
). As it is
built upon a common framework, we can run a pre
-
built reasoner
over the ontology tree
. Those
should be integrated t
o the Portal via web services (5
) in order to create a seamless interfac
e. Clients
can t
hen query the Ontology Server (6
)
directly (though should appear to be the same sever)
and
have
the
request in the ontology server
,

which returns a result

from the reasoned that is also downloadable
.



I would suggested implementing the ontology server in
Roo

or grails as they are both RAD
Java

servers
and most of the ontology reasoner libraries are written in
Java

already.


Other possible design decisions:

1


querying (6) could be done directly

through the Portal, with full integration via the Ontology

Server.
However, if you were going to install GWT to provide a richer querying interface, it would be easier to
do so in the server directly, which is already Java.











New W
ork
Po
rt
a
l
(R
u
b
y
+
D
B)
T
o
o
l
ki
t
(Ma
t
l
a
b
)
(3
)
D
u
mp

R
D
F

i
n
t
o


D
a
t
a
b
a
se
Ontology
Se
rve
r
(4
)
Syn
ch
ro
n
i
ze

R
a
w

R
D
F
'
s
(5
)
w
e
b

se
rvi
ce
s
i
n
t
e
g
ra
t
e
Ext
e
rn
a
l

C
l
i
e
n
t
s
(6
)
Q
u
e
ry
Se
rve
r
u
si
n
g

(5
)
(1
)
Pu
sh

ER
P'
s
t
o

p
o
rt
a
l
(2
)
Pu
sh

ER
P'
s
t
o

t
o
o
ki
t

3

Short
-
term Estimates:



Get system up and running to start (
1
-
3 days) (Portal
with a valid dump)



Create OWL server:

o

Stub
server and integrate with OWL (2
-
5

days)

o

Create accessible web services:



Push RDF’s (2
-
4

days)



Query
/ Download RDF’s (2
-
4 days)



Reason RDF’s (2
-
4 days)

o

Create
simple view interface for RDF (1 week)

o

Create query e
ngine
interface
(1
-
2

week
s
)



Portal changes:

o

Integrate download with web services (if necessary) (2
-
3 days)


o

Create web service for having Ontology Server pull content from portal on startup

(2
-
4
days)


4.5
-
8.5 weeks

~
1
-
2 months at 1.0 FTE


~ 2
.5
-
5.3

months

at 0.3 FTE





4

3. Long
-
term Goals


This assumes the
completion of the previous short
-
term goal. The goal of this step is to eliminate the
need for user’s to download Matlab and run the pipeline separately. In this step, the Matlab toolkit is
hid behind the
Portal
, whi
ch accepts submitted ERF data (1
), pr
ocesses it
, storing it locally, sends it to
the Toolkit (2
). The toolkit then push
es the processed RDF’s to the (3). The portal then synchronizes
with the Ontology Server (4).

At this point processing is done and external clients can Query the
Portal
,
which u
ses a web service to query the Ontology S
erver.


An important piece of this is that the Portal should be rewritten in Java. As most of the major
reasoner’s and API’s are written in Java, it makes the most sense to leave it in Java.

Additionall
y, the
integration opportunities with Matlab are far greater with Java then with Ruby.


Other possible design decisions:



The Portal could launch Toolkit instances on
-
demand in the cloud



Q
uerying
(4)
could be done directly on the Ontology Sever

as in the short
-
term goals



If the memory footprint is sufficiently small, the Ontology Server could be integrated into the
Ontology Server



Once converted into Java, the provenance pieces can easily be added, as well.

This piece
integrate
s

with GWT in or
der to provide a richer application and faster workflow.


.....



New W
ork
Po
rt
a
l
(Ja
va

+
D
B)
T
o
o
l
ki
t
(Ma
t
l
a
b
)
(3
)
Pu
sh

R
D
F

i
n
t
o


D
a
t
a
b
a
se
Ontology
Se
rve
r
(5
)
w
e
b

se
rvi
ce
s
i
n
t
e
g
ra
t
e
Ext
e
rn
a
l

C
l
i
e
n
t
s
(6
)
Q
u
e
ry
Se
rve
r
vi
a

(5
)
(1
)
Pu
sh

ER
P
(2
)
L
a
u
n
ch

T
o
o
l
ki
t

w
i
t
h

ER
P'
s
(4
)
syn
ch
ro
n
i
ze

se
rve
r

5



Long
-
term Estimates:



Convert Portal to Java (8
-
20 weeks
)



Integrate Toolkit with Portal:

o

Allow Portal to auto
mate Matlab Toolkit spawning (
2 weeks)

o

Modify Toolkit to Dump RDF back into
Portal (1 week)



Add Provenance:

o

Integrate GWT with Portal (1 week
)

o

Update
schema to reflect Provenance requirements (2 weeks)

o

Update interfac
e for Provenance requirements (4

weeks
)


Some estimates include requirement gathering and architecture changes.



18
-
38 weeks

~
4
-
9 months at 1.0 FTE


13


30 months at 0.3 FTE