Use Cases for EA-CoP Data Access and Sharing Policies

From D4Science Wiki
Revision as of 16:59, 14 March 2013 by Aureliano.gentile (Talk | contribs) (→‎Applifish - FAO Species fact sheet)

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

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

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;
    • 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.

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.

Applifish Credits, Disclaimer and Copyright notice

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.

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

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

Retrieved from "https://wiki.d4science.org/index.php?title=Use_Cases_for_EA-CoP_Data_Access_and_Sharing_Policies&oldid=11046"