output fromNEMO ERP metric extractionrepresented in RDF structured using theNEMO ontologyqueried using a SPARQL

schoolmistInternet και Εφαρμογές Web

22 Οκτ 2013 (πριν από 4 χρόνια και 2 μήνες)

500 εμφανίσεις


1

NEMO Technical Document 2010
-
011


Created: 2010
-
06
-
11 (SN)

Last Updated: 2010
-
07
-
0
5 (
JS
)





Toward a Working Prototype for the NEMO ontology database:

Linking NEMO ERP Data (metrics) to NEMO Ontologies


Gwen Frishkoff, Snezana Nikolic, Robert Frank,
Paea LePendu

& Jason Sydes



1. INTRODUCTION


This document describes the methods we are using to build a first working model of the NEMO
ontology database. "Working" means four things:


1.


The ontology database contains
output from

NEMO ERP metric extractio
n

(Section 2.1)

2.


These output data are
represented in RDF
(Section 2.2)

3.


The ontology database schema is
structured using the

NEMO ontology

(Section 3); and

4.


The ontology database can be successfully
queried using a SPARQL

query engine (Section 4).


2. ON
TOLOGY DATABASE CONTENTS


The purpose of the NEMO ontology database is to represent ERP summary data (spatial, temporal, and
functional attributes of ERP patterns) in a structure that is compatible with NEMO ontologies and in a
form that can be queried usi
ng an RDF query language, such as SPARQL.


The remaining parts of Section 2 describe the database contents (Sec. 2.1) and the specific dataset (Sec
2.2) that we are using for initial design and implementation of the database.


2.1 Nature of Database Conte
nts


The ontology database is designed to store summary data (ERP attributes or "metrics") that are extracted
from ERP patterns using Robert Frank's matlab script,
NEMO_ERP_Metric_Extraction

(
Metric
Extraction

for short) and associated routines that are ca
lled by this script. These routines are part of the
NEMO_ERP_Toolkit

(http://nemo.nic.uoregon.edu/wiki/NEMO_ERP_Analysis_Toolkit). The latest
version of the toolbox can be downloaded from
(http://nemoontologies.svn.sourceforge.net/viewvc/nemoontologies/too
lkit).


The output from Metric Extraction can be visualized in Excel, where a single spreadsheet represents
summary data for each experimental condition and each subject in an ERP experiment. Each
column

in
a spreadsheet corresponds to a
spatial, temporal
or other identifying attribute

contained in the NEMO
ontology. Each
row

represents an
ERP pattern

extracted via PCA/ICA or microstate analysis
(http://nemo.nic.uoregon.edu/wiki/NEMO_ERP_Analysis_Toolkit#NemoErpPatternExtraction). Each
spreadsheet cell ther
efore contains the
value

of a particular attribute class (cell column) that is
associated with an
instance

of some ERP pattern class (cell row). For example, row 1 of Figure 1
indicates that PCAfactor #01 (an ERP pattern that was extracted using temporal P
CA) onsets at 424ms
(TI_begin) and offsets at 528ms (TI_end) and that center of positivity (CoP_XYZ) for this pattern has a

2

set of xyz coordinate values (
-
0.00, +3.35,
-
1.93). Note that the terms used for this sample output are not
precisely the same as te
rms in NEMO ontologies. However, there are precise mappings, as described in
Sec 3.



Figure 1.
Sample output from Metric_Extraction script, formatted in tab
-
delimited text and viewed in Excel.


This same kind of information can be output to a comma
-
delim
ited (.csv) text file. See Figure 2 for
example. Row 1 of Figure 2 indicates that observation 001 (
PCAfactor#001
) is associated with a specific
stimulus type, namely,
sim_word

(simulated words).


Figure 2
. Sample output from Metric_Extraction script, form
atted in CSV and viewed in Excel.


Finally, Bob Frank's ERP Metric script outputs metrics in an RDF triple form (see
TR2010
-
003_RDF

for details). See Figure 3 for example. Row 1 of Figure 3 states that 0121 is a (instance of) the class
event_related_durat
ion
. Row 2 specifies the value of this instance as 152 (a
number
). Row 3 specifies
the units as
milliseconds
. Finally, row 4 indicates that this measurement_datum is associated with
(
inheres_in
) observation 001 (PCAfactor#001). Note that the relation "inh
eres in" here serves as a
temporary placeholder for relations that are specified in NEMO_relations (Sec 3.1).



Figure 3
. Sample output from Metric_Extraction script, formatted in RDF. See TR2010
-
003_RDF for details.


Section 3 (below) describes the steps

to transform this RDF output into RDF that is semantically
structured (using NEMO ontologies).


3

2.2 RDF and RDF Syntax


RDF (Resource Description Framework) is a standard language for representing information about
resources on the World Wide Web, that c
ould also be used to represent information about things that can
be identified on the Web (http:www.w3.org/TR?rdf
-
primer/). The underlying mechanism used by RDF
to represent the information, is based on two simple principles: 1) each resource (i.e. where t
o find a
searched piece of information/data on the Web) is determined by a unique identifier called
Universal
Resource Identifier

