NEESgrid Data Effort

Jean-Pierre Bardet, Amr Elnashai,

Charles Severance, Joe Futrelle

Goals Data is online and persistent Data and Metadata are supported together Data migrates transparently including security, and

metadata Data is completely secure with access controls but

security does not get in the way Data provenance - how was it gathered, how has it

been manipulated? Data in support of research publication Support for repeatable experiments Data oriented research computation support Support for workflow

Vision: data on the Grid

studies

Data

Gathering

Repository

Extracting

Mapping

Meta Data

Objectives of Data Effort in NEESgrid through 09/04 Develop deploy and extend the NEESgrid toolset Educate community on the tools and how to use the

tools Work with sites to help in the adoption and

localization of the NEESgrid toolset Work with the community to define and implement a

basic NEES-wide data model to enable some basic sharing - much of this will be based on adopting existing work.

NEESgrid Data – Core Elements Local Repository Central Repository JAVA APIs – Run locally on the same system as a

repository or over OGSA Web Services– NEES File Management Services– NEES Meta Data Services

Data Viewers– Streaming (numeric, X/Y graph)– Stored (X/Y graph, 2-D structure, video)

NEESdata

NEESpop

LocalRepository

Core Elements

AP

I

CentralRepository

DataTeamlets

Data Acquisition

Workstation

AP

I

DataTeamlets

AP

I

Data/MDIngestTools

Data tools

Data viewers

Grid and Web Services

NEESgrid Data – Technologies Grid

– GRIDFTP is used for data transport– Grid Web Services are used to insure security and

provide access control between systems over the Internet – also provide for credential passthrough

– Grid credentials are used as part of login providing a single sign-on framework

CHEF– Provides a flexible mechanism for deploying GUI

tools like the data viewers and data browsers.

A Simple Experimental Scenario

DAQ System

Glue

Test S

pe

cimen

Lab

view

Developer System

Researcher System

Simulation System

Code

Simulation System

Code

A Simulation ScenarioDeveloper System

Simulation System

Code

The MOST Scenario

Part of the run-up to NEESPop 2.0– Used Beta of NEESpop and Beta of CHEF– Tested the data ingestion– Tested the metadata capabilities– Developed sample metadata– Tested mapping capabilities

System still available at

https://cee-nees.cee.uiuc.edu/chef/

NCSA NEESPop (1.1)

Colorado

NEESPop (1.1)

Incoming FTP

NEESMost (Win XP)

UIUC/Newmark

NEESPop (2.0)

LabView DAQ

MatLab Host And Real-Time Target Control

SystemSim Controller

CO

LabView DAQ

NSDS

UIUC

Test Specimen

Matlab Computational

Model

Shore-Western

Test Specimen

Incoming FTP

NSDSRepository

CO

NCSA

UIUC

Meta

Series of files

Complete file (aggregated)

NTCP

Site / LocationComputer Process

NCSA

Ingest

Ingest

NTCP

Matlab

NTCP

Ftp

NTCP

Wires

NFMS/NMDS

NSDS

File I/O

Plug In

Ingest

UIUC

MOST Data Flows

Oregon State: Experiment Based Deployment looking at Synchronized Video

Experiment Setup An LED was added to be visible in

the video frame which was connected to a button which would signal the “start of the experiment” (1)

This signal was also patched into the DAQ (channel 15) (2)

A person was stationed at the DAQ and at the video camera to manually start both processes. (3)

Both DAQ and Video capture were manually started about 10 seconds before experiment start.

The experiment was run for about 20 seconds at which time both the video and data acquisition were manually stopped

Done using NEESgrid 2.0 beta without any changes

DAQ

2

13

3

NEESpop 2.0 Alpha

DAQ

0 2 35 3 35 3 40 3 40 6 8

Metadata

0.000.01

Time

36

ch01

48

ch02

Mpeg video data was moved to a PC using a memory stick and the DAQ data was transferred into Excel.• (1) The video data was trimmed using Pinnacle Studio to discard the frames before the trailing edge of the LED signal.• (2) The DAQ data was discarded through the trailing edge of the LED signal• (3) A time channel (100hz) was added and the data channels were extracted and placed in the NEESpop• (4) We put meta data into the NEESpop (neesevent.xml) describing the event and channels (this was done before the experiment was started)

