Ontology meeting 2015-03-19

Attendees:

Minutes:

Protein family binding terms

We've been discussing this over the past few weeks, and it was brought up again at the managers call yesterday. E.g. see http://wiki.geneontology.org/index.php/Ontology_meeting_2015-03-05#How_to_define_protein_families_in_enzyme_binding_terms where the resolution was NOT to allow for protein family binding terms. If so, we need a strategy, and we then need to communicate it broadly (mailing list, annotation call, all-hands GOC call?). Paul T tested a promising strategy based on a list of recently requested terms that David H provided. Let's discuss.

For reference: a recent SF request: https://github.com/geneontology/go-ontology/issues/11693

  All agreed that the best way to do this is using 'protein binding' + AE (not with!) to protein.
  But to make this useful we will need to either make new defined classes for binding + Panther family, 
  or enable grouping via some automagic on-the-fly system in Amigo2.

  We should also do the equivalent for domain binding using pfam

  DOS: But how do we put this into usable tools in the near term.  
  We will get push-back from curators if we don't have a reasonable proposal for this.

   Chris: We also need to have a plan for the existing named classes.  
   To be consistent we should get rid of terms and convert them all to
   annotation extension

   Big question: How can this fit into Term enrichment?  Do we have a generic solution
   for term enrichement that works for cells, chemicals etc as well as
   protein families.  Or do we implement a specific strategy for panther
   domains.  Paul:  this would be easy to do using panther DB, don't even
   need OWL inference.

   Chris: I already have AE folding and unfolding code:  Makes extended ontology terms on the
   fly - but this would only make the leaf nodes.  Still doesn't give us grouping terms need.

   Summary: We all agree that on the solution   - rather than bloating GO with ad hoc binding terms, 
   binding should be recorded in annotation extension.
   But we need a realistic plan for how to provide the tools to allow users to take advantage of the 
   information recoded in this way.  Extending the GO term enrichment tool to cope with this (and annotation 
   extensions more generally) needs to be a very high priority.

New Protege release

Please test and give feedback (or plan to do so by the next call if possible). For details, see Chris' email 'New Build of Protege 5.0.0 Beta available' dated March 11th.

   Not Discussed

Follow-up: Acids and bases in GO

Copying from two weeks ago - any action item left for this? Documentation?

   Not Discussed

Stemming from https://sourceforge.net/p/geneontology/ontology-requests/11524/

The solution we've adopted so far is proving unsatisfactory specifically with respect to NH4+, NH3 and NH2- conjugate-acid-base relations. We need to think of an alternative, with or without the direct involvement of ChEBI.

Does NH2- exist in biology (azanide ion) (Harold: I can't find; it is really unstable; reacts with
water quickly to form NH3 + OH-; Azanides as a class: Chebi has; these aren't like natural metabilites
More like drugs, etc. 
Option: exception to the GCI generation rule (equivalence is transitive so we have to do this): 
for azanide; We should document this somewhere very well for all times we have to do this.

Update from Heiko (March 10th): "as discussed on the call, we have modified the generator for bio-chebi. It now supports exceptions for the generation of the GCI axioms, i.e. ammonia and it's conj base/acids. The current approach to define these exception is a new subset in the seed file for bio-chebi generation called no_conj_equiv. The bio-chebi.owl update file has been committed today. "

results_in strategy

See emails from Chris (threads on go-ontology 'results_in outliers' and 'results_jn refactor'). Chris asked for feedback on his proposal. Discuss, then reply to email thread.

results_jn refactor: Looks OK, but has many very indirect cases.

(Note that, since generation of Chris' list above, we've approved a couple of terms created with the old reg_by_reg TG template)

   Not Discussed

catabolism and biosynthesis

Are we going to create a new relation for the entities that are being manufactured and degraded? Just having input an output is resulting in inference errors.

   Discussed briefly at start of meeting.  General consensus seems to be that more specific subproperties of
   has_participant will be necessary as genus is not sufficient. Previous discussion of this has gotten rather 
   bogged down on the definition of has_input and has_substrate.  However, we may be able to define
   general relations for synthesis and degredation.   NEEDS FURTHER DISCUSSION.

long term hosting of ontology project and issue tracker

• Should we migrate our ticket archive? https://trello.com/c/nf1HDHwv/149-evaluate-feasibility-of-migrating-tickets-from-sourceforge
• If we migrate to github, should we migrate files too, so files and tracker are co-hosted and can be mutually referred to
  • here is an example of how this works: https://github.com/obophenotype/uberon/issues/585

   Not Discussed

interesting TGFF request

[Term]
id: GO:1990708
name: conditioned place preference
namespace: biological_process
def: "The ability of an animal to learn and remember an association between a putatively rewarding, internal state 
produced by a xenobiotic or drug with a neutral, unchanging environment." [PMID:21549821]
subset: termgenie_unvetted
is_a: GO:0008306 ! associative learning
created_by: sl
creation_date: 2015-03-18T20:28:59Z

  Decision: We agreed this term is OK.  As it describes a specific learning process.
  DOS further note:  Having re-read the definition, I think it is too strict for the name.  
  A conditioned place preference may be learnt by a varierty of mechanisms, not just 
  association with a 'putatively rewarding, internal state produced by a xenobiotic or drug'.  
  It would be better to have a more general term with this name and, if necessary, a more 
  specific term for how it is produced.
  See http://en.wikipedia.org/wiki/Conditioned_place_preference