1. 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 (; ). There is an urgent need to work toward clear, ethical, efficient agricultural data sharing practices (; ) with improvements to discoverability, accessibility, interoperability, and quality of data across the value chain (; ; ). 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 to create systems to govern data for the benefit of all?’ ().

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 (; ). Data providers require confidence in data infrastructure governance before they share their data including ethics of ownership, access, and control. Strong value propositions are also key. This helps grow participants via a ‘network effect’ increasing infrastructure value further (; ; ).

Offerings of the many data infrastructures vary and include data deposition for persistence, citation, publisher and funding requirements (see ); increasing collaborative opportunities; regulatory compliance; on-farm operations; leveraging standardisation, quality assurance and quality control pipelines and specialist analysis capacity (e.g., ; ); running simulations through Virtual Research Environments (); cross domain data integration () and linking data and models to knowledge products and decision support tooling ().

If the goal is to make data trusted, discoverable, and re-usable across the sector (Peason et al. 2021; ) then a single platform is unlikely to meet all (public, private, commercial) needs (; ). Sector concerns include lock-ins and stifling innovation (). So, a grand challenge is how can data be discovered and interoperate between so many different databases and infrastructures? One solution is a decentralised federated approach where there is no single master data repository or registry (). Instead, a network of independent databases and infrastructures can deliver data through a shared platform using standard transfer protocols (via Application Programming Interface, API). The data remains with providers, as can the access controls.

Data federation is not novel, and many of the FAIR principles () underpin data federations’ functions. Some examples include Earth System Grid Federation (), materials science data discovery (), and OneGeology (). In agriculture, there is AgDataCommons (), proposed UK Food ‘Data Trust’ (), AgINFRA (), and CGIAR Platform for Big Data In Agriculture (). Many of these data federation initiatives specify standards for description and exchange of data, focus on a particular data type of provider and/or provide a central intermediate space to standardise data. We believe agriculture required a different approach given the diversity of data stores including ways data is structured, described, and delivered; differences in organisational and research requirements and norms; and economic, trust and Intellectual Property concerns connected to agricultural data in general.

From 2018 we piloted a community-governed federation approach (the Agricultural Research Federation, AgReFed) (). Participants provisioned their data holdings from their own choice of data repository aligned to their organisation’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 high-level guiding principles () or generalist practice recommendations (). This case study addressed this gap in an agricultural-specific implementation of FAIR in practice. We:

  1. co-developed FAIR threshold criteria for participants to deliver data through a federation
  2. though a consensus process 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

2. The Use Cases

The datasets of the pilot included point observations, 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).

Table 1

The data providers and their data products.


IN-TEXT ABBREVIATIONDATA PRODUCTS’ NAMEDATA PRODUCT TYPEDATA PROVIDER TO AGREFED (* INDICATES BOTH DATA PROVIDER AND USER OF THE DATASET OR COLLECTION)

SH (Soil Health)Corangamite Soil Health Monitoring Program Data https://doi.org/10.25955/5c1c6b8f4d8d2 ()Dataset and serviceFederation University, Centre for eResearch and Innovation (CeRDI).

SMN-1 (Soil Moisture Network 1)Soil moisture probe network, SFS (Southern Farming Systems https://doi.org/10.25955/5cdcff6168a76 ()DatasetFederation University, CeRDI.

WT (Wheat Trials)Waite Permanent Rotation Trial https://doi.org/10.4225/08/55E5165EC0D29 ()Dataset*University of Adelaide, School of Agriculture, Food and Wine

NS (NatSoils)Soil SITES database (NatSoil) https://doi.org/10.25919/5c36d77a6299c ()Dataset and serviceCommonwealth Scientific and Industrial Research Organisation (CSIRO)

SLG (Soil and Landscape Grid)Soil and Landscape Grid National Soil Attribute Maps (3” resolution), Release 1 Collection. Sample see Rossel et al. () https://doi.org/10.4225/08/546ED604ADD8A Data product (maps), collection and serviceCSIRO

FT (Frost Trials)Crop Variety Frost Trial data collections https://doi.org/10.26182/5cedf001186f3 ()Dataset collection*University of Western Australia (UWA) and Department of Primary Industries and Regional Development (DPIRD)

SMN-2 (Soil Moisture Network 2)SensorNets – SMART Farms Soil Moisture Network https://doi.org/10.4226/95/5b10d5ca18aef ()Dataset*University of New England (UNE)

The data providers defined a set of research use cases for the data in Table 1 (see ), identifying the current and anticipated data users and their ideal user experience. We then identified the requirements of the AgReFed platform and the (meta)data needed to deliver the use cases, and the FAIR principles that supported these requirements as follows:

  • 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, Q3 and Accessible Q4 and Q7, Table 2).
  • Support appropriate data reuse and access controlled from the providers’ infrastructure through licencing, 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 visualised 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). 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 ‘metre’ with ‘http://qudt.org/vocab/unit/M’) (Interoperable Q10, Table 2).
  • Allow locality to be interoperable between datasets (for example latitude and longitude with coordinate reference system) (Interoperable Q9 and Q10, Table 2).

