Ontology meeting 2014-01-16

From GO Wiki
Jump to navigation Jump to search

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

Minutes: Paola

Assert inferences job / Can we please use automation to make our lives easier rather than harder?

Does the assert inference job always instantiate all its inferences/removals in the master before review and corrections? If so, then the only way to remove the errors introduced is either to roll back the master - potentially losing edits that happen between instantiation and review - OR to remove by hand. Both options are a waste of time and effort. The second option is dangerous and potentially a massive waste of time and effort given that a single bad axiom can cause massive amounts of incorrect inference.

  Decision:
1. Freeze inference assertion for two weeks while we deal with the "EXISTS, TAGGED-INFERRED, NOT-ENTAILED" list.
2. A dry mode run of assert inferences will run at every check-in, starting ASAP
3. Once the assert inference job is started, incorrect inferences will be removed automatically at each weekly run. 
 It will be up to editors to add back anything they think should be retained.
4. Over the next 2 weeks we aim to eliminate all tagged inferred not entailed on this list (432 lines!)
5. Strategy: Rota for working on the list in turn (?)  
We will avoid taking the list in order as it is much easier to work on sets of similar items together
6. No rota yet, but David OS will work on this list on Monday - fixing and triaging. 

Progress:
Heiko writes: "as discussed during the call, I have disabled the normal assert-inferences job. 
As an alternative and to verify if changes did the intended thing, there is now a job which runs
 the verification after each commit in dry-run mode. No commit is done and there won't be an e-mail each time. 
The short cut link for the latest report file is the following:
http://build.berkeleybop.org/job/build-go-assert-inferences-report/lastSuccessfulBuild/artifact/assert-report.txt"

All that follows is bumped to next week

How direct does regulation have to be to justify a regulates relationship?

These inferred links result from regulates relationships that have been in GO for some time.

ADD GO:0007272 'ensheathment of neurons' GO:0051969 'regulation of transmission of nerve impulse' ADD GO:0007272 'ensheathment of neurons' GO:0098900 'regulation of action potential'

Paola notes: The ensheathment has an effect on action potential and therefore impulse transmission, but it's not a type of regulation, it's a separate process... what do you think? DOS: The regulating effect is clearly quite indirect (via changing the electrical environment of the membrane) - but do we have guidance on how direct regulation of a process has to be before we make a relationship? The documentation on regulation does not make this clear.

Should regulation of quality and regulation of biological process be disjoint?

If so, the hierarchy will need much untangling as many terms are under both.

(DPH) No. In almost all cases, once we know enough we will find that regulating a quality will be the result of regulating a process.

(DOS) OK. Thinking about it I can see how this could be true, but I'm not sure it is necessarily true. (To be fair, you did write 'in almost all cases'). Right now we have action potential as a process that regulates membrane potential (a quality). I'm not sure it does so by regulating a process, rather parts of the process (the flow of ions through membrane channels) result in changes to this quality. So perhaps it is still worth adding declarations of disjointness further down the hierarchy.

Abnormal cellular components (from Harold)

SF 10612 Abnormal terms in component https://sourceforge.net/p/geneontology/ontology-requests/10612/

Harold agreed that the SF ticket can be closed. Done.

Megafile update

Protege Plugin for OBO related data

Chris has started to spec out the requirements for a new Protege Plugin.

The main task is to provide a concise and useful representation of OBO-relevant annotation properties (label, def, synonyms, ...).

The plugin itself will not be OBO-specific, but will provide a default mode for OBO (GO?). Here is the current out-line/discussion: https://docs.google.com/document/d/17tph3jwrDGEaa7DyYPOK8HCi2dCDdJxi3VrTWNQpbqc/edit?pli=1#

Draft formalisation of multi-species annotation

https://docs.google.com/document/d/196nLKiQ2Go4toilCq226w7u0p52odvCkq-bU5qgtzu0/edit?usp=sharing

There are two versions. The first is probably best. The second doesn't make individuals for classes and as a result uses some odd nominalisation patterns in the class expressions.

OWL files implementing these examples are here:

http://viewvc.geneontology.org/viewvc/GO-SVN/trunk/experimental/David/multi_species_annotation/

Have a look at the query classes. Can you think of any more useful queries?

One piece of formalisation I feel unsure about right now: I'm wondering whether we need to have the relationship between gene product and organism be 'encoded by' rather than 'expressed in' or 'expressed by'. In the case of viruses - it is arguably the host that does the expressing.

A second issue: I'd like to make this consistent with the formalisation we're working on in PCO - I still think we need some kind of formal bridge between NCBI taxon and organism terms in CARO2/PCO. I guess this could be a simple as making an equivalence mapping between the root of NCBI taxonomy and some term for an individual organism (or organism, virus or viroid).

Also to discuss - how this fits with Lego.

Ontology Development project about Ubiquitination

Seems there has been lots of discussion internally and there are other groups that would like to see improvements in this area.