View source for Talk:Air Quality Community Summer 2009 Meeting

== Erin's Meeting Notes -- [[User:Erinmr|Erinmr]] 13:14, 14 July 2009 (EDT) ==

Hi All - I'm adding a few observations I had from the meeting. Would others also add their notes/comments about the meeting? Thanks-
Key questions seemed to be: (1) what is the AQ Community Infrastructure? (2) how does it interact with the GEOSS Common Infrastructure? (3) How will AQ Comm Infra improve/support AQ Community
Day 1: 
# From Tim Dye: Need for "Super Easy" button, i.e. the barrier to participate in community activities needs to be low; there need to be tools/methods clearly established that help data providers enter
# From Uma: Barriers to entry - need common vocabulary, developers dilemma (the cost is to high to participate) 
# From Rudy/me: The AQ Community Infrastructure spans more than just the GCI and AQ conventions need to be established for AQ data access and metadata. When standards are in place, HTAP activities are enhanced.

Needs: identify high value data for users, identify processes that are redundant among users (like georeferencing) that could be done once before distribution, provide metadata that answers user questions, allow data selection for particular space-time-parameter subset

Day 2: Focused on use cases, how information currently flows and how it could be improved by AQ Comm. Infrastructure

GEO AQ CoP discussion - 
* ESIP is one area where members of the GEO AQ CoP will come from. ESIP/GEO AQ CoP will overlap, but both be maintained
* Need autonomous web space for the GEO AQ CoP
* Forest CoP is active, should check out. 

Action items to move forward: 
* Map out the NO2 use cases with a better description 
* What can be implemented by Jan 2010 ESIP?
* Twitter FUNding Friday

== Stefan's Meeting Notes -- [[User:Sfalke|Sfalke]] 14:56, 20 July 2009 (EDT) ==

Lawrence Friedl:

What is the problem we're trying to address? Interoperability and the infrastructure being pursued have many dimensions and issues to address. Which ones ought we address first? How do we make it a tangible problem for this group to address?
What is a systematic approach to tackling these and when do they need to be addressed?

Lawrence suggested the ESIP AQ Workgroup address the upcoming NASA AQ team meeting and define how PIs can participate.

He envisions decision makers having tools that provide, behind the scenes, access the data needed for the tool. Data access is not a worry for the decision makers nor something that they explicitly make decisions on  - the data are simply there for their purposes.

Lawrence suggested putting together an updated version of near term opportunities
-have the aq community say this is what we want and how do we draw in non-profits, private industry, etc.

Rich Scheffe:

Rich's final point on dealing with spatial incommensurabilities was a nice way to end his comments because it highlighted a deficiency in approaches to interoperability efforts so far. 

The focus has been on the data and data access. That is of interest to data providers and standards makers but less so for the data user. The user has particular use needs, such as reconciling differences in spatial resolution in order to combine heterogenous datasets for an analysis. Granted the data and access standards are needed and tools for finding data are important but our complaints for getting more people in the interoperability effort involved may be addressed if we can get to the next step in helping users do something more with the data. 

Uma Shankar:

Uma outlined three types of integration used in her project for bringing together different pieces from other organizations:

1) Full integration - completely immersed in the "closed" system. Like adding an internal function to a program.
2) Partial integration - overlap between components. The 'code' is shared, allowing the two components to be integrated.
3) Interoperability - use of standards to connect two independent components.

This type of characterization is another reminder that interoperability standards is not the only way. In some cases it makes sense to 'hardwire' the interoperability. It would be helpful to present the AQ infrastructure not as a solution to all interoperability but more focused to those cases where it is a clear benefit. It will help address questions like, "Why do I need GEOSS when I already exchange data and tools with the people I need to?"