1 / 26

The ORST Data Model / NEESGrid

The ORST Data Model / NEESGrid. Charles Severance October 2, 2003. Work to date. Partial Conversion of ORST model As example for NEESML Expect to be able to create ORST objects in Release 2.0 of NEESgrid Work has begun on CHEF based experiment management tool modeled after the ORST tool.

gpacheco
Download Presentation

The ORST Data Model / NEESGrid

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The ORST Data Model / NEESGrid Charles Severance October 2, 2003

  2. Work to date • Partial Conversion of ORST model • As example for NEESML • Expect to be able to create ORST objects in Release 2.0 of NEESgrid • Work has begun on CHEF based experiment management tool modeled after the ORST tool

  3. Why start with the ORST Model? • It provides good coverage of a well-understood scope • It has consensus across multiple sites • A prototype toolset exists around the model which is an important validation • http://nees.orst.edu/IT/data.model/ • We can adopt the core elements and extend as necessary

  4. http://nees.orst.edu/IT/data.model/docs/v1.3a.july16.pdf

  5. o:project specialCondions title startDate o:experiment[s] o:role[s] o:acknowledgement[s] o:facility title shortDescription longDescription <type id="o:project" title=”Project"> <specialConditions title=”Special Conditions"/> <title title=”Title"/> <startDate title=”Starting Date"/> <o:experiment allow="o:experiment” max="unbounded" /> <o:role allow="o:role” max="unbounded" /> <o:acknowledgements allow=“o:acknowledgement” max=“unbounded” /> </type> <type id="o:experiment" title=”Experiment"> <status title=”Status"/> <title title=”Title"/> <shortDescription title=”Description"/> <o:facility allow="o:facility” /> </type> <type id="o:experiment" title=”Experiment"> <title title=”Title"/> <shortDescription title=”Description"/> <longDescription title=”Description"/> </type> o:experiment status title shortDescription o:facility

  6. o:project specialCondions title startDate o:acknowledgement[s] o:experiment status title o:facility shortDescription title o:project shortDescription o:facility longDescription <type id="o:project" title=”Project"> <specialConditions title=”Special Conditions"/> <title title=”Title"/> <startDate title=”Starting Date"/> <o:acknowledgements allow=“o:acknowledgement” max=“unbounded” /> </type> <type id="o:experiment" title=”Experiment"> <status title=”Status"/> <title title=”Title"/> <shortDescription title=”Description"/> <o:project allow="o:project” /> <o:facility allow="o:facility” /> </type> <type id="o:facility" title=”Experiment"> <title title=”Title"/> <shortDescription title=”Description"/> <longDescription title=”Description"/> </type>

  7. o:project object specialCondions title startDate o:acknowledgement[s] o:experiment status title o:facility shortDescription title o:project[s] shortDescription o:facility longDescription <type id="o:project" title=”Project"> <specialConditions title=”Special Conditions"/> <title title=”Title"/> <startDate title=”Starting Date"/> <o:acknowledgements allow=“o:acknowledgement” max=“unbounded” /> </type> <type id="o:experiment" title=”Experiment"> <status title=”Status"/> <title title=”Title"/> <shortDescription title=”Description"/> <o:project allow="o:project” max=“unbounded” /> <o:facility allow="o:facility” /> </type> <type id="o:experiment" title=”Experiment"> <title title=”Title"/> <shortDescription title=”Description"/> <longDescription title=”Description"/> </type>

  8. 42 42 42 o:experiment o:experiment o:project nsf:iniative nsf:iniative o:project o:project When Querying SQL: “work your way down joins” select * from tExperiment inner join on iProjectID where iProjectID = 42 RDF-style: “Work your way out from what you want” retrieve object of type “o:experiment” where the “o:project” = this-project

  9. object object object object object object object object object object object Translating Terminology • One to many (project to experiments) • Reference goes in the destination (experiment) • Many to one (experiments to facilities) • Reference goes in the source (experiment) • Many to many (people to roles) • Create intermediate object to store linkage (person-role)

  10. Flexiblity using this approach • Can extend objects when creating new objects • Can make hierarchical structures • Can make network structures • Structures can coexist in the same repository

  11. o:project specialCondions title startDate o:acknowledgement[s] nsf:iniative title startDate …. <type id=”x:project" title=”Project” extends=“o:project”> <nsf:iniative allow=“nsf:iniative” /> </type> <type id=“nsf:iniative” title=“Iniative”> <title title=”Title"/> <startDate title=”Starting Date"/> …. </type> x:project specialCondions title startDate o:acknowledgement[s] nsf:iniative At some point we just make a new object - we can relate it to the existing object.

  12. object object x:project o:project x:project specialCondions specialCondions title title startDate startDate o:acknowledgement[s] o:acknowledgement[s] nsf:iniative nsf:iniative x:project-parent title x:related-project[s] startDate …. <type id=”x:project" title=”Project” extends=“o:project”> <nsf:iniative allow=“nsf:iniative” /> <x:project-parent allow=“x:project” /> <x:related-project allow=“x:project” max=“unbounded” /> </type> <type id=“nsf:iniative” title=“Iniative”> <title title=”Title"/> <startDate title=”Starting Date"/> …. </type> At some point we just make a new object - we can relate it to the existing object.

  13. Data Formats / Metadata Models • There is a difference between data and meta data • Data is in a file - it has a format - some tools know who to read and write the format • Word Autocad STEP • Metadata is information “about” files and other things stored in our format • Sometimes metadata is automatically extracted from files in a particular format by software which knows some or all of the format of files

  14. object object object object object object object object object Autocad SensorML RDBMS RDBMS

  15. object object object object object object object object object Autocad SensorML RDBMS RDBMS

  16. object object object object object object object object object Autocad SensorML RDBMS RDBMS

  17. object object object object object object object object object Autocad SensorML RDBMS RDBMS

  18. Strategies • Take Existing Data Models and Adopt • Build tools and data models at the same time • Find existing tools that produce types of data we find interesting • Build meta data extractors for important file formats • Build converters for things like Excel

  19. CHEF Tool ORST • Effort to understand the ORST data model • CHEF tools are broken into services and GUI components using a cleanly defined API • We can have different service implementations • Test service using memory • Repository based service • RDBMs based service • Service which can integrate across both Repository and RDMBS sources. • The tool can be used to explore extensions to the model. • Simple service has been written GUI is being developed

  20. Looking for Data Models…

  21. Questions about data efforts • Is this a data format or is this a meta data model? • How is the data represented? Is the representation published? Can we get a copy of the documentation? Does it have a URL? • Is the model/format extensible? • What community developed the model/format? Who is responsible for maintaining the model/format? What kind of relationship is necessary to work with them? Are there fees? • What applications has the model/format been used for? • Is this model in use at NEES sites? • What kinds of software support are there for the model/format? Are there APIs to manipulate the model?

  22. STEP • ISO 10303, commonly known as STEP (Standard for the Exchange of Product model data) • Base standards plus “profiles” - (i.e. “how we use step around here”) • http://pdesinc.aticorp.org/ http://www.steptools.com/. • AP-227 for Ship Piping Usage Guide v0.1 • http://www.steptools.com/support/stdev_docs/express/part227/index.html • We could develop our own STEP “profile”

  23. How to prioritize model exploration and development • Focus on the following areas: • Areas where we have or are building tools • Areas where we already have incoming data in some format • Christopher tells me that they have equipment that emits SensorML • Build the model through experiment based deployment - solve real problems in an open way and see if (with some adaptation) the solutions apply more broadly (i.e. Minnesota )

  24. Summary • The ORST model is an excellent place to start because it is small enough to understand and well documented so we can actually build tools and achieve some interoperability • We will quickly find places in which we need additional capabilities (i.e. the Minnesota report) • We need to prioritize model work to work on the most useful portions first

More Related