Data collection and service records need to be discoverable through the federation’s platform (). AgReFed currently harvests from Research Data Australia (). Therefore, it is an additional requirement that minimum metadata is entered into or harvestable by Research Data Australia ().

Table 2

AgReFed Version 1 FAIR thresholds for participation ().


START-STATUSEND-STATUS

FINDABLE

Q1. The data product has been assigned (an) identifier(s)

No identifierFT

Local identifier

Web address (URL)SH, SMN-1

Globally unique, citable, and persistent identifier (e.g., DOI, PURL, or Handle)WT, NS, SLG, SMN-2SH, SMN-1, WT, NS, SLG, FT, SMN-2

Q2. The data product identifier is included in all metadata records/files describing the data

NoSH, SMN-1, FT, SMN-2

YesWT, NS, SLGSH, SMN-1, WT, NS, SLG, FT, SMN-2

Q3. The data product is described by a metadata record

Not describedSH, SMN-1, FT

Brief title and descriptionSMN-2

Brief title, description, and other fieldsWT, NS

Comprehensively1 in a formal metadata schemaSLGSH, SMN-1, WT, NS, SLG. FT, SMN-2

Q4. The data product is described by a metadata record that is indexed in a searchable registry or repository.

Not indexedSH, SMN-1, FT

Local institutional repository

Domain specific repository

Generalist public repository

Discoverable through several places (i.e., other registries, Research Data Australia, Google Data Search)WT, NS, SLG, SMN-2SH, SMN-1, FT, WT, NS, SLG, SMN-2

ACCESSIBLE

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.

Not accessibleSH, SMN-1

Access to metadata only

Through unspecified access conditions e.g., ‘contact the data custodian to discuss access’NS, FT, SMN-2SMN-2

Embargoed access after a specified date; or a de identified version of the data is publicly accessible

Fully accessible public, or to persons who meet and follow explicitly stated conditions and processes, e.g., ethics approval for sensitive dataWT, SLGSH, SMN-1, NS, FT, WT, SLG,

Q6. Data are available for reuse via a standardised communication protocol, such as file download over https, or a web service

No access to dataSH, SMN-1, FT

By individual arrangementSMN-2SMN-2

File download onlineWT, SLG (partial)

Non-standard web service (e.g., OpenAPI/Swagger/informal API)WT, FT

Standard web service API (e.g., OGC)NS, SLG (partial)SH, SMN-1, NS, SLG (full)

Q7. The repository/registry agrees to maintain the persistence of the metadata record, even if the data product is no longer available

No, or not applicable if no metadata recordSH, SMN-1, FT

UnsureWT

YesNS, SLG, SMN-2SH, SMN-1, NS, SLG, FT, SMN-2, WT

INTEROPERABLE

Q8. The data products are available in (an) open (file) format(s)

Data are mostly available only in a proprietary formatWT, FT

Data are available in an open formatSH, SMN-1

Data are available in an open, documented, widely used standard format (e.g., NetCDF, CSV, JSON, XML)NS, SLG, SMN-2SH, SMN-1, WT, NS, SLG, FT, SMN-2

Q9. The data is machine-readable2

The data are unstructuredSMN-1, WT, FT

The data are structured and machine-readable (e.g., csv, JSON, XML, RDF, database files)SH, NS, SLG, SMN-2SH, SMN-1, WT, NS, SLG, FT, SMN-2

Q10. The data are semantically interoperable, because they use standard, accessible ontologies and/or vocabularies to describe the data elements/variables.

Data elements are not described (i.e., fields or objects are labelled with codes or not at all)SMN-2

Data elements are described (so that a human user can correctly interpret the data), but no standards have been used in the descriptionSH, SMN-1, WT, FTSMN-2

