# Presentation: 025996

## National  Center for Geographic Information and Analysis

Department of Spatial Information Science and Engineering

**Role of Standards for SEEDS**

**National  Center for Geographic Information and Analysis**
**Department of Spatial Information Science and Engineering**

**Silvia Nittel**

## Motivation

- ESE *collects*, *maintains*, *distributes*, and *analyzes* massive amounts of geophysical data sets
- ESE includes many diverse ‘scientific tribes’
- Highly specialized small scientific communities
- More and more multi-disciplinary research
- In search of the next generation infrastructure
- Allows to access, process and distribute data and results faster, more flexibel, and convenient

## Interoperability and SEEDS

## Motivation

- The ‘next generation infrastructure’:
- Easier, fast search for and (online) access to data
- Simpler data subsetting and integration
- Allows for organic growth of infrastructure
- Allows for specialization of ‘tribes’
- Accommodates new scientific interests
- Provides for interoperability and re-use of tools, data, mechanisms
- ‘Cheaper’ and faster turn-around’

*Standards help here*

## Requirements for Standards

- Standards should make the task **simpler**
- Let scientific tribes do things in their familiar, specialized way, does not hamper specialization
- Makes tasks for multi-disciplinary groups simpler
- Allows all groups to re-use tools, and mechanisms
- ‘Light touch’
- Adaptiveness, and flexibility
- Necessary
- Common set of *minimal standardized interfaces* to bridge/’translate’ between differences
*Processes* to find, define, and implement them
- Community Engagement

## Soo.....

- “Good” standards make life simpler.
- What are the pitfalls?
- The standard has to be the right ‘fit’ (what to standardize ?)
- Provide tools that help using the standard, or even hide it
- It takes a lot of effort and resources to develop and maintain standards.
- Community acceptance is necessary
- Continuously new technology, instruments, mechanisms,...
-  Need for *Standard Process Models*
- What works, what does not?
- We cannot know in advance which standards will evolve or be necessary, but we need a process model and standards body that enable the evolvement.

## How to get ‘good’ standards?

- Essential to process: ‘**Community Engagement’**
- Community-based development is necessary (experts!)
- The need has to come out of the community.
- Small teams of experts from community.
- The standard has to be the right ‘fit’: concrete needs
- Small is beautiful: fast turn-around of problem specification, testing, standardization
- Open, democratic process
- Everyone can suggest a standard
- Each standard can be commented on by every community member
- Motivate community to accept standard rather then enforce
- Open source and/or public domain tools are essential

## Lessons learned: What does not work well?

- If scope of standard is too large/too complex
- Problems/needs are not concrete and clear
- why is data interoperability hard?
- Turn-around too long
- Better smaller scope, and evolution
- Working groups too big
- Someone ‘owns’ the process and/or the standard
- Others have only ‘advisory’ input
- Trying to come up with the best fit solution in a 50 experts group discussion
- People tend not to agree, and like to discuss. Tedious.
- No implementation

## Examples for Successful Standards

- IETF (Internet Engineering Task Force)
- Background:
- 1980s: Many isolated computer networks (arpanet, uunet,....)
- 1986:  how can these networks be used seamlessly?
-   Internet
- IETF as community-born organization:
- “The Internet Engineering Task Force is a loosely self-organized group of people who contribute to the engineering and evolution of Internet technologies.“
- “The IETF is not a traditional standards organization.... The IETF is made up of volunteers, many of whom meet three times a year to fulfill the IETF mission. “
- From “The TAO of IETF”
- Process to adopt standards (later talk)

## Successful Standards

- OpenGIS Consortium:
-   Background
- 1993: time of object-oriented distributed computing
- Small group is interested in defining Open GIS:
- Define vendor-independent interoperable GIS interfaces
- Standards Body: OpenGIS Consortium
- Members, fees, board of directors
- Standards are developed by members
- Standards are easy to influence, and everyone can participate in the process
- OGC went through several process models
- Discussion approach (1st generation): 3 year turn around
- RPF approach (2nd  generation): 1 1⁄2 year turn around
- Testbed approach (3rd generation): ca. 6 months

## SEEDS and Standards?

- Caution: Standards development is expensive
- Leverage existing (commercial?) standards whereever possible
- Adopt, profile, extend existing standards
- Re-use commercial software products
- Nevertheless:
- A *SEEDS Standards Body* and a *SEEDS Standards Process *are required
- To identify, extend and adopt possible useful standards
- Both need to accommodate the diverse communities
*Resources* to support standards identification, profiling, adoption, development

## Models for Standard Processes

- Personal background
- Used standards for distributed interoperable software platforms (CORBA) (pre-Java)
- Worked with OpenGIS Consortium since 1995
- Co-author and editor of OGC’s “CORBA Simple Features”
- Study Group “Long-Term Standards and Standard Processes”
- Group of people with experience in developing standards
- Group investigated and analyzed a large variety of relevant standards and standard processes for ESE
- Identification of Standards Needs relevant to ESE
- Identification of successful Standard Process Models and Standards Bodies