(
URI
) and, 2) each resource is described by using simple statements about the
resource properties and property values. An inf
ormation about a resource could be conveniently
conceived as simple sentence of English language, where sentence subject (S) is the described resource,
sentence predicate is a property associated with a subject resource (P) and sentence object (O) is a val
ue
of the property stated by the predicate.

RDF subject, predicate and object (also known as the RDF triple) have their URIs and are commonly
represented together as an RDF graph where subject and objects are represented as nodes and predicate,
a relation,

(represented as line) between the subject and object nodes.


RDF graphs can be encoded using several different syntaxes all of which convey the same information
about the subject resource. Most common RDF syntaxes are 1)
N
-
triples syntax

which uses the fu
ll URIs
written in the RDF S
-
P
-
O order; 2)

Notation 3

(
N3
) syntax which writes the S
-
P
-
O triples in the form of
QNames (qualified names) and 3)
XML syntax for RDF
, generally known as
RDF/XML

which encodes
RDF graphs using the mechanisms of XML namespaces (
http://www.w3.org/XML/1998/namespace)
,
XML Information Set and XML Base. (Note: For details on XML namespaces, please see
http://www.w3.org/XML/1998/namespace), for details on
XML Information Set and XML Base, please
see the document http://www.w3.org/TR/1
999/REC
-
xml
-
names
-
19990114/).


Taking into account that RDF/XML syntax is been supported by a vast majority of parsers and has
become almost a standard for RDF syntax, as well as the fact that the same syntax (as the allowed
exchange syntax for OWL, Web O
ntology Language) is been used for encoding NEMO onotologies,
NEMO team has made a decision to use RDF/XML syntax as long
-
term format for the textual
representation of RDF generated by the NEMO_ERP_Metric_Extraction tool.

(Note: For further RDF/XML please
see http://www.w3.org/TR/rdf
-
syntax
-
grammar/).


3. MAPPING RDF DATA REPRESENTATION TO NEMO ONTOLOGIES


Each term that is represented in the ontology

database is assigned a unique identifier (URI), which
corresponds to a term in the NEMO ontology. (The exceptions are instances of
ERP_spatiotemporal_pattern and instances of data_item and label classes; URI for these individuals are
assigned "on the fly"

as described in Sec. 3.1). NEMO ontologies should therefore contain the following
information, in order to support ontologically correct representation of Metric_Extraction data:


1.


Classes

that map to terms in the Metric_Extraction script and output data
(Section 3.3
-
3.4 &
Appendix A).

2.

Object properties
that are used to specify class restrictions and, more precisely, to specify the
domain and range of operators that map between classes in the Metric_Extraction output
(Section 3.4 & Appendix B).

3.

Individual
s

that map Metric_Extraction output data to instances of classes in the ontology
(Section 3.5 & Appendix B).


4

4.

Data properties

that specify constraints on individuals


i.e., instances of NEMO classes
(Section 3.5 & Appendix C).


3.1 Minimal set of RDF asser
tions to relate data to ontology


For initial development and testing of the ontology database we are using extracted metrics for a
subset

of the simulated ERP dataset called
SimERPv5

('Sim_ERP_Data.raw'). The
Sim_ERP_Data.raw

file
(http://nemo.nic.uoregon
.edu/wiki/images/8/84/Sim_ERP_Data.zip) contains 80 simulated ERP datasets.
Each dataset represents the ERP data for one of 40 simulated subjects in one of 2 experimental
conditions, and is the result of superposing 5 simulated (latent) patterns that resem
ble actual patterns
seen in ERP responses to visual words: the P100, N100, N3, MFN and P300. Inter
-
subject and inter
-
conditional variance were introduced by modulating pattern intensity across individual datasets as
described in (TR2010: 'SimDataPCAICAv5
-
T
est Dataset.docx.').


Let's consider how to represent a
single instance of the ERP metric
peak_latency_measurement_datum

for
a single instance of some ERP_spatiotemporal_pattern
in a
way that establishes core linkages between the RDF data representation an
d NEMO ontologies. There
are four basic types of assertions that are needed to accomplish this:


1.

Assertion Type 1
: Establishes that there is an instance of the class,
ERP_spatiotemporal_pattern
, and assigns this instance an auto
-
generated unique URI.
I.e.
,
one row is linked to the NEMO ontology.

a.

Example using term_labels:



rdf:type

(001, ERP_spatiotemporal_pattern)

b.

Same example rendered with NEMO URI:

rdf:type

(001**,

http://nemo.nic.uoregon.edu...NEMO_ERP#NEMO_0000093)

c.


(**) Note that 001 corresponds
to a URI that is auto
-
generated in Bob Frank's RDF
output script. Thus, there is not a corresponding entity in the ontology. If there were a
corresponding entity in NEMO.owl, it would be an individual (i.e., an instance of a
class).


2.

Assertion Type 2
: Esta
blishes that there is an instance of
peak_latency_measurement_datum

and assigns this instance an auto
-
generated unique URI.
I.e., one column is linked to the NEMO
ontology.


a.

Example using term_labels:



has_type

(002, peak_latency_measurement_datum)

b.

Sam
e example rendered with NEMO URI:

has_type

(002,

http://nemo.nic.uoregon.edu...NEMO_data#NEMO_0745000)


3.

Assertion Type 3
: Establishes that the cell indexed by the row and column, and assigned the
URI from assertion type 2, has a particular
measurement_val
ue

(and measurement units in a
separate assertion, where appropriate).

a.

Example using term_labels:



has_numeric_value***

(002,

+152.00^^<decimal>)

b.

Same example rendered with NEMO URI:

http://nemo.nic.uoregon.edu/ontologies/working/NEMO_relations.owl#NEMO
_7
943000
(002,

+152.00^^<decimal>)


5

c.

(***)
has_numeric_value

takes numbers as its range; we have a separate data property,
called
has_character_string_value,
which takes strings as its range).

d.

When appropriate, cells will also be assigned a value for the rela
tion
has_measurement_unit

in another assertion.


4.

Assertion Type 4
: Establishes that 002 (an instance of the class
peak_latency_measurement_
datum
) has a specific
ontological relation

to 001 (an instance of the class
ERP_spatiotemporal_pattern
). The type of

relation is determined by the metric type (i.e., the
ontology class associated with a particular column).

a.

Examples using term_labels:



is_peak_latency_measurement_of

(002,

001)

b.

Same example rendered with NEMO URI:

http://nemo.nic.uoregon.edu/ontologies
/working/NEMO_relations.owl#NEMO_9
278000
(002,

001).


Note that Assertions 2
-
4 specify the minimal information that is needed to identify a particular cell (002)
within a graph representation of the data (e.g., Fig. 1).


3.3 Enumerating classes that corres
pond to rows in RDF output


ERP_spatiotemporal_pattern

(NEMO_0000093), is the only ontological class that is needed for
classification of rows in the RDF output. Classification of the instance as a particular type of ERP
pattern is accomplished through inf
erences based on ERP pattern class restrictions (see Section 4 for
discussion).


3.4 Enumerating classes and object properties that correspond to columns in RDF output


We need to identify (or create) a term in NEMO ontologies that corresponds to each metr
ic ("attribute")
in the NEMO_ERP_Metric_Extraction output. As we continue to add class and property restrictions, a
number of complex or "derived" attributes in the metric extraction can be deprecated. Appendix A lists
about 25 core attributes (represented

as classes in the ontology) that express basic and generally
nonoverlapping information. Generally, these fall into two major superclasses:
IAO:label

and
IAO:data_item
.


Table 1 gives examples of three subclasses of IAO:label and specifies how the relatio
nship is_about
relates each label to another entity in the ontology. For example, the class
experiment_participant_ID

is_about some person (or animal) who plays the role of experiment_participant in some investigation.
This experiment_participant cannot be

a member of the class
experiment_participant_ID
; class members
must be actual labels (strings), such as "experiment_participant
-
01." In other words, the string
"experiment_participant
-
01" is
used

to label a real
-
world entity (the actual experiment_partici
pant); it is
mentioned

as a member of the class
experiment_participant_ID
.



Table 1
. Left
-
hand column, NEMO subclasses of IAO label.


Middle column, NEMO subclasses that designate entites that NEMO labels are about.



Right
-
hand column, examples (hypoth
etical individual members of IAO:label classes).


subclasses of IAO:label

is_about
<class>

class instance

cell_standard_condition_label

experiment_condition

string="experiment_condition
-
01"

experiment_participant_ID

experiment_participant

string="experim
ent_participant
-
01"

ERP_pattern_label

tPCA_factor_pattern

string="tPCA_factor_pattern
-
01"


6


Similarly, the string "experiment_participant" refers to a class in the ontology; however, instances of this
class are not labels, but real
-
world (biomaterial) ent
ities (Table 2).



Table 2.

Onto superclasses and examples of instances for NEMO classes that are not IAOs




(but are what the IAOs refer to or are "about")


onto class

onto superclass

class instance

experiment_condition

planned_process

real
-
world exper
iment condition

experiment_participant

biomaterial_entity

real world human participant

tPCA_factor_pattern

ERP_spatiotemporal_pattern

real
-
world instance of some ERP pattern


There is a corresponding use
-
mention distinction that applies to
IAO
:
measurem
ent_datum

(Table 3).





Table 3
. Left
-
hand column, NEMO subclasses of
measurement_datum
.


Middle column, NEMO subclasses that designate entites that NEMO data are "about."


subclasses of IAO:measurement_datum

is_about*
(class)

class instance

temporal_m
easurement_datum

some
temporal_region
**

e.g., instance of
latency_measurement
:

a value (numeric literal +unit =
millisecond
)

spatial_measurement_datum

some
spatial_region
**

e.g., instance of
xcoordinate_measurement
:

a value (numeric literal)

intensity_
measurement_datum

some
intensity

(


quality) **

e.g., instance of
mean_intensity_measurement
:

a value (numeric literal +unit =
microvolt
)

*is_about is the super
-
relation. There are 9 sub
-
relations as specified in Appendix B.

**Note that we are temporaril
y designating the range for all "about" relations as a subclass of ERP_spatiotemporal_pattern.


Note that IAO has defined class
measurement_datum

as a type of
IAO:Information Content Entity

(ICE), similar to
IAO:label
. Therefore, just as
experiment_partic
ipant_ID

is_about

some real
-
world
participant in an experiment,
temporal_measurement_datum

is_about
some temporal entity (a temporal
interval or instant).


The following
object properties

are used in our initial RDF representations to relate ICE (label/ID

or
measurement_datum classes) to
ERP measurement data
. Note that they are all subclasses of the relation
is_about
.




specifies_provenance_of



is_peak_latency_measurement_of



is_onset_measurement_of



is_offset_measurement_of



is_duration_measurement_of



is_xcoor
dinate_measurement_of



is_ycoordinate_measurement_of



is_zcoordinate_measurement_of



is_mean_intensity_measurement_of



is_standard_deviation_intensity_measurement_of


The precise domain and range for each of these relations is specified in Appendix B (and

will be
specified in the
NEMO_relations
.owl, either in the form of class restrictions or in annotations). These
relations are located in the
NEMO object property hierarchy

as follows:


7




is_about

o

is_label_of

o

is_quality_measurement_of



is_temporal_measureme
nt_of



is_peak_latency_measurement_of



is_onset_measurement_of



is_offset_measurement_of



is_duration_measurement_of



is_spatial_measurement_of



is_xcoordinate_measurement_of



is_ycoordinate_measurement_of



is_zcoordinate_measurement_of



is_intensity_measurement
_of



is_mean_intensity_measurement_of



is_standard_deviation_intensity_measurement_of



NOTE: Although each of these relations has a distinct range, for short
-
term rendering of data in RDF,
we are specifying the range simply as ERP_spatiotemporal_pattern,
to avoid complex chains of
inference.


8


3.5 Enumerating data (values) and data properties


Instances of ERP_spatiotemporal_pattern (what the data are about) and instances of ERP metrics can be
represented directly in Protege/OWL by declaring individuals. I
t is probably more sensible, however, to
have URI automatically assigned
--

that is, generated "on the fly"
--

as the data are being output to RDF.
In this way, we can keep the NEMO_data module from exploding.


Once these individuals have been generated,

we need to assign values and specify datatype restrictions.
To this end, we have three basic data properties defined in NEMO:




has_numeric_value

(NEMO_7943000)


applies to subclasses of IAO:data_item



has_measurement_unit
(NEMO_5052000)


applies to subcl
asses of IAO:measurement_datum



has_character_string_value
(NEMO_2466000)


applies to subclasses of IAO:label


See Table 3 below for examples.



has_numeric_value

(NEMO_7943000)

has_measurement_unit

(NEMO_5052000)

has_character_str
ing_value

(NEMO_2466000)

peak_latency_measurement_d
atum (NEMO_0745000)

+484.00^^<double>

millisecond*



mean_intensity_measurement_
datum (NEMO_9201000)

+1.99^^<double>

microvolt*



one_dimensional_xcoordinate_
measurement_datum
(NEMO_9128000)

+96.12^^<double>





cell_standard_
condition_label

(NEMO_6444000)





"C01"^^<string>


*Range = any subclass or instance of unit_of_measure


4. QUERYING THE DATABASE


The final step is to query the ontology database. There are three steps:




Formulate a sample query (Sec. 4.1)



Link the RDF
representation of the data to the rest of NEMO ontologies (Sec. 4.2)



Query the combined ontology + data with a SPARQL query engine (Sec. 4.3)


4.1 A sample query to test the ontology
-
based data representation


A central motivation for developing NEMO ontol
ogies is to support valid classification and labeling of
ERP data (i.e., assignment of instances of ERP_spatiotemporal_pattern to specific ERP pattern
subclasses). One way to accomplish this goal is to specify the necessary and sufficient conditions on
cla
ss restrictions on each ERP_spatiotemporal_pattern subclass (using Equivalent Classes: Class
Expression Editor in Protege, or the equivalent statement in OWL (<owl:equivalen
tClass>).


9

For example, suppose the following assertions are true:



has_type

(001,ER
P_spatiotemporal_pattern)



has_type

(002, peak_latency_measurement_datum)



has_numeric_value

(002,

+152.00^^<double>)



Further suppose that the class
N100_occipital_pattern
has the following restriction:



ERP_pattern_peak_latency_measurement that
has_numeri
c_value

some double[>=140] and
ERP_pattern_peak_latency_measurement that
has_numeric_value

some double[<=220]


Then the appropriate inference engine should be able to infer that



has_type

(001, N100_occipital_pattern)


Note that if we set this up correctly
, we should be able to handle two interesting cases:




Case #1: 001 is assigned to
multiple subclasses

of ERP_spatiotemporal_pattern. This is
fine, since Protege/OWL does not adopt the Unique Name Assumption (UNA). An
individual can have several names (cf.
Frege's famous example of the Morning Star and
the Evening Star).


These cases will provide interesting grist for the ontologies. Assuming that each instance should belong
to one and only one ERP pattern class, one solution would be to modify the class re
strictions (i.e., ERP
pattern class definitions). However, we need to be cautious about over
-
restricting the definitions. Many
ERP patterns do show substantial spatial and temporal overlap, and this fact should be honored in the
ontology. As long as patte
rn definitions (from the literature) are non
-
identical, we are listing them as
separate classes in the ontology. When we have compelling evidence that the two classes are exact
synonyms, we may then deprecate one class and list the other class as a synonym
.




Case #2: 001 is assigned to
no particular subclass

of ERP_spatiotemporal_pattern.


These cases also provide critical input to the ontology development. If we have reason to believe that the
instance does belong to an existing pattern class, then we will

need to revise the class definition. More
interesting is the case where we believe we have genuinely identified a new pattern class.


Note that we need to define a subclass of ERP_spatiotemporal_pattern that is the
complement

of all the
defined classes (i
.e., is disjoint with all of the ERP patterns that we have explicitly defined in the
ontology). We can call this class Undefined_ERP_spatiotemporal_pattern. Chapter 6 in the Protege
OWL Tutorial provides instructions for defining this complement class (not
e that there are several steps,
including specification of necessary and sufficient properties for the non
-
pattern class).


4.
2

Implementing query with SPARQL


As a first approach to the inference above, we can manually code a SPARQL query that will make
a
single inference. For example, we can code a SPARQL query that will
return all ERP patterns with
peak_latency between 200ms and 350ms; we note that such ERP patterns
happen to match the definition
of

N3 frontotemporal ERP patterns, even though our SPAR
QL query made no direct reference to that
definition.



10

We first need to
up
load our
data
into Virtuoso. To do so,
we
utilize
the ISQL interface of Virtuoso
(found at
http://nemo.nic.
uoregon.edu:8890/conductor/main_tabs.vspx

by clicking on
ISQL
).
In the
ISQL popup window, we execute the following query, which will insert two triples of data:


SPARQL INSERT IN GRAPH
<test/data/00001>

{

<http://nemo.nic.uoregon.edu/data/00001/0001>

<http://www.w3.org/1999/02/22
-
rdf
-
syntax
-
ns#type>
<http://nemo.nic.uoregon.edu/ontologies/working/NEMO_ERP.owl#NEMO_0000093>.

<http://nemo.nic.uoregon.edu/data/00001/0002>
<http://www.w3.org/1999/02/22
-
rdf
-
syntax
-
ns#type>
<http://nemo.nic.uoregon
.edu/ontologies/working/NEMO_ERP.owl#NEMO_0000093>.

}


To formulate

our query
, we first write
it
in natural language, and then we convert it to SPARQL.


In natural language:

"If (1) E type ERP_spatiotemporal pattern

and (2) D type peak_latency_measurement_
datum

and (3) D is_peak_latency_measurement_of E,

and (4) D has_numeric_value V,

and (5)
V >= 200
,

and (6) V <=

350
"


To convert to SPARQL,
we
replace
the
labels
above
with their
OWL classes
:

a)

rdf:type

replaces
type


b)

NEMO_0000093

replaces
ERP_spatiotemporal
_pattern

c)

NEMO_0745000

replaces
peak_latency_measurement_datum


d)

