N A S A NASA’s Earth Science Data Systems Standards Process Experiences Richard Ullman – NASA/GSFC Ming Tsou - SDSU co-chair July 17, 2007

p1 NASA’s Earth Science Data Systems Working Group, Standards Process Charter NASA’s Standards Process Group started work in January 2004 Advise NASA decision makers on standards: –Maximize value of NASA’s investment in Earth science data systems by: lowering the cost to use the data increasing the opportunities for data interuse or data interoperability increasing the integration of NASA data in “communities of interest”, such as discipline communities –Identify Strengths, Weakness, Applicability and Limitations of particular standards in the context of readiness for operational use by NASA stakeholder communities. NASA-funded researchers and data systems Users of NASA data

p2 Insights Interoperability does not require homogeneous systems, but rather coordination at the interfaces. What communities build, they own. Communities of practice have solutions. Published practices that demonstrate benefit can grow … – successful practice in specific community – broader community adoption – community-recognized “standards” Examples: –extend data collections to multiple uses by describing data content –enable the use of NASA data with other data –enhance data documentation –decrease distribution barriers –etc

p3 EOSDIS Evolution 2015 Vision Tenets Vision Tenet Vision 2015 Goals Archive Management  NASA will ensure safe stewardship of the data through its lifetime.  The EOS archive holdings are regularly peer reviewed for scientific merit. EOS Data Interoperability  Multiple data and metadata streams can be seamlessly combined.  Research and value added communities use EOS data interoperably with other relevant data and systems.  Processing and data are mobile. Future Data Access and Processing  Data access latency is no longer an impediment.  Physical location of data storage is irrelevant.  Finding data is based on common search engines.  Services invoked by machine-machine interfaces.  Custom processing provides only the data needed, the way needed.  Open interfaces and best practice standard protocols universally employed. Data Pedigree  Mechanisms to collect and preserve the pedigree of derived data products are readily available. Cost Control  Data systems evolve into components that allow a fine-grained control over cost drivers. User Community Support  Expert knowledge is readily accessible to enable researchers to understand and use the data.  Community feedback directly to those responsible for a given system element. IT Currency  Access to all EOS data through services at least as rich as any contemporary science information system.

p4 Standards We are Interested in Are there components (technologies practices) that if documented and more widely used would promote: –Easier sharing or exchanging of data among distributed partners and users. –Distributed systems development and sharing of software and technical expertise. –Reducing the cost of developing or maintaining a system. –Increasing the use of scientific data products and bringing more funding. –Interoperability and enhancing innovation, collaboration, and computing performance. For identified technologies/practices, Is there a community of use that: –Has experience in implementation and has demonstrated operational readiness –Has leadership necessary to promote the advantage of wider use.

p5 The Request For Comment Process Modeled after example of Internet “IETF RFC”. Tailored for responsiveness to NASA. Proposed standards are documented as specifications according to SPG guidelines and submitted by practitioners within the NASA community. The Standards Process Group forms a Technical Working Group (TWG) to coordinate evaluation. –What does “implementation” of this specification mean in the context of NASA Earth Science Data Systems? –What constitutes successful demonstrated “operational readiness”? The community is invited by means of announcement to comment on the specification and particularly to address questions formulated by the TWG. The TWG also identifies key stakeholders that are likely to have particular experience with the technology and solicits their opinion. The TWG reports to the SPG and the SPG makes recommendations for final status of the RFC.

p6 Proposed Standard Community Review Recommendation SPG Evaluate Proposed Standard Implementations and Community Response TWG Evaluate Proposed Standard Stakeholders Initial Screening Initial review of the RFC Provide RFC submission support Form TWG; set schedule Recommended Standard RFC Review Questions: Technical Specification Operational Readiness Suitability for Use TWG SPG Technical Note Technical Note Reject The RFC review process

p7 Case History: Data Access Protocol (DAP) Characteristics of OPeNDAP’s DAP: –“Homegrown” standard, not adopted by any de rigueur standards organization, new implementations from scratch are expected What happened? –First run - Standards Process worked well –Responsive community - many supportive reviews for technical specification and operational experience –Reviews were painless for the SPG to get Why? –OPeNDAP community very cohesive and engaged –Strong leadership from both the OPeNDAP Group and key community users. Was successful in “getting out the vote” Was responsive in correcting “errors” in the specification RESULT: Recommended Endorsement of DAP

p8 Case History: OGC Web Map Server Characteristics of proposed standard: –Already approved by OGC & ISO as standard, new implementations from scratch are expected What happened? –Difficult to get many technical spec reviews; reviewers wondered why we are asking for a spec review when it was already an international standard is a spec review important for a spec that has been exhaustively vetted by the OGC and ISO? –Reviews of operational experience also difficult “Operational experience” means something very specific in the NASA world. Some of the reviewers mentioned that they were serving hundreds of users each day with thousands of accesses to images – but didn’t consider themselves operational. But clearly, WMS could be used in operational environment based on actual number of users, data volumes, and hours of daily operation RESULT: Recommended endorsement of WMS

p9 Case History: Hierarchical Data Format Characteristics of proposed standard: –Homegrown, not adopted as standard by any other external organization, single implementation (shared software libraries), completely new implementations from spec not necessarily expected What happened? –Difficult to get many technical spec reviews – only one implementation so not many people had experience with implementing HDF5 from the spec. –Although only one NASA funded implementation of software libraries, recently Microsoft decided to implement HDF5 in future IE version. This was not anticipated. So accurate spec is still important –Some returned reviews were about usability of HDF5 and not about the technical spec. –Since users are exposed to HDF5 if they get data, should we ask for usability or usefulness review from users? RESULT: Still in review, status: looking at operational readiness

p10 Experience Summary Operational Readiness is more important than Operational Experience –or else standards adoption becomes trailing edge. “Community” as a starting point, is those who have experience with implementation of a particular proposed standard. –rather than “science discipline community” 3 types of reviews and all reviews can be done simultaneously – some reviewers wear more than one hat –Technical specification review –Usefulness for purpose review –Operational readiness Teamwork and LEADERSHIP are both important. –Communities “own” what they have a hand in building –Leadership is essential to provide momentum.

p11 Focus Today: Catalogs and Metadata Standards and Best Practices Agenda Introduction and Background of SPG – Richard Ullman KML – Brandon Badger ISO Part 1 & 2 – David Danko Thredds & CF conventions – Ethan Davis OGC CS/W & ebRIM – Panagiotis (Peter) Vretanos NASA Experiences with CS/W – John Evans GCMD DIF – Tyler Stevens Discussion - Future steps for NASA

p12 Contact Information NASA’s Standards Process Group – Richard Ullman