Zoom URL
https://stanford.zoom.us/j/679970729
Agenda
github Trackers
- Clarification about which one(s) to use
- noctua - client and middleware code
- noctua-models - annotation (may be merged with go-annotation)
- minerva
Table Editor Workbench
- Chris and Seth will demo the new 'Simple annoton editor' workbench now available in Noctua
- The table editor allows curators to add, and edit, simple annotons in a table format
- Annotations entered in the table are automatically added to the Noctua graph editor
Annotation Provenance
- Review of how attribution is assigned for Noctua annotations
- de novo annotations
- imported annotations using function and component companions
Annotating with any UniProtID
- Use add individual functionality
Minutes
- On call: Chris, Harold, Karen, Kevin, Kimberly, Pascale, Paul T., Rob, Sabrina, Sage, Seth, Stacia, Suzi
New Noctua Features
- Curators can submit an issue to the github tracker from the Issues menu
- Model will be automatically referenced in the github ticket and the github ticket number will be listed in the models menu
- Simple annoton editor
- Curators are prompted to add an annoton, but can add distinct parts of the annoton, if needed
- Will be prompted to add evidence and a reference
- References are fairly neutral right now - can add PMIDs, GO_REFs - just need to have them be properly formatted (e.g., PMID:nnnnnnnn or GO_REF:nnnnnnnn)
- Save annoton button adds the annoton to the graphical view, but curators still need to add a title and save their models in the graph view
- ACTION: Curators need to test the editor and give feedback.
Modeling in Noctua
- We discussed what the current modeling statements in Noctua actually mean
- For example, the model currently requires that a molecular_function is associated with a cellular component
- Is it possible to make a different type of statement in Noctua, or GO in general?
- For example, a TF is observed in the cytoplasm, but it does not execute its MF there
- Curators should read Paul T.'s chapter about representation of function in the GO Handbook
- Can different localizations be annotated using different CC qualifiers?
- Counter-argument
- Shouldn't GO just be focused on capturing where activities occur?
- Adding more relations to CC could potentially generate another point for annotation inconsistency and noise
- One question: when would curators make an annotation to a CC and when not?
- If you don't know anything about a protein but its localization, curators would typically make that CC
- There is a distinction between saying a protein localizes to a CC and likely functions there vs a protein localizes to a CC and we don't know if it actually has a function there
- This is a very fundamental question for GO - what information do we want to capture and why?
- There are fundamental differences between the annotations that might result, say, from an HTP localization screen vs a well-studied gene for which we know exactly where and how it functions
- Should we use different qualifiers for CC?
- Should the GO supply different files with different qualifiers for our users?
- In terms of Noctua, what should the behavior be for simply adding a conventional CC annotation?
- ACTION ITEM: Draft different proposals for how to handle GO annotation statements going forward
- Annotation of well-studied genes vs annotation of isolated observations and GO-CAM models vs conventional annotation
- These proposals should be in place by the October GO meeting so we can discuss and make a decision
- Stakeholders and considerations:
- Developers
- Tool development and maintenance
- Impacts on data storage
- Impacts on annotation file generation
- Impacts on data display
- Curators
- Efficiency of annotation
- Capturing all data when reading a paper vs capturing only a defined subset of data
- Consistency of annotation
- Adding more relations increases the number of decision points during curation which could lead to more inconsistency, and could, at least temporarily, reduce efficiency
- Dealing with legacy annotation
- Individual groups could decide what is best for their annotation set
- Need for clear curation guidelines
- Users
- Clarity in semantics of GO annotation
- Ease of use of GO data, i.e. would GO users effectively use different slices of GO annotation
- Opportunities to use GO for different types of analyses
- Communication and outreach