BrAPI

Table of Contents

• Documentation
• Pros and Cons
• Example use cases
• FAIR Principles

Documentation

• Technology Description

  • The Breeding API (BrAPI) project is an effort to enable interoperability among plant breeding databases. BrAPI is a standardized RESTful web service API specification for communicating plant breeding data. This community driven standard is free to be used by anyone interested in plant breeding data management. Any time two agricultural applications need to communicate data programmatically, BrAPI can provide a common language both applications can understand without much effort. Organizations can use BrAPI to share data, as well as sharing BrAPI compatible applications.

• Learn from an expert

  • Recorded presentation from Peter Selby: https://youtu.be/K8NQehzBTDA
  • Slides: https://docs.google.com/presentation/d/1mGMWRnty_D-Ldqn2jNnI9rbVEzB1-LIA

• More Information

  • The official BrAPI Website: https://brapi.org

Pros and Cons

• Cost to setup

  • The Standard is free to use
  • 1-4 months of development time is required to build a custom implementation, depending on complexity and use case
  • Pre-built implementations and libraries are available to help reduce that development time, maintained by the community

• Pros

  • Represents an ag/breeding domain specific tool, unlike other technologies with generic data structures
  • Community developed for solving specific Ag/Breeding related use cases
  • Works well as an addon to existing databases and systems

• Cons

  • Requires mapping existing data into the standard (rather then just defining the structure of existing data). The mapping process can be complicated and is not always a 1-to-1 match
  • The small/moderate sized community means there are less resources available for support and development

Example use cases

• Connect application to database using a standard

  • Build a single application that can access multiple data sources the same way. For example, the QBMS R Package can pull data from a phenotypic database and a genotypic database, both via BrAPI. This is data, pulled programmatically from two (or more) unrelated sources, formatted in the same way, ready for analysis.

• Transfer data between systems

  • Synchronize (meta)data between databases in an automated and standardized way. Automated processes can be written to maintain links or copies of data in multiple sources, for multiple user audiences. As an example, the "Brapi-Sync" tool facilitates the automated transfer of whole studies between databases, allowing private data in one system to be published in another.

FAIR Principles

• Findability - Metadata and data should be easy to find for both humans and computers.

  • F1 - (Meta)data are assigned a globally unique and persistent identifier

    BrAPI supports place holders for Persistent Unique Identifiers for key data types. DOIs are a recommended best practice in the community, but not enforced.

  • F2 - Data are described with rich metadata (defined by R1 below)

    The BrAPI search schema and interface are used for findability

  • F3 - Metadata clearly and explicitly include the identifier of the data they describe

    Persistent identifiers are generally stored directly with the metadata records, linked to other data internally

  • F4 - (Meta)data are registered or indexed in a searchable resource

    FAIDARE is the BrAPI enabled search engine, as well as custom interfaces as needed"

• Accessibility - Once the user finds the required data, it should be clear how the data can be fully accessed.

  • A1 - (Meta)data are retrievable by their identifier using a standardized communications protocol

    Data accessible using RESTful Web Services (HTTP) with JSON

  • A1.1 - The protocol is open, free, and universally implementable

    OAuth2 (OpenID) is the recommended best practice for auth

  • A1.2 - The protocol allows for an authentication and authorization procedure, where necessary

    Data longevity is not applicable for BrAPI

  • A2 - Metadata are accessible, even when the data are no longer available

    Data longevity is not applicable for BrAPI

• Interoperability The data should easily interoperate with other data, as well as applications for analysis, storage, and processing.

  • I1 - (Meta)data use a formal, accessible, shared, and broadly applicable language for knowledge representation.

    JSON is used as the knowledge representation language

  • I2 - (Meta)data use vocabularies that follow FAIR principles

    Supports the use of general ontologies for data

  • I3 - (Meta)data include qualified references to other (meta)data

    Metadata is partly BrAPI community vocabulary and partly pre-existing domain specific vocabularies (MIAPPE, MCPD, GA4GH Variants, GeoJSON, etc). BrAPI defines the complete data schema, can be mapped or converted to other schemas

• Reusability Metadata and data should be well-described so that they can be replicated and/or combined in different settings.

  • R1 - (Meta)data are richly described with a plurality of accurate and relevant attributes

    Supports place holders for dataset license information, but has no best practice define for licensing.

  • R1.1 - (Meta)data are released with a clear and accessible data usage license

    Supports place holders for external links, which can be used to indicate provenance, but has no best practice defined for provenance.

  • R1.2 - (Meta)data are associated with detailed provenance

    Supports place holders for external links, which can be used to indicate provenance, but has no best practice defined for provenance.

  • R1.3 - (Meta)data meet domain-relevant community standards

    Supports place holders for external links, which can be used to indicate provenance, but has no best practice defined for provenance.