SPG Meeting Notes

SPG session at the ESDSWG meeting in Philadelphia

Oct 23-25, 2007

Tuesday Oct 23rd SPG Session– slides posted to SPG web site

Presentation: Standards Life Cycle (Framework) – Ted Habermann

• Consider spending time on standards evaluation coefficient matrix
• However, different coefficients depending on who is evaluating – missions, research, etc. Allan noted that the evaluation matrix is so subjective – can be constructed to come up with the "answer" that the person wants. However, thinking about the coefficients for an evaluation matrix is something that we should try to do at least once.

Presentation: Revised process for “established practices” – Allan Doyle

• Currently, 2 tracks in the standards process – standards track -> Endorsed standard. The tech note track -> tech note.
• There may be a certain class of standards for which our standards track may be too unwieldy. This was noted at the July 2007 meetings in Madison. The purpose of the standards track is to produce a list of standards thjat should be considered for new projects. Endorsed standards have been vetted by a review process which included some or all of tech review, usability review, and the operational suitability review. Some standards may not require a two phase review process.
• What are criteria that might help distinguish among the types? Relationship of standards/established practice/tech notes. SPG to decide whether stds RFCs should be STDS track or established practice track. Need objective criteria. Can widespread use by quantified? Availability of reviewers may influence track chosen. Established practice could sometimes be handled by the SPG without outside review.
• Frank Lindsay – cadre of stds should lower risk of new projects implementing. If new projects use well understood stds, then lowers the risk.
• Rich: Need to get things on our endorsed list more efficiently
  • Allan: 30-day comment period – if no negative, “established practice” ?
  • Glenn: Q – What does each category mean (standard, established practice, tech note)? A – same result (standard, est. practice), different path
  • Randy: don’t have to do part of evaluation because done already (not because that part of evaluation is not applicable)
• Frank: does the proposed standard raise or lower risk for data system using that standard?
  • Nadine: note “risk” is project specific and time specific. Maybe look for recommendations but not The Answer.
• Ted: more nuanced recommendations (use these now if can accept more risk, use these to minimize risk, etc.). This goes to cost model as well.
• Rich: matrix without weights – refinement of SWAL
• Ted: any thought of recognizing when established practices begin to tail off? Define migration paths to emerging standards?
• Julie: new standard can supersede previous one.
• Ted: Recommend resources for developing new technologies and transitioning it.
  • But note there’s never funding for migrating existing data to new format…
• Nadine: but can have several standards for any given category
• Rich: should we recommend HDF4 as well, since there’s petabytes of data in it?
• Ted: NetCDF3 vs 4. 3 is to be superseded, but 4 doesn’t yet exist. How to minimize switching cost?
• SWAL: which standards are living, compatibility with existing data and systems, etc., to help missions decide what to use
• Ted: document groups of related standards, to decide which of competing standards to use
• If “established practice” submission fails to become “endorsed standard” then something’s wrong with it – need to recommend against it (not just drop it to tech note status) and publish assessment on site

US GEO standards – Frank Lindsay

• Frank is part of arch & data mgmt (ADM) of US GEO Frank – showed illustration of graphic – SOA-WS Orchestration diagram. This diagram is representative, not prescriptive. The blocks show examples of categories that are representative.
• How could GEO registries for stds affect NASA? Are new software developers are looking at this? The SIF has 81 stds & interoperability arrangements and special arrangements listed in its registries. Very fast process.
• SPG role – periodically investigate the stds in the SIF registries to see what is suitable for use in the NASA environment --- which stds are rising to the top?
• Martha is “keenly interested” in the standards process
• White paper on SOA-WS. Includes “representative” (rather than prescriptive) examples of technologies that can be used.
• Rich: Note this (Frank’s WS-SOA illustration) is an information architecture. Do we want to define standards for each of these components?
• Frank: This is purposely non-prescriptive, acknowledging current world of distributed data sources, etc. Figure out how to plug in our existing systems.
• Ted: role of NASA (and NOAA) in international process – needs to take leadership role because has resources to develop infrastructure, implementing standard protocols
• Frank: technology will continue to evolve even as GEOSS settles on implementations. Agencies are big and slow, but will have to adapt.
• (International) GEO ADC Standards Interoperability Forum – Rich
  • Recognize existing standards and encourage their use
  • Standards registry populated by members (currently 81 registered). “Special arrangements” blessed by SIF.
• Julie: How is this publicized? How broad are announcements?
  • George: to “geo principals” (leads from different agencies), should be propagated from there
  • Rich: should SPG further those announcements?
