Difference between revisions of "Ecosystem Approach Community of Practice: VRE planning"

From D4Science Wiki
Jump to: navigation, search
(VRE Profiles)
(Proposed VREs)
 
(54 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Proposed VRE Developments ==
+
{| align="right"
 +
|| __TOC__
 +
|}
 +
Virtual Research Environments (VREs) are web based working environments tailored to serve the needs of a specific eScience scenario.
  
Deliverable D6.1; Virtual Research Environments Plan, describes the identified Virtual Research Environments to be
+
The iMarine project is called to deploy and operate a number of VREs to satisfy the needs arising in selected scenarios identified by the Ecosystem Approach Community of Practice. The plan governing this VREs operation activity is documented in a [[Virtual_Research_Environments_Deployment_and_Operation:_Plan | dedicated wiki page]].
deployed in the iMarine Data e-Infrastructure as requested by the EA-CoP. At the due data of the Deliverable, the EA-CoP was not yet equipped with a functioning requirements collecting and assessment support; that will be provided by the iMarine Board.  
+
  
However, since the drafting of the iMarine project started, strong impulses from both the technology suppliers as the intended CoP already outlined a set of services and resources to be made available through a high-performance infrastructure such as D4S.  
+
Such a plan mainly results from the needs and desiderata with respect to VREs that the Ecosystem Approach CoP documented by this page.  
  
This deliverable has to be prepared by the CoP, but requires a carefull assessment before being submitted to the other Consortium members. This review will see the iMarine Board involved in assessing the technological and functional 'added value' that will be provided by any proposed VRE. This review procedure applies to all types of VRE's, services and resources identified in the project that will be exposed to the CoP.
+
== VREs Specification Procedure ==
  
The VRE proposal review process is organized in 3 main phases: Preparation and Board review, Consortium review, and PEB review and approval.
+
The specification of a VRE mainly consists in a characterisation of the expected service in terms of data/datasets to be made available, facilities to be offered, and qualitative aspects to be guaranteed. In addition to that the service characterization should include the target scenario it is conceived for.    
  
=== Proposed VREs ===
+
Such a characterisation is expected to be produced by the CoP, however it requires an assessment before being submitted to the project Consortium for the actual implementation of the service. This assessment consists of a review procedure having three phases:
 +
# iMarine Board Review: the members of this board are called to assess the technological and functional 'added value' that will be provided by any proposed VRE. This review procedure applies to all types of VRE's, services and resources identified in the project that will be exposed to the CoP;
 +
# PEB Review: the Project Executive Board is called to evaluate the feasibility of the proposed VRE as well as to perform a cost-benefit analysis of the proposal;
 +
# Consortium Review: the project members involved in the implementation of the VRE are called to evaluate the feasibility of the proposed VRE implementation and to agree on a deployment schedule;
  
Currently, a set of functional VRE's is it the CoP disposal, but these will need various modifications before they will be adopted by new consortium members.
+
If all the three review phases are passed, the project agrees to implement the identified VRE and start working on it.  
# '''[[FCPPS]]''' The reporting tool;
+
# '''[[ICIS]]''' The Timeseries management environment;
+
# '''[[AquaMaps]]''' The species predictive modeling envrionment;
+
# '''[[VTI]]''' The Vessel Transmitted Information management and modeling envrionment;
+
  
Already in an advanced state of progress, or planned extensions to the above are:
+
== Proposed VREs ==
# '''[[SPREAD]]''' Building on a subset of ICIS capabilities, SPREAD will add geospatial reallocation features ;
+
# '''[[Codelistmanager]]''' The management of Codelists requires the further development of the facility in ICIS;
+
# '''[[CodelistMapper]]''' The generation of persitent mappings between codes, code lists, and data using those codes requires that similar functionality developed in ICIS be made available as a separate VRE;
+
# '''[[VME DB]]''' The Vulnerable Marine Ecosystem database will contain VME Factsheets. These factsheets rely on services provided in FCPPS for document workflow and content management, and will be published using the FiMES schema;
+
# '''[[VME Mapper]]''' based on VTI/ AquaMaps modelling and aggregation functions; access to geospatial data related to VME's;
+
  
In addition, a range of new VRE's that answer to specific data manipulation needs has been identified to support other VRE's; they provide functionality that other VREs may need to increse their uptake, or that open new data sources to existing VRE's
+
Several VRE's are already used, while others are being implemented. Throughout the project, VRE's will be built, sometimes 'on top of' other VRE's. This VRE planning page is a living page, where the several stages of VRE development are tracked. These go from inception (1), proposal (2), review (3), implementation (4), to delivery (5).  
# '''[[SpeciesModeller]]''' The AquaMaps VRE with added algorithms;
+
# '''[[OBIS]]''' The functionality required by OBIS;
+
# '''[[Taxon]]''' Support for all VRE's in need of Taxonomy data; a Species Finder, based on GBIF and other repositories, supporting DarwinCore;   
+
# '''[[Semantic Annotator]]''' The FLOD service to annotate a document;
+
# '''[[Environmental Explorer ]]''' The Thredds data finder, schedule the finder, publish results;
+
# '''[[Environmental Processor]]''' Invoke an internal or external process on a geospatial product, such as an aggregation over space and time, sample an image, filter on a bandwidth, transform into another format, etc.;
+
# '''[[FishFrame]]''' The support for the IRD / EU FishFrame format and COST model with R integration;
+
  
=== VRE Profiles ===
+
After delivery, the functioning and use of the VRE will be subject to validation, for which a dedicated wiki page is available.
  
The many opportunities provided by the infrastructure at times may be overwhelming and difficult to grasp by representatives from e.g. the Communities of Practice behind the Business Cases.
+
The delivered VRE's have been validated:
  
In order to facilitate the collection of and negotiations on specific desiderata, a template that captures first the CoP 'wishlist', and then discusses these with Board representatives, WP3 members, and PEB delegates.  
+
# '''[[Ecosystem Approach Community of Practice: FCPPS | FCPPS]]''' (5) The reporting tool;
 +
# '''[[Ecosystem Approach Community of Practice: ICIS | ICIS]]''' (5) The Timeseries management environment;
 +
# '''[[Ecosystem Approach Community of Practice: AquaMaps | AquaMaps]]''' (5) The species predictive modeling environment;
 +
# '''[[Ecosystem Approach Community of Practice: VTI | VTI]]''' (5) The Vessel Transmitted Information management and modeling environment;
 +
# '''[[Ecosystem Approach Community of Practice: Trendylyzer | Trendylyzer]]''' (5) Analytical tool, with a similar concept to Trendalyzer / gapminder for data manager to discover long-term trends in TimeSeries.
 +
# '''[[Ecosystem Approach Community of Practice: SPREAD | SPREAD]]''' (5) Building on a subset of ICIS capabilities, SPREAD will add geospatial reallocation features ;
 +
# '''[[Ecosystem Approach Community of Practice: FishFinder | FishFinderVRE]]''' (5) Reporting tool and work flow environment based on FCPPS to facilitate the collation and editing of Species Fact Sheets;
 +
# '''[[Ecosystem Approach Community of Practice: FishFinderOffLine | FishFinderOffLine]]''' (5) Reporting tool based on FishFinder for authors to compile Species Fact Sheets.
 +
# '''[[Ecosystem Approach Community of Practice: SpeciesNameFinder | SpeciesNameFinder]]''' (5) Species name disambiguation tool. And nothing more than that;
 +
# '''[[Ecosystem Approach Community of Practice: VME DB | VME DB]]''' (5) The Vulnerable Marine Ecosystem database will contain VME Factsheets. These factsheets relate to services provided in FCPPS for document workflow and content management, and will be published using the FiMES schema. The use cases and requirements are completed (August2014);
 +
# '''[[Ecosystem Approach Community of Practice: TaxonReconciliation | TaxonReconciliation]]''' (5) Using iMarine and FAO technologies, this service calculates distances between objects, often using lexical matchers. A first candidate is the FIN requirement for name reconciliation by taxonomists, delivered through BiOnym. Another application to integrate would be the FAO VRMF tool for vessel name reconciliation. Many other domains are being considered such as FAO-areas and a geonames locator;
  
A proposal for such template could be:
+
In additon, several VRE similar gCubeApps have been released, most notably the
 +
# '''[[Ecosystem Approach Community of Practice: BiodiversityResearchEnvironment | BiodiversityResearchEnvironment]]''' (5) The environment to access and browse species occurrence data from multiple Darwin Core enabled repositories, and to view these in the GeoExplorer tool;
 +
# '''[[Ecosystem Approach Community of Practice: EcologicalModeling | EcologicalModeling ]]''' (4) The combination of data, tools and services to deliver species predictive maps and datasets, conceived as a richer AquaMaps;
  
'''Problem''': ''Describe the CoP issue to be addressed by the Componenent (VRE / service / resource / etc)''
+
Already in an advanced state of implementation, either as independent VRE's, or as extensions to the above are:
 +
# '''[[Ecosystem Approach Community of Practice: SmartFish | SmartFish]]''' (4) A toolset to offer a advanced search and data retrieval over 3 data repositories (XML, Excel and a database) focused on capture species data through the iMarine e-infrastructure.
 +
# '''[[Ecosystem Approach Community of Practice: Codelistmanager | Codelistmanager]]''' (4) The management of Codelists requires the further development of the facility in ICIS, and the development of Cotrix;
 +
# '''[[Ecosystem Approach Community of Practice: CodelistMapper | CodelistMapper]]''' (3) The generation of persistent mappings between codes, code lists, and data using those codes requires that similar functionality developed in ICIS be made available as a separate VRE. In addition, it will have to be enabled to extract data using Cotrix components; a code lists and vocabulary management environment being developed by FAO and others;
 +
# '''[[Ecosystem Approach Community of Practice: FishFrame | FishFrame]]''' (4) The support for the IRD / EU FishFrame format and COST model. The specifications are provided by ICES, and implemented in an experiment;
 +
# '''[[Ecosystem Approach Community of Practice: NEAFC2ICES | NEAFC2ICES]]''' (4) Support to NEAFC to 1.) anonymize confidential data in their infrastructure, 2) publish these anonymized datasets in a controlled repository, 3) 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.
 +
# '''[[Ecosystem Approach Community of Practice: MixeR | MixeR]]''' (4) Support to read from / write to an integrated, parallel R script. This component will build on the existing R functions in ICIS, and is developed as an iMarine Experiment with FAO Stock Assessment software. The expected reduction in processing time is from 12 days to 12 hours.
 +
# '''[[Ecosystem Approach Community of Practice: EA-LOD | EA-Linked Open Data]]''' (4) A toolset to produce Linked Open Data in the iMarine e-infrastructure.
 +
# '''[[Ecosystem Approach Community of Practice: SpeciesModeller | SpeciesModeller]]''' (4) The AquaMaps VRE with added algorithms, enriched with additional algorithms supported by e.g. OpenModeler. This can be achieved through the Statistical Manager facility; 
 +
# '''[[Ecosystem Approach Community of Practice: SpeciesChart | SpeciesChart]]''' (4) Interactive display and editing of OBIS and other occurrence data, related to TrendyLyzer;
  
'''Product:'''  
+
# '''[[Ecosystem Approach Community of Practice: TBTI | TBTI]]''' (2) The Too Big To Ignore VRE will serve the EA-CoP interested in the socio-economic data specific to small scale fisheries, their geospatial context, and document retrieval.
''Describe the proposed solution in maximum 3 sentences:''
+
+
'''Priority to CoP:'''
+
''List proposed solution priority following the iMarine Board priority setting criteria: ''
+
  
* ''Identified community: Users now:''
+
In addition, a range of new VRE's that answer to specific data manipulation needs has been identified to support other VRE's; they provide functionality that other VREs may need to increase their uptake, or that open new data sources to existing VRE's
* ''Potential for co-funding:''
+
* ''Structural allocation of resources:''
+
* ''Referred in DoW:''
+
* ''Business Cases:''
+
* ''How does the proposed action generally support sustainability aspects''
+
* ''How consistent it is with EC regulations/strategies (eg INSPIRE, ... ):''
+
* ''Re-usability – benefits – compatibility''
+
  
'''Parentage:'''
 
''Relation to CoP Software''
 
''Relation to D4S technologies''
 
  
''Does the proposed solution solve other problems associated with EA-CoP Business Cases?''  
+
# '''[[Ecosystem Approach Community of Practice: Semantic Annotator | Semantic Annotator]]''' (3) The FAO services to annotate a document. Existing FAO services that might be re-purposed here are FLOD, the AgroTagger and VocBench;
 +
# '''[[Ecosystem Approach Community of Practice: KB Browser | KB Browser ]]''' (2) This service will prepare request to FLOD, and manage the results by e.g. integrating these in the a FCPPS report. Also IRD will have to describe their expectations.
  
''If the proposed solution can be used in another SW scenario (not users!) please describe.''
 
  
'''Public:''' 
 
''How big is the expected user community after delivery?''
 
  
'''Productivity:'''
+
Additionally, the CoP offers a host of independent services that will require to be interoperable with the VRE's. Examples are OpenSDMX, Cotrix, and Spread. these can be described in separate wiki's:
''Are the proposed measures effective?''
+
+
''Does it reduce a known workload?''
+
  
'''Price:'''  
+
# OpenSDMX. [http://opensdmx.wikispaces.com/home OpenSDMX] is the FAO Open Source project in support to SDMX data acquisition and dissemination.
''Is the proposed solution cheap?''  
+
# '''[[Ecosystem Approach Community of Practice: Cotrix | Cotrix]]'''Cotrix. [https://github.com/cotrix/cotrixrep/wiki/_pages Cotrix] is the development of a shared code list manager. It is currently identical to the code list manager above. It can become a Open Source development tool, once FAO departments decide that it is worth investing in.
 +
# '''[[Ecosystem Approach Community of Practice: FLOD | FLOD ]]'''is the Semantic data-set combining strategic FAO Assets in a knowledge base. FAO uses iMarine resources to enrich this dataset, and position it as a knowledge base for other resources to refer to concepts rather than string literals. The FLOD content management is currently being bolstered through the development of a Semantic data work-flow.
  
''Expected effort in PM:''
+
Other tools extract data from the iMarine e-infrastructure, but do not rely on specific services or resources. The data may be prepared in a VRE, but the are consumed e.g. through a web service only.
 +
 
 +
# '''[[iMarine Species App]]'''; (3) The updated version of the AppliFish mobile app;
 +
# '''[[AppliFish2]]'''; (2) A redesigned AppliFish with better integration with e-infra services, such as search and country-statistics.
 +
 
 +
== VRE Specification Template ==
 +
 
 +
The many opportunities provided by Virtual Research Environment operated through a gCube-based infrastructure at times may be overwhelming and difficult to grasp by representatives from e.g. the Communities of Practice behind the Business Cases.
 +
 
 +
In order to facilitate the collection of and negotiations on specific desiderata, a template that captures first the CoP 'wishlist', and then discusses these with Board representatives, WP3 members, and PEB delegates.
 +
 
 +
The current template contains:
 +
 
 +
; Product
 +
: Describe the expected service in maximum 3 sentences
 +
 +
; Priority to CoP
 +
: List proposed solution priority following the iMarine Board priority setting criteria:
 +
:* Potential target community;
 +
:* Users;
 +
:* Potential for co-funding;
 +
:* Structural allocation of resources;
 +
:* Referred in DoW;
 +
:* Business Cases;
 +
:* How does the proposed action generally support sustainability aspects;
 +
:* How consistent it is with EC regulations/strategies (eg INSPIRE);
 +
:* Re-usability – benefits – compatibility;
  
'''Presentation:'''
+
; Parentage
''How is the component delivered to users? (Design / on-line help / training material / support).''
+
: Relation to CoP Software
 +
: Relation to D4S technologies
  
'''Privacy:'''
+
; Productivity
''Are they safe?''
+
: Are the proposed measures effective?
''Need the proposed solution to manage confidential info at data / dataset / organizational level?''
+
: Does it reduce a known workload?
''Describe security and privacy issues:''
+
  
'''Policy:'''
+
; Presentation
''Are there any policies available that describe data access and sharing?''
+
: How must the component be delivered to users? (UI Design / on-line help / training material / support)
''Are these really needed?''
+
''Copyright / attribution / metadata / legal''
+
  
'''Pericolo:'''
+
; Policy
''Do they introduce moral hazard? (A hazard here is the risk that users will behave more recklessly if they are insulated from the effects of the software, or if they do noit understand what it produces, where data come from, what they represent etc. .)''
+
: 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?

Latest revision as of 09:40, 28 August 2014

Virtual Research Environments (VREs) are web based working environments tailored to serve the needs of a specific eScience scenario.

The iMarine project is called to deploy and operate a number of VREs to satisfy the needs arising in selected scenarios identified by the Ecosystem Approach Community of PracticeA term coined to capture an "activity system" that includes individuals who are united in action and in the meaning that "action" has for them and for the larger collective. The communities of practice are "virtual", ''i.e.'', they are not formal structures, such as departments or project teams. Instead, these communities exist in the minds of their members, are glued together by the connections they have with each other, as well as by their specific shared problems or areas of interest. The generation of knowledge in communities of practice occurs when people participate in problem solving and share the knowledge necessary to solve the problems.. The plan governing this VREs operation activity is documented in a dedicated wiki page.

Such a plan mainly results from the needs and desiderata with respect to VREs that the Ecosystem Approach CoPCommunity of Practice. documented by this page.

VREs Specification Procedure

The specification of a VREVirtual Research Environment. mainly consists in a characterisation of the expected service in terms of data/datasets to be made available, facilities to be offered, and qualitative aspects to be guaranteed. In addition to that the service characterization should include the target scenario it is conceived for.

Such a characterisation is expected to be produced by the CoPCommunity of Practice., however it requires an assessment before being submitted to the project Consortium for the actual implementation of the service. This assessment consists of a review procedure having three phases:

  1. iMarine Board Review: the members of this board are called to assess the technological and functional 'added value' that will be provided by any proposed VREVirtual Research Environment.. This review procedure applies to all types of VREVirtual Research Environment.'s, services and resources identified in the project that will be exposed to the CoPCommunity of Practice.;
  2. PEB Review: the Project Executive Board is called to evaluate the feasibility of the proposed VREVirtual Research Environment. as well as to perform a cost-benefit analysis of the proposal;
  3. Consortium Review: the project members involved in the implementation of the VREVirtual Research Environment. are called to evaluate the feasibility of the proposed VREVirtual Research Environment. implementation and to agree on a deployment schedule;

If all the three review phases are passed, the project agrees to implement the identified VREVirtual Research Environment. and start working on it.

Proposed VREs

Several VREVirtual Research Environment.'s are already used, while others are being implemented. Throughout the project, VREVirtual Research Environment.'s will be built, sometimes 'on top of' other VREVirtual Research Environment.'s. This VREVirtual Research Environment. planning page is a living page, where the several stages of VREVirtual Research Environment. development are tracked. These go from inception (1), proposal (2), review (3), implementation (4), to delivery (5).

After delivery, the functioning and use of the VREVirtual Research Environment. will be subject to validation, for which a dedicated wiki page is available.

The delivered VREVirtual Research Environment.'s have been validated:

  1. FCPPS (5) The reporting tool;
  2. ICIS (5) The Timeseries management environment;
  3. AquaMaps (5) The species predictive modeling environment;
  4. VTI (5) The Vessel Transmitted Information management and modeling environment;
  5. Trendylyzer (5) Analytical tool, with a similar concept to Trendalyzer / gapminder for data manager to discover long-term trends in TimeSeries.
  6. SPREAD (5) Building on a subset of ICIS capabilities, SPREAD will add geospatial reallocation features ;
  7. FishFinderVRE (5) Reporting tool and work flow environment based on FCPPS to facilitate the collation and editing of Species Fact Sheets;
  8. FishFinderOffLine (5) Reporting tool based on FishFinder for authors to compile Species Fact Sheets.
  9. SpeciesNameFinder (5) Species name disambiguation tool. And nothing more than that;
  10. VME DB (5) The Vulnerable Marine Ecosystem database will contain VME Factsheets. These factsheets relate to services provided in FCPPS for document workflow and content management, and will be published using the FiMES schema. The use cases and requirements are completed (August2014);
  11. TaxonReconciliation (5) Using iMarine and FAO technologies, this service calculates distances between objects, often using lexical matchers. A first candidate is the FIN requirement for name reconciliation by taxonomists, delivered through BiOnym. Another application to integrate would be the FAO VRMF tool for vessel name reconciliation. Many other domains are being considered such as FAO-areas and a geonames locator;

In additon, several VREVirtual Research Environment. similar gCubeApps have been released, most notably the

  1. BiodiversityResearchEnvironment (5) The environment to access and browse species occurrence data from multiple Darwin Core enabled repositories, and to view these in the GeoExplorer tool;
  2. EcologicalModeling (4) The combination of data, tools and services to deliver species predictive maps and datasets, conceived as a richer AquaMaps;

Already in an advanced state of implementation, either as independent VREVirtual Research Environment.'s, or as extensions to the above are:

  1. SmartFish (4) A toolset to offer a advanced search and data retrieval over 3 data repositories (XML, Excel and a database) focused on capture species data through the iMarine e-infrastructure.
  2. Codelistmanager (4) The management of Codelists requires the further development of the facility in ICIS, and the development of Cotrix;
  3. CodelistMapper (3) The generation of persistent mappings between codes, code lists, and data using those codes requires that similar functionality developed in ICIS be made available as a separate VREVirtual Research Environment.. In addition, it will have to be enabled to extract data using Cotrix components; a code lists and vocabulary management environment being developed by FAO and others;
  4. FishFrame (4) The support for the IRD / EU FishFrame format and COST model. The specifications are provided by ICES, and implemented in an experiment;
  5. NEAFC2ICES (4) Support to NEAFC to 1.) anonymize confidential data in their infrastructure, 2) publish these anonymized datasets in a controlled repository, 3) 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.
  6. MixeR (4) Support to read from / write to an integrated, parallel R script. This component will build on the existing R functions in ICIS, and is developed as an iMarine Experiment with FAO Stock Assessment software. The expected reduction in processing time is from 12 days to 12 hours.
  7. EA-Linked Open Data (4) A toolset to produce Linked Open Data in the iMarine e-infrastructure.
  8. SpeciesModeller (4) The AquaMaps VREVirtual Research Environment. with added algorithms, enriched with additional algorithms supported by e.g. OpenModeler. This can be achieved through the Statistical Manager facility;
  9. SpeciesChart (4) Interactive display and editing of OBIS and other occurrence data, related to TrendyLyzer;
  1. TBTI (2) The Too Big To Ignore VREVirtual Research Environment. will serve the EA-CoPCommunity of Practice. interested in the socio-economic data specific to small scale fisheries, their geospatial context, and document retrieval.

