Difference between revisions of "Journal:Development and governance of FAIR thresholds for a data federation"
Shawndouglas (talk | contribs) (Saving and adding more.) |
Shawndouglas (talk | contribs) (Saving and adding more.) |
||
Line 132: | Line 132: | ||
! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" |End-status | ! style="background-color:#e2e2e2; padding-left:10px; padding-right:10px;" |End-status | ||
|- | |- | ||
| style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |''Findable'' | | style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |''Findable''<br /> <br /> | ||
|- | |- | ||
| style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |'''Q1. The data product has been assigned (an) identifier(s).''' | | style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |'''Q1. The data product has been assigned (an) identifier(s).''' | ||
Line 202: | Line 202: | ||
| style="background-color:#b6b6b6; padding-left:10px; padding-right:10px;" |SH, SMN-1, FT, WT, NS, SLG, SMN-2 | | style="background-color:#b6b6b6; padding-left:10px; padding-right:10px;" |SH, SMN-1, FT, WT, NS, SLG, SMN-2 | ||
|- | |- | ||
| style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |''Accessible'' | | style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |''Accessible''<br /> <br /> | ||
|- | |- | ||
| style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |'''Q5. How accessible is the data? The access method(s) must be explicitly stated in the metadata record e.g., if any authentication is needed, or there are any restrictions to access.''' | | style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |'''Q5. How accessible is the data? The access method(s) must be explicitly stated in the metadata record e.g., if any authentication is needed, or there are any restrictions to access.''' | ||
|- | |- | ||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Not accessible | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |SH, SMN-1 | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" | | | style="background-color:white; padding-left:10px; padding-right:10px;" | | ||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Access to metadata only | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" | | | style="background-color:white; padding-left:10px; padding-right:10px;" | | ||
| style="background-color:white; padding-left:10px; padding-right:10px;" | | | style="background-color:white; padding-left:10px; padding-right:10px;" | | ||
|- | |- | ||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Through unspecified access conditions e.g., "contact the data custodian to discuss access" | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |NS, FT, SMN-2 | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |SMN-2 | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Embargoed access after a specified date; or a de-identified version of the data is publicly accessible | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" | | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" | | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Fully accessible public, or to persons who meet and follow explicitly stated conditions and processes, e.g., ethics approval for sensitive data | |||
| style="background-color:#b6b6b6; padding-left:10px; padding-right:10px;" |WT, SLG | |||
| style="background-color:#b6b6b6; padding-left:10px; padding-right:10px;" |SH, SMN-1, NS, FT, WT, SLG | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |'''Q6. Data are available for reuse via a standardized communication protocol, such as file download over https, or a web service.''' | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |No access to data | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |SH, SMN-1, FT | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" | | | style="background-color:white; padding-left:10px; padding-right:10px;" | | ||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |By individual arrangement | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |SMN-2 | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |SMN-2 | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |File download online | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |WT, SLG (partial) | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" | | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Non-standard web service (e.g., OpenAPI/Swagger/informal API) | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" | | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |WT, FT | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Standard web service API (e.g., OGC) | |||
| style="background-color:#b6b6b6; padding-left:10px; padding-right:10px;" |NS, SLG (partial) | |||
| style="background-color:#b6b6b6; padding-left:10px; padding-right:10px;" |SH, SMN-1, NS, SLG (full) | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |'''Q7. The repository/registry agrees to maintain the persistence of the metadata record, even if the data product is no longer available.''' | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |No, or not applicable if no metadata record | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |SH, SMN-1, FT | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" | | | style="background-color:white; padding-left:10px; padding-right:10px;" | | ||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Unsure | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |WT | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" | | | style="background-color:white; padding-left:10px; padding-right:10px;" | | ||
|- | |- | ||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Yes | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |NS, SLG, SMN-2 | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |SH, SMN-1, NS, SLG, FT, SMN-2, WT | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |''Interoperable''<br /> <br /> | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |'''Q8. The data products are available in (an) open (file) format(s).''' | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Data are mostly available only in a proprietary format | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |WT, FT | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" | | | style="background-color:white; padding-left:10px; padding-right:10px;" | | ||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Data are available in an open format | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |SH, SMN-1 | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" | | | style="background-color:white; padding-left:10px; padding-right:10px;" | | ||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Data are available in an open, documented, widely used standard format (e.g., NetCDF, CSV, JSON, XML) | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |NS, SLG, SMN-2 | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |SH, SMN-1, WT, NS, SLG, FT, SMN-2 | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |'''Q9. The data is machine-readable.<sup>2</sup>''' | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |The data are unstructured | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |SMN-1, WT, FT | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" | | | style="background-color:white; padding-left:10px; padding-right:10px;" | | ||
|- | |- | ||
| style="background-color:white; padding-left:10px; padding-right:10px;" |The data are structured and machine-readable (e.g., CSV, JSON, XML, RDF, database files) | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |SH, NS, SLG, SMN-2 | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |SH, SMN-1, WT, NS, SLG, FT, SMN-2 | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |'''Q10. The data are semantically interoperable, because they use standard, accessible ontologies and/or vocabularies to describe the data elements/variables.''' | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Data elements are not described (i.e., fields or objects are labelled with codes or not at all) | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |SMN-2 | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" | | | style="background-color:white; padding-left:10px; padding-right:10px;" | | ||
| style="background-color:white; padding-left:10px; padding-right:10px;" | | |- | ||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Data elements are described (so that a human user can correctly interpret the data), but no standards have been used in the description | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |SH, SMN-1, WT, FT | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |SMN-2 | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Recognized standards have been used in the description of data elements, but no published vocabularies with resolvable URIs | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |NS, SLG | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |SLG, FT | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Published vocabularies using resolvable global identifiers linking to explanations are used, so that the data can be read and understood by machines as well as humans | |||
| style="background-color:#b6b6b6; padding-left:10px; padding-right:10px;" | | |||
| style="background-color:#b6b6b6; padding-left:10px; padding-right:10px;" |SH, SMN-1, NS, WT | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |'''Q11. The relationships to other data and resources (e.g., related datasets, services, publications, grants, etc.) are described in the metadata or data, to provide context around the data.''' | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |There are no links to other metadata or data | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |SH, SMN-1, FT, SMN-2 | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |SMN-2 | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |The metadata record includes URI links to related metadata, data, and definitions | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |WT, NS | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |NS | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Qualified links to other resources are recorded in a machine-readable format, e.g., a linked data format such as RDF | |||
| style="background-color:#b6b6b6; padding-left:10px; padding-right:10px;" |SLG | |||
| style="background-color:#b6b6b6; padding-left:10px; padding-right:10px;" |SH, SMN-1, WT, SLG, FT | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |''Reusable''<br /> <br /> | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |'''Q12. Machine-readable data licenses are assigned to each data product and are stated in the metadata record.''' | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |No license applied | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |SH, SMN-1, FT, SMN-2 | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |FT (standard license but not in metadata record) | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Non-standard license applied, with a machine-readable license/license deed URL | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |WT | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" | | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Standard license applied, without a machine-readable license deed URL | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" | | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" | | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Standard license applied, with a machine-readable license/license deed URL | |||
| style="background-color:#b6b6b6; padding-left:10px; padding-right:10px;" |NS, SLG | |||
| style="background-color:#b6b6b6; padding-left:10px; padding-right:10px;" |SH, SMN-1, WT, NS, SLG, SMN-2 | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |'''Q13. The provenance of the data product is described in the metadata i.e., project objectives, data generation/collection (including from external sources) and processing workflows.''' | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |None recorded | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |SH, FT, SMN-2 | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |FT | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Partially recorded | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |SMN-1, WT | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |SMN-2 | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Comprehensively recorded in a text format (e.g., TXT or PDF) | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |NS, SLG | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |WT, NS, SLG | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Comprehensively recorded in a machine-readable format (e.g., in metadata record’s schema or PROV, or in RDF, JSON, NetCDF, or XML) | |||
| style="background-color:#b6b6b6; padding-left:10px; padding-right:10px;" | | |||
| style="background-color:#b6b6b6; padding-left:10px; padding-right:10px;" |SH, SMN-1 | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" colspan="3" |'''Q14. The preferred citation for the data product is provided in metadata record.''' | |||
|- | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |No | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" |SH, FT, SMN-1 | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" | | | style="background-color:white; padding-left:10px; padding-right:10px;" | | ||
|- | |- | ||
| style="background-color:white; padding-left:10px; padding-right:10px;" |Citation but with no persistent identifiers | |||
| style="background-color:white; padding-left:10px; padding-right:10px;" | | | style="background-color:white; padding-left:10px; padding-right:10px;" | | ||
| style="background-color:white; padding-left:10px; padding-right:10px;" | | | style="background-color:white; padding-left:10px; padding-right:10px;" | | ||
| style="background-color:white; padding-left:10px; padding-right:10px;" | | |- | ||
|- | | style="background-color:white; padding-left:10px; padding-right:10px;" |Citation with persistent identifiers | ||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |WT, NS, SLG, SMN-2 | |||
| style="background-color:#e7e6e6; padding-left:10px; padding-right:10px;" |SH, SMN-1. WT, NS, SLG, FT, SMN-2 | |||
|- | |||
|} | |} | ||
|} | |} |
Revision as of 18:04, 10 June 2022
Full article title | Development and governance of FAIR thresholds for a data federation |
---|---|
Journal | Data Science Journal |
Author(s) | Wong, Megan; Levett, Kerry; Lee, Ashlin; Box, Paul; Simons, Bruce; David, Rakesh; MacLeod, Andrew; Taylor, Nicolas; Schneider, Derek; Thompson, Helen |
Author affiliation(s) | Federation University, Australian Research Data Commons, Commonwealth Scientific and Industrial Research Organisation, University of Adelaide, The University of Western Australia, University of New England |
Primary contact | Email: mr dot wong at federation dot edu dot au |
Year published | 2022 |
Volume and issue | 21(1) |
Article # | 13 |
DOI | 10.5334/dsj-2022-013 |
ISSN | 1683-1470 |
Distribution license | Creative Commons Attribution 4.0 International |
Website | https://datascience.codata.org/articles/10.5334/dsj-2022-013/ |
Download | https://datascience.codata.org/articles/10.5334/dsj-2022-013/galley/1138/download/ (PDF) |
This article should be considered a work in progress and incomplete. Consider this article incomplete until this notice is removed. |
Abstract
The FAIR (findable, accessible, interoperable, and re-usable) principles and practice recommendations provide high-level guidance and recommendations that are not research-domain specific in nature. There remains a gap in practice at the data provider and domain scientist level, demonstrating how the FAIR principles can be applied beyond a set of generalist guidelines to meet the needs of a specific domain community.
We present our insights developing FAIR thresholds in a domain-specific context for self-governance by a community (in this case, agricultural research). "Minimum thresholds" for FAIR data are required to align expectations for data delivered from providers’ distributed data stores through a community-governed federation (the Agricultural Research Federation, AgReFed).
Data providers were supported to make data holdings more FAIR. There was a range of different FAIR starting points, organizational goals, and end user needs, solutions, and capabilities. This informed the distilling of a set of FAIR criteria ranging from "Minimum thresholds" to "Stretch targets." These were operationalized through consensus into a framework for governance and implementation by the agricultural research domain community.
Improving the FAIR maturity of data took resourcing and incentive to do so, highlighting the challenge for data federations to generate value whilst reducing costs of participation. Our experience showed a role for supporting collective advocacy, relationship brokering, tailored support, and low-bar tooling access, particularly across the areas of data structure, access, and semantics that were challenging to domain researchers. Active democratic participation supported by a governance framework like AgReFed’s will ensure participants have a say in how federations can deliver individual and collective benefits for members.
Keywords: agriculture, AgReFed, FAIR data, community, governance, RM-ODP, data federation
Context and contribution
The agriculture data landscape is complex, comprising of a range of data types, standards, repositories, stakeholder needs, and commercial interests, creating data silos and potential "lock-ins" for consumers. (Kenney, Serhan & Trystram 2020; Ingram et al. 2022) There is an urgent need to work toward clear, ethical, efficient agricultural data sharing practices (Jakku et al. 2019; Wiseman & Sanderson 2018) that incorporate improvements to discoverability, accessibility, interoperability, and quality of data across the value chain. (Barry et al. 2017; Perrett et al. 2017; Sanderson, Reeson & Box 2017) A priority stakeholder question across the agri-tech sector is "how do we create systems whereby people feel confident in entering and sharing data, and in turn how do we create systems to govern data for the benefit of all?" (Ingram et al. 2022: 6)
Agricultural data stakeholders span the public and private sector, including farmers, traders, researchers, universities, consultants, and consumers. Their varied needs around data type, trustworthiness, timeliness, availability, and accuracy shape the many data capture, storage, delivery, and value-add products emerging across the public and private sector. (Allemang & Bobbin 2016; Kenney, Serhan & Trystram 2020) Data providers require confidence in data infrastructure governance before they share their data, in turn requiring ethics of ownership, access, and control. Strong value propositions are also key. This helps grow participants via a "network effect," increasing infrastructure value further. (Chiles et al. 2021; Ingram et al. 2022; Sanderson, Reeson & Box 2017)
Offerings of the many data infrastructures vary and may include a means for:
- depositing data for persistence, citation, publisher, and funding requirements (Datacite, 2022);
- increasing collaborative opportunities;
- enhancing regulatory compliance;
- improving on-farm operations;
- leveraging standardization, quality assurance, and quality control pipelines and specialist analysis capacity (Harper et al. 2018; Wicquart et al. 2022);
- running simulations through virtual research environments (VREs) (Knapen el al. 2020);
- performing cross-domain data integration (Kruseman el al. 2020); and
- linking data and models to knowledge products and decision support tooling (Antle et al. 2017).
If the goal is to make data trusted, discoverable, and re-usable across the sector (Peason et al. 2021; Ernst & Young 2019), then a single platform is unlikely to meet all (public, private, commercial) needs. (Pearson et al. 2021; Ingram et al. 2022) Sector concerns include among others vendor lock-ins and a tendency towards stifling innovation. (Ingram et al. 2022) As such, a grand challenge is found in how data can be discovered and made interoperable among so many different databases and infrastructures. One solution is a decentralized federated approach where there is no single master data repository or registry (Harper et al. 2018) but rather a network of independent databases and infrastructures that can deliver data through a shared platform using standard transfer protocols via application programming interface (API). The data still remains with providers, as can access controls.
Preferring a single front-end source of data, as found in data federation, is not novel, and many of the FAIR (findable, accessible, interoperable, and re-usable) principles (Wilkinson et al. 2016) underpin data federations’ functions. Some examples include the Earth System Grid Federation (Petrie et al. 2021), materials science data discovery (Plante et al. 2021), and OneGeology (One Geology 2020). In the case of agriculture, there is the AgDataCommons (USDA 2021), the proposed U.K. Food Data Trust (Pearson et al. 2021), AgINFRA (Drakos et al. 2015), and CGIAR Platform for Big Data In Agriculture. (CGIAR 2021) Many of these data federation initiatives specify standards for the description and exchange of data, focusing on a particular data type of provider and/or providing a central intermediate space to standardize data. However, we believe agriculture requires a different approach given the diversity of data stores, one that addresses the ways data is structured, described, and delivered; differences in organizational and research requirements and norms; and economic, trust, and intellectual property concerns connected to agricultural data in general.
Since 2018, we have piloted a community-governed federation approach via the Agricultural Research Federation (AgReFed). (Box et al. 2019a) Participants provisioned their data holdings from their own choice of data repository aligned to their organization's capabilities and requirements of their research field. Concurrently, they aligned with collective expectations for FAIR data. This required developing acceptable levels of FAIR data to be implemented and governed by AgReFed participants. Current practices adopt FAIR as a high-level set of guiding principles (Wilkinson et al. 2016) or a set of generalist practice recommendations. (Bahim et al. 2020) This case study addressed this gap in an agricultural-specific implementation of FAIR in practice. As part of this study, we co-developed FAIR threshold criteria for participants to deliver data through a federation, and, through a consensus process, we integrated these FAIR thresholds into a framework for ongoing governance by a research domain community, for generating individual and collective benefit and growth of a data federation.
Use cases
The datasets of the pilot included point observations, as well as spatial, temporal, on-ground, sensor, and remote sensed data. The data described plants (yield, crop rotation, metabolomic, proteomic, hyperspectral), soil, and climatic variables from across Australia (Table 1).
|
The data providers defined a set of research use cases for the data in Table 1 (MacLeod et al. 2020: 29–31), identifying the current and anticipated data users and their ideal user experience. We then identified the requirements of the AgReFed platform, the data and metadata needed to deliver the use cases, and the FAIR principles that supported these requirements. These requirements are:
- Allow the datasets and the services delivering the data to be discovered through metadata. Ideally the ability to discover should be persistent and through multiple avenues (Findable Q1, Q2, and Q3, and Accessible Q4 and Q7; Table 2).
- Support appropriate data reuse and access controlled from the providers’ infrastructure through licensing, data access controls, and attribution (Accessible Q5 and Q6, and Reusable Q12 and Q14; Table 2).
- Allow the data to be queried on user-defined parameters, including temporal and spatial properties, what is being measured (e.g., "wheat," "water"), the observed property being measured, the result, the procedure used to obtain the result, and the units of measurement (Interoperable Q9 and Q10, and Accessible Q6; Table 2).
- Allow a subset of the data to be visualized through the platform and downloaded in a useable format (e.g., .csv). This requires a web service interface (Accessible Q6 and Interoperable Q8 and Q9; Table 2).
- Allow the combining of data from different datasets (Interoperable Q8 and Q9; Table 2). This requires the ability to map terms in the data to external vocabularies and semantics (e.g., replacing local descriptive terms with published controlled vocabulary concepts, such as "m" or "meter" with "http://qudt.org/vocab/unit/M") (Interoperable Q10; Table 2).
- Allow locality to be interoperable between datasets (e.g., latitude and longitude with coordinate reference system) (Interoperable Q9 and Q10; Table 2).
|
References
Notes
This presentation is faithful to the original, with only a few minor changes to presentation, grammar, and punctuation. In some cases important information was missing from the references, and that information was added.