Phenotype Data Collection

From BrAPI-Wiki
Jump to navigation Jump to search

Back to Use Cases

PhenoApps KSU Field Book

The KSU Fieldbook is BrAPI compatible.

BrAPI V1.3

The following BrAPI V1.3 endpoints are needed for full Field Book BrAPI functionality:

BrAPI V2.0

The following BrAPI V2.0 endpoints are needed for full Field Book BrAPI functionality:

BrAPI V2.0 Authorization

Moving from V1.3 Field Book auth to V2.0 OAuth/OIDC: Insructions Doc

Slides from "Field Book Auth Mini-Hack": OAuth_Flow_Field_book.pptx

Recording of "Field Book Auth Mini-Hack": YouTube

Trait Mapping Notes

When downloading data from a BrAPI compliant database to KSU Field Book, Field Book will make a call to GET /variables to retrieve a list of ObservationVariable objects. It maps "observationVariableDbId" to "externalDbId" directly. It will attempt to map the first synonym from the "synonyms" list to "trait". If there are no "synonyms" (null or empty list), then it will map "observationVariableName" to "trait". The "trait" column from the .trt file is directly mapped to "trait" in the Field Book internal DB and used as the display identifier in the app.

When uploading data from KSU Field Book to a BrAPI compliant database, Traits are not uploaded, only Observations are uploaded. Each BrAPI Observation has a field "observationVariableDbId" which is populated from the "externalDbId".

From a data server perceptive, whatever value is mapped to BrAPI "observationVariableDbId", Field Book will use that value to upload observation data attached to known traits.

 BrAPI                           Field Book
 "observationVariableDbId"  ->   "externalDbId"
 "synonyms"                 ->   "trait"
 "observationVariableName"  ->   "trait"

Old Notes

These notes were originally created July 29, 2016 as a thought experiment. They are maintained for historical reference only.

Field Data Collection

To be able to collect field trial data with a hand held device the following Brapi calls are initially needed and have been reviewed:

  1. GET /trials : Get list of trial summaries STATUS: OK as is
  2. GET /studies/{studyDbId} : Get study details with expand parameters.
    • Fields required:
      • trialDbId
      • trialName
    • Field to remove:
      • programDbId
  3. POST /studies/{studyDbId}/observationunits : Save or update measurements STATUS: OK as is
  4. POST /variables-search : Search observation variables (IRRI use case: no pre-defined variables in study) STATUS: NEW call needed. Has been added to apiary!
  5. GET /programs : List Programs STATUS: NEW parameter added to filter by name/abbreviation. Not required so doesn’t break current implementation.

Core Entities and Operations

This was originally created June 29, 2015 as a thought experiment. It needs to be updated

Entities and Operations for Version 1 of the field data collection APIs.


  • List of crops supported
  • Should crop param be a part of URL (path parameter) or a query parameter? We prefer the former.


  • List of Programs
  • Filters e.g. "my programs"


  • List all Studies
  • List study types
  • Study Details
    • Collection Order/Traversal schemes (different from planting order) is important for collection
  • Filter by season, location, type


  • List of traits
  • Filter by program, name


  • CRUD

Notes from hacking day 1

  • Common data structure for entities and whether to return all fields with "N/A" or to not return not applicable fields at all.
  • Does things like pictures make sense as a trait?


Misc other methods we might need

  • List of scales/methods
  • Treatments
  • List Plot att


  • List of users

Extra Info

  • Core API data structure
  • Extra info - implementation specific extra info : general structure
     id: 1,
     name: "Trial A",
     // OtherFieldsOfCoreAPI...
     extraInfo : {
         implementationId : "BMS or KDDART",
         body : {
           // any data structure implementor might want to add as extra info here