GO-CAM August 23, 2017: Difference between revisions

From GO Wiki
Jump to navigation Jump to search
Line 60: Line 60:
***Developers
***Developers
****Tool development and maintenance
****Tool development and maintenance
*****Changes to UI
*****Changes to existing UI
****Impacts on data storage
****Impacts on data storage
****Impacts on annotation file generation
****Impacts on annotation file generation

Revision as of 17:35, 23 August 2017

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
          • Changes to existing UI
        • 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
          • We will need clear annotation guidelines
        • Dealing with legacy annotation
          • Individual groups could decide what is best for their annotation set
      • 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