LEGO June 13, 2016
From GO Wiki
- Function Companion
- Importing Evidence
- When importing an MF annotation, the evidence includes the paper, the evidence code, and the orcid of the person who imported the annotation, but not the group or person who originally made the annotation, who should get credit
- Importing annotation extensions when using Function Companion
- Couldn't find a github ticket for this, but was wondering if/what we had discussed wrt importing annotation extensions when using the Function Companion (even if just a subset, e.g. has_input). Thx. --Kimberly
- Importing Evidence
- On call: Chris (until 9am PST), Dan, David H., David OS, Heiko, Kimberly, Melanie, Sabrina, Stacia, Val
- Over the last week, Berkeley has worked on some back-end preparations to update the evidence model that we treat papers as objects and thus allow additional information, e.g. text spans from papers via TextpressoCentral searches, to be associated with papers
- Heiko working on code for GAF generation
- Function companion - handling attribution
- When importing annotations using the function companion, the resulting import includes the paper and evidence code and the orcid of the curator who imported the annotation
- GAF output currently just populates the Assigned_by field as GO_Noctua
- GPAD assigns GO_Noctua but also includes the orcid of the curator who imported the annotations in the annotation properties field
- The curator (or their associated group) who originally made the annotations is not preserved
- What is the expected behavior for tracking attribution?
- For GAF, cardinality of contributing group is currently 1, so any change there would require a change to GAF specs
- GPAD could include more than one orcid in the properties field
- What is important to track and why?
- Individual curators or contributors, e.g. community members?
- Annotation groups, e.g. MGI, UniProt_GOA?
- Project, e.g. GO_Noctua
- Function companion - importing annotation extensions
- Currently when importing annotations using the Function Companion, annotation extensions are not imported
- This makes extra work for curators since they have to add that information manually
- Curators felt that annotation import, in general, should include annotation extensions
- Curators can always prune back extensions that might not be relevant for the particular instance they are modeling in Noctua
- This led to a broader discussion of the types of annotation imports that curators would like to use, as well as the expected behavior of each
- A github ticket has been created for this discussion - this ticket references other tickets that have touched on similar issus/requests
- Going forward, we will work through use cases for imports to make sure we've covered the desired behaviors
- Please read over the draft documentation on Google docs and add your comments.
- Note that the documentation can also be reached by following the Learn More link from the Noctua homepage.
- There is a lot in the documentation right now and we want feedback on what curators like/don't like.
- David OS working on importing GO-specific relations into RO
- There are usage statements associated with specific AE relations - these are operational, but not quite logical definitions
- Can be found in property_value usage in go_rel.obo
- Usage statement for occurs_in:
property_value: usage "Identifies the cell, tissue, cellular component or anatomical entity within which all parts of the molecular function or biological process occurs" xsd:string
- Want to have uniform way of expressing usage