Recognised standards have been used in the description of data elements, but no published vocabularies with resolvable URIsNS, SLGSLG, FT

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.SH, SMN-1, NS, WT

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

There are no links to other metadata or dataSH, SMN-1, FT, SMN-2SMN-2

The metadata record includes URI links to related metadata, data, and definitionsWT, NSNS

Qualified links to other resources are recorded in a machine-readable format, e.g., a linked data format such as RDFSLGSH, SMN-1, WT, SLG, FT

Reusable

Q12. Machine-readable data licenses are assigned to each data product, and are stated in the metadata record

No licence appliedSH, SMN-1, FT, SMN-2FT (standard licence but not in metadata record)

Non-standard license applied, with a machine-readable license/license deed URLWT

Standard license applied, without a machine-readable license deed URL

Standard license applied, with a machine-readable license/license deed URLNS, SLGSH, SMN-1, WT, NS, SLG, SMN-2

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.

None recordedSH, FT, SMN-2FT

Partially recordedSMN-1, WTSMN-2

Comprehensively recorded in a text format (e.g., TXT or PDF)NS, SLGWT, NS, SLG

Comprehensively recorded in a machine-readable format (e.g., in metadata record’s schema or PROV, or in RDF, JSON, NetCDF, or XML)SH, SMN-1

Q14. The preferred citation for the data product is provided in metadata record

NoSH, FT, SMN-1

Citation but with no persistent identifiers

Citation with persistent identifiersWT, NS, SLG, SMN-2SH, SMN-1. WT, NS, SLG, FT, SMN-2

Light grey indicates the AgReFed minimum acceptable requirements (‘Minimum thresholds’) and dark grey the ideal (‘Stretch targets’). The start-status and end-status indicate the progression of FAIR maturity. Data products are SH Soil Health; SMN-1 Soil Moisture Network 1; WT Wheat Trials; NS NatSoils; SLG Soil Landscape Grid; FT Frost Trials; SMN-2 Soil Moisture Network 2. 1 The minimum metadata requirement for data collections and services (). 2 ‘Machine-readable’ defined in terms of both syntax and structure, that is, as the representation of data products in a standard computer language that is structured in a way that is interpretable by machines.

3. Developing and Testing the FAIR Thresholds

The development of the FAIR Thresholds for AgReFed participation were co-developed by the participating research data experts and data providers. Baseline assessments of the ‘FAIRness’ of providers’ data (‘start-status’ in Table 2) were made using the Australian Research Data Commons (ARDC) FAIR data self-assessment tool (). The manual ARDC self-assessment tool articulates various levels of FAIR maturity (or ‘FAIRness’) of (meta)data from not at all discoverable or machine understandable, through to fully understandable by both humans and machines. It also serves as an education resource for providers working to improve the FAIR maturity of their holdings.

Following this baseline assessment, providers determined where improvements could be made to move their data products along the FAIR continuum. Solutions were identified that met their own organisation’s goals, capabilities, and end users’ needs. These were combined with requirements in the Use Cases to identify ‘Minimum thresholds’ of data maturity required to support key platform functionality for (meta)data discovery, access and reuse through AgReFed. ‘Stretch targets’ were also defined to communicate to the agricultural research community the level of data maturity that enables maximal data integration and (re)use (see the shading in Table 2).

As well as the addition of ‘Minimum thresholds’ and ‘Stretch Targets’, the content of the ARDC FAIR tool was modified somewhat to assist with ease of interpretation (Table 2). Changes made in response to user feedback included:

  • Examples of some possible information and technology solutions were worked into the questions and answers.
  • The concept of ‘comprehensive’ metadata was clearly specified for both data collection and service records (see ).
  • Preferred citation in the metdata was added as an AgReFed requirement (Q14)
  • The openness of the file format was separated from the machine readability of the data (Q8). The term ‘Machine-readable’ was defined in terms of both syntax and structure, that is, as the representation of data products in a standard computer language structured in a way that is interpretable by machines (Q9).
  • A challenge for data providers was that their (meta)data were not only individual datasets contained in a single file but multiple collections, derivations (e.g., maps) and data service endpoints. Hence the ARDC FAIR assessment was refocused from the word ‘data’ to ‘data product’, being the data collection or product that is provided to users, along with any associated metadata or services required for its delivery. Here for simplicity of a manual assessment Q1 – 4, 7, 10, 12 and 13 are focused on assessment of the metadata and 5, 6, 8, 9 and 10 on the data. It is acknowledged that data and metadata can be assessed for FAIRness independently (see ) and the feasibility of assessing this way for AgReFed’s purposes should be evaluated in the future.