NEMO_9278000
replaces
is_peak_latency_measurement_of

e)

NEMO_7943000

replaces
has_numeric_value


Additionally,
we rename our variables such that a
?

precedes each variable name (e.g.
E

becomes
?e
rp
).
We
type each numeric value by surrounding it with bif:atof

(where
bif

is
built
-
in
-
function

and
atof

is
string
-
to
-
float
).

We indicate

which named graph we wish to query with a
FROM

clause, and which
variables we wish
displayed with a
SELECT

clause.


Finally, to aid readability, we
use
PREFIX

clauses to abbreviate base URIs.


In SPARQL
, we have the following:














11

PREFIX rdf:<http://www.w3.org/1999/02/22
-
rdf
-
syntax
-
ns#>

PREFIX NEMO_erp:<http://nemo.nic.uoregon.edu/ontologies/working/NEMO_ERP.owl
#>

PREFIX NEMO_data:
<http://nemo.nic.uoregon.edu/ontologies/working/NEMO_data.owl#>

PREFIX NEMO_relations:
<http://nemo.nic.uoregon.edu/ontologies/working/NEMO_relations.owl#>


S
ELECT DISTINCT ?erp ?dat ?val

FROM <test/data/00001>

WHERE

{

?erp rdf:type N
EMO_erp:NEMO_0000093 .

?dat rdf:type NEMO_data:NEMO_0745000 .

?dat NEMO_relations:NEMO_9278000 ?erp .

?dat NEMO_relations:NEMO_7943000 ?val .

FILTER (bif:atof (?val) >= 200)

FILTER (bif:atof (?val) <= 350)

}


