Ontology meeting 2013-10-31

Attendees:

Chris, David OS, Heiko

Follow-up: EXISTS, TAGGED-INFERRED, NOT-ENTAILED

Was the solution below implemented?

(From the Oct. 17th meeting:) Decision: Inferred classifications no longer inferred are removed automatically, but a report is sent out listing which are being deleted. This happens at each commit (?). It is the responsibility of the person doing the commit to check that the removed classifications are expected. Note: removing at each user commit may be technically tricky in that it will require running scripts to generate a new file and then committing this.

Decisions

For now - we carry on with business as usual. There are too many dangers in trying to automate removal of links given the hybrid model we currently follow. Ultimate aim: get rid of asserted inferred links in editors file. Relay on editors accessing reasoner. Interim support for accessing reasoner: implement support for elk in OBOEdit. This will require editing a megafile (or a hack that kinda supports imports in OE). Interim experiments: using a version of GO with inferred links stripped out & elk reasoning in Protege. DOS to expt and demo to editors. At the same time, and in collaboration with Simon, develop OBO-Edit annotation property plugin for Protege (or generic configurable annotation property template).

Follow-up: Creating a megafile

(From the Oct. 17th meeting:) David OS to experiment & report back to Chris. (See background here: http://wiki.geneontology.org/index.php/Ontology_meeting_2013-10-17#Creating_a_megafile)

New OE features needed:

1. Support for saving import tags in header

2. Ignore ontology tag in merge to internal OE model (right now the filtered saved file has multiple ontology tags coming form imports).

3. Relations need to work entirely on imports.

Further down the line we want to be able to save an OWL file from OE and convert import declarations to their OWL equivalents. This is challenging because OWL requires spec of URI. Chris suggests a catalog type system.

Problem - how do we deal with regenerating imports? - needed every time a new external term is required. Also when term genie adds a new term - we also need imports to be updated (Note TG uses full files to allow users to choose what they want). Would also be very useful if import files included definitions (added to CL tracker - Chris will migrate from there once it works)

Follow-up: TG TEMPLATE FOR ORGANELLE PART (LUMEN, MEMBRANE)

Background:

"We've scheduled to have this done by the end of Q4/13.

The Jira ticket is https://www.ebi.ac.uk/panda/jira/browse/GO-185

Looking at Chris' comments in its sub-task "Verify that all xps for existing organelle part (lumen, membrane) terms are in place" (https://www.ebi.ac.uk/panda/jira/browse/GO-186), what do we need to do here?

Need to be sure that all inferences work using part_of"

Where are we with this?

At the Oct. 17th meeting, Chris and DavidOS agreed to discuss potential patterns for this, and report back.

Progress:

Do we really need a relation?

surrounds is not safe as a template (e.g. inner mitochondrial membrane is_a mitochondrial membrane but does not surround mitochondria). But could be used on an ad hoc basis. Note surrounds here is a SubProperty of part_of. (membranes are clearly part of the organelles they 'surround'). Would be good if we could formally define this relationship further. A relation that excludes part_of - bounds. Also implies adjacency - which strictly may be necessary.