Ontology meeting 2015-02-05

Attendees:

Minutes: David OS

Review of release pipeline

Chris would like to do a review of the release pipeline, and have James Overton join us, he is reengineering OORT.

   Background:  Oort hard-wired the release process.  
   This turned out to be too rigid for GO - and for some other OBO ontologies.  
   These now use various OWLtools commands strung together using Make files.
   May move instead to using Gradle
    {- with re-engineered OWLtools?  not clear - Ed}
   Chris: This could help to deal with some versioning issues in imports
  
   Questions:  Is there anything about the release pipeline you'd like to change?
   DOS:  Less files?  (Thought of while writing up notes:
    May be some demand for tools that allow specification of beskpoke files with some specified cut of relations.
    Tony has suggested this as potentially useful for QuickGO.
    Would only make sense if equivalence axioms relaxed to subClassOf.)

Membrane Issues

Logical definition issues with partial membranes. Many membranes are classified as 'membrane part', but have no further classification or like 'dendrite membrane' have no indication that they are part of a dendrite.

https://www.ebi.ac.uk/panda/jira/browse/GO-186

 Mostly good. Notes on issues added to ticket. 
 AI: DOS will edit obol results.  Chris will merge edited axioms into GO.

Organization branch

We could get a lot more automated classification if we relax genus to something very general - probably 'cellular process'. There doesn't seem to be any over-inference that results - although we may need to stick to a convention of using has_output in the cellular_component biogenesis branch. Should we do this?

 DOS has already changed axiomatisation of root terms.  No problems encountered (at least none that aren't due to problems elsewhere).  
  All agreed that this was a sensible change.

TermGenie templates for receptor activity

Please look at https://www.ebi.ac.uk/panda/jira/browse/GO-240

Where are we with this?

  AI: Harold will do a first pass and try to fill in as many XPs as he can.
  WIll then report back.  Hold off on template.  But could go ahead if we get a batch of requests.

Jira tickets

Need to review the situation with Chris. (Paola has a list of tickets that need special attention. For my own reference, they're in an email thread "GO tickets in the EBI Jira instance".)

  NOT DISCUSSED - MOVE TO NEXT WEEK.

Obsoleted/merged terms in external ontologies we cross-ref to

Need solution. Reported in https://www.ebi.ac.uk/panda/jira/browse/GO-161

   Chris suspects that this is due to failure of term to be imported due once logical axioms are removed on obsoletion.
   Poss solutions:
   (a) Check for obsoletion prior to regeneration of import files.
   (b) Make report of dangling terms.
   AI: Chris to add details of fix to ticket

Sources of db_xrefs

Sometimes, db_xrefs go stale and this is hard to keep under control. See a recent example here: http://jira.geneontology.org/browse/GO-716

We should probably have some kind of minimal guarantee of sustainability for sources.

Ideas?

[Paola] We need to define 'sustainable sources', other than the obvious PMIDs and ISBNs. E.g. Wikipedia; others? Criteria? We may want to make sure that new terms have at least 2 db_xrefs if one of them is in danger of going stale. For existing terms, how feasible would it be to pull out all terms that have only one db_xref, check that the single db_xref is from a 'sustainable' source, collect the suspicious ones, and update them? If too many, possibly a project for a summer student? Or, (a more systematic approach maybe) how feasible would it be to compile a catalogue of all unique types of db_xrefs in GO (with an indication of how many instances of each we have), inspect these unique db_xrefs types, mark the suspicious ones and update them?

General consensus: we should stick to papers, reviews and books.

However: 1) What about medium-to-large scale mapping projects? 2) Sometimes books are not available or fully accessible.

  Discussion: Can we just check everything for 404 nightly. Make big report?
  Harold:  Might hammer pubMed too much to check everything ?
  Consensus: We should run checks, but excluding sources, like pubmed, that we assume to be stable.
  Chris:  We may be able to roll this into a system we already have for checking the status of our own resources.
   AI: ??

OWLTools project moved from googlecode to github

[Chris] owltools is a kitchen-sink library for working with ontologies developed in large part by the GO. The project was previously sourced on google, now here: https://github.com/owlcollab/owltools

It's something of a misnomer, as it includes things that go beyond OWL, including GAF processing, map2slim, loading golr. Some of this may be refactored into different repos in the future.

ontology group: in you do anything beyond obo/owl conversion you'll want to be sure you're getting the latest code from gh. Can discuss on OG call

  AI: EDITORS TO MAKE SURE THEY ALL HAVE THE LATEST CHECKED OUT AND BUILT. 
  Best to all be using the same for obo to owl roundtrip while we still need to do this.

Follow-up: working with ChEBI to add high-level disjoints

(For background, see http://wiki.geneontology.org/index.php/Ontology_meeting_2015-01-27#Adding_disjoints_under_.27binding.27_.28and_more_broadly_in_the_ontology.29)

Paola and David discussed this with Helen. Janna is ending her 9 years at EBI soon, so we should arrange a meeting with ChEBI soon if we wish to explore feasibility.

  Chris:  Bigger picture question here is how we make sure that ChEBI doesn't stray the OWL way of doing things
    once Janna leaves.  Should discuss this with her.
  AI: Paola and David to organise meeting with Janne to discuss disjoints & the OWL-yness of ChEBIs future.  
  Before meeting should: 
   (a) check out the extent of existing disjoints in ChEBI. 
  (b) Come up with a rough priority list for high level disjoints to add.

Filling in missing positive or negative regulation of xxx terms

See https://sourceforge.net/p/geneontology/ontology-requests/11498/ and Paola's comment there.

Are we in favor or against? And how feasible is this?

  Chris & Harold - there are definitely cases where this doesn't make sense, so will need to stay manual.
  (Perhaps we could encourage people to add all three, if they are all biologically feasible/meaningful?)