Difference between revisions of "Ecosystem Approach Community of Practice: SPREAD"

Revision as of 10:41, 21 February 2012

SPREAD Profile

The SPatial REallocation of Aquatic Data (SPREAD) aims to provide the conversion of geospatial explicit data from one resolution to another.

The Use Cases were already descibed in D4ScienceAn e-Infrastructure operated by the D4Science.org initiative.-II, and can be found under the Advanced Curation Use Case.

It was included under ICIS Advanced Curation because in the context of D4ScienceAn e-Infrastructure operated by the D4Science.org initiative.-II, the starting point for a re-allocation is a TS-Object, and the re-allocation was perceived as a precision of geospatial location of a reported capture without much reasoning or change of the reported values.

A progress report on SPREAD accomplishments and opportunities can be found on BSCW (SPREAD120207.docx).

Problem

Describe the CoPCommunity of Practice. issue to be addressed by the Component (VREVirtual Research Environment. / service / resource / etc)

The problem of re-allocation is fully described in the SPREAD report.

The UNGA asked for a distinction between capture from the High Seas and those taken from EEZ's. Since the reporting for FAO does not include that distinction, a means has to be identified to disaggregate time-series.

Product

Describe the proposed solution in maximum 3 sentences:

With SPREAD capture time-series from ICIS can be re-allocated to another area using geospatial information on species distribution and capture areas. If the intersection between reporting area and target area is not known, SPREAD offers a facility to generate the intersection using a accurate projection. The generated products are reviewed before they are shared with other users and VREVirtual Research Environment. for e.g. inclusion in species distribution analysis, which can be either and expert-review, or a machine driven review.

Priority to CoPCommunity of Practice.

List proposed solution priority following the iMarine Board priority setting criteria:

• Identified community: Users now: The need was identified by the UNGA, and the users are in FAO-FI. In general, disaggregation is in high demand in understanding Time-Series in the agriculture and fisheries domains.

• Potential for co-funding: reasonable, if a community can be identified that requires a. dynamic intersection generation, b. statistical data disaggregation.

• Structural allocation of resources: To be discussed in a. SB, b. iMarine Board

• Referred in DoW: Not explicitly.

• Business Cases: Supports BC 1.

• How does the proposed action generally support sustainability aspects If based on OGC standards, SPREAD will be key to bringing the power of the infrastructure to a geospatial explicit data community as a product that is easy to understand (for OGC community members), brings additional resources that do not exist in geo-statistical workflows (integrated R, TS management), and offer VREVirtual Research Environment. secure collaboration.

• How consistent it is with EC regulations/strategies (eg INSPIRE, ... ): For SB

• Re-usability – benefits – compatibility High.

Parentage

Relation to CoPCommunity of Practice. Software For Emmanuel

Relation to D4S technologies For WP6

Does the proposed solution solve other problems associated with EA-CoPCommunity of Practice. Business Cases? For iMarine Board evaluation

If the proposed solution can be used in another SW scenario (not users!) please describe. For WP6

Public

How big is the expected user community after delivery? 4 persons will use SPREAD.

Productivity

Are the proposed measures effective? There are already alternatives to assess the amount of distant fishing which can serve a proxy for high-seas fisheries.

Does it reduce a known workload? No.

Price

Is the proposed solution cheap? No, it should only be pursued if the components can be re-used in other scenarios. That is for the iMarine Board to decide.

Expected effort in PM: 12

Presentation

How is the component delivered to users? (Design / on-line help / training material / support).

SPREAD is conceived to be delivered through a VREVirtual Research Environment. that starts from the ICIS (the data to re-allocate). This should provide GIS features to GIS-enable the time-series.

It also requires an user interface to select a target area to re-allocate to,

For the algorithm, machine access to the intersection layer is required.

The output are maps in xyz format that can either be stored in a geospatial database, or in the D4S WS.

These maps will have to be accessible by other VREs if the owner so decides.

Privacy

Are they safe?

There are no privacy issues of legal or physical persons involved.

Need the proposed solution to manage confidential info at data / dataset / organizational level?

Initially this is not needed.

However, every map produced can only be shared by the VREVirtual Research Environment. User that generated it in the VREVirtual Research Environment.. Only the VREVirtual Research Environment. manager can publish the generated maps to render them discoverable and visible to other VREs.

Describe security and privacy issues:

Not possible, here WP6 can contribute.

Policy

Are there any policies available that describe data access and sharing?

No, a beginning has been made in T3.2 by FAO.

Are these really needed?

Yes, the data used are often confidential, and the products convey a strong message. The output should always be validated and cleared by the data owner.

Copyright / attribution / metadata / legal

The SPREAD use case is interesting to see how policies can be developed that range from statistical data in the public domain, but attributable to FAO, with geospatial maps generated by VLIZ, with a legal information on fisheries agreements. The produced products, be they maps, images, geospatial formats or reports, will all need to propagate the ownerships, address copyright issues and contain a clear disclaimer.

Perils

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 not understand what it produces, where data come from, what they represent etc. .)

Several critical comments were made that have to be better understood before SPREAD can be fully implemented:

1. Several FI officers have doubts that the produced re-allocated maps can be distributed openly as FAO and / RFB maps. They may convey a message that goes beyond the quality of the data and the algorithm involved.
2. There is no intrinsic generic mechanism to check the statistical relevance of the products. This may lead to a product that can not be validated.
3. The quality of the source data may not be up to standards for the required processes. One important reason to develop SPREAD was indeed to identify these gaps in e.g. reliable maps of EEZ's, difficulties in generating reliable intersections, solving issues with authoritative metadata, e.g. to differentiate between country, flag, and sovereignty.