Use Cases for EA-CoP Data Access and Sharing Policies

From D4Science Wiki
Revision as of 19:15, 23 March 2013 by Marc.taconet (Talk | contribs) (→‎Strategy)

Jump to: navigation, search

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

Code List management is split in 2 topics to address the difference between general policies related to the principle of code list management within a community and policies related to the implementation of code list management in a tool (Cotrix). As described in the Cotrix use case below, code list manager policies are quite limited as, for instance, the policies in terms of sharing are directly linked to the user profile authorized to create/publish/disseminate code lists.

We will in this use case, we will address more general policies principles related to code list management within a community no matter which the tool is.

Strategy

Code List management is a key component when dealing with data management. It is meant to provide a central repository of quality code lists (reference data, master data) to be shared within a given community. Code list management answers several needs of the community:

  • Some code lists are authoritative to the community. These code lists are maintained and shared by the authoritative institution. Community needs to have access easily to these code lists in different formats (simple one as CSV, more complex one as SDMX). Community expects to be alerted on time when code lists are updated and get a comprehensive description of the changes.
  • Community needs to have the code list evolve to address new needs (new species caught in an area, the ASFIS needs to be updated regularly): they need to know which communication channel is opened to the institution responsible for the code list maintenance.
  • Some authoritative code lists needs to be enriched by community members as it doesn’t completely answer the needs in terms of classification. Either the code list is design to be enriched (CPC classification for instance with reserved block of codes to define the user own classification based on the CPC model) or the code list is not designed for it (Case of CWP vessel type classification, a national institution will create its own local vessel type list and map it to the CWP classification).


Policy

Code list management exposes code lists and their mapping to the community in several electronic formats. These resource are open data, there is no restriction on the use and the sharing of code list.

Code list quality is enforced with a set of comprehensive metadata describing the code list and insuring identification of source, owner, communication channel, authoritativeness and validity range. Frequency of update varies from one code list to another. Some are very stable and are update every 10 – 20 years (Gear type, vessel type), some will have a yearly version.

Given some complex distribution mechanism, these code list metadata must be strongly attached to code list data. An example of complex distribution mechanism is the following: ASFIS code list is published by FAO, collected by DG-Mare which validates changes (or not) and then distributes it the EU countries. Each national institution is then in charge of distributing code lists to their partners (local professional organizations, research institutions like IRD, eLog book software companies). At each level, a request could be sent to FAO to add new species. The communication channel to FAO/ASFIS (Owner e-mail) needs to be clearly identified for all actors and available at each level. The example above illustrates the complexity of the responsibility in the code list dissemination. Each level has its own responsibility of sharing the code list. But as soon as code list is extracted for the code list management tool, the responsibility of using and sharing the code list lies with the users neither with the code list management nor the code list owner.

Code list evolution is deeply linked to a good collaboration with code lists users. Community submits requests for item insertion to the code list.

[policy for Enrichement/mapping]


Guidelines

Code list management requires a set of business metadata that are already covered by the iMarine general policies with the 12 standard Dublin Core publication metadata. Additional metadata are required to address the specific needs expressed previously:

  • Version: a code list evolves in time and versions are issued regularly
  • Authoritativeness: there is a need to extend the DC source metadata to capture if this code list is considered as authoritative by the community. A context or scope would be sufficient (Scope of the current list is international, regional, national or local).

Code list management should comply to the general iMarine data sharing policy, especially making sure that code list metadata are associated and distributed with the code list.

Cotrix 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.

Code 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 in 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, and under the aegis of WP6, relevant elements of the code list manager will be brought in the iMarine ecosystem, and advanced functionality is expected to consume e-infra resources. Future mapping use cases are described in the code list mapping wiki page.

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 resources
  • 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 mostly 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 data access and sharing policies in the broader context of iMarine objectives:

The expected products and services are described here: Ecosystem_Approach_Community_of_Practice:_EA-LOD. To summarize:

  • 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 scientific datasets accurately interlinked within and beyond the iMarine infrastructure, with focus/core in the EA domain, and to deliver the services easing the exploitation of this network of interlinked datasets. The goal of this initiative is to overcome the challenges of the demanding task of LOD engineering and exploitation, by supplying what providers lack: the resources, and the technical expertise.

  • Identify the benefits

LOD datasets bring full fruition when 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 domain, created by institution or even citizen scientists. Scenarios of interoperable systems, integrated information retrieval environment, information mash-up environments, data harmonization, dissemination of public URIs for content annotation at web scale, can be engineered on top of the network of distributed LOD datasets, with minimum obstrusion in existing systems.

These benefits are reflected in two products developed in the context of iMarine: SmartFish Regional Information System (RIS), and IRD Tuna dynamic fact sheets.

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

The EA to fisheries and conservation of marine living resources requires the combination of data gathered from multiple contexts, and most of these data reference each other in the same way ecosystems relate organisms. When the co-referencing is captured in a consistent, reusable and shared network of semantic computational relationships, this produces a knowledge asset which didn’t use to previously exist. The key role of the iMarine platform is that of mediator for iMarine partners that want to ship their data into the LOD cloud. Because of its catalysing role for data sharing in the EA, the iMarine platform is ideally positioned to produce itself a node of EA LOD meant to become the reference hub of scientifically accurate data mapping in the EA. The production of the core set of LOD builds and extends the iMarine code lists management facility. Last but not least, the iMarine platform can offer scalability for storage and computing performance, a welcomed asset for a demanding technology in such resources.

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).

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

Species Products Discovery

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, free, global and scientifically based 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. It is thus an example of a derivative work. The policy concern when preparing the app was to ensure no copyright infringements were made, that each contributor agreed to have its data disseminated jointly with the other sources, and that the fair use was recognized and acknowledgments were included. AppliFish was built on the understanding that all mashed up data are open, and extracted from controlled and quality sources.

The principles are implemented through:

  • Disclaimer, which was developed with the assistance from the FAO Legal Office;

The following issues were debated during the compilation of the Disclaimer: - Permissions to use, re-use/re-distribute the information - Identification of the legitimate copyright holder (legal body) and consequently the contact point (although this has not legal implication) - Disclaim any liability of the data owner (e.g. in regards of country boundaries) - Full list of sources of information - Update of the disclaimer in case the list of sources vary

  • Copyright, which was derived from the FAO copyright statement;
  • Data Citation is ensured through the AppliFish credits page;
  • Posting Content is not enabled, but will become relevant in future versions.

See below the actual text for credits, disclaimer and copyright notice. A citation mechanism has not been implemented yet. A proposed text is indicated below. A CC possible license is also provided.

AppliFish was conceptualized with the following uses in mind:

  • The only actors are users interested to learn more about an aquatic species, but not for scientific or political uses;
  • For the normal usage of the tool, no specific requirements wrt collaborations are required. However, the tool evidences the loose collaboration with FIN, WoRMS, OBIS and other at data integration levels.
  • The operation of the tool requires no significant support structure. Regular updates of the tool are under the control of the developers.

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.

Source texts for Credits, Disclaimer and Copyright notice, Citation (Draft)

Credits

iMarine services help to combine data coming from different global and authoritative data providers, into informative fact sheets on over 550 marine species. AppliFish species information is built by meshing-up data from various sources:

  • FAO aquatic species fact sheets
  • AquaMaps species probability maps
  • AquaMaps species 2050 probability maps
  • Local names from Fishbase, SeaLifeBase and WoRMS
  • Links to data sources, such as OBIS, Fishbase/SeaLifeBase, FAO
  • IUCN species conservation status

The following FAO criteria were used for selecting species available in this app:

  • an annual catch exceeding 10 thousand MT
  • importance for local industry or social groups
  • commercial value
  • endangered or vulnerable species
  • importance to aquaculture
  • by-catch
  • potential future importance to fishery

www.i-marine.eu

Diclaimer and Copyright notice