The ARDC and the Centre for eResearch and Digital Innovation (CeRDI) supported the data providers to improve the level of FAIR maturity of their data across a twelve-month period (2018–2019). The baseline assessments, progress to the final states and the information and technology solutions used at those states are available as supplementary data (). Some notable experiences informed the AgReFed FAIR ‘Minimum thresholds’ to ‘Stretch targets’ (Table 2). These included:

  • Providers’ exemplar data products each had different FAIR starting points (See start-status, Table 2).
  • Improvements to metadata records to meet AgReFed ‘Minimum threshold’ requirements were possible with organisational library and ARDC support (Findability Q1 to Q4) so ‘Minimum thresholds’ were set high for Q1 to Q3.
  • Access requirements and licencing varied. These were accommodated across the thresholds of Q5 and Q12.
  • Data format and structure (Interoperability Q8 and Q9) and data access method (Accessibility Q6) varied between providers, as did FAIR solutions. The solutions varied depending on the data types and the organisational/research group aspirations, skills, and IT support available. So, examples of acceptable solutions were given for Interoperability Q8 and Q9, and ‘Minimum thresholds’ to ‘Stretch targets’ highlighted for Accessibility Q6. Provider examples included a data service provider converting sensor data from web viewable-only-HTML to O&M structured data in machine-readable format (JSON), delivered by Sensor Things API via Frost-server. Agronomic researchers converted data in Microsoft Excel tables to PostGreSQL and MySQL databases with partial O&M design patterns. These delivered JSON and CSV by Swagger PostgREST API and OpenAPI.
  • The semantic interoperability (Q10) of the data products was initially highly variable. However, no data providers utilised vocabularies that were FAIR () or near to FAIR. This was a ‘Stretch target’ for providers, reflected in the sliding scale from the ‘Minimum threshold’ (Q10). Providers described data with the URIs of external machine-readable vocabularies from within their database headers or lookup tables. These were expressed through the API endpoints. Challenges included finding and selecting vocabularies including evaluating authority and persistence; and the need to create (e.g., ) and therefore upskill.
  • Provenance was recorded in different formats, reflected in ‘Minimum threshold’ to ‘Stretch target’ (Reusable Q13). Improvements were inconsistent and further work is needed defining ‘comprehensive’ content.

4. FAIR Threshold Governance and Implementation

The FAIR thresholds were presented to the AgReFed Council and approved through consensus (see AgReFed Council Terms of Reference, ) for integration into AgReFed’s Membership and Technical Policy (; ). An in-depth discussion of AgReFed’s architecture is not the focus of this practice paper and is reported elsewhere (). However, we provide an overview in the context of how founding members implemented the governance around the FAIR thresholds.

AgReFed’s operation and design is a federated architecture (Figure 1) (). It draws on a Service Orientated Architecture Reference Model design for Open Distributed Processing (RM-ODP) (), with the addition of a unique ‘Social Architecture’ viewpoint to structure social aspects of the system – such as governance. AgReFed’s Social Architecture adopts a democratic cooperative governance approach. It is led by its members to meet shared goals of self-governance, trust through active participation, and self-determination (; ). Governance, Roles and Responsibilities are defined in the Social (Membership, Financial and Strategic) and Technical Policies (, ) that determine operation of AgReFed including the implementation and governance of FAIR thresholds.

Figure 1 

The FAIR alignment process within the AgReFed architecture. FAIR thresholds are part of the alignment process for organisations to participate in the federation. They are integrated into Governance and Technical Policies, and Roles and Responsibilities ().

The recommended process is that applications for membership to AgReFed are assessed by a Federation Data Steward (, ). They assess if the provider/provider community meets the Membership Policy including whether the thresholds are met. The Technical Committee work with the Federation Data Steward and potentially Data Standards and Vocabularies Steward or delegated expert advisors/groups to ensure the partners’ solutions align with and are integrated into Technical Policy.

The provider has now demonstrated alignment with collective expectations for FAIR data (). They nominate a Data Provider Collection Custodian and member to Council and (optionally) Technical Committee. Their (meta)data is made discoverable/harvestable to AgReFed and they are now AgReFed members. All members have equal participation and decision rights. In this way, the community participates in the governance of the FAIR threshold settings including how they are maintained and implemented.

5. Reflections and Next Steps