In addition, a range of new VREVirtual Research Environment.'s that answer to specific data manipulation needs has been identified to support other VREVirtual Research Environment.'s; they provide functionality that other VREs may need to increase their uptake, or that open new data sources to existing VREVirtual Research Environment.'s


  1. Semantic Annotator (3) The FAO services to annotate a document. Existing FAO services that might be re-purposed here are FLOD, the AgroTagger and VocBench;
  2. KB Browser (2) This service will prepare request to FLOD, and manage the results by e.g. integrating these in the a FCPPS report. Also IRD will have to describe their expectations.


Additionally, the CoPCommunity of Practice. offers a host of independent services that will require to be interoperable with the VREVirtual Research Environment.'s. Examples are OpenSDMX, Cotrix, and Spread. these can be described in separate wiki's:

  1. OpenSDMX. OpenSDMX is the FAO Open Source project in support to SDMX data acquisition and dissemination.
  2. CotrixCotrix. Cotrix is the development of a shared code list manager. It is currently identical to the code list manager above. It can become a Open Source development tool, once FAO departments decide that it is worth investing in.
  3. FLOD is the Semantic data-set combining strategic FAO Assets in a knowledge base. FAO uses iMarine resources to enrich this dataset, and position it as a knowledge base for other resources to refer to concepts rather than string literals. The FLOD content management is currently being bolstered through the development of a Semantic data work-flow.

