Ontology meeting 2012-09-26

From GO Wiki
Jump to: navigation, search

60-minute meeting

MINUTES: Becky

ATTENDEES:

  • Judy
  • David
  • Tanya
  • Chris
  • Heiko
  • Becky
  • Paola
  • Harold


CHEBI PAPER

  • It's over the journal limit for Nature Chemical Biology at the moment. Judy is going to edit as a fresh pair of eyes, and Jane is going to try and crop also. If can cut it down and retain its integrity, can still submit to NCB.
  • Need to change lots to past tense, where we've already done the work.


Transmembrane Transport

BACKGROUND

The builds keep failing because several 'x transport' terms have an 'x transport' XP and an 'x transport' definition, but have a 'y transmembrane transport' parent or ancestor.

E.g.

purine-containing compound transmembrane transport ; GO:0072530 
--[isa]purine nucleobase transport ; GO:0006863
--[isa]purine nucleoside transport ; GO:0015860
--[isa]purine nucleotide transport ; GO:0015865
[Term]
id: GO:0015865 ! purine nucleotide transport
intersection_of: GO:0006810 ! transport
intersection_of: transports_or_maintains_localization_of CHEBI:26395 ! purine nucleotide


OPTIONS

  1. Rename all 'x transport' terms that have a TM transport parent to 'x transmembrane transport'. Also need to update definitions and XPs.
  2. Move all 'x transport' terms OUT from under a 'TM transport' parent. Keep their definitions and XPs as 'x transport'.

Need to decide what we mean by 'transmembrane transport' and whether we can assume that most/all transporters are acting across a membrane.


PLAN OF ACTION

GO WITH OPTION 2: Given that most people probably annotate based on the definition rather than the placement, it will be safer to move the 'x transport' terms up in the graph so they don't have a transmembrane transport parent. Will need to check definitions, XPs and synonyms (some 'x transport' terms have 'x transmembrane transport' as an exact synonym. Tanya has volunteered to make a start on these.

Need to look at both transport and transporter terms.

Chris has committed changes to fix the intersections of the transmembrane terms that were lacking a 'transmembrane' genus.

 [Term]
 id: GO:0005372 ! water transmembrane transporter activity
+intersection_of: GO:0022857 ! transmembrane transporter activity
-intersection_of: GO:0005215 ! transporter activity
 intersection_of: transports_or_maintains_localization_of CHEBI:15377 ! water

EXPORT & IMPORT

There's been email discussion (see email thread: process start and end location relations) about adding generic export and import terms. What would be the differentia for these?

  • Problem 1: For generic 'protein export', the export can be from an organelle OR a cell, so we'd need an 'or' grouping, which we can't do in obo.
  • Problem 2: Not all export/import is across a membrane (e.g. nuclear import/export)
nucleocytoplasmic transport ; GO:0006913
--[isa]nuclear export ; GO:0051168
--[isa]nuclear import ; GO:0051170
Comment for GO:0006913: Note that transport through the nuclear pore complex is not transmembrane because the nuclear membrane is a double membrane, and is not  traversed.


  • IMPORT is the transport of some x into some location y
  • EXPORT is the transport of some x out of some location y
  • AI: Chris to create import and export relationships as subtypes of 'to' and 'from'. Will keep these broad (ommit any transmembrane info).

For transport, need to make it clear that it's the cargo and not the transporters that are changing location. E.g. for actin filaments, the actin filament itself isn't being transported, but the cargo is being moved along the filament.

Annotation relationships

Following on from the annotation call on Tues, at which there was a lot of confusion. I explained what we meant by 'actively_involved_in' v/s 'involved_in', and that you can be actively involved in something directly or indirectly, as described in Chris's handy figure:

Capable of.jpg

as well as the difference between being actively and passively involved in a process. I don't really think I got the message across, so we need to figure out a better way of explaining this - perhaps with a simplfied version of the above? But the consensus seemed to be that no-one had been annotating the passive participants of a process, so I think we can probably use 'actively_involved_in' for all process annotations.

AI: Keep the default relationship (can be used retrospectively) as 'actively involved in process' but change label to: HAS_ACTIVE_ROLE_IN_PROCESS/FUNCTION.