Gathering of the SCOOP Data & MMI Wizards – 2 Aug 2006

Participants

• Philip Bogden
• David Forrest
• Helen Conover
• Donna Cote
• Gerry Creager
• Don Reilly
• Marilyn Drewry
• Ken Kaiser
• Luis Bermudez

Name agreement: OOSTethys. Need to register the domain, find someone to host it and open a sourceforge project.

Discussion

• OOS Tech Service Definition Team
• Cookbooks
• Sourceforge
• Development environment

• OGC Interoperability Experiment
• IOOS Catalog work – first step in a win-win, working toward a controlled vocabulary, not a stovepipe in the making
• QARTOD
• ACT – Interoperable Ocean Sensors
• SWE & Harmonization – Folks in OWS4 won’t harmonize SWE and WFS. SWE is about getting data from sensors and WxS is about getting data from a data store.
• Google a sponsor option – SciCorp (contractor to NGA for things geospatial) – Lockheed Martin
• OpenIOOS “Interoperability Test Bed”
• OceanUS DMAC ST
• OOS Tech 2006 (and past OOS Techs)
• Expanding participation – e.g., Univ of Maryland, S

• SURA & MMI
• Sourceforge
• “Credit” and “Visibility”
• Touching base:
• OceanUS DMAC ST
• MMI Steering Team
• OOS Tech Steering Team
• Outcomes
• Plan for Tethys
• Planning for SCOOP’s new “Data Grid” initiative

• Gerry: Need to add the archival function
• Aggregator may maintain a transient data cache – Archive implies a permanent record. Aggregator does not have responsibility for archiving the data, but provides added value services such as integrated products, performance caching, etc.
• Data providers, aggregators and archives must go to the single registry. Archive has similar functions as a data aggregator. Metadata are provided by the data provider.
• Lineage is a big problem, and ISO has mechanisms for addressing this.
• Aggregator is a black box that actually involves a lot of really hard problems that still need to be solved.
• Mediator itself isn’t novel, but it’s emphasized in our architecture because we anticipate a lot of heterogeneity in our system. We anticipate that heterogeneity is one of our biggest problems. Matryoshka aspect (i.e. systems within systems within a system) isn’t novel, but making it work is.
• In the Lockheed/NASA world, an ICD (Interface Control Document) is the mechanism in use by these top-down folks to describe all interfaces in a project.

• Draft Project Scope -- Luis will create a draft document as a framework, send it out to this group for discussion next week, and then work toward Aug meeting at UAH. Wednesday!! This is scope for what’ll be done for OOS Tech 2006.
• Project Scoping Meeting – Aug 15 & 16 at UAH – Complete drafts of documents below in the context of something we can achieve by November (for OOS Tech 2006).
• Synopsis – Need to identify someone or some people (Joanne) who will synopsize (in draft form) the outcomes of the listserv, and defines a finite review period for folks on the listserv. After that listserv review, it goes for final review and publication. (Responsible individual: Joanne)
• Editorial Review – Need to identify individuals who will review and approve the draft synopses, after which they will be published to the outside world. (Leads: Gerry & Luis)
• Requirements Document – Functional requirements (use cases), including things like: we’ll use OGC interfaces, in-line documentation of code (i.e., perldoc & javadoc) to support user documentation, etc.
• Scope of Work – Flesh out the draft above.
• Interface Definition Document – Define interface requirements for the various components, e.g., a data provider implements SOS, etc.
• Design Document
• Build to Design – Our reference implementations will be in Java and Perl to start of a toolkit for data providers.
• User Documentation – Cookbooks, etc. for reference implementation (that’ll include reference data set for testing)