Difference between revisions of "Use Cases for EA-CoP Data Access and Sharing Policies"

Revision as of 15:11, 11 March 2013

Here follows a list of use cases for which the EA-CoP Data Access and Sharing Policies may apply.

Template for the Policy use cases

Strategy

The Strategy chapter positions the concerned Use Case in the broader context of iMarine objectives (draw a link to relevant Wiki page in case the strategy has already been defined elsewhere):

• Define the initiative and set the Goal
• Identify the benefits
• Position the role of the iMarine plaftform in respect of the concerned Use Case

Policy

The Policy chapter

• Define the properties/set of quality(*) required to achieve the specific objective
• Define the principles prevailing for the concerned use case; these principle refer to the general iMarine data sharing Policy (Disclaimer, Copyright, Posting Content, Shared Data, Public Data, Secondary Use, Derivative Work, and Data Citation) and might extend these
• Define the responsibilities of the various actors involved
• Define the type of collaborations required
• Define the kind of support required

Guidelines

The policy is extended with Guidelines:

• Metadata and models implementing the use case; this chapter includes a mapping with the business metadata
• Editorial workflow
• Roles and responsibilities in the workflow

(*) e.g. from FACP policy document: Objectivity; Reliability and timeliness; Length versus comprehensiveness; Hard copy – versus electronic format; Languages and translations; Partnerships

Code list management

Strategy

The Code list management is envisioned to be the natural extension to several existing code list management tools to offer specific functionality not yet delivered through other tools.

Codel list management in iMarine aims to deliver through Cotrix a versatile and flexible environment for the management and versioning of code lists and the provision of existing code lists repositories with quality code lists n their native format.

The product delivering the services is described here: CLM

The process to develop and implement the Cotrix components is described in a separate wiki, as this is done in collaboration with external entities without access to the iMarine wiki environment: cotrixrep

The initial role of the iMarine platform for Cotrix will be that is consumes the output of the code list manager as SDMX code lists, and provisions the code list manager with SDMX code lists where a new version is required. In later iterations, the code list manager will be brought in the imarine ecosystem, and for advanced functionality is expected to consume e-infra resources.

Policy

Specific policies for the operation of code list management are not required because:

• The properties/set of quality required to achieve the specific objective are all based on open and accessible resoureces
• The principles for code list management in the realm of Cotrix are beyond the policies offered through the e-infra and other structures. Therefore, no direct impact on CLM development is expected.
• The principles of the general iMarine data sharing Policy (Disclaimer, Copyright, Posting Content, Shared Data, Public Data, Secondary Use, Derivative Work, and Data Citation) need extending when the output of the CLM is considered. These are met by enriching the CLM products (i.e. code list with a set of well-defined metadata) on which iMarine policies can be based.
• The CLM has authentication and security components to which the enforcing of responsible use by the users is outsourced. The various actors involved in CLM are the Cotrix manager and the Cotrix users. These depends on access rights granted trhough oter systems, and maintanied by the cotrix manager to share produced code lists. However, these formally make no part of Cotrix.
• Cotrix has a specific user-group defined elsewhere.
• Users of Cotrix will need support to ingest, manage, version and share codelists. The support will mostty be provided through on-line and tool-tip texts in English. Since the WF is rather narrow, the support can be limited.

Guidelines

The policy can not yet be extended with Guidelines, as it is too early to tell how the tool will behave:

iMarine EA Linked Open Data Initiative

content to be provided by Claudio Baldassarre, Julien Barde, and Anton Ellenbroek

Strategy

The Strategy chapter positions LOD in the broader context of iMarine objectives:

• Define the initiative and set the Goal

The EA-iMarine-LOD, initiative promoted by FAO, is meant to develop the necessary capacities in the infrastructure, to instantiate a network of interlinked datasets of scientifically accurate data in the domain of EA to fisheries. The EA-iMarine-LOD is contributed in portions by the partners willing to be part in return of mutual data enrichment. Such distributed evolution paradigm fits well with the structure of network of interlinked datasets.

