Ontology meeting 2016-05-12

From GO Wiki
Jump to navigation Jump to search

Attendees: Paola, David OS, David H, Harold, Heiko, Tanya, Paul T, Melanie, Chris

Minutes: Tanya

Old Business

Val's requests - discuss term specificity

Val can't make it this week, so we will postpone this until we can all make it again. (June 2nd looks like the first good date. Paola made a note to follow up with Val closer to then.)

ETINEs-removal of stale inferred relations that are no longer valid

How close are we to having a remove and reload strategy for inferred relationships? If this is ready to go, we need to have one of these calls where everyone is instructed on the what new filters we need in OBO edit and someone should create step-by-step documentation about changes to editing procedures.

https://github.com/geneontology/go-ontology/issues/12315#issuecomment-215582241

 Jenkins is currently down but will be back. Work is in progress.  No time to work on this right now but it is pending. 
 Everything is in place but hasn't been executed.
 Filtered save will change.  Same settings for renderer can be used to show inferred links as a different color.
 Need to update Wiki documentation - update filter settings when this new feature goes live.

New Business

Requests for Terms Referring to Protein Families

We have previously discussed how to handle terms that refer to protein families in protein binding terms and a new request has come in that also involves this issue (GH ontology issue 12440). How are we going to handle these kinds of terms? I don't think that putting terms that refer to all of the different protein families in the ontology is sustainable or practical for reasons that we have already discussed with respect to protein binding. So how will we handle this? Will we only record information if the specific target gene is known? The proposal for protein binding was to record the target gene and then at some later step computationally determine the protein family membership.

GH12440

 These types of terms are not desirable.  Without the specificity, knowing which protein is being regulated and being able to put
 that target in the annotation extensions, the usefulness of the annotation is suspect.  This type of non-specific annotation does
 not make sense in the LEGO view as it is too vague. These types of terms will no longer be added into the ontology.
 
 Evaluate which resources can use AEs and which can't.  In LEGO call, find out what the blockers are and how they could be reduced/
 removed.  Try to guide them towards a path that will enable such annotations as they are the most specific and capture the most
 knowledge.
 Look at existing terms of this type and make a plan for removing them so that new terms of this type will not be requested based
 on the preexistence of similar terms.

Cell-cell signaling differentiated by signaling molecule

On the LEGO call, DavidOS proposed that we should have ontology terms that represent cell cell signaling by specific molecules, for example 'Wnt cell-cell signaling'. Up until this point we have avoided the addition of these types of terms, but they could be useful grouping classes. Do we want to go this route? If so, can we come up with standard equivalence axioms?

DOS:

  • I think these are useful because they give us grouping terms covering Sig trans, ligand release (perhaps we should broaden to include processing?), co-receptors & any factors facilitating transport of ligand between cells.) Wnt signaling example discussed on the LEGO call may be instructive.
  • we already have some of these for trans-synaptic signalling. I've just been using 'mediated by' some fu. Easy for chemicals from ChEBI. Harder for families of related ligands.
 Useful as grouping terms in most cases but probably also as terms to use for annotation.
 PaulT:  ...it makes a lot of sense to have an overarching class, with subclasses that divide 1) events in the cell that 
 generates and releases the signal, and 2) events in the cell that receives the signal
 DOS: will manually wire up the part_of/ has_part relations after creating the parent class, might be able to automate 
 a part of the process
 Consult Becky for input.
 
 Long discussion on use of the causally-upstream-of relationship in LEGO models and how far upstream that relationship goes,
 implications on reasoning.  Will be further discussed in LEGO call.