Has part

From GO Wiki
Jump to: navigation, search

All relations in GO follow an ALL-SOME pattern; e.g.

  • X part_of Y : all instances of X are part_of some instance of Y

We call the term on the left (X) the subject and the term on the right (Y) the target. The link is always a statement about instances of subject in general rather than instances of the target.

All relations are transitive over is_a

 X part_of Y, Y is_a Z => X part_of Z


 X is_a Y, Y part_of Z => X part_of Z

This also holds for has_part:

 X has_part Y, Y is_a Z => X has_part Z
 X is_a Y, Y has_part Z => X has_part Z


What does this mean for annotations? Previously we have been used to propagating gene products up the graph. With the addition of has_part this is no longer so simple.

First we have to have some notion of what an annotation means.

For BP annotations (GP,BP), what we are saying (closely enough) is that GP actively participates_in BP. The participates_in is transitive over the part_of relation (as well as over is_a of course). This is the reason why we can propagate gene products up the graph; e.g.

 GP participates_in X
 X part_of Y
 Y is_a Z
 GP participates_in Z

For CC annotations the relations is (roughly) localizes_to. This is also transitive over part_of. This is why we can propagate CC annotations up the DAG.

However, these relations are not transitive over has_part. For example, if a protein participates in a process, it is not necessarily participating in the subparts of that process.

This means we have to modify the TP rule for ontologies that include has_part. gene products should not be propagates across has_part relations

See: http://www.slideshare.net/cmungall/haspart-in-go

To properly make use of has_part see Proposal_for_integral_to_qualifier

Display of has_part relations

Normally we draw graphs/denormalized trees such that the following conditions hold:

  • The term for which the link is about is placed lower down, with an arrow pointing toward the related term. Logical implications always flow up the DAG
  • Granularity increases as we go down the tree/graph

These constraints work for part_of. However, for has_part, one of the constraints must be violated.

For example, given:

  • GO:0006099 tricarboxylic acid cycle has_part GO:0003994 aconitate hydratase activity

Using the normal algorithm we would show:

[ i] hydro-lyase activity
 [ i] aconitate hydratase activity
  [hp] TCA cycle
   [ i] reductive tricarboxylic acid cycle

logical implications always flow up the DAG. E.g. ALL reductive tricarboxylic acid cycles have as sub-part SOME hydro-lyase activity

Thus we are consistent with the first constraint. However, there is a reverse of expectation w.r.t granularity (?? - check)

As an alternative means of display, we can retain the granularity constraint by reversing the direction in which we draw the has_part link.

  [ i] TCA cycle
   [ i] reductive tricarboxylic acid cycle
 ->[ p] aconitate hydratase activity
 [ i] hydro-lyase activity
  [ i] aconitate hydratase activity

Here we retain intuition w.r.t. granularity; we 'explode' TCA cycle into its parts as we go down the DAG. However, it violates expectations w.r.t the flow of implications.

Example: Nitrogen utilization