To execute the query, we load Virtuoso
’s S
PARQL interface found at
http://nemo.nic.uoregon.edu:8890/sparql
, copy and paste the query above into the
Query text

textbox,
and click
Run Query
. With the query above, we receive these results:



This direct approach of using SPARQL has already been helpful in identifying errors. For example,
an
initial testing
of a
SPARQL
query similar to the one
listed above revealed a misprint of an ow
l:class
within our data triplestore file generation workflow.


We are exploring the use of JENA (
http://jena.sourceforge.net
)

in the hopes that it will
allow us to
verify
the consistency of
the NEMO
ontologies
and data,
convert
the ontologies and data into different formats
(e.g. RDF/XML), and possibly reveal further issues or areas of focus.


To implement automated reasoning of the kind described in section 4.1, we are
exploring various
reasoners, including
the

HermIT Reasoner
(
http://hermit
-
reasoner.com/
)
(independently as well as in
conjunction with
Protégé
)

as well as
Jena (
http://jena.sourceforge.net
)
.


5. FUTURE WORK




Revisions to ontology

o

We spec
ified ERP_spatiotemporal_pattern as range for all is_about relations as a kluge.
Need to fix this, add assertions to ontology and try out chains of inferences to link ERP
metrics to ERP patterns

er
p

dat

