Chat from GitHub.
Hi Pete! I have a question about the BrAPI phenotyping spec. I was wondering whether it would be a good idea to also include fields for Variable Description and/or Variable Label. This stems from the importance of making sure the human-readable names get transferred with variable. What I am seeing is that when you call from CO (assuming the guidelines were followed pretty closely), observationVariableDbId would be their CO_321:0001199 ID and observationVariableName would be the trait_method_scale abbreviation. If calling from MIAPPE, observationVariableDbId = short name (possibly human-readable) or the Variable accession number (CO_321:0001199). It is very possible that the actual human readable name could be excluded depending on the source (most likely with CO, because MIAPPE has the variable name formatted as human readable, but does not actually require that field). Anyways, long story short having additional (optional) fields for Label and Description could allow that human readable name and more detailed description of the variable to stay linked to the variable itself. CO would (theoretically) render human readable name as Variable label. Any other situations and BrAPI could spec Variable label specifically as the human readable name. One specific use case this causes problems is when BreedBase ingests a new ontology (from CO for example) and there requires quite a bit of manual curation to get human-readable names rendered there and eventually to Field Book.
Hi Heather! Yes you are making sense. I would be happy to add a Variable Label and/or description.
However, this lead me to an actual error in the mapping between BrAPI and MIAPPE. MIAPPE has three terms DM-83 Variable ID, DM-84 Variable name, and DM-85 Variable accession number The mapping documentation here maps MIAPPE's Variable accession number (example: CO_321:0001199) to BrAPI's observationVariable.ontologyReference (example: CO_321) which is just incorrect. Would your issue be solved if BrAPI borrowed the Variable accession number directly from MIAPPE so they could be in more direct alignment?
We could also add a description field, though I'm not sure where the data would come from to populate it
Nice catch. Their Trait accession number also maps to observationVariable .trait .ontologyReference. I was also looking at the mapping on MIAPPE's github here and that is also different (they map Variable ID to BrAPI's observationVariableName and Variable Name to either observationVariableName or observationVariableDbId.
Are you thinking that their Variable accession number would now be observationVariableDbID or using that as the human readable label? Mapping it to observationVariableDbID makes sense. As far as Label and Description, I think there would still be a need depending on where the mapping is coming from. If the Variable Label and Description are added then there are actual endpoints to map to when available from the source (MIAPPE doesn't have a specific field for that, but CO does) especially when the required endpoints are not human readable or provide enough info to be useful.
To summarize:
We would like to add 3 optional fields to BrAPI Observation Variable: accessionNumber, label, and description
observationVariableName, label, and description must all be human readable
observationVariableDbId should be a primary key and a guaranteed unique value within its source database. It does NOT need to be human readable, only used by software to identify exactly one record
accessionNumber is reserved for the ontology's reference number (example CO_321:0001199 for Crop Ontology) It does NOT need to be human readable
Chat from GitHub.
Hi Pete! I have a question about the BrAPI phenotyping spec. I was wondering whether it would be a good idea to also include fields for Variable Description and/or Variable Label. This stems from the importance of making sure the human-readable names get transferred with variable. What I am seeing is that when you call from CO (assuming the guidelines were followed pretty closely), observationVariableDbId would be their CO_321:0001199 ID and observationVariableName would be the trait_method_scale abbreviation. If calling from MIAPPE, observationVariableDbId = short name (possibly human-readable) or the Variable accession number (CO_321:0001199). It is very possible that the actual human readable name could be excluded depending on the source (most likely with CO, because MIAPPE has the variable name formatted as human readable, but does not actually require that field). Anyways, long story short having additional (optional) fields for Label and Description could allow that human readable name and more detailed description of the variable to stay linked to the variable itself. CO would (theoretically) render human readable name as Variable label. Any other situations and BrAPI could spec Variable label specifically as the human readable name. One specific use case this causes problems is when BreedBase ingests a new ontology (from CO for example) and there requires quite a bit of manual curation to get human-readable names rendered there and eventually to Field Book.
Hi Heather! Yes you are making sense. I would be happy to add a Variable Label and/or description.
However, this lead me to an actual error in the mapping between BrAPI and MIAPPE. MIAPPE has three terms DM-83 Variable ID, DM-84 Variable name, and DM-85 Variable accession number The mapping documentation here maps MIAPPE's Variable accession number (example: CO_321:0001199) to BrAPI's observationVariable.ontologyReference (example: CO_321) which is just incorrect. Would your issue be solved if BrAPI borrowed the Variable accession number directly from MIAPPE so they could be in more direct alignment?
We could also add a description field, though I'm not sure where the data would come from to populate it
Nice catch. Their Trait accession number also maps to observationVariable .trait .ontologyReference. I was also looking at the mapping on MIAPPE's github here and that is also different (they map Variable ID to BrAPI's observationVariableName and Variable Name to either observationVariableName or observationVariableDbId.
Are you thinking that their Variable accession number would now be observationVariableDbID or using that as the human readable label? Mapping it to observationVariableDbID makes sense. As far as Label and Description, I think there would still be a need depending on where the mapping is coming from. If the Variable Label and Description are added then there are actual endpoints to map to when available from the source (MIAPPE doesn't have a specific field for that, but CO does) especially when the required endpoints are not human readable or provide enough info to be useful.
To summarize:
We would like to add 3 optional fields to BrAPI Observation Variable: accessionNumber, label, and description
observationVariableName, label, and description must all be human readable
observationVariableDbId should be a primary key and a guaranteed unique value within its source database. It does NOT need to be human readable, only used by software to identify exactly one record
accessionNumber is reserved for the ontology's reference number (example CO_321:0001199 for Crop Ontology) It does NOT need to be human readable