AppliFish is provided "as is" without any warranties of any kind, either express or implied, including but not limited to, warranties of title or implied warranties of merchantability, accuracy, reliability or fitness for a particular purpose. The Parties to the iMarine Consortium make no warranty, either express or implied, as to the accuracy, reliability, or fitness for a particular purpose of the data disseminated through AppliFish.

The designations employed and the data assembled in this application are taken from multiple sources (FAO-FishFinder, WoRMS, Fishbase, SeaLifeBase, IUCN, Aquamaps, OBIS) and may sometimes be contradicting or overlapping. In no event shall the Parties to the iMarine Consortium be liable to you or any other person for any loss of business or profits, or for any indirect, incidental or consequential damages arising out of any use of, or inability to use, AppliFish, even if previously advised of the possibility of such damages, or for any other claim by you or any other person.

Information, text, graphics, etc. provided to you through AppliFish are provided solely as a resource and a convenience to you and do not imply the expression of any opinion whatsoever on the part of any of the Parties to the iMarine Consortium, including but not limited to the legal or development status of any country, territory, city or area or of its authorities, or concerning the delimitation of its frontiers or boundaries.

AppliFish contains copyrighted material and/or other proprietary information and thus, is protected by copyright laws and regulations worldwide. Use of any material copied from AppliFish is restricted to informational, non-commercial or personal use only; no modifications to the information are permitted and the source of information must be fully acknowledged; all references to AppliFish data must mention the iMarine name and URL and specify the AppliFish version number. Use for any other purpose is expressly prohibited without written permission of the copyright holders. To obtain this permission, iMarine may assist in identifying and contacting the legal owner. Permissions to use the information provided by AppliFish must be made in writing to the Chief, Fisheries Statistics and Information Service, FAO, Viale delle Terme di Caracalla, 00153 Rome, Italy; or by e- mail to FI-Inquiries@fao.org.

Citation - DRAFT

Here follows a possible example of Species fact sheet citation:

© FAO, 2013. AppliFish. Albacore. In: iMarine (Data e-InfrastructureAn operational combination of digital technologies (hardware and software), resources (data and services), communications (protocols, access rights and networks), and the people and organizational structures needed to support research efforts and collaboration in the large. Initiative for Fisheries Management and Conservation of Marine Living Resources) [online]. Updated 12 march 2013. [Cited 14 March 2013]. http://www.i-marine.eu/AppliFish/ .See "Disclaimer and Copyright Notice" for the whole list of contributors to AppliFish".

CC License - Proposal

Attribution-NonCommercial-NoDerivs 3.0 Unported

AppliFish by iMarine is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. Permissions beyond the scope of this license may be available at http://www.i-marine.eu/AppliFish/Disclamer.aspx.

Geospatial data and OGC Web-Services

Strategy

The Strategy chapter positions the geospatial data access and sharing policies in the broader context of iMarine objectives.

An alternative title of this Policy use case is "iMarine Geospatial data discovery, access and sharing Policy". This Policy Use case has been initially mainly promoted by IRD and FAO through the Geospatial cluster. The products intended to be shared with and discoverable through the infrastructure are summarized here: Geospatial Cluster - Data Sources. To summarize:

  • Define the initiative and set the Goal

The sharing and discovery of geospatial data products, is aimed to:
1. instantiate a catalogue of relevant and well-described GIS data coming from organizational Spatial data infrastructures, for access within and beyond the i-Marine web portal, with focus on marine and fishery domain
2. deliver the services to properly discover, access and process the data made available through the catalogue

The goal is to lead to MoUs on the description, access and sharing of GIS products, whether shared with or produced within the infrastructure, in close connection with initiatives such as the Open Geospatial Consortium and the EU INSPIRE directive

  • Identify the benefits

The main benefits of the iMarine Geospatial data discovery, access and sharing Policy are as follows:

- take advantages of the existing standard methodologies in term of data description & cataloguing, and underlying implementation solutions to facilitate the discovery and access to geospatial data sources published through their respective infrastructures, thus ensuring access to most up-to-date geospatial information from data owners.