val

http://nemo.nic.uoregon.edu/data/00001/0002

http://nemo.nic.uoregon.edu/data/00001/0128

216.00000000

http://nemo.nic.uoregon.edu/data/00001/0003

http://nemo.nic.uoregon.edu/data/00001/0129

260.00000000

http://nemo.nic.uoregon.edu/data/00001/00
04

http://nemo.nic.uoregon.edu/data/00001/0130

252.00000000

http://nemo.nic.uoregon.edu/data/00001/0006

http://nemo.nic.uoregon.edu/data/00001/0132

204.00000000

http://nemo.nic.uoregon.edu/data/00001/0140

http://nemo.nic.uoregon.edu/data/00001/0266

216.0
0000000

http://nemo.nic.uoregon.edu/data/00001/0141

http://nemo.nic.uoregon.edu/data/00001/0267

260.00000000

http://nemo.nic.uoregon.edu/data/00001/0142

http://nemo.nic.uoregon.edu/data/00001/0268

252.00000000

http://nemo.nic.uoregon.edu/data/00001/0144

http://nemo.nic.uoregon.edu/data/00001/0270

204.00000000


12

o

Terms that are subclasses of IAO:label need work. Add class d
escriptions to indicate
what each one is "about" (e.g.,experimenter_ID is_label_of experimenter, etc...). Then
link second concept to ERP pattern.

