Difference between revisions of "Networking impediments and opportunities"
From Earth Science Information Partners (ESIP)
| Line 10: | Line 10: | ||
* Clear statements about obstacles: no clear structure; no dedicated funding and no clear idea(s) yet how to do it. | * Clear statements about obstacles: no clear structure; no dedicated funding and no clear idea(s) yet how to do it. | ||
* Opportunities, fixes: ID manageable work packages; Find, organize, distribute reusable components, resources; Create win-win situation | * Opportunities, fixes: ID manageable work packages; Find, organize, distribute reusable components, resources; Create win-win situation | ||
| − | |||
== Impediment Slide == | == Impediment Slide == | ||
* Differing requirements, agendas, goals, timelines | * Differing requirements, agendas, goals, timelines | ||
** Need to plan in advance, adding requirements/needs mid-course | ** Need to plan in advance, adding requirements/needs mid-course | ||
| + | ** DLR - WCS version; NASA wants 1.0, community WCS uses 1.1.x | ||
| + | ** NILU - service interface must support "point observation view" | ||
| + | ** STI - commitment to adopt community server; need help on technical level | ||
| + | ** EEA - wants to add WCS service but needs to determine how to do this (e.g. decide which standard(s) to support) | ||
| + | ** CNR comment - INSPIRE can add stability to standards | ||
* Mismatched funding / mismatched development cycles | * Mismatched funding / mismatched development cycles | ||
| − | ** | + | ** NILU - must answer immediate needs; this drives development efforts |
* Open source community efforts versus off-the-shelf software | * Open source community efforts versus off-the-shelf software | ||
** Difficult to keep open source software going over the years | ** Difficult to keep open source software going over the years | ||
** Require resources staff/$ | ** Require resources staff/$ | ||
| − | ** Is it | + | ** DLR - limited resources - limit development efforts, not unwilling to install and run community server |
| − | ** Don't trust open source | + | ** NILU - limited funding, but maybe not impossible |
| + | ** STI - limited funding, need to prioritize | ||
| + | ** Is it reliable? | ||
| + | ** Don't trust open source | ||
| + | ** STI and EEA - must be certain that system survives ~10 years, not only on technical level but as a community | ||
| + | ** Unidata - backward compatibility is part of netcdf philosophy, not so in WCS (example multi-part mime wrapper); CF has slow development cycle on purpose, largely backward compatible although newer versions resolve ambiguities and therefore may break old code | ||
* Unclear expectations/requirements of the community | * Unclear expectations/requirements of the community | ||
* Need for clear, simple documentation/instructions | * Need for clear, simple documentation/instructions | ||
** Group needs to add feedback/experience to documentation | ** Group needs to add feedback/experience to documentation | ||
** Responsibility to maintain structure | ** Responsibility to maintain structure | ||
| − | * Changing/evolving standards and approach - | + | ** STI - communication tools, repository+version control are critical elements |
| + | * Changing/evolving standards and approach - Interoperability burnout | ||
** Too many new things - how to know where to focus? | ** Too many new things - how to know where to focus? | ||
** Governance needs - limited resources, growing needs | ** Governance needs - limited resources, growing needs | ||
| + | ** STI - structured community software development would probably work | ||
** Support vs. documentation vs. development | ** Support vs. documentation vs. development | ||
** Organisation of community software development: formal vs. informal; need for some sort of steering group with a mandate to take decisions | ** Organisation of community software development: formal vs. informal; need for some sort of steering group with a mandate to take decisions | ||
| Line 34: | Line 45: | ||
** Modifications needed to be made to the software for data coming in frequently | ** Modifications needed to be made to the software for data coming in frequently | ||
** performance | ** performance | ||
| + | ** STI - must persuade users to go through services rather than data downloads | ||
| + | |||
| + | * Insufficient user feedback/ user involvement | ||
| + | |||
| + | * Agreement on protocols (i.e. WCS x.y, W*S) vs. payload (i.e. adopt new netcdf-cf standard as community standard) | ||
Revision as of 02:13, August 25, 2011
< Back to 
| Workshops | Air Quality Data Network
JJ Bogardi, Global Water System Project (GWSP) at EGIDA, Bonn:
Nature of Networking Projects: Complex funding; mixture of paid and voluntary; multiple obligations; international; differing project maturity; governance, cultures
Which glue keeps it together? Trust and personal affinity. Common objectives and scientific values. Mutual respect. Mutual benefit (win-win). Complementarity. Donor dictate
Lethal“ ingredients. Turf mentality. Budget discrepancies. Too much competition. Lack of data and information exchange. Donor jealousy
- Clear statements about obstacles: no clear structure; no dedicated funding and no clear idea(s) yet how to do it.
- Opportunities, fixes: ID manageable work packages; Find, organize, distribute reusable components, resources; Create win-win situation
Impediment Slide
- Differing requirements, agendas, goals, timelines
- Need to plan in advance, adding requirements/needs mid-course
- DLR - WCS version; NASA wants 1.0, community WCS uses 1.1.x
- NILU - service interface must support "point observation view"
- STI - commitment to adopt community server; need help on technical level
- EEA - wants to add WCS service but needs to determine how to do this (e.g. decide which standard(s) to support)
- CNR comment - INSPIRE can add stability to standards
- Mismatched funding / mismatched development cycles
- NILU - must answer immediate needs; this drives development efforts
- Open source community efforts versus off-the-shelf software
- Difficult to keep open source software going over the years
- Require resources staff/$
- DLR - limited resources - limit development efforts, not unwilling to install and run community server
- NILU - limited funding, but maybe not impossible
- STI - limited funding, need to prioritize
- Is it reliable?
- Don't trust open source
- STI and EEA - must be certain that system survives ~10 years, not only on technical level but as a community
- Unidata - backward compatibility is part of netcdf philosophy, not so in WCS (example multi-part mime wrapper); CF has slow development cycle on purpose, largely backward compatible although newer versions resolve ambiguities and therefore may break old code
- Unclear expectations/requirements of the community
- Need for clear, simple documentation/instructions
- Group needs to add feedback/experience to documentation
- Responsibility to maintain structure
- STI - communication tools, repository+version control are critical elements
- Changing/evolving standards and approach - Interoperability burnout
- Too many new things - how to know where to focus?
- Governance needs - limited resources, growing needs
- STI - structured community software development would probably work
- Support vs. documentation vs. development
- Organisation of community software development: formal vs. informal; need for some sort of steering group with a mandate to take decisions
- Unidata - started as small grant to look at needs
- Challenges of real-time systems
- Modifications needed to be made to the software for data coming in frequently
- performance
- STI - must persuade users to go through services rather than data downloads
- Insufficient user feedback/ user involvement
- Agreement on protocols (i.e. WCS x.y, W*S) vs. payload (i.e. adopt new netcdf-cf standard as community standard)