The goal of this initiative is to supply what providers lack: the resources, the technical expertise, or when they can’t find the proper tools. In doing so the initiative will set a plan of development for LOD engineering tools built on data access facilities. Innerly the goal of this initiative is to help to overcame the challenges of LOD engineering that is demanding and requires actions beyond the simple creation of datasets ( e.g. complex ETL workflows, and to be bound to full dataset lifecycle)

• Identify the benefits

LOD engineering and maintenance goes way beyond publishing data in RDF (e.g. as WoRMS currently does via TDWG services). LOD datasets requires to be as densely interlinked as possible innerly, and with external LOD dataset. The return on investment on good quality LOD engineering is the possibility to become part of fast growing network of datasets in the EA to fisheries domain, created by institution or even citizen scientists. On top of the network of distributed LOD datasets scenarios of interoperable systems, or integrated information retrieval environment can be engineered.

SMARTIFISH Regional Information System (RIS) This web application is one-stop-shop for users that require a comprehensive view on Fisheries in the SWIO area encompassing aspects of conservation plans, fishery gears and vessels, marine species, catches and beyond. Of the partners participating in to SMARTFISH project, none of them produces information covering the initial requirements, but together they do. An unobtrusive solution to develop a portal that publishes the integrated data from three information systems, is to define the integration outside in to a network of shared entities made globally unique and dereferenceable in the scope of the RIS. The network of relationships is defined to capture the knowledge of the domain (i.e. the SWIO fisheries), the application requirements (i.e. oriented to presentation of high level fisheries concepts), and ultimately a core of scientifically accurate data (i.e. codes and code lists). The final result is a LOD based knowledge repository used to annotate (i.e. represent) the information resources in the remote information systems, as well as harmonize the level of heterogeneity in the terminology adopted locally by the system being part of the RIS. The approach to integration achieved trough LOD, make it so that extension to data from new information system requires essentially an extension of the network of entities and relationships. Similarly an evolution of the requirements for the RIS requires an update to the LOD based knowledge repository that sits separated from the integrated information systems.

• Position the role of the iMarine plaftform in respect of the LOD

The iMarine platform, for both the VREVirtual Research Environment. and the infrastructure, plays a key role in the production and consumption of LOD inside and outside the project. The root motivation is that EA to fisheries requires the combination of data gathered from multiple contexts, and most of all these data reference each other in the same way ecosystem relates organisms. When the co-referencing is captured in a reusable and shared network of semantic computational relationships, this produces a knowledge asset which was not previously existing. More over the processes happening in the VREVirtual Research Environment. set in place additional knowledge to be publish as an extension of the EA-iMarine-LOD. As stated at the beginning there is a bootstrap phase for good quality engineering of LOD that requires expertise and software tools to process the production of linked data, and their maintenance over time. When this capabilities are delivered to the iMarine platform users, the project is in charge to instantiate the core of the EA-iMarine-LOD that is a valuable set of mapping that consolidates the interconnection through code lists of entities. This is otherwise only achievable through creation of yet another massive data container and poorly reusable for multiple application requirements, as it requires highly impacting schema refactoring, with respect to pluggable schema to accommodate requirements extension achievable with LOD based knowledge repositories. By maneuvering in this core set of mapping the project can lead activities of information systems interoperability, or information mash-up environments, data harmonization, dissemination of public URIs for content annotation at web scale. In short the key role of the iMarine platform is the mediator for iMarine partners that wants to ship their data in to the LOD cloud, and produce itself a node that is the hub to become the reference of scientifically accurate data mapping.

Policy

The Policy chapter The EA-iMarine-LOD is centered in a core of mapping relationships among the LOD datasets contributed by project partners. This definition requires a preparatory phase of LOD dataset engineering for those who do not have resources, expertise or the tools to underpin such LOD production. The configuration of the EA-iMarine-LOD components, and with respect to its core, can be described with 2 areas or data realms. In the first realm are the LOD datasets strictly produced in iMarine (e.g. WoRMS, EEZ, GIBIF, CoL etc). This is because the LOD engineering is controlled and the specifications negotiated among the people part of iMarine. The LOD datasets in the first realm are directly connected to and through the core of EA-iMarine-LOD. In the second realm are the LOD datasets produced externally to the project (e.g. AGROVOC, data.fao.org, BIO-LOD etc). This realm is an interface to the LOD cloud and is filled with interconnections instantiated from the LOD datasets in the first realm outward in the cloud. The second realm is the gateway to and from the core of EA-iMarine-LOD and the cloud allowing external communities to refer project and partners data, and as such intensifying the concentration of incoming references in to EA-iMarine-LOD.