• Rich: what is relationship between NASA standards and SIF? Parallel, systems, always push standards from one to the other?
  • Frank: NASA standards may be pushed toward international use
  • Ted/Rich: then perhaps SPG should recommend some standards from this list to NASA (early warning system – standards adopted by many countries vs. the many that are never used)

ACTIONS:

• Consider set of rubrics to map to SWAL analysis ?? Should discuss at SPG telecon
• Specific recommendations on changes to process document
  • Define type (tech/impl, usabiliy, operational suitability) and scope (internal or external) of review before establishing TWG

Thursday Oct 25 SPG Session

IOOS/DMAC standards process – Julie Bosch (IOOS Steering team member)

• Discussion of IOOS and DMAC structure and organization. NOAA is lead agency for IOOS. Standards process is under Ocean.US. Kurt Schneble has retired, but is continuing to work standards process. IOOS standards process – not a NOAA process although most members are NOAA.
• A system designed in a way to provide ocean data, products, and information in forms and at rates required by decision makers to address seven societal goals. Not a NOAA program. It’s an interagency program – participating organizations – federal agencies, national program, international programs, regional associations. USGS, NSF, NASA, NOAA, EPA, programs under NSF, IOOS has 7 societal goals – mostly aligned with the GEO SBAs.
• Steering team meets twice a year generally but have not met since May 2006. Have meeting scheduled end of Nov this year.
• DMAC structure – bulk of work gets done in expert teams and working groups.
• Expert teams in archive, metadata and data discovery, transport and access.
• Caucuses – outreach to communities, user groups, and data providers. Regional associations are the non-federal components of the system like universities or non-profits,
• Standards are the key to the success of DMAC. DMAC standards process background – identify standards needed to enable interoperability, support draft data policies and archive policy, enhance guidance to data providers, coordination with other stds processes.
• Identifying stds is the first step.
• DMAC stds process highlights – initially structured and agreed uipon at May 2006 DMAC steering team meeting. NOAA’s IOOS Program office has developed the online system in coordination with the DMAC chair. Kickoff operational of the DMAC stds process in Oct 2007.
• http://ioodmac.fedworx.org - DMAC stds collaborative workspace – hub of stds activity. need login and password to get into the site. The site will be the hub of the activity. Stds are contributed and discussions can take place. The polling of the steering team occurs, public comment can be contributed, etc.
• DMAC Stds Process; 6 step process - 3 status levels for stds – submitted, proposed, recommended. No endorsement. Involves six key participant roles – DMAC chair, DMAC steering team, experts (not just expert teams but outside experts also), public, gatekeeper (administrator & monitor of process and documentation, pushes things along, works closely with DMAC chair), originator. If stds reach “proposed” stage, goes out for public review.
• Expert review: involves gatekeeper, experts, originator, steering team, and DMAC chair. Status is submitted at the beginning of expert review. Status is proposed after completion of the expert review.
• Public review: involves the gatekeeper and public. Status is proposed. Hoping for implementers to comment here.
• Not sure where tech spec review happens or if it happens.
• Standards philosophy – looking at suites of standards for various applications
• Plan to vote on any proposed standards at semi-annual steering team meetings.
• Q: What about operational readiness? A: hope standards description will include justification and description of current use. Current operational use should carry a lot of weight. For emerging standards, public (IOOS community) comment should have a lot of weight.
• Q: Criteria for public comment, or just free form? A: Need to think about that.
• Q: Tech spec review just by experts, or combined with other parts of review? A: Expert review should be quick (couple weeks) and focus on applicability within IOOS. Looking for tech spec comments in public review section. “Adopt, adapt, as last resort develop” – hope this means tech vetting is already done before standards submitted for review.
• Q: How to attract submissions? A: Looking at NOAA and GEOSS lists for ones that are on multiple lists.
• Also considering pilot projects for test implementations or test cases as part of emerging standards evaluation (depending on resources available, timelines on when needed, current usage)
• Q: What does “recommended” mean? How will standards be propagated? A: IOOS can’t require use of particular standards. Certification for Regional Association or Observing System may require system to meet certain IOOS recommended standards.
• Julie – Q: How does SPG distribute copy-written materials for review? A: not looking for tech review of ISO spec. But could use NASA access to spec for review from NASA people (don’t look for these reviews from those without access to it?)
• John – there are some really bad specs from standards orgs. Need at least “fitness for purpose” review to determine how useful proposed standard would be.
• Ted – How does NASA or NOAA participate in ISO and OGC standards processes? Profiles and extensions of these standards, prototypes and real life testing.
• Rich – participants in these groups (OGC, etc.) often become advocates. So evaluators of a standard should ideally not be the developers.
• Ted – note IOOS/DMAC has already endorsed certain standards (netCDF, FGDC, OPENDAP, etc.) and produced guidance for data providers

