# BrAPI - an Application Programming Interface for Plant Breeding Applications.

Rafael Abbeloos, Jan Erik Backlund, Martin Basterrechea Salido, Guillaume

Bauchet, Omar Benites-Alfaro, Clay Birkett, Viana C Calaminos, Pierre

Carceller, Guillaume Cornut, Bruno Vasques Costa, et al.

► To cite this version:

Rafael Abbeloos, Jan Erik Backlund, Martin Basterrechea Salido, Guillaume Bauchet, Omar Benites-Alfaro, et al. BrAPI - an Application Programming Interface for Plant Breeding Applications. Bioinformatics, 2019, 35 (20), pp.4147-4155. 10.1093/bioinformatics/btz190. hal-02626802

HAL Id: hal-02626802

https://hal.inrae.fr/hal-02626802

Submitted on 26 May 2020

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Full paper

# BrAPI - an Application Programming Interface for Plant Breeding Applications

## The BrAPI consortium*

*in alphabetical order

Rafael Abbeloos¹, Jan Erik Backlund², Martin Basterrechea Salido³, Guillaume Bauchet⁴, Omar Benites-Alfaro⁵, Clay Birkett⁶, Viana C. Calaminos⁷, Pierre Carceller⁸, Guillaume Cornut⁹, Bruno Vasques Costa¹⁰, Jeremy D. Edwards¹¹, Richard Finkers¹², Star Yanxin Gao¹³, , Mehmood Ghaffar³, Philip Glaser¹³, Valentin Guignon¹⁴, Puthick Hok¹⁵, Andrzej Kilian¹⁵, Patrick König³, Jack Elendil B. Lagare⁷, Matthias Lange³, Marie-Angélique Laporte¹⁴, Pierre Larmande¹⁶, David LeBauer¹⁷, David Lyon⁴, David Marshall¹⁸, Dave Matthews⁶, Iain Milne¹⁸, Naymesh Mistry¹⁹, Nicolas Morales⁴, Lukas Mueller⁴, Pascal Neveu²⁰, Evangelia Papoutsoglou¹², Brian Pearce - ¹⁵, Ivan Perez-Masias⁵, Cyril Pommier⁹, Ricardo H. Ramirez-Gonzalez²¹, Abhishek Rathore²², Angel M. Raquel⁷, Sebastian Raubach¹⁸, Trevor Rife²³, Kelly Robbins¹³, Mathieu Rouard¹⁴, Chaitanya Sarma²², Uwe Scholz³, Peter Selby¹³, Guilhem Sempéré⁸, Paul Shaw¹⁸, Reinhard Simon²⁴, Nahuel Soldevilla², ²⁵, Gordon Stephen¹⁸, Qi Sun¹³, Clarysabel Tovar²,²⁵, Grzegorz Uszynski¹⁵, Maikel Verouden¹², ²⁶

¹VIB, Ghent, Belgium. ²Integrated Breeding Program (IBP), CYMMIT, Texcoco, Mexico. ³IPK-Gatersleben, Germany, ⁴Boyce Thompson Institute, Ithaca, NY, USA. ⁵International Potato Center (CIP), Lima, Peru, ⁶USDA ARS, Ithaca NY, ⁷International Rice Research Center (IRRI), Los Banos, The Philippines. ⁸CIRAD, Montpellier, France. ⁹INRA URGI, Versailles, France. ¹⁰Instituto de Biologia Experimental e Tecnológica (iBET), Oeiras, Portugal. ¹¹USDA ARS, Stuttgart, Arkansas, USA. ¹²Wageningen University, Wageningen, The Netherlands. ¹³Cornell University, Ithaca, NY, USA. ¹⁴Biodiversity International, Montpellier, France. ¹⁵Diversity Arrays Technology, Bruce, Australia. ¹⁶Institute of Research and Development (IRD), Montpellier, France. ¹⁷University of Arizona, Phoenix, Arizona. ¹⁸The James Hutton Institute, Dundee, UK. ¹⁹LeafNode Technology, Auckland, New Zealand. ²⁰MISTEA, INRA, Montpellier, France. ²¹John Innes Centre (JIC), Norwich, UK. ²²ICRISAT, Hyderabad, India. ²³Kansas State University, Manhattan, KS, USA. ²⁴Patranca E.I.R.L, Lima, Peru. ²⁵Leafnode Technology, Buenos Aires, Argentina. ²⁶Biometris, Wageningen, The Netherlands.

Author for correspondence: Lukas Mueller (lam87@cornell.edu)

Associate Editor: XXXXXXX

Received on XXXXX; revised on XXXXX; accepted on XXXXX

## Abstract

### Motivation

Modern genomic breeding methods rely heavily on very large amounts of phenotyping and genotyping data, presenting new challenges in effective data management and integration. Recently, the size and complexity of datasets have increased significantly, with the result that data is often stored on multiple systems. As analyses of interest increasingly require aggregation of datasets from diverse sources, data exchange between disparate systems becomes a challenge.

### Results

To facilitate interoperability among breeding applications, we present the public plant Breeding Application Programming Interface (BrAPI). BrAPI is a standardized web service Application Programming Interface (API) specification. The development of BrAPI is a collaborative, community-based initiative involving a growing global community of over a hundred participants representing several dozen institutions and companies. Development of such a standard is recognized as critical to a number of important large breeding system initiatives as a foundational technology. Â The focus of the first version of the API is on providing services for connecting systems and retrieving basic breeding data including germplasm, study, observation, and marker data. A number of BrAPI-enabled applications, termed BrAPPs, have been written, that take advantage of the emerging support of BrAPI by many databases.