The manual AgReFed FAIR thresholds assessment, with practical examples and definitions, was useful for helping data providers conduct meaningful assessments of their data across the full continuum of data maturity. It was also useful for developing and implementing works plans. However, to enable transparency, repeatability, and scalability of assessments across the agricultural domain some improvements could be made. Where (meta)data and services are machine actionable, automated assessment could be used to support scalability and repeatability (see Devarju et al. 2021). In contrast, manual assessment will still be required for less mature meta(data) or where a more nuanced interpretation is required for example of content to enhance re-usability. In the current platform phase () we plan to improve repeatability of the FAIR threshold assessment by integrating a hybrid (semi-automated) approach (). To improve transparency and repeatability the evidence required for both manual and machine assessment will need to be specified and may include, as examples, screen shots and automated assessment outputs.

Our experience highlighted the expertise of a Federation Data Steward will be essential for assisting partners with FAIR threshold assessments. As the federation grows the assessments will encompass more standards and technology solutions used by different communities (for example see FAIRsharing, ). If various solutions align with or should be integrated into AgReFed Technical Policy this will need to be evaluated by the steward in consultation with the Technical Committee. Keeping up to date with current developments such as the FAIR Data Maturity Model () will ensure the relevance and currency of the policy and thresholds. A dedicated Federation Standards and Vocabulary Steward () would be valuable here for brokering conversations with expert domain communities and working groups that can advise or make delegated decisions.

Here, we focused on defining FAIR data thresholds. However, we recognise that repositories that the data is served from should be ‘FAIR data enabling’ as a critical component of the broader ‘FAIR data ecosystem’ (; ). There are various ways of assessing or accrediting repositories relating to areas of security risk management, organisational and physical infrastructure, and digital object management (). As a preliminary trial, we included assessment of a ‘pass’ or ‘fail’ of several CoreTrustSeal requirements deemed necessary for persistent delivery of trusted of agricultural data whilst not being onerous and disincentivising participation (). Our early experience showed that research scientists and even data managers had difficulty knowing if their repositories complied. Furthermore, there were challenges knowing what to assess if the data products were served from multiple repositories. AgReFed could play a role helping providers assess and choose repositories that meet community expectations. We look forward to learning about the solutions of other domains here.

Our experience was that the starting point FAIRness of pilot participants’ data varied as did their priorities, capacities, and solutions for improving. To ensure these viewpoints were encapsulated, setting the FAIR thresholds and their governance and implementation was done through consensus with providers. It is envisaged that this active participation will help ensure the settings are realistic and promote trust and self-determination giving providers incentive to participate. The thresholds aimed to strike a balance between the realities and priorities of providers so as not to disincentivise participation whilst also aiming to inspire, support and educate for fully FAIR data and meet end-users needs.

Improving the FAIRness of data took resourcing, so value propositions are required for providers to have confidence in participation. Benefits to founding partners included being an exemplar of FAIR best practice at the institutional level, making access and re-use easier for end-users, and being able to combine data types for research insights (see Use Case stories, ). Providers benefited from metadata guidance through education resources, library, and licencing support. Expert assistance including from providers’ organisational IT was required for data structuring, access through APIs, and finding, selecting, creating, and applying vocabularies. In one case (SMN-2) institutional IT resourcing for data service work was a challenge but raised the prioritisation of upgrades now being worked on. Data federations can support collective advocacy, relationship brokering, and tailored support across these areas.

The provision, assembling and demonstration of tooling resources for data providers’ various needs, priorities and capabilities would also lower the cost of delivering FAIR data, thereby incentivising federation participation. Examples across the data management cycle include data management plans, data collection tools (e.g., ), data deposition tools (e.g., ) and example protocol/reference implementations (for example ). This is a focus of AgReFed’s next phase. Virtual research environments with example workflows are also being integrated. Furthermore, the federation can continue to align/encourage membership with intermediates or broker platforms that offer value in specific fields of research including in data standardisation.

The current phase has focused on research institutes. Expanding participation to co-operatives, Research Development Corporations, industry, and farmers as envisaged by members () will require incentivisation. The governance structure of AgReFed enables the community to make policy adjustments to support this. For example, alternative funding models may be leveraged, such as user-pays for certain services and data in the competitive space. Stakeholders can bring assets aside from data to the table to help meet the varied needs of participants. Recognising this, membership was recently expanded to providers of tooling, infrastructure, and other resources. Active participation through the federation will help ensure individual and collective benefits are delivered across the agricultural research sector, including through FAIR and trusted data.