Marine Metadata Initiative - John Graybeal

• Maximizing community involvement – communication, visibility, inclusion, collaboration, create value for community, and have transparency. http://Marinemetadata.org MMI funded by NSF grant
• Collect various vocabularies and encode in OWL
• VINE: vocabulary integration environment – “the easiest semantic mapping tool that exists”
• Ontolog – http://ontolog.cim3.net/ – open, international, virtual community of practice on ontology, ontological engineering and semantic technology
• Cites FGDC as large mandate with small participation – not enough community engagement in process
• Lots of overlap between IOOS and NASA ES standards processes – can we blend?
• All about community – build credibility to gain engagement. Visibility – Google and Wikipedia.
• MMI provides lists of standards, no guidance at this point. See his “what we want” slide for important evaluation criteria. Similar to reuse readiness levels.” But not planning to rank different standards –usefulness is very specific to purpose.
• Q: what about community forums or comments attached to each standard? A: have done this initially, but many user comments were trivial (e.g., about web page rather than content of page). Considering collecting “user experiences” – targeted, structured guidance to get the information you want – and community rankings.

NetCDF – Ed Hartnett

• NetCDF = file format, software library, API . 1996 – netCDF 3.0 released. NetCDF 3.6.0 released, 64 bit offset format introduced. NetCDF 4.0 Beta released. NetCDF 4/HDF5 format introduced. April 2007 beta 1 released. NetCDF 4 is different than NetCDF3 file format. NetCDF4 files are HDF5 files. NetCDF4 can read all NetCDF3 files.
• NetCDF4 Class Model /HDF5 format without new features backward code compatible. NetCDF4/HDF5 – HDF5 format with new features such as groups, user defined data types, compression, parallel I/O
• All docs are available from the netCDF_documentation page – “classic” data format
  • Versions 1(?) and 2 still supported – and they have no intention of ever dropping support
  • V3 is current and most widely used – still default format for software library
• V4 (based on HDF5) is now in beta. NetCDF API on HDF5 data format. NetCDF4 tools and software library will read NetCDF3 files as well. NetCDF4 files can also be read by HDF5 tools.
  • When create a file with NetCDF4 library, pick format (classic (default), 64-bit, classic-model HDF5 (no new HDF features introduced), HDF5). NetCDF4 library can read all NetCDF files.
  • NetCDF 4.1 will also be able to read any HDF5 file – alternate API for HDF5.
• Planning to merge OPeNDAP remote access code into NetCDF library.
• Discussion of file extension (.nc, .nc4, .hdf)
  • John suggest .nc4 to advertise to users that the data can be read by both NetCDF4 and HDF5 libraries.
• Ted: standards agnostic platforms (same tool to handle multiple formats or protocols) very important: NetCDF library that reads any NetCDF and HDF files, THREDDS that handles OPeNDAP and WCS, open source feature server that can serve up any OGC Simple Feature in various formats (like KML, etc.)
• Rich: what to standardize on? API or format?
  • Ed: classic format (already have HDF5 on list)
  • Rich: API to access netCDF and HDF5 files
  • Ted: Common Data Model framework (GRIB, NetCDF, others?) rather than specific format
• Ed: too high level to standardize on
• Ted: high level allows you to be inclusive and build community
• Follow up in future telecon – decide what recommendation to make and potential benefit

SPG/DMAC coordination discussion

• Maybe use NetCDF as a test case for joint SPG/DMAC standards review
  • Combine comments across systems
  • Run processes independently and compare notes
• Can the SPG and IOOS process share technical reviews – share info about best practices and implementations
• IOOS and NASA may not have an interest in combining processes (but IOOS encompasses NASA ocean observations)
• Helen can be liaison from IOOS to SPG.
• Daniel is liaison from SPG to IOOS.
• Ask Kurt to draft coordination agreement?

Actions

• coordinate telecon with Russ Rew, Ed, and any others on their team to discuss what are the next steps with netCDF version x to be submitted to the SPG
• work through Helen to get IOOS DMAC’s input on evaluation criteria for our reviews of the netCDF.
• netCDF will be test case for collaboration with IOOS DMAC and SPG – get some insights through actual practice.
• IOOS DMAC Steering Team meeting Nov 27/28 in Silver spring -- Leads of expert teams and leads of caucuses will be at this meeting. Expert team reviews will happen.

Rest of SPG meeting

• Wrap up discussion – table remaining agenda for future telecons
• Outreach to missions – what they can do for us and what we can do for them
• Co-chair election – need to do aggressive recruiting