### Availability and Implementation

More information on BrAPI, including links to the specification, test suites, BrAPPs, and sample implementations is available at https://brapi.org/. The BrAPI specification and the developer tools are provided as free and open source.

<footnote>© The Author(s) 2019. Published by Oxford University Press.
This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted reuse, distribution, and reproduction in any medium, provided the original work is properly cited.</footnote>
# 1. Introduction

Plant breeding is widely recognized as crucial to feeding a rapidly growing population, especially in developing countries (Flavell 2017), (http://www.fao.org/fileadmin/templates/wsfs/docs/expert_paper/How_to_Feed_the_World_in_2050.pdf). To meet this demand, it is necessary to breed new varieties that maintain high productivity with reduced inputs and are adapted to new eco-agricultural environments resulting from climate change. Plant breeding is a complex undertaking that necessarily integrates many interrelated disciplines, each with their own conventions for data structure and storage, and increasingly large, multifaceted datasets.

To address the challenges in the size and complexity of breeding data, a number of database systems have been designed over the years to solve specific problems. Although the power and insights that can be gleaned from large datasets increase with a greater volume and diversity of data sources, these separate systems make data integration difficult. Breeders need seamless access to all relevant data, but each system tends to keep its data siloed with ad-hoc formats that hinder the ability to exchange, compare, and combine data across research teams.

To meet these requirements, numerous groups have been working together to create an Application Programming Interface (API) for breeding data (Ghouila et al. 2018). An API specification describes the functions and services available in an application which can be accessed in an automated way by a computer program. It describes what services are available, what inputs are allowed, what the structure of the output data will be, and the protocol used to pass data to a service, often on the web. In recent years, web services have become the major paradigm for information exchange on the web, and web service standards have also been defined and implemented successfully by the bioinformatics community. Examples of such systems include the Distributed Annotation System (DAS) (Dowell et al. 2001), BioMOBY (M. D. Wilkinson 2002), and the EMBRACE (Pettifer et al. 2010) Web Service collection.

Most of the modern web service infrastructure follows the REST standards (R. T. Fielding and Taylor 2002). REST stands for “Representational State Transfer” and defines a stateless client/server communication architecture, built on the HyperText Transfer Protocol (HTTP) (https://tools.ietf.org/html/rfc7231). In a RESTful API, HTTP is the communication protocol and the available services are defined as Unified Resource Locators (URLs). Typically, the inputs are defined by constructing a URL with query parameters defined by the API (or HTTP request body objects for more complex inputs), the output data is usually returned in a defined structure. For the output, historically, XML was used, but newer APIs typically prefer the Javascript Object Notation (JSON) format.

Beyond the API layer, dData exchange requires solutions on many other levels, including the semantic level and the syntactic level (Doan, Noy, and Halevy 2004). For breeding data, standardization of the semantic level has made significant progress over the last few years through the definition of ontologies for describing plant structure and development (Cooper et al. 2018), and for describing traits in popular crops (Shrestha et al. 2012). However, the breeding community still needs to standardize data at the syntax level. This can be achieved by defining a standardized Application Program Interface.

Here, we report on the design and implementation of a standard RESTful Breeding API (BrAPI), as a specification with a focus on common plant breeding data requirements. The interface was designed by members of the BrAPI consortium. A complete list of contributors is given in the consortium description and a continuously updated list can be found on the BrAPI website (https://brapi.org/).

# 2. Results

The Breeding API is a practical tool to help solve problems in accessing, exchanging, and integrating data across systems and applications. Given the multidisciplinary nature of plant breeding, there is a broad range in the particulars of the possible data operations that could be considered. Since a complete list of BrAPI related use cases would grow unmanageably large, we decided to focus on a small number of main use cases to design the primary API elements with a view towards reusability in other use cases.

## Use cases

These are the main use cases we considered:

## Field Phenotyping Apps

Trials are often performed in fields that have limited internet connectivity, requiring special solutions for collecting phenotypic data. A popular approach is to collect data using handheld devices paired with custom mobile apps (Rife and Poland 2014). Information about the field, the plot and accession identifiers needs to be loaded on the device before phenotypic data collection. After completion, collected data needs to be uploaded to the database, when internet connectivity is available. Currently available solutions require custom files to be transferred, often involving significant user intervention. However, a simpler method would be to use an API to retrieve and store the data directly from the database.

## Sample tracking

For both phenotyping and genotyping applications, analyses may need to be run by service providers third party organizations, such as analytical labs and genotyping centers, that use different tracking mechanisms. The sample tracking use case describes the hand-off of the sample information to the service provider, and the subsequent retrieval of the results. In practice, a sample tracking samples implementation can become very complex because the identifiers from several different systems must be correlated.

## Genome visualization and analysis

Genome-based breeding requires extensive genotyping, which can be helpful to visualize in different ways to aid in breeding decisions. An example of such a tool is Flapjack (Milne et al. 2010), which can display a number of genotypes and run analyses on the data. BrAPI standardizes the interfaces for such tools, hence they can be used with a much wider range of data sources and without the need for special adaptations for each source.

## FAIR Data Portals

One of the challenges of big data is identifying datasets of interest and ensuring their long term availability. This can be addressed by building federations of Findable, Accessible, Interoperable and Reusable (FAIR) data repositories (Mark D. Wilkinson et al. 2016), Interfaces such as BrAPI can help such efforts by all offering standardizing access to the
Choose a list of trials to filter.

compare_trials_IITA

Plots

<figure><img src="image_2.png" /></figure>

Group By Accession

<figure><img src="image_3.png" /></figure>

Filtered Results

Show 10 entries

Search:

<table><thead><tr><th>Study</th><th>Unit</th><th>Accession</th><th>total carotenoid by iCheck method|CO_334:0000162</th><th>total carotenoid by chart 1-8|CO_334:0000161</th><th>top yield|CO_334:0000017</th><th>taste of boiled root rating 1-3|CO_334:0000085</th><th>storage root size visual rating 1-7|CO_334:0000019</th><th>storage root shape visual rating 1-6|CO_334:0000020</th></tr></thead><tbody><tr><td>15ayt18highTCIB</td><td>2016-15ayt18highTCIB-rep2-IITA-TMS-IBA070593</td><td>IITA-TMS-IBA070593</td><td>4</td><td>29.25</td><td>2</td><td>5</td><td>2</td></tr><tr><td>15ayt18highTCIK</td><td>2016-15ayt18highTCIK-rep1-IITA-TMS-IBA130329</td><td>IITA-TMS-IBA130329</td><td>3.14</td><td>16.75</td><td>1</td><td>5</td><td>2</td></tr><tr><td>15ayt18highTCUB</td><td>2016-15ayt18highTCUB-rep1-IITA-TMS-IBA130089</td><td>IITA-TMS-IBA130089</td><td>10.13</td><td>33.13</td><td>2</td><td>7</td><td>2</td></tr></tbody></table>

Figure 1: A screenshot of an example web applications that retrieves information through BrAPI. Such applications are often referred to as “BrAPPs”. This application, called “Graphical Filtering”, allows to filter accessions by phenotypic data, by interactively selecting ranges of trait values for different traits in the dataset. Data from Cassavabase (https://cassavabase.org/) is shown, but BrAPPs seamlessly integrate with any BrAPI-enabled database.

data repositories through BrAPI, thereby hence creating federations. General or Ccommunity or species specific p on which pPortals to the federated data can then be deployed to provide general or community specific data access. take advantage of it. the federationdata portal. This ose portals and federationis federations increasess the visibility of all datasets and therefore reduces the risk of losing building isolated datasets silos that may be lost that were built over time. The portals should implement simple searches on standard metadata, such as MCPD or MIAPPE (Milne et al. 2010; Ćwiek-Kupczyńska et al. 2016), (Krajewski et al. 2015).

## Data Integration and Exchange

In this use case, two databases exist with overlapping data as well as specific data in each database. Database A would like to access data in database B. For example, database A may contain information about accessions, such as phenotypic and trial metadata, while database B contains genotypic information. Using a BrAPI call, database A can extract the genotyping data from database B and use that data in breeding decision support.

## API Definition

The BrAPI definition is kept in the “API” repository of the “plantbreeding” organization on GitHub (https://github.com/plantbreeding/API), with all changes to the definition managed using GitHub’s “issues”, “projects” and “pull requests” facilities.

## API Organization

BrAPI calls are organized into categories that reflect the major domains needed for exchanging data between plant breeding information management systems and client applications. Some example categories include Studies, Germplasm, Traits, Trials, MarkerProfiles and Authentication (a full list of the categories is presented in Table 1).

## URL structure

All BrAPI calls follow a common URL structure. The URL starts with a domain name (and optional base path of the implementation server) followed by “/brapi/” and the major version number. Next, the call name appears, with optional object ids and other parameters. Most calls use the HTTP request method ‘GET’, but some require ‘POST’ and ‘PUT’, as specified in the documentation. For security, the use of SSL (HTTPS) is highly recommended for all BrAPI endpoints.

### Examples:

https://example.com/brapi/v1/locations

https://example.com/brapi/v1/trials?programDbId=abc123

https://example.com/maize-db-01/brapi/v1/studies-search

## Return object structure
```json
{
    "metadata": {
        " pagination": {
            "totalCount": 20,
            "pageSize": 3,
            "totalPages": 7,
            "currentPage": 0
        },
        "status": [
            {
                "code": "200",
                "message": "Success"
            }
        ]
    },
    "datafiles": ["/mnt/local/matrix_01.csv",
                  "/mnt/local/matrix_02.csv"]
},
"result": {
    "key0": "master",
    "key1": 20,
    "key2": ["foo", "bar", "baz"],
    "data": [
        {
            "detailKey0": "detail0",
            "detailKey1": ["foo", "bar"]
        },
        {
            "detailKey0": "detail1",
            "detailKey1": ["bar", "baz"]
        },
        {
            "detailKey0": "detail2",
            "detailKey1": ["baz", "foo"]
        },
    ]
}
```

<caption>Figure 2: An example BrAPI response object. This object shows a generic response with "metadata", a "master" result record, and a set of "data" records.</caption>

We have defined a standard JSON formatted response structure that is common across all calls. The standard response consists of a JSON object with a "metadata" key and a "result" key. The "metadata" key provides the pagination information, an array of status information, and an array of data files. If the response data contains an array of entities which could possibly grow large, the " pagination" object will be populated with the keys "pageSize", "currentPage", "totalCount", "totalPages" containing the appropriate values. If the response is a single entity that does not require pagination, then the " pagination" object still must be returned, but all data elements within it should be set to zero. All pages are zero indexed, so the first page will always be page zero. The "status" array contains a list of objects with the keys "code" and "message". These status objects should be used to provide additional status or log information about the call. If the call was completed successfully and there are no status objects reported, an empty array should be returned. The "datafiles" array contains a list of URLs to any extra data files generated by the call. For example, this could be images related to the data returned, or large data extract files which contain more data than that returned in the response payload. See Figure 2 for an example.

The data payload "result" contains the specific model object for the given call response. There are three basic patterns that response objects follow. The "master" pattern is used for returning all the data associated with a single entity. The "details" pattern is used to return an array of

entities. In the "details" pattern, the "result" object always contains a single array called "data" and no other fields. The "master/details" pattern is a combination of the "master" and "details" patterns. It is used to represent a parent object which has an array of child entities. The "result" object contains some data associated with the parent as well as the "data" array with all the child entities. Whenever the "data" array is present, the response is assumed to be paginated. This means the size of the "data" array is always limited by the " pagination" object in the "metadata".

In most cases, all the data will be contained within the JSON response. For large "data" arrays, several requests might need to be made to retrieve every page of the array. In the event that the size of the data package exceeds what could reasonably be handled using the HTTPS protocol and the client, the service provider can place the data in a file and provide a link in the "datafiles" array, to be downloaded later.

## Authentication

A user or system may have to authenticate to a server to access protected data. BrAPI is a data communication specification, so the authentication scheme used to protect that data is considered outside the scope of the BrAPI specification. However, authentication and authorization are important topics to address whenever any kind of data is moved or presented. In order to facilitate communication of data between tools in a standardized way, the BrAPI community has developed a set of best practices using the OAuth2 architecture for implementing proper authentication with any BrAPI enabled tools and databases. In its most basic form, the OAuth2 architecture is a sessionless, token based architecture. OAuth2 allows users to sign in with user credentials they already have, and provides a token. This token can then be used to authenticate that user within different tools and databases. The token should be added as a header in every BrAPI request.

## Versioning

All software projects need the ability to evolve to reflect changing requirements, to cover new use cases, and to incorporate user feedback. A well defined and rigorous versioning scheme is essential for BrAPI to ensure that client and server communication is well defined and the community can keep track of the changes. In BrAPI, there are major versions and minor versions. The major version is currently "v1", which is reflected in the URL scheme. Minor versions are incremented about every three months, reflecting changes in the API that have been accepted by the BrAPI community and reviewed by the BrAPI coordinator. To help maintain consistency, all changes in minor versions are backward compatible with earlier minor versions within the same major version. The "calls" call provides meta-information about each BrAPI call available on a given server. The response of the "calls" call includes all the supported version numbers for each call, so external clients can easily check for compatibility with that server.

## Community

For a communication standard like BrAPI to be successful, there must be people and organizations willing to contribute and use it. Early on in the development of BrAPI, we recognized the need to foster and develop a strong community of users. This community has grown rapidly over the
<table><caption>Table 1. Categories of BrAPI calls. In each category, there are one or more calls that provide services to support the corresponding domain of plant breeding data management.</caption><thead><tr><td>Category</td><td>Comments</td><td># of calls</td></tr></thead><tbody><tr><td>Calls</td><td>Meta information about which BrAPI calls are available on a server implementation.</td><td>1</td></tr><tr><td>Crops</td><td>Provides the common names for the crops available on a server implementation.</td><td>1</td></tr><tr><td>Germplasm</td><td>Provides search capabilities and details for germplasm data. Includes MCPD, pedigree and breeding method data.</td><td>8</td></tr><tr><td>Germplasm Attributes</td><td>Germplasm Attributes are simply-inherited characterization descriptors that are inherent in the germplasm line but not environment-dependent.</td><td>3</td></tr><tr><td>Markers</td><td>Provides search capabilities and details for genetic marker metadata.</td><td>3</td></tr><tr><td>Marker Profiles</td><td>Provides search capabilities and details for genomic data. Includes allele matrices.</td><td>5</td></tr><tr><td>Programs</td><td>Provides search capabilities and details for breeding programs. A program may contain multiple trials.</td><td>2</td></tr><tr><td>Trials</td><td>Provides search capabilities and details for breeding trials. A trial may contain multiple studies. Used also for any large phenotyping dataset like multilocal phenotyping networks.</td><td>2</td></tr><tr><td>Studies</td><td>Provides search capabilities and details for genotyping and phenotyping studies and support for observation data gathering. Includes germplasm, observation, plot layout, and season details related to a particular study.</td><td>17</td></tr><tr><td>Phenotypes</td><td>Provides search capabilities for phenotyping observation data across studies, trials, and programs</td><td>5</td></tr><tr><td>Traits</td><td>Provides details for trait ontology data which are available for observation variables.</td><td>2</td></tr><tr><td>Observation Variables</td><td>An Observation Variable is combination of a trait, a method and a scale. Phenotyping data is collected for observation variables. Fully aligned to the Crop Ontology.</td><td>5</td></tr><tr><td>Genome Maps</td><td>Provides summaries and details for stored genome maps.</td><td>4</td></tr><tr><td>Location</td><td>Provides details of geographical locations of studies.</td><td>2</td></tr><tr><td>Samples</td><td>Provides support for storing and retrieving plant sample metadata</td><td>4</td></tr><tr><td>Vendor Samples</td><td>Provides support for sending sample metadata to an external vendor for processing (ie gene sequencing)</td><td>5</td></tr></tbody></table>

past few years and it now has representatives from several dozen different organizations from around the world.

The development of BrAPI is a community effort. Work on the API is mainly organized around regular “hackathons”, where BrAPI contributors gather for a week of discussions and API design work. BrAPI community institutions take turns organizing and hosting the hackathons. This has proven very effective for collaborative development and capacity building (Ghouila,A. et al. 2018). Between the hackathons, the proposed APIs are implemented at the different sites, and problems encountered during implementation are fed back into the design at the following hackathon. An important role in the community is played by the BrAPI coordinator, who helps to organize the hackathons and workshops, reviews and coordinate proposals for new or updated calls, provides support for implementers, and maintains the documentation and the BrAPIbrapi website.

## Brapi.org

To serve the developer community, a website (https://brapi.org) was created as a nexus of all BrAPI related tools and information. It provides the official documentation for the API as well as information on meetings, hackathons, community news, testing tools, development libraries, BrAPPs, and a community forum.

## Server Implementations

BrAPI server implementations have been created for a number of popular breeding, genebank and plant genomics databases. A variety of languages and database systems have been used to develop BrAPI-compliant systems. Web frameworks languages include Drupal/Tripal (PHP), Catalyst (Perl), Java Spring (Java), NodeJS (JavaScript), Django (Python) whereas databases and data query systems include Postgres, MongoDB, Elasticsearch, HDF5, and MySQL. Many of these systems are open source, so their code may be adapted for other systems with similar implementation parameters. A list of current BrAPI server implementations is given in Table 2.

## Client Implementations

BrAPI clients have been implemented in Java GWT, Javascript, and R (https://www.r-project.org). BrAPI cClient code libraries have been created in several languages, such as Java (https://github.com/imilne/jhibrapi), the BrAPI R package (https://github.com/CIP-RIU/brapi), Brapi Drupal for PHP, and brapi.js for Javascript (https://github.com/solgenomics/BrAPI-js). A non-exhaustive list of current client applications is given in Table 3. It is possible for service providers to use BrAPI for the implementation of native website features. Some of these features have been implemented as reusable BrAPI compliant widgets, which we call BrAPI Apps or “BrAPPs” for short. The available BrAPPs are listed on the BrAPI website (https://brapi.org/brapps.php). Figure 1 shows a screenshot of an example BrAPP which performs graphical filtering of phenotypic values.

## Test Suites and Fixtures

Comprehensive testing is very important for any software project. Testing tools are available for both BrAPI server implementations and BrAPI enabled clients. For testing server implementations, the BRAVA test client is available for testing compliance with the BrAPI specification (http://webapps.ipk-gatersleben.de/brap/). BRAVA is able to test a server implementation and confirm the response structure and data types matches the expected JSON schema.

For testing BrAPI enabled clients, a BrAPI test server is available at the brapi.org site (https://test-server.brapi.org/brapi/v1). The BrAPI Test Server has a complete implementation of the BrAPI specification and returns a consistent sample set of data. This allows developers of clients to build tests which are appropriate for their tool, while calling a live BrAPI server implementation. The sample data reported by the test server is completely fabricated, and can be updated at any time upon request.
BrAPI Interface

<table><caption>Table 2: Server implementations</caption><thead><tr><th>Database Name</th><th>URLs</th><th>Organization, Reference</th></tr></thead><tbody><tr><td>Breeding Management System (BMS)</td><td>https://www.integratedbreeding.net</td><td>CGIAR https://cgiar.org</td></tr><tr><td colspan="3">Description: Comprehensive breeding management system with trial design, data collection, and analyses.</td></tr><tr><td>Cassavabase</td><td>https://cassavabase.org</td><td rowspan="4">Boyle Thompson Institute (BTI)<br>https://btiscience.org</td></tr><tr><td>Musabase</td><td>https://musabase.org</td></tr><tr><td>Yambase</td><td>https://yambase.org</td></tr><tr><td>Sweetpotatobase</td><td>https://sweetpotatobase.org</td></tr><tr><td>Solanaceae Genomics Network</td><td>https://solgenomics.net</td><td></td></tr><tr><td colspan="3">Description: Comprehensive breeding management system, including trial design management, phenotyping sample and data collection; with a focus on genomic breeding technologies such as Genomic Selection</td></tr><tr><td>B4R</td><td>https://b4r.irri.org</td><td>International Rice Research Institute (IRRI), http://irri.org</td></tr><tr><td colspan="3">Description: Comprehensive breeding management system tailored for rice and other grains</td></tr><tr><td>Germinate</td><td>https://ics.hutton.ac.uk/get-germinate</td><td>The James Hutton Institute, http://hutton.ac.uk</td></tr><tr><td colspan="3">Description: Breeding database and analysis tools</td></tr><tr><td>GOBii</td><td>http://gobiproject.org</td><td>Cornell University, https://cornell.edu<br>BTI, https://btiscience.org</td></tr><tr><td colspan="3">Description: Large scale and efficient genotyping storage system including data analysis workflows</td></tr><tr><td>T3</td><td>https://triticeaetoolbox.org</td><td>USDA,<br>https://usda.gov</td></tr><tr><td colspan="3">Description: Comprehensive breeding management system designed for wheat</td></tr><tr><td>Musa Germplasm Information System (MGIS)</td><td>https://www.crop-diversity.org/mgis</td><td>Bioversity International, https://bioversityinternational.org, (Ruas et al. 2017)</td></tr><tr><td colspan="3">Description: Information system on banana germplasm</td></tr><tr><td>Gigwa</td><td>http://gigwa.southgreen.fr</td><td>CIRAD, IRD (South Green)</td></tr><tr><td colspan="3">Description:Gigwa (Sempéré et al. 2016) is a web-application that aims at storing and exposing genotypic datasets and provides a web interface for filtering them in real time. It is able to interoperate with genome browsers and export results into several formats.</td></tr><tr><td>EU-SOL Database</td><td>https://www.eu-sol.wur.nl</td><td>Wageningen University &amp; Research, https://wur.nl</td></tr><tr><td colspan="3">Description: This site contains information about a collection composed of ~7000 domesticated (S. lycopersicum) lines, along with representative wild species, collected with the scope of the european project EU-SOL. This germplasm was generously provided by different international genebanks and by donations from private collections. This Integrated Project is supported by the European Commission through the 6th framework program. Contract number: FOOD-CT-2006-016214</td></tr><tr><td>GnplS</td><td>https://urgi.versailles.inra.fr/gnps</td><td>INRA, https://www.inra.fr</td></tr><tr><td colspan="3">Description: French national archive for plant phenotyping data. It provides any type of PGR and Phenotyping data. Used for instance by Perpheclim for climate change adaptation studies and as a data repository in the Elixir federation which is under construction. It contains almost a thousand Phenotyping trials over thousands of woody and annual plant varieties..</td></tr><tr><td>KDDart</td><td>https://kddart.diversityarrays.com/brapi/v1/</td><td>DArT, http://www.kddart.org</td></tr><tr><td colspan="3">Description: Genotype and phenotype database, linked to genotyping service</td></tr><tr><td>Crop Ontology</td><td>http://www.cropontology.org/</td><td>Bioversity, https://bioversityinternational.org</td></tr><tr><td colspan="3">Description: Database of available trait ontologies for diverse crops in the CGIAR system</td></tr><tr><td>PIPPA</td><td>https://pippa.psb.ugent.be</td><td>VIB<br>https://www.psb.ugent.be/</td></tr><tr><td colspan="3">Description: PSB Interface for Plant Phenotype Analysis</td></tr><tr><td>PHIS</td><td>http://www.phis.inra.fr</td><td>INRA, https://www.inra.fr</td></tr><tr><td colspan="3">Description: Ontology-driven Information System designed for Plant Phenomics. PHIS is designed to store, organise and manage highly heterogeneous and multi-spatial and temporal data from multiple sources (field, greenhouse).</td></tr><tr><td>GBIS/I</td><td>https://fair-ipk.ipk-gatersleben.de/public/ breedingapi.html</td><td>IPK-Gatersleben, https://www.ipk-gatersleben.de</td></tr><tr><td colspan="3">Description: Among other, FAIR-IPK offers access to IPK genbank information system GBIS. This comprise passport data (information on the identity, history, geographical origin and botanical classification of the material) of the 150,780 accessions in Gatersleben (as of 30 June 2016), including the Satellite Collections North in Gross Lüsewitz (potatoes) and Malchow/Poel (oil and fodder crops).</td></tr><tr><td>TERRA REF</td><td>https://terraref.ncsa.illinois.edu/bety</td><td>https://terraref.org</td></tr><tr><td colspan="3">Description: An open access reference database for high throughput phenomics. Crops include sorghum and wheat.</td></tr></tbody></table>
<figure><img src="image_4.png" /><figcaption>Figure 3: BRAVA portal. A) List of publicly available endpoints and their compliance status according to BRAVA. An expanded report panel shows the individual test results for the selected resource. B) “Test your own” panel where the user can test a custom URL, or C) subscribe to get periodic reports.</figcaption></figure>

## BrAPI Validator (BRAVA) test tool

For testing server implementations, the BRAVA test client is available for testing compliance with the BrAPI specification (http://webapps.ipkgatersleben.de/brap/). Available as a web frontend, BRAVA enables developers to check the compliance of their BrAPI endpoints against the specification and the referential integrity of input and output

parameters of dependent endpoints. The frontend, as shown in Figure 3, enables testing of BrAPI server implementations. A user can also schedule tests and generate periodic reports of the overall status and details of BrAPI endpoint compliance. The compliance tests and results are grouped by and aggregated per REST resource. Using the BrAPI meta-endpoint “/calls”, BRAVA is able to detect the available endpoints on the server and will only test those endpoints.

A given endpoint might be tested multiple times with different inputs or HTTP methods. Each test checks the HTTP status code, content type, validity of response body, and response data types. Each test will also compare the response to the expected JSON schema which defines the structure of a JSON object and acceptable types. Some tests check the compatibility of response data to a corresponding parameter. For example, a test will call “/germplasm-search” and will use the first “germplasmDbId” from the response to make the call “/germplasm/{germplasmDbId}”. Some tests will compare a response value to a pre-

viously stored value. For example, an entity accessed by calling “/germplasm/1” must have a “germplasmDbId” of “1”.

When a test run is complete, the test suite result is sent to the web client and a report is generated. The report can be inspected in the client and has a tree-like structure to analyse individual test results for individual calls. The scheduled and public resource test reports are stored for future assessment.

## 4. Discussion & Outlook

We have defined a first version of a plant breeding API that defines the key calls needed to exchange information about germplasm, phenotypes, experiments, studies, geographic locations, samples, and genetic markers. This opens the door to a rich set of possibilities for building client applications that can work with any BrAPI-compliant data provider.

Since 2015, a diverse group of data providers and client application programmers have been building BrAPI into their software. Client applications can rely on the standard interface to enable integration with any BrAPI data source. Building software using standard interfaces is an efficient and sustainable coding practice which enables the reuse of software components. As the public plant breeding software community is relatively small, this will be essential for creating a feature-rich breeding software ecosystem. A good example of the efficient reuse of com-
## BrAPI Interface

<table><caption>Table 3: Client implementations</caption><thead><tr><td>Program Name</td><td>URL</td><td>Institution(s)</td></tr></thead><tbody><tr><td>Flapjack</td><td>https://ics.hutton.ac.uk/flapjack</td><td>The James Hutton Institute, https://hutton.ac.uk</td></tr><tr><td>Highly Interactive Data Analysis Platform (HIDAP)</td><td>https://apps.cipotato.org/hidap_sbase/</td><td>International Potato Center (CIP)</td></tr><tr><td>brapi R package: Implementation of Breeding API in R</td><td>https://github.com/CIP-RIU/brapi</td><td>International Potato Center (CIP), Wageningen University &amp; Research, Patranca</td></tr><tr><td>brapixR package</td><td>https://github.com/c5sire/brapix</td><td>Patranca</td></tr><tr><td>brapiui R package</td><td>https://github.com/c5sire/brapiui</td><td>Patranca</td></tr><tr><td>Pedigree Viewer</td><td>https://github.com/solgenomics</td><td>BTI</td></tr><tr><td>Graphical Phenotype Filtering</td><td>https://github.com/solgenomics</td><td>BTI</td></tr><tr><td>Trial Comparison</td><td>https://github.com/solgenomics</td><td>BTI</td></tr><tr><td>Comparative Map Viewer</td><td>http://maps.solgenomics.net/</td><td>BTI</td></tr><tr><td>ISMU</td><td>https://github.com/icrisatSbdm/ismu</td><td>ICRISAT</td></tr><tr><td>Gigwa</td><td>http://gigwa.southgreen.fr</td><td>CIRAD, IRD (South Green)</td></tr><tr><td>Beegmac</td><td>http://webtools.southgreen.fr/BrAPI/Beegmac/</td><td>CIRAD (South Green)</td></tr><tr><td>GnpiS</td><td>https://urgi.versailles.inra.fr/gnpiS</td><td>INRA</td></tr><tr><td>Variable Ontology Widget</td><td>https://github.com/gnpiS/trait-ontologyWidget</td><td>INRA</td></tr><tr><td>Drupal BrAPI Implementation</td><td>https://www.drupal.org/project/brapi</td><td>Bioversity</td></tr></tbody></table>

ponents can be seen in the community developed BrAPPS, which are tools that make extensive use of BrAPI and can be widely shared and deployed on different BrAPI enabled systems. This framework is useful to commercial plant breeding software development efforts and we welcome more engagement with that community.

We are continuing our efforts and have initiated work on improved versions of the API. We recognize that the types of data relevant to plant breeding are expanding, and BrAPI will continue to evolve in response.

One aspect of the API that we would like to enhance is the ability to handle linked data (Xin et al. 2018). For example, linking between datasets can rely on standard variables ontologies, this would be useful for linking BrAPI data with standard vocabularies or ontologies, such as the Crop Ontology for Agricultural Data (Shrestha et al. 2012) which can be used in Observation Variables. To fully enable this, the current research and developments are for including linked data is based on adding semantic capabilities to BrAPI, especially through the JSON-LD standard, and some support will likely be included in the next major version of BrAPI. It is also important to improve the clarity and understandability of the BrAPI data model clarity and understandability for both human and machine. Future development will include documentation of the mapping between BrAPI and other common data specifications, such as MIAPPE and MCPD. This will provide a human friendly documentation of BrAPI formats fields and concepts. Furthermore, it will also provide reference concepts and schemas necessary to integrate BrAPI with other initiatives such as bioschemas.org.

Beyond breeding applications, BrAPI has also found a niche in gene bank applications, such as MGIS (Ruas et al. 2017), through compatibility with the Multi-Crop Passport Data standard (MCPD). Although the

initial intent was to enable interoperability between breeding management resources, BrAPI can also be used with other types of databases, such as applied to plant genetic resources databases (ie, MGIS (Ruas et al. 2017)) and plant genome databases (ie, SGN, MaizeGDB, etc). BrAPI offers a way to link genetic resources distributed by gene banks with materials used in breeding programs. Improved integration between gene banks and management genetic resource databases, and plant breeding management databases, and genomic databases has the potential to greatly enhance the management and utilization of plant germplasm collections (Ruas et al. 2017; Spindel and McCouch 2016). Efficient and smart use of genetic diversity is key for continued progress in plant breeding efforts to address the challenges of increased productivity and adaptation (Halewood et al. 2018).

As the needs and technologies of our community continue to evolve, we expect BrAPI to grow to meet those needs. We invite the reader to join our community and contribute to the future of BrAPI. Please visit us at https://brapi.org/ to learn more.

## Getting Involved

We invite the reader to join our community and contribute to the future of BrAPI. To start, please visit https://brapi.org/ to learn more, contact the BrAPI coordinator at brapicoordinatorselby@gmail.com to join the mailing list, Slack channel, and community forum.

## Acknowledgements

The BrAPI consortium gratefully acknowledges The Bill and Melinda Gates Foundation for providing funds and support for an organizational meeting in Seattle and three hackathons. We would also like to thank the following organizations for hosting BrAPI Hackathons: GOBii, The Boyce Thompson Institute, INRA, CGIAR Bioversity International, CGIAR Research Program on Roots, Tubers, and Bananas. We acknowledge Elixir (European Infrastructure for bioinformatic) and Phenome EMPHASIS.fr (French Phenotyping Infrastructure) for the adoption and support of the BrAPI. We also acknowledge the Excellence in Breeding Platform (EiB) for their ongoing support of the BrAPI effort.

## Funding

Bill and Melinda Gates Foundation, Bioversity International, Boyce Thompson Institute for Plant Research, CGIAR Research Program and Roots, Tubers and Bananas, Cornell University, Excellence in Breeding Platform

Conflict of Interest: none declared.

## References

* Cooper, Laurel, Austin Meier, Marie-Angélique Laporte, Justin L. Elser, Chris Mungall, Brandon T. Sinn, Dario Cavaliere, et al. 2018. "The Planteome Database: An Integrated Resource for Reference Ontologies, Plant Genomics and Phenomics." Nucleic Acids Research 46 (D1): D1168-80.

* Ćwiek-Kupczyńska, Hanna, Thomas Altmann, Daniel Arend, Elizabeth Arnaud, Dijun Chen, Guillaume Cornut, Fabio Fiorani, et al. 2016. "Measures for Interoperability of Phenotypic Data: Minimum Information Requirements and Formatting." Plant Methods 12 (1): 44.

* Doan, Anhai, Natalya F. Noy, and Alon Y. Halevy. 2004. "Introduction to the Special Issue on Semantic Integration." ACM SIGMOD Record 33 (4): 11.
Dowell, R. D., R. M. Jokerst, A. Day, S. R. Eddy, and L. Stein. 2001. "The Distributed Annotation System." BMC Bioinformatics 2 (October): 7.

Fielding, Roy T., and Richard N. Taylor. 2002. "Principled Design of the Modern Web Architecture." ACM Transactions on Internet Technology 2 (2): 115–50.

Flavell, Richard B. 2017. "Innovations Continuously Enhance Crop Breeding and Demand New Strategic Planning." Global Food Security 12: 15–21.

Ghouila, Amel, Geoffrey Henry Siwo, Jean-Baka Domelevo Entfellner, Sumir Panji, Katrina A. Button-Simons, Sage Zenon Davis, Faisal M. Fadlelmola, DREAM of Malaria Hackathon Participants, Michael T. Ferdig, and Nicola Mulder. 2018. "Hackathons as a Means of Accelerating Scientific Discoveries and Knowledge Transfer." Genome Research 28 (5): 759–65.

Halewood, Michael, Tinashe Chirugwi, Ruaraidh Sackville Hamilton, Brad Kurtz, Emily Marden, Eric Welch, Frank Michiels, et al. 2018. "Plant Genetic Resources for Food and Agriculture: Opportunities and Challenges Emerging from the Science and Information Technology Revolution." The New Phytologist 217 (4): 1407–19.

Krajewski, Pawel, Dijun Chen, Hanna Ćwiek, Aalt D. J. van Dijk, Fabio Fiorani, Paul Kersey, Christian Klukas, et al. 2015. "Towards Recommendations for Metadata and Data Handling in Plant Phenotyping." Journal of Experimental Botany 66 (18): 5417–27.

Milne, Iain, Paul Shaw, Gordon Stephen, Micha Bayer, Linda Cardle, William T. B. Thomas, Andrew J. Flavell, and David Marshall. 2010. "Flapjack--Graphical Genotype Visualization." Bioinformatics 26 (24): 3133–34.

Pettifer, Steve, Jon Ison, Matús Kalas, Dave Thorne, Philip McDermott, Inge Jonassen, Ali Liaquat, et al. 2010. "The EMBRACE Web Service Collection." Nucleic Acids Research 38 (Web Server issue): W683–88.

Rife, Trevor W., and Jesse A. Poland. 2014. "Field Book: An Open-Source Application for Field Data Collection on Android." Crop Science 54 (4): 1624.

Ruas, Max, V. Guignon, G. Sempere, J. Sardos, Y. Hueber, H. Duvergey, A. Andrieu, et al. 2017. "MGIS: Managing Banana (Musa Spp.) Genetic Resources Information and High-Throughput Genotyping Data." Database: The Journal of Biological Databases and Curation 2017 (January).

Sempéré, Guilhem, Florian Philippe, Alexis Dereeper, Manuel Ruiz, Gautier Sarah, and Pierre Larmande. 2016. "Gigwa—Genotype Investigator for Genome-Wide Analyses." GigaScience 5 (1).

Shrestha, Rosemary, Luca Matteis, Milko Skofic, Arllet Portugal, Graham McLaren, Glenn Hyman, and Elizabeth Arnaud. 2012. "Bridging the Phenotypic and Genetic Data Useful for Integrated Breeding through a Data Annotation Using the Crop Ontology Developed by the Crop Communities of Practice." Frontiers in Physiology 3 (August): 326.

Spindel, Jennifer E., and Susan R. McCouch. 2016. "When More Is Better: How Data Sharing Would Accelerate Genomic Selection of Crop Plants." The New Phytologist 212 (4): 814–26.

Wilkinson, Mark D., Michel Dumontier, I. Jsbrand Jan Aalbersberg, Gabrielle Appleton, Myles Axton, Arie Baak, Niklas Blomberg, et al. 2016. "The FAIR Guiding Principles for Scientific Data Management and Stewardship." Scientific Data 3 (March): 160018.

Wilkinson, M. D. 2002. "BioMOBY: An Open Source Biological Web Services Proposal." Briefings in Bioinformatics 3 (4): 331–41.

Xin, Jiwen, Cyrus Afrasiabi, Sebastien Lelong, Julee Adesara, Ginger Tsueng, Andrew I. Su, and Chunlei Wu. 2018. "Cross-Linking BioThings APIs through JSON-LD to Facilitate Knowledge Exploration." BMC Bioinformatics 19 (1): 30.