FIGS meeting Minutes EBI 17 may 2006

From GO Wiki
Jump to: navigation, search

Minutes from FIGS meeting, EBI, 18th May 2006.

Present: Suzi, Michael, Chris, Jane & Midori

- Discussion of figs2go mapping: GO office and Michael spoke with Rob Edwards who works for FIGS in San Diego (?) when he was visiting the campus. We agreed to do mapping between FIGS subsystems and GO processes, and Rob would help. We decided this is tangential to the function/process mapping but would be useful to have anyway.

- Discussion of adding relations between process and function based on FIGS roles (see slide):

- Michael and Suzi suggested we create sub-processes for existing processes (pathways), where variants are known, e.g. for a FIG subsystem that looks like this:

pathway A:
				gene a	gene b	gene c	gene d	gene e
species A	variant 1	X	X	X	X	X
species B 	variant 2	X	X	X	O	X
species C	variant 3	X	X	X	X	O

pathway A
---[p] function a
---[p] function b
---[p] function c
---[i] pathway A, variant 2
------[p] function e
---[i] pathway A, variant 3
------[p] function d

(ignoring complexities of part_of relation for now, [p] here means process has part)

- Jane pointed out that although this would work fine for the species A, B and C, you cannot make these statements globally, particularly as these pathways are only for prokaryotes - it's very likely that another species, species X, has another variant with different set of genes making the tree incorrect. Would curators have to go out and examine all research for all species for pathway A?

- Michael suggested that in the situation where you found a new pathway, which didn't include the common functions, you would have to rearrange the tree, e.g. like this:

pathway A
---[p] function a
---[i] pathway A, variant 4
------[p] function c
------[p] function e
------[p] function f
---[i] pathway A, variant 2
------[p] function b
------[p] function c
------[p] function e
---[i] pathway A, variant 3
------[p] function d
------[p] function c
------[p] function e

We realised the problem with this was that we'd end up having to recapitulate all the functional parts under every subprocess, massively increasing the complexity with every extra process variant added.

Chris suggested that rather than thinking about this in tree terms, we have a simple table in which processes are linked to functions, with a context column in which you could specify under which conditions the relation existed:

function	process		context
a		pathway A	variant 1
a		pathway A	variant 2
etc

The file could be maintained separately of the actual ontologies, and the context column would mean that we wouldn't have to recapitulate the functions under each subprocess. The file could be used to automatically draw an inferred graph, using the most parsimonious structure. This system has the added advantage that we could use it straight away, without worrying about causing problems with the live ontology. action items:

- Jane to continue with figs2go mapping for subsystems