GO-CAM November 8th, 2017: Difference between revisions
Jump to navigation
Jump to search
Line 64: | Line 64: | ||
*'''ACTION (DONE)''': Added [https://github.com/geneontology/go-site/issues/453 github ticket] to go-site repo | *'''ACTION (DONE)''': Added [https://github.com/geneontology/go-site/issues/453 github ticket] to go-site repo | ||
=== Legacy Annotation === | === Legacy Annotation (in the sense of "old GO-CAM models") === | ||
*For legacy models, and here legacy refers to models that were created before the providedBy tag was populated for each evidence, we will need to decide how to populate providedBy in the evidence | *For legacy models, and here legacy refers to models that were created before the providedBy tag was populated for each evidence, we will need to decide how to populate providedBy in the evidence | ||
*For all development and production legacy models: | *For all development and production legacy models: |
Revision as of 20:50, 8 November 2017
Zoom URL
https://stanford.zoom.us/j/679970729
Agenda
Noctua GitHub Organization
- Using projects to organize tickets
- Using milestones for ticket prioritization
- Creating new tickets - do we need a different SOP?
Requirements/Roadmap
Attribution
Attribution with GO-CAM exports to GOC annotation files
- Current behavior: example model: http://noctua.berkeleybop.org/editor/graph/gomodel:59dc728000000246
- Each piece of evidence is associated with values for Contributor and providedBy
- Contributor = orcid
- providedBy = annotation group
- Currently, for new annotations, even when the appropriate annotation group for an individual contributor is selected in Noctua, the Assigned By field in the resulting GPAD is populated with GO_Noctua
- This is true for both the Annotation Preview and the gpad files on Jenkins (http://build.berkeleybop.org/job/export-lego-to-gpad-sparql/lastSuccessfulBuild/artifact/legacy/gpad/)
- Currently, for annotations imported using the Function Companion:
- The Contributor field is the curator who imported the annotation into the model
- The providedBy field is a PURL for the annotation group who originally made the annotation
- Note that at the model level, all providedBy values are associated with the model (see Model -> Edit Annotations)
- Legacy behavior: example model: http://noctua.berkeleybop.org/editor/graph/gomodel:586fc17a00000273
- No providedBy field in the evidence or at the model level
- If curator is only affiliated with one group -> providedBy
- What about annotations imported using the Function Companion?
- If curator is affiliated with multiple groups ->
GPAD Outputs
- Annotations groups will consume GPAD only?
- GPAD missing annotations via 'causally upstream of'?
- TEST: causally upstream of - KRC
- With Chris, Jim, and Karen out for today's call, I suggest that we take up these issues again on the next GO-CAM call on November 8th
Simple Annoton Editor
dealing with blank MF in the simple annoton editor
Extend form to include standard GO-CAM model fields
Bare MF annotation should generate part-of triples
- Editor enhancements to come:
- Ability to add basic set of annotation extensions, e.g. has_input for an MF
- Ability to just add a CC annotation and get the resulting part_of annotation in the graphical interface
Minutes
- On call: David H., Dmitry, Harold, Jim, Karen, Kimberly, Pascale, Paul T., Rob, Sabrina, Seth, Stacia
Attribution
Current Annotation
- We need to have groups properly captured in the Assigned By field of output GPAD files
- All current and future Noctua curators who are associated with one or more curation groups need to fill out the groups field in their entry in the users.yaml file
- Full path: https://github.com/geneontology/go-site/blob/master/metadata/users.yaml
- Groups are entered as URLs, e.g. http://www.wormbase.org, in single quotes
- If curators belong to multiple annotation groups, the first group will be considered the default
- To change groups in Noctua, select from the drop-down list next to the curator name in the upper right of the tool
- ACTION (DONE): Added to agenda for 2017-11-14 annotation call
- ACTION (DONE): Added github ticket to go-site repo
Legacy Annotation (in the sense of "old GO-CAM models")
- For legacy models, and here legacy refers to models that were created before the providedBy tag was populated for each evidence, we will need to decide how to populate providedBy in the evidence
- For all development and production legacy models:
- How many models just have a single curator?
- For single curator models, we will need to confirm with each curator what their preferred annotation group should be
- How many models have multiple curators?
- For multiple curator models, we need to determine if there is one annotation group or multiple annotation groups
- If there are multiple annotation groups, curators will need to decide how they want to handle annotation attribution
- ACTION: Seth will investigate the distribution of curators on legacy models and report back so we can formulate a plan for populating providedBy in legacy models
- How many models just have a single curator?
- For legacy models that included annotations from the function companion, it may be difficult to trace, and we may not be able to deal with these annotations via a script.
- This issue needs a bit more investigating, but note that we always want to preserve the provenance of the annotation and give credit to the correct group.
Assigned By in GPAD Output
- ACTION:Chris, Jim, and Seth will review what code/pipeline revisions need to be made in order to populate providedBy correctly for GO-CAM models
Prioritization
- ACTION:All github tickets relating to proper providedBy attribution will be assigned the 1.0 milestone
- Note that 1.0 milestone exists in the noctua repo but not in the minerva repo or the go-site repo and some relevant tickets are housed in both of those latter repos
Related Issues
- Several other related issues arose on today's call:
- Is it important to somehow flag annotations imported into Noctua from some other source, e.g. AmiGO or TextpressoCentral?
- We need to think this through some more, but if yes, it would require changes to
the underlying data modeladd the appropriate (owl) annotations to mark the data.
- We need to think this through some more, but if yes, it would require changes to
- Importing annotations from AmiGO will result in redundant annotations when groups collate all annotations for their organism.
- Seth: I believe that we already have some filtering system either in place or in planning; we'll need to verify this, creating tickets as necessary for any gaps.
- MGI has already dealt with this, but we should have an SOP for all groups to follow.
- What if Noctua curators don't belong to an annotation group?
- We will need to have an SOP for this, but this is not a showstopper for the 1.0 release.
- Is it important to somehow flag annotations imported into Noctua from some other source, e.g. AmiGO or TextpressoCentral?