o

More restrictions on ERP_spatiotemporal_pattern subclasses
--

i.e., formal defs (nec &
sufficient criteria, i
ncluding spatial and functional restrictions as well as temporal
restrictions)



Revisions to RDF/XML (in line with changes to ontology)



Alternative implementations of queries?



New queries [and classify these into interesting types, acc to type of inference
needed to support?]


13

APPENDIX A.

Mapping between NEMO_ERP_Metric_Extraction
matlab output

and NEMO v1.00
classes




乏NE㨠
To simplify the first
-
pass RDF representation, all labels are currently defined as open classes
(i.e., members not enumerated). We wi
ll probably want to restrict membership for some classes in the
future, to align with the closed classes that they refer to elsewhere in the ontology.


Term in Metric_Extraction

Onto Term (pref_label)

Onto URI frag

Example: has_value (for
simERP) !

COP_RO
I_Mean_Intensity

COP_ROI_mean_intensity

NEMO_5391000

+484.00^^<double>

CON_ROI_Mean_Intensity

CON_ROI_mean_intensity

NEMO_1047000

+484.00^^<double>

ERP_Component_Analysis_Method_Lab
el

ERP_component_analysis_method_label

NEMO_4252000

"tPCA"^^<string>

El
ectrode_Montage_ID

electrode_montage_ID