• Define the principles prevailing for the implementation of LOD
• Define the responsibilities of the various actors involved

Accomplishing the goad of the EA-iMarine-LOD involves FAO, CNR and a data provider (i.e. the partners committed to the initiative ) FAO: is responsible for issuing the policies of participation, and coordinating the activities of design and development of the tools for LOD engineering, finally to lead the creation of the core of the EA-iMarine-LOD. CNR: is responsible for the implementation and service provider of the capabilities shipped with the tools for LOD engineering trough the infrastructure, hosting the storing facilities of the EA-iMarine-LOD and to be the main publisher of its content. The data provider: is responsible to instantiate a data access mechanism for the data to be engineered as LOD, also it will be involved in to choosing the relationships and concepts that best describe its domain, to the extent that is of interest to it. Also the data provider is responsible to provide a mechanism for persistent URIs, and to choose a publication channel for the engineered LOD dataset whether in house or through the infrastructure.

• Define the type of collaborations

FAO will be actively involved with CNR in to the bootstrap phase by proposing a design of the components to be introduced in to the infrastructure. This will include interfacing with existing data access services, as well as defining new services to access the capabilities for LOD engineering. Given the experience matured by FAO in the technologies for hosting and publishing LOD, this will be also transferred to the CNR so that the same capacity can be started on the infrastructure.

CNR will be actively involved with FAO in a second phase envisaging the implementation of the designed components, and setting up of gCube services for LOD data engineering. CNR will also provide usual support to consume gCube services for LOD engineering under the same policies for other infrastructure service.

Data providers will be collaborating with FAO and CNR to start-up the creation of the first LOD dataset, the storage and publishing, by configuring workflow of dataset creation (will be maintenance from the second iteration) using the gCube cervices for LOD engineering.

• Define the kind of support required

This initiative requires that at least the project partners that are already data providers for the VREs, or are involved to provide reference data for the processes in the VREVirtual Research Environment., are also involved in the creation of the EA-iMarine-LOD. Also the initiative needs support to realize a vision plan so that the EA-iMarine-LOD is used also outside the project by a liaison management among iMarine and other (EU) projects.

Guidelines

The policy will be extended with Guidelines:

• Metadata and models

• Editorial workflow

The editorial workflow for this initiative is instantiated by a specific configuration of execution in pipeline of gCube services for LOD engineering. The execution will process a number of transformation sequentially from the data access exposed by the data provider, and produce a LOD dataset. During this ETL process the workflow includes provenance metadata or linage metadata to inform of the executed processes, sources and target of transformations.

• Roles and responsibilities in the workflow

The committed member may want to be participative across a number of levels of involvement when creating their LOD dataset :

a. full delegation: by opening access to their repository: linked data generation and storage run in the D4S infrastructure; b. semi-delegation: by opening access to their repository: linked data generation run in the D4S infrastructure, while storage resides to the data provider; c. no delegation: when the data providers completes all the tasks in house and exposes its linked dataset to be connected to the network.

For all of the three policies of participations the data provider is guaranteed to keep the authority on the generated linked data by the technical mean of domain name authority (direct), or the metadata expression of ownership, rights holder, publication rights etc. (indirect).

Taxonomic data

WORMS data use

Strategy

The Strategy chapter positions the concerned Use Case in the broader context of iMarine objectives (draw a link to relevant Wiki page in case the strategy has already been defined elsewhere):

• Define the initiative and set the Goal
• Identify the benefits
• Position the role of the iMarine plaftform in respect of the concerned Use Case

Policy

The Policy chapter

