GO-CAM Working Group Call 2018-09-18: Difference between revisions
Jump to navigation
Jump to search
Line 4: | Line 4: | ||
=Agenda= | =Agenda= | ||
== Evidence Codes in Noctua == | |||
== Evidence Codes in Noctua == | == Evidence Codes in Noctua == | ||
*Currently, Noctua allows for use of the full Evidence and Conclusion Ontology | *Currently, Noctua allows for use of the full Evidence and Conclusion Ontology | ||
Line 10: | Line 11: | ||
**has_related_synonym 'IDA' | **has_related_synonym 'IDA' | ||
**database cross reference GOECO:IDA (inferred from direct assay) | **database cross reference GOECO:IDA (inferred from direct assay) | ||
*Some groups, e.g. SynGO use an expanded set | |||
*Have had feedback that it's harder to find the traditional GO codes, although searching by the first word of the label works well for finding the relevant code | |||
*Need to gauge how big an issue this is for curators | |||
*There are possible work-arounds but they all have pros/cons | |||
**Hard-coded list | |||
**Boost to specific fields in search result, i.e. fine-tuning specific autocompletes - any unintended consequences? | |||
*Best long-term solution? | |||
== Relations between MF and Input(s) == | == Relations between MF and Input(s) == |
Revision as of 20:04, 17 September 2018
Meeting URL
https://stanford.zoom.us/j/976175422
Agenda
Evidence Codes in Noctua
Evidence Codes in Noctua
- Currently, Noctua allows for use of the full Evidence and Conclusion Ontology
- GO has typically only used a subset of ECO codes, e.g. IDA
- ECO:0000314 direct assay evidence used in manual assertion
- has_related_synonym 'IDA'
- database cross reference GOECO:IDA (inferred from direct assay)
- Some groups, e.g. SynGO use an expanded set
- Have had feedback that it's harder to find the traditional GO codes, although searching by the first word of the label works well for finding the relevant code
- Need to gauge how big an issue this is for curators
- There are possible work-arounds but they all have pros/cons
- Hard-coded list
- Boost to specific fields in search result, i.e. fine-tuning specific autocompletes - any unintended consequences?
- Best long-term solution?
Relations between MF and Input(s)
- has_input vs has_direct_input
- Proposal: replace has_direct_input with has_input; obsolete has_direct_input
- Need to review has_input annotations to remove any extensions that are inconsistent with GO-CAM usage, i.e. an indirect or unknown proximity for an input
- Seth retrieved, as of 2018-07-31, all MF annotations that use has_input in annotation extensions.
- Initial review:
- used to capture a regulatory effect, e.g. protein kinase activator activity, when it was not known whether the effect was direct or indirect (e.g. expression of protein or complex X increases the activity of Y)
- used to capture a regulatory subunit whose presence is necessary for the activity to occur (e.g. cyclin-dependent protein kinase)
- used to capture an enzymatic activity when it was not known if the effect on a substrate was direct or indirect (e.g. caspase-dependent but not known if it was the caspase mutated)
- used to capture an enzymatic substrate where there wasn't also a direct binding assay in the paper (e.g. testing possible chemical substrates for glucuronysyltransferase activity)
- used to capture metal ion-dependence of protein binding (e.g. Ca2+-dependent protein binding)
- used (correctly) to capture the physiologically relevant input in a binding reaction (i.e. cross-species experiment where with/from captures experimental binding partner and AE the relevant binding partner)
- Initial review:
- Relations Ontology working group (broader than just GO) that is also considering how to model participants in an MF and documentation of has_input and child relations