Other tools extract data from the iMarine e-infrastructure, but do not rely on specific services or resources. The data may be prepared in a VREVirtual Research Environment., but the are consumed e.g. through a web service only.

  1. iMarine Species App; (3) The updated version of the AppliFish mobile app;
  2. AppliFish2; (2) A redesigned AppliFish with better integration with e-infra services, such as search and country-statistics.

VREVirtual Research Environment. Specification Template

The many opportunities provided by Virtual Research EnvironmentA ''system'' with the following distinguishing features: ''(i)'' it is a Web-based working environment; ''(ii)'' it is tailored to serve the needs of a Community of Practice; ''(iii)'' it is expected to provide a community of practice with the whole array of commodities needed to accomplish the community’s goal(s); ''(iv)'' it is open and flexible with respect to the overall service offering and lifetime; and ''(v)'' it promotes fine-grained controlled sharing of both intermediate and final research results by guaranteeing ownership, provenance, and attribution. operated through a gCube-based infrastructure at times may be overwhelming and difficult to grasp by representatives from e.g. the Communities of Practice behind the Business Cases.

In order to facilitate the collection of and negotiations on specific desiderata, a template that captures first the CoPCommunity of Practice. 'wishlist', and then discusses these with Board representatives, WP3 members, and PEB delegates.

The current template contains:

Product
Describe the expected service in maximum 3 sentences
Priority to CoPCommunity of Practice.
List proposed solution priority following the iMarine Board priority setting criteria:
  • Potential target community;
  • Users;
  • Potential for co-funding;
  • Structural allocation of resources;
  • Referred in DoW;
  • Business Cases;
  • How does the proposed action generally support sustainability aspects;
  • How consistent it is with EC regulations/strategies (eg INSPIRE);
  • Re-usability – benefits – compatibility;
Parentage
Relation to CoPCommunity of Practice. Software
Relation to D4S technologies
Productivity
Are the proposed measures effective?
Does it reduce a known workload?
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?