NEMO_6832000

"GSN_128v1"^^<string>

Experiment_ID

experiment_ID

NEMO_0000537

"simERP_experiment"^^<st
ring>

Subject_Group_ID

subject_group_ID

NEMO_2014000

"simulated_adults"^^<string
>

ERP_Component_Label

ERP_compone
nt_ID

NEMO_0000534

"tPCA_factor_001"^^<strin
g>

Cell_Standard_Condition_Label

cell_standard_condition_label

NEMO_6444000

"C01"^^<string>

Cell_Event_Modality

cell_event_modality

NEMO_1693000

"simulated_visual"^^<string
>

Cell_Event_Type

cell_event_type

N
EMO_2202000

"simulated_stimulus_onset"
^^<string>

Cell_Stimulus_Type

cell_stimulus_type

NEMO_8938000

"simulated_word"^^<string
>

Cell_Comparison_Condition_Label

cell_comparison_condition_label

NEMO_1479000

"simulated_nonword"^^<str
ing>

COP_ROI_Mean_Inten
sity_Comparison_
Condition

COP_ROI_mean_intensity_comparison_c
ondition

NEMO_1705000

+484.00^^<double>

CON_ROI_Mean_Intensity_Comparison
_Condition

CON_ROI_mean_intensity_comparison_c
ondition

NEMO_0546000

+484.00^^<double>

COP_ITT_Electrode_Label

COP_ITT_el
ectrode_label

NEMO_5562000

"ITT_F1"^^<string>

COP_ROI_Label

COP_ROI_label

NEMO_0125000

"left_frontocentral_scalp_su
rface_region"^^<string>

CON_ITT_Electrode_Label

min_electrode_ITT_label

NEMO_0445000

"ITT_F1"^^<string>

CON_ROI_Label

CON_ROI_label

NEMO_7
969000

"left_frontocentral_scalp_su
rface_region"^^<string>

Peak_Latency

peak_latency_measurement_datum

NEMO_0745000

