Ontology meeting 2015-03-19
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.
Follow-up: Acids and bases in GO
Copying from two weeks ago - any action item left for this? Documentation?
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. "
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)
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
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