Manual processing of the data

1

2

3 4

NEESpop 2.0 Alpha

DAQ

0 2 35 3 35 3 40 3 40 6 8

Metadata

0.000.01

Time

36

ch01

48

ch02

The experiment was viewed using the standard NEES stored viewer with synchronized video and data and the ability to move back and forth

NEES Metadata Effort

NEES Markup Language (NEESML)– Provides an RDF-like structure capable of representing

semantic information– XML is the syntax which is used– Logic is more “object oriented”

• Can define objects• Can create objects• Can reference objects

Meta data is many different things…. Goal if we EVER want to build reusable data tools,

we have to represent the semantics inside the meta data rather than just the information

Which one is Semantic Metadata and Why?

<stuff> <person id=“68”> <title string=“phillips”> </person> <unit id=“second”> <title string=“second”/> </unit> <sensor-info> <manufactured-by string=“phillips”> <owner id=“68”/> <which-beam string=“second”> <width double=“0.13”> </sensor-info> <nees-experiment> <time-step double=“0.13” unit=“second”/> <pi id=“68”> </nees-experiment></stuff>

<stuff> <sensor-info>

<manufactured-by>phillips</manufactured-by>

<owner>phillips</owner><which-beam>second

</which-beam> </sensor-info> <nees-experiment>

<time-step>0.13</time-step><time-step-unit>second

</time-step-unit><pi-name>phillips</pi-name>

</nees-experiment></stuff>

Instant Tutorial: Semantics / RDF

This is an XML document. We can do some things with this document like ask the following questions:

• What string is the “which-beam” attribute of “sensor-info”• Does this document meet the syntax requirememts of a DTD (i.e. does it contain “compile”?)

That is it. There are some unanswered questions:

• What does “phillips” mean?• What does “second” mean?

With enough effort, we could write software which made intelligent choices about the meaning of the elements in each of these two “sub-document types”. Effectively, to build “knowledge” from data, software must evolve which “understands” each new document type.

<stuff> <sensor-info>

<manufactured-by>phillips</manufactured-by>

<owner>phillips</owner><which-beam>second

</which-beam> </sensor-info> <nees-experiment>

<time-step>0.13</time-step><time-step-unit>second

</time-step-unit><pi-name>phillips</pi-name>

</nees-experiment></stuff>

<stuff> <person id=“68”> <title string=“phillips”> </person> <unit id=“second”> <title string=“second”/> </unit> <sensor-info> <manufactured-by string=“phillips”> <owner id=“68”/> <which-beam string=“second”> <width double=“0.13”> </sensor-info> <nees-experiment> <time-step double=“0.13” unit=“second”/> <pi id=“68”> </nees-experiment></stuff>

type: sensor-infoman: phillipsowner:which-beam: Secondwidth: 45.33

Instant Tutorial: Semantic Information

type: Persontitle:chuck

Type: Unittitle:second

type: nees-experimenttime-step: 0.13pi:

This is a semantic (or at least “more” semantic” document. It is best represented by a picture.

Instead of thinking of things as strings and having to parse lots of documents, we can learn about seconds and then we can build components which understand “seconds” or “people” and ALWAYS know when to use those components. To “understand” a new “object type”, software must only understand the new elements introduced in that document type.

Important: Semantic representation of information is necessary but not sufficient for understanding.

Links can encode semantic structure

Tools are coded so as to “understand” a particular semantic structure – this becomes “meaning” and something useful

The Slide

gas

mile

gallon

car

model

ratio

mileage

fluid

volume

denominator

numerator

measurementdistance

rate

travel

consumption

fuel

unit

efficiency

vehicle

estimate

Metadata

Data

Data Viewers

Data

Map

pers

Data Ingestors

There is a layer is where we develop tools which take advantage and begin to depend on of the “meaning” of the data – where we begin to depend on the meaning of a second.

Where we make a viewer capable of viewing a certain type of object.

This is where we build things which make use of knowledge.

This layer will never be complete but it is a large focus of the coming months.

Concept

s

Search

Partial ORST Data Model as Types

   <type id="o:experiment" title="Experiment" extends="o:described">     <o:facility allow="o:facility" title="facility"/>     <o:startDate title="start date" type="date"/>     <o:endDate title="end date" type="date"/>     <o:specialConditions" title="special conditions"/>     <o:status title="status"/>     <o:configurations max="unbounded" title="configurations">       <type id="o:experimentConfiguration" title="Experiment Configuration" extends="o:descrbied">         <o:specialConditions title="special conditions"/>         <o:startDateTime title="start date and time" type="date"/>         <o:endDateTime title="end date and time" type="date"/>         <o:isFidelity title="requires fidelity to real-world conditions?"/>         <o:status title="status"/>         <o:trials max="unbounded" title="trials" extends="o:described">           <type id="o:trial" title="Trial">             <o:output max="unbounded" title="resource output">               <type id="o:resourceOutput" title="Resource Output">                 <o:resourceConfiguration allow="o:resourceConfiguration"                        title="resource configuration"/>                 <o:outputFile allow="io:file" title="output file"/>               </type>             </o:output>           </type>         </o:trials>       </type>     </o:configurations>   </type></neesml>

<neesml xmlns:o="http://www.nees.org/md/ns/orst-example"         xmlns:md="http://www.nees.org/md/ns/md">

   <type id="o:described" title="Object with Description">     <o:description title="description"/>     <o:shortDescription title="short description"/>     <o:longDescription title="long description"/>   </type>

   <type id="o:resource" title="Resource" extends="o:described">     <o:name title="name"/>     <!-- "equipment class" can be represented by subtyping this type -->   </type>

   <type id="o:resourceConfiguration" title="Resource Configuration">     <o:resources allow="o:resource" max="unbounded" title="resources"/>     <o:x0 type="quant" title="x0"/>     <o:y0 type="quant" title="y0"/>     <o:z0 type="quant" title="z0"/>     <o:x1 type="quant" title="x1"/>     <o:y1 type="quant" title="y1"/>     <o:z1 type="quant" title="z1"/>     <o:angle type="double" title="angle"/>     <o:configurationFile allow="io:file" title="configuration file"/>     <o:acquisitionDevice title="acquisition device"/>     <o:acquisitionChannel title="acquisition device"/>   </type>

   <type id="o:facility" title="Facility">     <o:name title="name"/>     <o:resources allow="o:resource" max="unbounded" title="resources"/>   </type>

Evolution of Data Technologies

SGML

HTMLXML

RDF/XMLNEESml CSS/DHTML RDBMS

Flat FileData

DictionariesValidation

RelationsObjects

Data Models

Concepts StorageFormats/Representation

Data Presentation

Relational DBs versus RDF-Style Stores

Both are ways to implement a relation-oriented data model RDBMS – style repository

– DBA “implements” data relationships and tunes important relationships for high performance

– Able to handle very large amounts of data with proper tuning– Not flexible – a new relationship requires DBS intervention– Query performance depends on building joins which exploit the hard-coded

relationships– Ideal in a high-transaction load environment

RDF – style repository– Relations are not determined a prioiri– Data model can be easily extended by any user as they insert data into the

store– Ideal for an archival situation where transaction performance is not critical

the ultimate use of data is not fully known in advance– Allows flexibility and change over time – can always put in new models and

then develop mappings for– Ideal for a situation where data may need to migrate between repositories

RDF/XML Versus NEESML

NEESml is topologically equivalent to RDF but more straightforward to use– A compromise between usability and functionality– Focused on solving the problems of ingesting types and

data – rather than “cross-server ontology webs”– Used to build a reference set of ingestion tools– RDF is a moving target

Repository does not store either RDF or NEESML – It is an relational database tuned to store “three-tuples”

NEESgrid Data - Value Proposition An RDF like store – Referential integrity long-

term flexibility Seamless data and meta data transport Smooth integration of data with meta data Cool set of extensible tools Willingness to support efforts to adapt and/or

build new tools – Data tools– Metadata tools– Data Viewer (s)

(lots of) Directions

In the past 45 days – we have gotten a lot of input on data directions– Form swat teams of interested site to build consensus (Data

workshop)– Investigate the ORST model and other models looking for

low hanging fruit (NEESgrid summit)– Coordinate with the Consortium data committee (EAB

Meeting)

These are all good ideas – we need to do them all – I would prefer that they are one effort for a while

We will discuss plans in the second meeting – I would like “one” direction – at least on the model

General Go Forward Plan on Technical Elements

Two words: “Experiment-Based Deployment”– Invest effort where sites are ready to produce results– Core SI team will focus on documenting and hardening the

NEESgrid software– EBD team will bring well-understood requirements back to

the Core SI team Liason with other data efforts for best practice

– GriPhyn – Physics data effort (Grid based automated storage and workflow)

– CMCS – Chemistry collaboration (notebook, automated mapping, and provenance)

Engage sites between releases who have skills that can help – discuss@neesgrid.org

Go Forward – Core Elements Investigate RDF and its relationship to

NEESML Investigate provenance – would like to adopt

from another project Investigate mapping – Would like to adopt

from another project Making notebook information available as

metadata

Go Forward - Tools

Evaluate the ORST interface and use it to implement experiment-based interface to meta data repository

Extend and improve viewers – publish API so that sites can extend the viewers

Improve notebook– Single signon using CHEF/Grid credentials– Integration with Metadata– Smother integration with CHEF

Explore synchronized video and data capture using DAQ and after-experiment replay of synchronized video and data (ORST UMinn)

Explore the capture of high quality still images as data (UMinn) Investigate adopting a data-editing tool (XMLSpy)

Go Forward – Data “Dictionary” Analyze the ORST model, determine core,

convert to NEESML, pre-populate repositories with types, and develop usage documentation

Form core group between SI, ES, and CS to push data model issues forward – once groundwork is better defined – we can disperse into distributed teams

Use experiment based deployment to help us encounter new data needs over time

What is in Release 2.0?October 7

Groovy look and feel Local Data Repository Repository Browser in CHEF

– Browse

– Create objects

– Upload / download data API documentation NEESML User

Documentation Extensible data mapping in

Java

Data Viewer in CHEF– Improved visually

– Configured by XML

– Can read data from repository or from urls

– Pre-populated with sample video and data formats

Local Repositories pre-populated with– SAC Data

– MOST Data

– ORST data model (subset)

NEESML 1 Introduction NEESML is a means for populating a NEESgrid metadata repository with objects and definitions of object types. It provides a syntax for defining object types and specifying objects, the values of their properties, and the relationships between objects. The NEESgrid metadata ingestion tool accepts NEESML files and uses them to populate a repository with objects and type definitions, communicating with the repository with the NEESgrid metadata service (NMDS) interface.

NEESML can be used to share type definitions and objects between repositories, and as an interface between other applications and repositories, because applications can either be written to read and write NEESML files, or can be augmented with translation utilities that translate the data formats they can read or write to and/or from NEESML. Finally, NEESML can be used to archive metadata to files.

1.1 About this document This document is intended as a comprehensive reference manual for the NEESML language. It does not explain how to use NEESML to represent real-world objects, but rather completely specifies the syntax and meaning of every NEESML construct. Using this document, you will be able to write NEESML documents that conform to the proper syntax, and will be able to understand syntax errors and other problems with non-conforming NEESML documents or document fragments.

For a more general introduction to NEESML, please refer to (Futrelle, 2003).

Some NEESML-specific terminology is used in this document. The first time every such term is used, it is italicized. Definitions of all special terms are given in the glossary in section 7.

NEESML is a general-purpose metadata description language. Throughout this document, examples are used that do not directly pertain to earthquake engineering. This is done merely in the interest of simplicity. All the constructs used in the examples can be applied to metadata describing earthquake engineering experiments and simulations.

1.2 Some XML “gotchas” NEESML documents are XML documents. There are some aspects of XML that constrain the syntax of NEESML documents in important ways:

XML element and attribute names are case-sensitive. “ID” is not equivalent to “id”, and “MyTypeName” is not equivalent to “mytypename”.

Namespaces, if they are used as relation ID’s or the ID’s of types for which objects are created, must be declared in an enclosing element.

Some characters are not allowed in element names. It is common practice to only use alphabetic characters and dashes. Colons and other punctuation are not allowed.

For details on XML syntax, consult the XML specification (Bray, Paoli, Sperberg-McQueen & Maler, 2000) or a good XML reference or tutorial.

Table 1: Primitive types in NEESML

Name Description Examples

string Text “Hello, world.”“BN# 493-2584x”

int Integer 3-22147483647

long Long integer. Can exceed the size of an integer.

-57823475624279223372036854775807

double Double precision floating point number.

523425.4568574636-0.0000000435234

date A moment in time, represented as a date and time stamp in UTC with 1ms resolution.

2002-10-27 15:40:32.0481969-01-12 00:03:48.774

Repository Browser

NFMSUploadAgent.java

Ingestor

API Documentation

Configuring Events in XML

<event id="oregon" desc="Oregon Large Tank Test September 8, 2003" host=“/chef/org.nees.repo.data/retrieve-data?lfn=nacse_sample_01.txt&amp; static=yes&amp;mapping=nacse-" type="stored"> <channel id="00" desc="time" unit="Seconds" url="t" /> <channel id="01" desc="Offshore Wave Gauge" unit="" url="02" /> <channel id="02" desc="Wave gauge at the front face of the cylinder" unit="" url="03" /> <channel id="03" desc="Wave gauge at the back face of the cylinder " unit="" url="04" /> <channel id="04" desc="Pressure at the front face of the cylinder " unit="" url="05" /> <video id="01" desc="Video of cylinder" url=“/chef/retrieve-data/static/nacse_sample_01.avi" /></event>

We may be able to get a patch out to switch this to NEESml and provide a simple entry tool.

   <type id="nees:storedEvent">     <data allow="io:file"/>     <url/>     <parseOptions/>     <storedTimeChannelsmin="1" max=“1" allow="nees:storedTimeChannel"/>     <storedDataChannels min=“0" max="unbounded" allow="nees:storedDataChannel"/>     <storedVideoChannels min=“0" max="unbounded" allow="nees:storedVideoChannel"/>     <storedStruct2DChannels min=“0" max="unbounded" allow="nees: stored2DStructureChannel "/>     <fileChannels max="unbounded" allow="nees:fileChannel"/>   </type>

Mappings and the Data Viewer NSDS (ISO 8601 Time channel) Column data with time recorded as a column Column – generate time Column – generate time – trigger filter

Channel units: g,g,in,kipTime ATL1 ATT12002-11-13T15:48:55.26499 -0.006409 0.004272 2002-11-13T15:48:55.36499 -0.005798 -0.003662

100.0000.435 0.161 -1.016 -0.981 0.430 0.161 -1.016 -0.9770.435 0.161 -1.016 -0.977

public class NEESDataMap{ public static boolean repoMap(File mainFile,

File mappingFile, String mapping) {

// Code here }}

Release 2.1 Data AspectsDecember 2003 NEESpop

– Notebook to metadata repository connection made– Closer integration of notebook into CHEF– First release of experiment tool (based on ORST)– Retool data viewers to be completely driven by

Metadata objects rather than their own objects– More fine grained access control– Enhanced data models

Tools– Ingestion tools released– A limited set of pre-release video/image tools

Further releases

Release 2.2 – March 04– Driven by your needs as we encounter them– Perhaps some “nice to haves” from the SI team

Release 3.0 – June 04– Very limited new functionality – maybe almost

nothing new in the core components of the NEESpop

DAQ

0 3 40 6 8

<experiment> <blah> <public-view></experiment>

<experiment> <blah> <public-view></experiment>

0 3 40 6 8

My Skunkworks Project

Detailed Session

Amr Elnashai and JP Bardet will lead Discussion of Metadata used in MOST and the

SAC data sets Discussion of Cosmos, SensorML, and the

ORST model Discussion of the effort on the ORST data

model to date Discussion of the ORST IT tool and how to get

its functionality into NEESgrid Discussion of the relationship between

Consortium DSAC and SI data effort

Summary

Once NEESpop 2.0 is released, we will have a powerful set of data tools that the sites could take and use out of the box.

Experiment based deployment says that the SI team will work hand-in-hand with EBD sites to use the tools

This will identify new needs and requirements over the next year– The SI team will extend the NEESpop (2.1, 2.2, and 3.0)

within resource constraints

This is really starting to be fun

NEESdata Worktools Site

neespop.si.umich.edu