- provide users with quality metadata that guarantee a suitable use

- ensure the retrieval, confrontation and processability of all geospatial data in a common and standard way

  • Position the role of the iMarine plaftform in respect of the concerned Use Case

The role of the iMarine plateform is to ensure that both external data shared with the infrastructure, and i-Marine products themselves, are well-described, sharable, accessible and processable and in a common and internationally-recognized standard fashion. Thanks to its transformation and derivative products services, iMarine should also contribute to the generation and publication of Geospatial datasets compliant with the INSPIRE directive. For such paper, iMarine has to assist data providers that want to share their data within the iMarine, facilitated by guidelines and appropriate services. At this stage of the Policy use case development, one important challenge and key role for the i-Marine plateform would be to ensure that geospatial data are searchable based on thematic domain categories (e.g. species distribution products, species occurence products).

Policy

  • Properties

The properties required to achieve a suitable GIS data sharing are as follows:
1. updateness: ensure that the data and related metadata are updated on a regular basis, and that the iMarine plateform is supplied with the update data
2. metadata discoverability: ensure that the descriptive metadata is annotated with the relevant information in order to be efficiently discovered, and that the discoverability is operational.
3. metadata completeness: ensure that the descriptive metadata is enought documented to be scientifically accurate, therefore in order to inform sufficiently the targets users on the data content, the methodology / protocol followed to obtain it, and their potential fields of use for derivative works
4. data accessibility: ensure that the online resources provided by the metadata, or the services themselves, are active and operational to deliever suitable and validated datasets.

  • Principles prevailing for the geospatial data sharing

All GIS datasets shared with the iMarine plateform are by principle open data. The principles are implemented through:
1. Disclaimer: is appended to the metadata by the data owner/provider if it deems necessary
2. Copyright: is appended to the metadata by the data owner/provider
3. Data Citation: is appended to the metadata by the data owner/provider. The citation should be mentioned in ways (i) using the Citation form inherent to the metadata standard being implemented, (ii) using a textual bibliographic form.

  • Responsabilities of the various actors

The fulfillment of the above properties and principles is under the main responsability of the data owner and provider. The metadata discoverability has to be ensured by both data provider and the iMarine data catalogue manager.

  • types of collaborations required:

A collaboration between the data provider and LOD managers can be required, with the objective to use LOD services to annotate in a suitable way the metadata, in order to guarantee their discoverability. As an application, such collaboration was done in FAO with the Fishery Linked Open Data for sharing the FAO aquatic species distributions.

  • The data sharing operation requires the support of an iMarine technical working group to interact with the data provider, for giving data sharing recommendations, and ensuring the data sharings are operational.

Guidelines

The policy is extended with Guidelines:

  • The following page gives the technical publishing guidelines for GIS data & services providers: Publishing guidelines for GIS Data and Services providers
  • Editorial workflow: The GIS products shared within the iMarine are produced, maintained by the data provider (including if the data provider is the iMarine plateform itself), ensuring that each GIS data collection, dataset and/or related service is properly described and discovered by iMarine through the data catalogue. If substantial changes are applied to the data description and/or access, the data provider should inform the iMarine Geospatial Technical working group.
  • Roles and responsibilities in the workflow: In addition of the data maintainer role, the data provider has the role of expressing initially their willingness to share (and promote) their data with the iMarine plateform. This action should be done by informing the iMarine geospatial technical working group, that will first analyse whether the data and/or services intended to be shared fulfill sufficient conditions for enabling the sharing, mainly established by guidelines. If the conditions are sufficient, it will therefore instantiate the sharing with the i-Marine catalogue. Where applicable, the technical working group should give recommendations to the candidate data provider.

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 VREVirtual Research Environment.

Strategy

The Strategy governing the FishFinderVRE product are described here

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 platform 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

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

SPREAD

Strategy

The SPREAD product and links to background documents are available here.

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
Retrieved from "https://wiki.d4science.org/index.php?title=Use_Cases_for_EA-CoP_Data_Access_and_Sharing_Policies&oldid=11635"