HELIO
Heliophysics Integrated Observatory

Community Coordination Meetings (CCMs)

Community Coordination Meetings (CCMs) are opportunities to talk with the communities involved in the HELIO project, report on the project and seek user input. They also provide an excellent opportunity to recruit users that will participate in the User Groups and help test the capabilities of the project throughout its development.

In some cases the CCM will just take the form of a splinter session of an hour or so where the HELIO project will report on how the project is progressing, its current capabilities and what it is planning; users will be invited to provide input and comments to the project and help refine to next set of objectives. Splinter meetings might just be related to the HELIO project, but could also be held in conjunction with another project such as SOTERIA or Europlanet RI. We also plan to participate in splinter sessions initiated by other projects or organizations so that the capabilities of HELIO can be broadcast to a wider audience.

CCMs could be held in conjunction with major international scientific meetings such as the European Geosciences Union (usually held in the spring, most recently in Vienna), the European Space Weather Week (usually held in November, most recently in Belgium) and possibly also the European Planetary Space Congress (usually held in September). We may also hold one at the American Geophysical Union (usually held in San Francisco in December).

We are also considering whether we should request sessions at such meetings devoted to heliophysics in order to allow the project to expand the set of Use Cases that are helping define the HELIO project requirements.

Note: As a result of the close cooperation between HELIO, SOTERIA and Europlanet RI, the CASSIS proposal was prepared and successfully submitted. CASSIS – the "Coordination Action for the integration of Solar System Infrastructures and Science" – will start on 1 June 2010 and last for 36 months.

 

User Groups

The User Group will help define the requirements of the HELIO system and provide feedback on which capabilities are working well, and those which need modification, should be added, dropped, etc.

Active user involvement during the development process will also allow the requirements to evolve throughout the project, making the infrastructure more adaptable to changing expectations. User-driven upgrades will occur frequently, once every few weeks.

Now that the basic components and infrastructure have been established, we need to have a recruitment drive to find people willing to help test the system and in particular to define the parts of the system related to the search for interesting events.

 

Focus Groups

This page describes the initial set of Focus Groups (FG) that will determine the requirements for the HELIO system. In the first instance, FG-1 to FG-4 will undertake their tasks; as the project progresses, the other FGs will start. Further FGs will be added in dues course as required.

It is intended that the Groups will conclude their discussions in a relatively short time – by early September 2009 in the case of the first four Groups.

FG-1 – Identify and prioritize types and sources of Metadata and Data

  • Objective:   In consultation with the Community, produce a list of the types of data from all the domains of heliophysics that HELIO should provide access to. Given that the project's resources are finite, one of the tasks of this FG is to prioritize this list.

    Similarly, identify and prioritize the types of event, etc. metadata from all domains that could be used within the search process to identify data sets of interest. Part of the task will be to determine which metadata may need to be regenerated or otherwise conditioned in order to facilitate searches that span the domains.

    The outputs of the FG will be used to determine what types of data should be included in Service Activities WPS2 (Metadata) and WPS3 (Data part).

  • Members:   Bentley (UCL); Messerotti (INAF-OATS); Jacquey (UPST); Hurlburt (LMATC); Aboudarham (OBSPARIS); Perry (STFC); Sanchez (ESA)

FG-2 – Identify and prioritize types of Features

  • Objective:   In consultation with the Community, produce a list of the types of feature from all the domains of heliophysics that HELIO should be able to identify and track. Given that the project's resources are finite, one of the tasks of this FG is to prioritize this list.

    The outputs of the FG will be used to determine which features will be addressed in Research (WPR2) and Service (WPS2) Activities.

  • Members:   Aboudarham (OBSPARIS); Gallagher (TCD); Jacquey (UPST); Hurlburt (LMATC)

FG-3 – Data models & Ontologies

  • Objective:   In this FG we are trying to work out how to provided integrated access to the heterogeneous data produced by the different domains involved in heliophysics. The FG needs to gather existing data models and ontologies from the domains, examine these to determine how they treat data and metadata, and look for ways that an over-spanning data model could be constructed.

    The outputs of the FG will be used to define what should be done in Research Activity WPR1 (Semantic VO).

  • Members:   Bentley (UCL); Fox (RPI); Gangloff (UPST); Hurlburt (LMATC); Brooke, Le Blanc (UNIMAN); Roberts (NASA); Sanchez (ESA)

FG-4 – Architecture

  • Objective:   Design the infrastructure that will be used to implement the initial version of HELIO – this should be built around capabilities that already exist within the consortium. The FG should also identity what functionality is required of the services so that the work to establish them can be started.

    The outputs of the FG will be used to define what will be implemented as the first task in Service Activity WPS1. Once the initial infrastructure has been determined, the Focus Group on the interfaces between the services (FG-5) can start.

  • Members:   Csillaghy, Soldati (FHNW); Coghlan, Childs, Pierantoni (TCD-CS); Brooke, Bechhofer (UNIMAN); Fox (RPI); Benson (UCL)

FG-5 – Define interfaces between services

  • Objective:   Define the interfaces for the services taking into account how the needs of the workflow tool may affect these, and the possible need to be able to respond to requests made in SPASE-QL, AD-QL, etc.

    The services should all be implemented independently with a well documented Web Service API. A simple Web portal should be ideally be provided on top of this.

  • Members:   Csillaghy (FHNW); Coghlan (TCD-CS); Brooke (UNIMAN); Messerotti (INAF-OATS); Bentley, Benson (UCL)

FG-6 – Science use cases (cross-domain)

FG-7 – Identify and prioritize types of processing required

FG-8 – Find a suitable Propagation Model

 
Last updated: 29th January 2019