• Define the properties/set of quality(*) required to achieve the specific objective
• Define the principles prevailing for the concerned use case; these principle refer to the general iMarine data sharing Policy (Disclaimer, Copyright, Posting Content, Shared Data, Public Data, Secondary Use, Derivative Work, and Data Citation) and might extend these
• Define the responsibilities of the various actors involved
• Define the type of collaborations required
• Define the kind of support required

Guidelines

The policy is extended with Guidelines:

• Metadata and models implementing the use case; this chapter includes a mapping with the business metadata
• Editorial workflow
• Roles and responsibilities in the workflow

Reconciliation of taxonomic data

Strategy

The Strategy chapter positions the concerned Use Case in the broader context of iMarine objectives (draw a link to relevant Wiki page in case the strategy has already been defined elsewhere):

• Define the initiative and set the Goal
• Identify the benefits
• Position the role of the iMarine plaftform in respect of the concerned Use Case

Policy

The Policy chapter

• Define the properties/set of quality(*) required to achieve the specific objective
• Define the principles prevailing for the concerned use case; these principle refer to the general iMarine data sharing Policy (Disclaimer, Copyright, Posting Content, Shared Data, Public Data, Secondary Use, Derivative Work, and Data Citation) and might extend these
• Define the responsibilities of the various actors involved
• Define the type of collaborations required
• Define the kind of support required

Guidelines

The policy is extended with Guidelines:

• Metadata and models implementing the use case; this chapter includes a mapping with the business metadata
• Editorial workflow
• Roles and responsibilities in the workflow

Applifish - FAO Species fact sheet

[AppliFish] is an iMarine mobile App based on the FAO Aquatic Species Fact sheets mashed up with information from other consortium partners (AquaMaps, Fishbase, SeaLifeBase, WoRMS, OBIS, IUCN).

It was released late December 2012, and nearly 1000 downloads were registerd as of March 1, 2013.

AppliFish was instrumental in the development of a set of default documents that may be re-used for other products.

The documents for Applifish that relate to the iMarine access and sharing policies are:

• The About page;
• The Credits page;
• The Disclaimer.

Strategy

The Strategy chapter of AppliFish concerning data access and sharing was that only open and free data are contained in the App, and that all data owners provide prior consent to the use of and context of their data in a mobile app.

The strategy for data access and sharing

• aims at informing a as wide as possible public on important marine species with publicy shared data,
• with the benefit of free information access to users that can be carried around, without any costs to the contributing organizations
• building on the iMarine platform as the orchestrator and container of data in the App.

Policy

The AppliFish Policies bring open data to a controlled Application; all content is under the control of the App manager.

• Build on the understanding that all mashed up data are open, and extracted from respectable controlled sources.
• Define the principles prevailing for the concerned use case; these principle refer to the general iMarine data sharing Policy (Disclaimer, Copyright, Posting Content, Shared Data, Public Data, Secondary Use, Derivative Work, and Data Citation) and might extend these
  • Define the responsibilities of the various actors involved
  • Define the type of collaborations required
  • Define the kind of support required

Guidelines

AppliFish, being fully controlled by FAO, requires the following guidelines for:

• Editorial workflow: Information is produced in large part by the FishFinder team, and using the Species fact sheet module, the FIGIS team ensures that the information is properly transferred to iMarine and consequently to AppliFish.
• Roles and responsibilities in the workflow: FishFinder is the responsible actor for giving clearance to the release of new information through AppliFish. OBIS, AquaMaps, and FB-SLB provided consent to use their data, IUCN public data were used, but no consent was sought.

Geospatial data and OGC Web-Services

• The geospatial data will be shared through OGC Web-Services (OWS)
  • Access to geospatial data as OGC WMSSee Workload Management System or Web Mapping Service./WFSWeb Feature Service/WCSWeb Coverage Service resources
  • Access to resources provided through ISO/IC211 - OGC metadata, served by CSW web-service with 2 access levels:
    • service metadata (ISO 19119:2005 / 19139) describing WxS instances specific to the data collection
    • dataset metadata (ISO 19115:2003 / 19139) describing each dataset
  • Such access could be completed later by Feature Catalogue description (ISO 19110), for data processing needs.
  • The set of metadata will be published in a CSW catalogue shared in i-Marine through Harvesting operation.
