Difference between revisions of "Ecosystem Approach Community of Practice: NEAFC2ICES"
From D4Science Wiki
m (moved Ecosystem Approach Community of Practice: NAF2FLUX to Ecosystem Approach Community of Practice: VTI2: The conversion of NAF formatted data to comply with the FLUX standard is no longer required.) |
|||
| Line 1: | Line 1: | ||
| − | NEAFC has been offered a sub-contract to assist the iMarine consortium with the development of a set of services that enables NEAFC to securely share fisheries information. Some of these facilities can not be provided by Virtual Research Environments, as the data to feed these services can not leave the NEAFC premises. Therefore, a facility is required that can be installed, configured and controlled by NEAFC staff in the NEAFC infrastructure. This facility would be the 'gatekeeper' to the NEAFC repository. Similar 'connectors' or more often needed, and e.g. through the iMarine OpenSDMX initiative, example connectors have already been delivered. | + | NEAFC has been offered a sub-contract to assist the iMarine consortium with the development of a set of services that enables NEAFC to securely share fisheries information. Some of these facilities can not be provided by Virtual Research Environments, as the data to feed these services can not leave the NEAFC premises. Therefore, a facility is required that can be installed, configured and controlled by NEAFC staff '''in the NEAFC infrastructure'''. This facility would be the 'gatekeeper' to the NEAFC repository. Similar 'connectors' or more often needed, and e.g. through the iMarine OpenSDMX initiative, example connectors have already been delivered. |
The NEAFC subcontract depends on these 'connectors', and hence can not commence until these have been validated by Q3 2013. | The NEAFC subcontract depends on these 'connectors', and hence can not commence until these have been validated by Q3 2013. | ||
; Product | ; Product | ||
| − | : The services sought by NEAFC should implement secure data exchange with ICES. In first instance, a data browser and data store will be developed for registered ICES staff. The | + | : The services sought by NEAFC should implement secure data exchange with ICES. In first instance, a data browser and data store will be developed for registered ICES staff. The main functions will be to |
| − | + | # develop a query tool to generate anonymized datasets from data stored in the NEAFC infrastructure, with parameters such as | |
| − | + | ## Species (group), | |
| − | + | ## Time period, | |
| − | + | ## Fishing area (EEZ / BBox / FAO), | |
| − | : The activities of NEAFC will focus | + | ## Vessel group identifiers such as flag state, |
| − | : In order to ensure a sustainable use and maintenance of the delivered software to NEAFC, NEAFC will have to | + | ## Activity identifiers such as Specific measure, |
| + | ## Other group characteristics, such as gear, target species, or landing site | ||
| + | # transform data to an ICIS recognizable format, as per ICES requirements, | ||
| + | # publish these anonymized datasets in an access controlled repository in the iMarine infrastructure (encrypted), | ||
| + | # ensure that these data-sets can be analyzed in a variety of other VRE's for e.g. statistical trend analysis, plotting, graphing and tabulation. | ||
| + | : The activities of NEAFC will focus on the requirements engineering, validation of results, and use of the services. The software will be supplied and / or further developed under the oversight of iMarine partners, and be covered under the sub-contract. | ||
| + | : In order to ensure a sustainable use and maintenance of the delivered software to NEAFC, NEAFC will have to contribute hardware and software (JAVA) skills, and oversee the development of the connector to their confidential data. | ||
; Priority to EA-CoP, and more specifically, NEAFC | ; Priority to EA-CoP, and more specifically, NEAFC | ||
: The proposed solution meets the following iMarine Board priority setting criteria: | : The proposed solution meets the following iMarine Board priority setting criteria: | ||
| − | :* | + | :* The target community are Marine scientists and policy makers in need of aggregate effort reports; |
| − | :* Users; | + | :* The Users will be ICES staff that require such information, for each Class NEAFC will manage the credentials; |
| − | :* Potential for co-funding; | + | :** Class 1 users; editors; will be allowed download of data in aggregated format, and be charged with ensuring confidentiality; |
| − | :* Structural allocation of resources; | + | :** Class 2 users; reviewers; will be allowed download of PDF reports; |
| − | :* Referred in DoW; | + | :** Class 3 users; consumers; will have access to some released PDF reports with |
| − | :* Business Cases; | + | :* Potential for co-funding; A confidential work-flow from RDBMS database to open access is often required, and can be offered as a service in StatsCube. The VALID and DCF work-flows will require a very similar service; |
| − | :* How does the proposed action generally support sustainability aspects; | + | :* Structural allocation of resources; The Sub-contract is mentioned in the DoW. |
| − | :* How consistent it is with EC regulations/strategies (eg INSPIRE); | + | :* Referred in DoW; Yes. |
| − | :* Re-usability – | + | :* Business Cases; BC1. |
| + | :* How does the proposed action generally support sustainability aspects; The action will result in a managed access to RDBMS and will open proprietary RDBMS systems in a confidential yet transparent manner. | ||
| + | :* How consistent it is with EC regulations/strategies (eg INSPIRE); To be discussed. NEAFC has a confidentiality requirement that will decide the design and scope of this effort. | ||
| + | :* JAVA component considerations | ||
| + | :** Re-usability – | ||
| + | :** Benefits - | ||
| + | :** Compatibility - ; | ||
; Parentage | ; Parentage | ||
| Line 29: | Line 41: | ||
: Relation to D4S technologies | : Relation to D4S technologies | ||
| − | * SDMX Registry | + | * Statistical service; ONLY if NEAFC agrees to allow advances aggregations on their source data, will the Statistical Service be a candidate, as it requires that data are physically present in the infrastructure |
| − | * Workspace | + | * SDMX Registry; Aggregated statistics can be stored in the iMarine SDMX Registry, if required; |
| − | * ICIS | + | * Workspace; Datasets in other formats can be stored in teh secure workspace. |
| − | * CLM | + | * ICIS; |
| − | * GeoExplorer | + | * CLM; |
| + | * GeoExplorer; Foreseen to offer vizualization over aggregate statistics | ||
; Productivity | ; Productivity | ||
Revision as of 17:35, 16 September 2013
NEAFC has been offered a sub-contract to assist the iMarine consortium with the development of a set of services that enables NEAFC to securely share fisheries information. Some of these facilities can not be provided by Virtual Research Environments, as the data to feed these services can not leave the NEAFC premises. Therefore, a facility is required that can be installed, configured and controlled by NEAFC staff in the NEAFC infrastructure. This facility would be the 'gatekeeper' to the NEAFC repository. Similar 'connectors' or more often needed, and e.g. through the iMarine OpenSDMX initiative, example connectors have already been delivered.
The NEAFC subcontract depends on these 'connectors', and hence can not commence until these have been validated by Q3 2013.
- Product
- The services sought by NEAFC should implement secure data exchange with ICES. In first instance, a data browser and data store will be developed for registered ICES staff. The main functions will be to
# develop a query tool to generate anonymized datasets from data stored in the NEAFC infrastructure, with parameters such as
## Species (group),
## Time period,
## Fishing area (EEZ / BBox / FAO),
## Vessel group identifiers such as flag state,
## Activity identifiers such as Specific measure,
## Other group characteristics, such as gear, target species, or landing site
# transform data to an ICIS recognizable format, as per ICES requirements,
# publish these anonymized datasets in an access controlled repository in the iMarine infrastructure (encrypted),
# ensure that these data-sets can be analyzed in a variety of other VREVirtual Research Environment.'s for e.g. statistical trend analysis, plotting, graphing and tabulation.
- The activities of NEAFC will focus on the requirements engineering, validation of results, and use of the services. The software will be supplied and / or further developed under the oversight of iMarine partners, and be covered under the sub-contract.
- In order to ensure a sustainable use and maintenance of the delivered software to NEAFC, NEAFC will have to contribute hardware and software (JAVA) skills, and oversee the development of the connector to their confidential data.
- Priority to EA-CoPCommunity of Practice., and more specifically, NEAFC
- The proposed solution meets the following iMarine Board priority setting criteria:
- The target community are Marine scientists and policy makers in need of aggregate effort reports;
- The Users will be ICES staff that require such information, for each Class NEAFC will manage the credentials;
- Class 1 users; editors; will be allowed download of data in aggregated format, and be charged with ensuring confidentiality;
- Class 2 users; reviewers; will be allowed download of PDF reports;
- Class 3 users; consumers; will have access to some released PDF reports with
- Potential for co-funding; A confidential work-flow from RDBMS database to open access is often required, and can be offered as a service in StatsCube. The VALID and DCF work-flows will require a very similar service;
- Structural allocation of resources; The Sub-contract is mentioned in the DoW.
- Referred in DoW; Yes.
- Business Cases; BC1.
- How does the proposed action generally support sustainability aspects; The action will result in a managed access to RDBMS and will open proprietary RDBMS systems in a confidential yet transparent manner.
- How consistent it is with EC regulations/strategies (eg INSPIRE); To be discussed. NEAFC has a confidentiality requirement that will decide the design and scope of this effort.
- JAVA component considerations
- Re-usability –
- Benefits -
- Compatibility - ;
- Parentage
- Relation to NEAFC Software
This para is for NEAFC to fill
- Relation to D4S technologies
* Statistical service; ONLY if NEAFC agrees to allow advances aggregations on their source data, will the Statistical Service be a candidate, as it requires that data are physically present in the infrastructure * SDMX Registry; Aggregated statistics can be stored in the iMarine SDMX Registry, if required; * Workspace; Datasets in other formats can be stored in teh secure workspace. * ICIS; * CLM; * GeoExplorer; Foreseen to offer vizualization over aggregate statistics
- Productivity
- Are the proposed measures effective? For ICES staff; reduce search effort and improves reliability. For NEAFC staff reduces support time to write / run ad-hoc queries and exchange the data.
- Does it reduce a known workload? Yes, for both ICES and NEAFC staff.
- Presentation
- How must the component be delivered to users? (UI Design / on-line help / training material / support)
- Policy
- Are there any policies available that describe data access and sharing?
- Have the Copyright / attribution / metadata / legal aspects been addressed from a user and technology perspective?
