Ontology meeting 2014-08-07

From GO Wiki
Jump to: navigation, search

Attendees:Paola, David H, David OS, Harold, Heiko, Tanya, Jane, Chris, Becky

Minutes: David H

'pathway' involved in 'regulation of' terms

Ruth requested 'regulation of adrenergic receptor signaling pathway involved in positive regulation of heart rate' plus pos. end neg. reg. children.

But 'adrenergic receptor signaling pathway involved in positive regulation of heart rate' is defined as "...The funny current is responsible for membrane depolarization and an increase in heart rate.". So the signaling pathway is upstream of the positive regulation of heart rate, rather than a part of it. Options:

1) The terms should be post-composed using 'causally_upstream_of' in annotation extension, and the terms obsoleted; see similar issue here: http://sourceforge.net/p/geneontology/ontology-requests/10750/

2) Add link 'positive regulation of heart rate' starts_with 'adrenergic receptor signaling pathway', and still get rid of the confusing GO:0086024.

Did we discuss this in the past - was the conclusion that we still want these terms to be involved_in so that annotations may propagate over part_of? If so, maybe we'd want to have them propagate over starts_with and ends_with instead? (But not over has_part in general).

There are 232 terms with label containing "pathway involved in". Some may be ok, but at a quick glance, many look similar, this one for example (see def): 'adrenergic receptor signaling pathway involved in cardiac muscle relaxation', def: "An adrenergic receptor signaling pathway that contributes to a reduction in cardiac muscle contraction. Beta-adrenergic receptor-induced *cardiac relaxation is achieved by* a GPCR-activated adenylate cyclase generating cAMP..."

For now we will allow this type of term, but we need to be very careful about how we parse the term.

TG template uberon metazoan development

Ready for testing, see https://www.ebi.ac.uk/panda/jira/browse/GO-169

Will only infer over is_a, not part_of. Do we really want to add if all the inferences aren't going to be there? Current proposal is to allow it through and then have the gatekeeper add the additional relations based on the anatomy part_of structure. We will need to prepare a standard operating procedure for this (David H and David OS).

In preparation for SF jamboree

AI from last week: We all need to take some time prior to the jamboree to comprehensively review tickets. Use the jamboree tag. Everyone to pick up their problem items, the ones that need input from others, whether for knowledge or for streamlining strategies. Then we'll work on them in rotation, say 1-2 a day from each editor.

'Foreign' compounds in GO terms

Stems from this SF ticket, please see latest comments (ticket has more than one page): https://sourceforge.net/p/geneontology/ontology-requests/10930/

We are not going to allow this in cellular component, but what about the response terms? When they are naturally encountered, then they would be ok.

cellular/multicellular distinction

David OS suggests: "Could we aim to get rid of the cellular/non-cellular distinction altogether, perhaps replacing it with a small number of more tightly defined differentia: intracellular, intercellular, extracellular, transport within tissue, transport between tissues … ?"

Jane: "I'm not convinced we can do away with 'cellular' but agree we need to do a better job at formalizing it."

Lots of discussion:

Can we split up the top level terms to make them either cellular or not? Maybe keep cellular things in place for now. Try to create logical definitions for the terms and see what falls out.

SO (bump to next week)

Should we use SO and switch later or wait for MSO?

Matt's response:

As for GO's needs, it should be straightforward to use the SO classes for now and automatically replace the URIs when the MSO is ready . . .  because the plan is for MSO class IDs to have the same numerical component as their SO counterparts, but the leading prefix will be "MSO_" instead of "SO_".  For example, the ID of MSO 'gene' will be MSO_0000704 instead of  SO_0000704. Should make swapping them out easy.

See also:


Review of Jira tickets (continued from last week) (bump to next week)

Last week we got as far as GO-198 included.