• A metadata constraints section will be added to the metadata, and will specify the license applicable to the data collection.
• Example: case of FAO aquatic species distributions, published through the FAO Geonetwork

Strategy

The Strategy chapter positions the concerned Use Case in the broader context of iMarine objectives (draw a link to relevant Wiki page in case the strategy has already been defined elsewhere):

• Define the initiative and set the Goal
• Identify the benefits
• Position the role of the iMarine plaftform in respect of the concerned Use Case

Policy

The Policy chapter

• Define the properties/set of quality(*) required to achieve the specific objective
• Define the principles prevailing for the concerned use case; these principle refer to the general iMarine data sharing Policy (Disclaimer, Copyright, Posting Content, Shared Data, Public Data, Secondary Use, Derivative Work, and Data Citation) and might extend these
• Define the responsibilities of the various actors involved
• Define the type of collaborations required
• Define the kind of support required

Guidelines

The policy is extended with Guidelines:

• Metadata and models implementing the use case; this chapter includes a mapping with the business metadata
• Editorial workflow
• Roles and responsibilities in the workflow

ICIS

Strategy

The Strategy chapter positions the concerned Use Case in the broader context of iMarine objectives (draw a link to relevant Wiki page in case the strategy has already been defined elsewhere):

• Define the initiative and set the Goal
• Identify the benefits
• Position the role of the iMarine plaftform in respect of the concerned Use Case

Policy

The Policy chapter

• Define the properties/set of quality(*) required to achieve the specific objective
• Define the principles prevailing for the concerned use case; these principle refer to the general iMarine data sharing Policy (Disclaimer, Copyright, Posting Content, Shared Data, Public Data, Secondary Use, Derivative Work, and Data Citation) and might extend these
• Define the responsibilities of the various actors involved
• Define the type of collaborations required
• Define the kind of support required

Guidelines

The policy is extended with Guidelines:

• Metadata and models implementing the use case; this chapter includes a mapping with the business metadata
• Editorial workflow
• Roles and responsibilities in the workflow

Species Fact Sheets

Strategy

The Strategy chapter positions the concerned Use Case in the broader context of iMarine objectives (draw a link to relevant Wiki page in case the strategy has already been defined elsewhere):

• Define the initiative and set the Goal
• Identify the benefits
• Position the role of the iMarine plaftform in respect of the concerned Use Case

Policy

The Policy chapter

• Define the properties/set of quality(*) required to achieve the specific objective
• Define the principles prevailing for the concerned use case; these principle refer to the general iMarine data sharing Policy (Disclaimer, Copyright, Posting Content, Shared Data, Public Data, Secondary Use, Derivative Work, and Data Citation) and might extend these
• Define the responsibilities of the various actors involved
• Define the type of collaborations required
• Define the kind of support required

Guidelines

The policy is extended with Guidelines:

• Metadata and models implementing the use case; this chapter includes a mapping with the business metadata
• Editorial workflow
• Roles and responsibilities in the workflow

Environmental Enrichment

Strategy

The Strategy chapter positions the concerned Use Case in the broader context of iMarine objectives (draw a link to relevant Wiki page in case the strategy has already been defined elsewhere):

• Define the initiative and set the Goal
• Identify the benefits
• Position the role of the iMarine plaftform in respect of the concerned Use Case

Policy

The Policy chapter

• Define the properties/set of quality(*) required to achieve the specific objective
• Define the principles prevailing for the concerned use case; these principle refer to the general iMarine data sharing Policy (Disclaimer, Copyright, Posting Content, Shared Data, Public Data, Secondary Use, Derivative Work, and Data Citation) and might extend these
• Define the responsibilities of the various actors involved
• Define the type of collaborations required
• Define the kind of support required

Guidelines

The policy is extended with Guidelines:

• Metadata and models implementing the use case; this chapter includes a mapping with the business metadata
• Editorial workflow
• Roles and responsibilities in the workflow

SmartFish

Content to be provided by Laurent