Ontology meeting 2015-04-23: Difference between revisions

From GO Wiki
Jump to navigation Jump to search
No edit summary
Line 9: Line 9:


If we need to keep some types of relationships out of the release file, can we please control this via a filtering mechanism at release.  Relying on editors to police this via what goes in subclassing axioms is incompatible with sensible use of logic for autoclassification (sometimes subclassing axioms are needed for classification, but equivalent class axioms would be wrong).
If we need to keep some types of relationships out of the release file, can we please control this via a filtering mechanism at release.  Relying on editors to police this via what goes in subclassing axioms is incompatible with sensible use of logic for autoclassification (sometimes subclassing axioms are needed for classification, but equivalent class axioms would be wrong).
<pre>
Response from Chris and Heiko:
We were surprised that this was the behavior, but it's not surprising that we were surprised as our build pipeline has gotten over-complex. Heiko and I spent the day untangling things.
The basic summary is:
- The assert-inferences operation is now run with every commit in build-go, but it does *NOT* write back to editors, only downstream products (validated.obo and it's derivatives such as go.obo)
- the http://build.berkeleybop.org/job/build-go-assert-inferences/ job and it's report counterpart will continue to run as normal. This is the one that writes back to the editors file
- one upshot of this is that users of go may see inferences *in advance* of editors working on OE mode. I think this is fine
- we actually have an extra level of checking now. As can be seen, build-go is failing due to the isa/partof issue I mentioned previously. I will make a temporary fix for this and we can discuss the temporary fix in the meeting
</pre>


=== Follow-up: Prefixing of obsolete to label of all obsoletes ===
=== Follow-up: Prefixing of obsolete to label of all obsoletes ===

Revision as of 18:27, 22 April 2015

Attendees:

Minutes: Paola


Please, Please, Please could we propagate from EC to subclass axioms on public release

We still need to redundantly repeat everything we say in Equivalent Class axioms in subclassing axioms in order to get things to appear in GO releases. While editing in Protege, it is almost inevitable that these are missed some times. This is a waste of everyone's time. e.g. see" https://sourceforge.net/p/geneontology/ontology-requests/11646/

If we need to keep some types of relationships out of the release file, can we please control this via a filtering mechanism at release. Relying on editors to police this via what goes in subclassing axioms is incompatible with sensible use of logic for autoclassification (sometimes subclassing axioms are needed for classification, but equivalent class axioms would be wrong).

Response from Chris and Heiko:

We were surprised that this was the behavior, but it's not surprising that we were surprised as our build pipeline has gotten over-complex. Heiko and I spent the day untangling things.

The basic summary is:

 - The assert-inferences operation is now run with every commit in build-go, but it does *NOT* write back to editors, only downstream products (validated.obo and it's derivatives such as go.obo)
 - the http://build.berkeleybop.org/job/build-go-assert-inferences/ job and it's report counterpart will continue to run as normal. This is the one that writes back to the editors file
 - one upshot of this is that users of go may see inferences *in advance* of editors working on OE mode. I think this is fine
 - we actually have an extra level of checking now. As can be seen, build-go is failing due to the isa/partof issue I mentioned previously. I will make a temporary fix for this and we can discuss the temporary fix in the meeting

Follow-up: Prefixing of obsolete to label of all obsoletes

Last week we discussed and resolved:

We should really do this for consistency. Or alternately remove from the release version since they are primarily there for the edit cycle. 
Consensus is we should be consistent and just prepend all the obsolete terms with obsolete-. The tag will still remain.

Are we going to retrofit and do this (automatically) for existing obsolete terms too? (We should, but can't remember.) Currently, obsolete term names come in 4 flavors, we need consistency:

- term name

- term name prefixed with 'obsolete' e.g. 'obsolete ATP catabolic process'

- term name prefixed with 'OBSOLETE' (only one example)

- term name prefixed with 'OBSOLETE:' (only one example)

ORE 2015

We should enter GO for this year's OWL reasoner evaluation competition. DOS: I'll enter go-plus.owl, but would also like to enter this combined with an annotation set expressed as OWL along with some queries across data. Can we get this ready for May 1st?

Axiomatizing Regulation of Biological Quality

Any objections to Chris' suggestion of going ahead and adding?

   DOS: Mostly looks good.  Not sure about location pattern though.
   occurs_in definition has domain process (although this is not formalised).

Details on email thread with same title on ontology list:

David H and I have gone through the proposed logical defs for RoBQs

http://wiki.geneontology.org/index.php/Extensions/x-attribute

(the wiki is v out of date, but these extension pages can soon disappear once is everything is part of the normal edit cycle)

These make use of OBA, which you can find out more about here:

https://github.com/obophenotype/bio-attribute-ontology/

including links to the OBA TG etc

I think they are now all valid (completeness can wait). I propose just going ahead and adding, raise any objections on thursday call

(Transmembrane) transport templates in TG

See email thread "Transmembrane transport again..." started by Paola on April 10th. Please comment.

Generic pattern in ontology:

transport/import/export
and ('has target start location' some A
and ('has target end location' some B)
and (imports some C)
and ('results_in_transport_across some D)

Should/could we implement this as a general TG template, or are more specific ones more appropriate?

New TG templates

Punted from two weeks ago:

The job of editors on SF and TG duties would benefit considerably if we could implement some TG functionalities we've already sort of agreed upon. We may want to revisit the related requests, prioritize, see what's missing.

1) TG: create MF-BP links when appropriate https://www.ebi.ac.uk/panda/jira/browse/GO-199

2) Create TermGenie templates with UBERON https://www.ebi.ac.uk/panda/jira/browse/GO-168 - follow-up

Last week we wrote:

 May be done already. Chris and Heiko will look into this.  Something is still missing. There was a problem with propagation over 'part_of' in
 the anatomy ontology and that extending into the GO ontology, development -- morphogenesis.  May be not urgent at this time.  Wait for requests
 to come in and then roll out the template.  Code is mostly in place but not switched on. Need to deal with the part_of thing before rolling out. 

A non-development request to add a part_of link that could have been inferred automatically: https://sourceforge.net/p/geneontology/ontology-requests/11635/

3) TG template for 'cellular component organization' https://www.ebi.ac.uk/panda/jira/browse/GO-327

4) TG template for 'cellular component binding' https://www.ebi.ac.uk/panda/jira/browse/GO-326

5) Create term genie template for response to organism https://www.ebi.ac.uk/panda/jira/browse/GO-212

GO-UBERON issues

Can we discuss Stan's hindgut issue and the issue of multi-species fuzziness in general?

https://github.com/obophenotype/uberon/issues/689