Networking impediments and opportunities
< Back to 
| Workshops | Air Quality Data Network
Session Intro
Martin: This third day will be a wrap-up day. The first day we have dealt with technical topics, the second day was about social, community and programmatic networking. This third day we would like to address the workshop motto: "from virtual to real". Now that the AQ Data network is in gear, what are the impediments toward further progress and what are the opportunities .. within the constrains of funding, manpower, knowledge. In the second morning session, we would like to listen to the participants: what at is their specific interest in participating in the network? The participants here are practitioners and they already have certain ways of doing things. What are the added values that the Network could contribute? What are the things that they could do with the network that they can not do now? It would be nice to take home ideas about showcasing these added values and opportunities. Finally for the afternoon, we have scheduled workshop outputs, outcomes and plans. In fact much of the day should be about outputs outcomes and plans.
Since we are now entering the discussion mode, and to capture the essence of those discussions, I am now suggesting to move from the PowerPoint to the wiki as the channel of communication. This will relieve us from the pressures of generating a workshop report after the fact. Furthermore, though the wiki everyone can participate and make contributions, now and in the future. So, a short wiki tutorial by Erin...link here.
Discussion
R.Husar: Voluntary human networks such as the AQ CoP have very special characteristics and impediments that have been well characterized by Bogardi:
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
Particularly intriguing is the list of "Lethal ingredients" that can cause these networks to be dysfunctional.
Impediment Slide
B. Domenico: The Unidata governance consist of a user community that brainstorms all the opportunities and leads that from the users point of view. The compliment of that is that we have a policy committee that considers the resource constraints, focus areas and opportunities that should be given off. SO the group in this room, augmented with others could be the policy committee to make decisions on priorities and directions.
R.Husar: The Unidata model of governance is indeed very attractive, practical and effective approach. The entire data community operations that includes both software developments, outreach/education and governance is maintained by a strong financial and moral support by NSF, spanning the past 25 years. This AQ group does not yet have such sponsoring support, neither does it have a deep and broad buy-in by the potential users.
- 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
- NG - community definition of metadata, in particular for client development; how can INSPIRE etc. help us?
- JRC - no impediments, all ready to go
- 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)