+484.00^^<double>

Peak_Onset

latency_onset_measurement_datum

NEMO_5662000

+484.00^^<double>

Peak_Offset

latency_offset_measurement_datum

NEMO_1180000

+484.00^^<double>

Peak_Duration

duration_measurement_datum

NEMO_4232000

+484.00^^<double>


14

APPENDIX B.

Mapping between NEMO_ERP_Metric_Extraction
inheres_in

and NEMO v1.00
object properties




乏NE㨠
To simplify the first
-
pass RDF representa
tion, the range for all object properties will be
specified as ERP_spatiotemporal_pattern (NEMO_ERP#NEMO_0000093), because all rows in the RDF
output represent instances of this class (see Figs. 1
-
3 for examples of metric extraction output in varous
tabula
r format).


Object Property

Onto URI

Domain

Range


Inverse

specifies_provenance_of

NEMO_6477000

any subclass of

label (IAO_0000009) in
NEMO_ERP_metrics

entity*

has_provenance_
specification

(NEMO_494000
0)

is_quality_measurement_of

IAO_0000221

any subc
lass of

information_content_entity

(IAO_0000030) [TEMP.....
for
ITT_label & ROI_label

for testing]

entity


has_quality_mea
surement

(NEMO_225600
0)

is_duration_measurement_of

NEMO_7329000

duration_measurement_dat
um (NEMO_0670000)

event_related_duration

(
NEMO_8849000)


has_duration_me
asurement

(NEMO_958400
0)

is_peak_latency_measurement_of

NEMO_9278000

peak_latency_measurement
_datum (NEMO_0745000)

event_peak_latency

(NEMO_0000524)


has_peak_latenc
y_measurement

(NEMO_282700
0)

is_temporal_onset_measurement
_of

NEMO_2618000

latency_onset_measuremen
t_datum (NEMO_5662000)

event_onset_latency

(NEMO_0000374)


has_temporal_on
set_measurement
(NEMO_355200
0)

is_temporal_offset_measurement_of

NEMO_3350000

latency_offset_measureme
nt_datum
(NEMO_1180000)

event_offset_
latency

(NEMO_0000375)


has_temporal_off
set_measurement
(NEMO_695400
0)

is_mean_intensity_measurement_of

NEMO_6934000

any subclass of

mean_intensity_measurem
ent_datum
(NEMO_9201000)

intensity

(PATO_0000049)

has_mean_intens
ity_measurement

(NEMO_477500
0)

is_stdev_intensity_measurement_of

NEMO_2782000

any subclass of

standard_deviation_intensit
y_measurement_datum
(NEMO_2049000)

intensity

(PATO_0000049)

has_stdev_intens
ity_measurement

(NEMO_244200
0)

is_x_coordinate_measurement_of

NEMO_1940000

any subclass
of

one_dimensional_xcoordin
ate_datum
(NEMO_9128000)

any subclass of

anatomical_point

(NEMO_1111115)


has_x_coordinate
_measurement

(NEMO_409600
0)

is_y_coordinate_measurement_of

NEMO_1732000

any subclass of

one_dimensional_ycoordin
ate_datum
(NEMO_9388000)

any subclass of

anatomical_point

(NEMO_1111115)


has_y_coordinate
_measurement

(NEMO_473200
0)

is_z_coordinate_measurement_of

NEMO_1723000

any subclass of

one_dimensional_zcoordin
ate_datum
(NEMO_9503000)

any subclass of

anatomical_point

(NEMO_1111115)


has_z_coordinate
_measurement

(NEMO_939300
0)


* range is unrestricted.




S
pecific range (for these measurement data) = event_related_duration. More generally, property range
can include any temporal_interval.




S
pecific range (for these measurement data
) = event_{onset,offset,peak}_latency. More generally,
property range can include any temporal_instant.



15



specific range (for these xyz coordinate data) = anatomical_point. More generally, property range can
include any zero_dimensional_region. Also note
that we cannot assume that the xyz coordinates are
directly

about an ITT_electrode_location (particularly if they are 3D measurements).


16

APPENDIX C.

A list of key data properties in NEMO ontology (v1.00)


NEMO Data Property

Onto URI (fragment)

Inverse

Dom
ain

Range

has_numeric_value

NEMO_7943000



IAO_0000027 (data_item)

<decimal>

has_measurement_unit

NEMO_5052000



IAO_0000027 (data_item)

unit_of_measure

has_character_string_value

NEMO_2466000



entity

<string>