LEGO June 27, 2016
From GO Wiki
MGI Meeting Follow Up
- Review the list of software and annotation issues that were discussed at the MGI training session, June 15th-16th.
- See the Google doc
On call: Dan, David H., David OS, Jim, Kimberly, Melanie, Midori, Sabrina, Seth, Stacia
- No updates.
Review of MGI Training Action Items
- GAF/GPAD output is the top software priority from this meeting
- Several issues here that need to be addressed:
- Causal relations - making sure we get the regulates, causally upstream of, or causally upstream of or within annotations that curators want since these are annotations they would typically make doing conventional GO annotation
- Qualifier column in GAF/GPAD will be used to store new relation information
- Question arose about what types of annotation files GO should provide wrt Biological Process annotations
- All associations in one file?
- Separate files for different causal relations?
- Multiple evidence on an assertion should yield separate lines of annotation
- This issue was raised with Heiko and there is a github ticket
- Dependent on the evidence model re-factor?
- MF-BP Links
- When curators make an MF annotations in Noctua and there is a BP link, at what point will those annotations be included?
- Would be nice to show these as curators are annotating, e.g. in a form interface, but do we have the infrastructure in place to do this?
- To generate a module with inferred links could take ages?
- Will we potentially generate duplicate annotations doing this? If so, how best to deal with that?
- Gene product identifiers
- Groups will need to provide a gpi file that includes every entity that they would like to annotate in Noctua
- The gpi file will be used to construct NEO (Noctua Entity Ontology) for use in the auto-complete and validation functionality
- Question arose about the extent of DB_xrefs that should be included in the gpi file
- For example, GOA currently does not include DB_xrefs in their gpi files, but could do so if there is a finite set needed
- One outstanding issue here, though, is how to make sure we get the semantics right in the OWL representation
- One solution would be to have a translation in the back end
- Another solution is to develop and use relations such as, has_input_product_of, so groups could use gene IDs for curation but still get the semantics correct if the GO term referred to an activity with a protein input, e.g. protein kinase activity
- ACTION ITEM: Review specs for gpi file for different entities to make sure what to put in each column is clear to contributing groups.
- One of the consistent messages we hear from curators is that it is sometimes difficult to choose the correct relation and then find it in the list presented in the pop-up window
- One possible solution is to restrict the set of relations offered for LEGO modeling and further, match the relations to the correct set for a given set of individuals
- For the former, we could display a smaller set of relations in a TermGenie-like manner where curators could browse the hierarchy to select the correct one
- For the latter, to what extent can we make use of the logical definitions, or design patterns, for terms?
- Agreed that is would be nice to have the relations dynamically populated, but that will be harder to do than to have a hard coded list from which to populate a list
- For the short term, we will generate the most up-to-date list we can so it can be hard-coded into the Noctua software
- For the long term, we can think about what infrastructure would be needed to serve relations up dynamically