BACKGROUND
much organized and sustained effort is currently made to develop the gene ontology  <cit> .
the primary purpose of go is to provide a uniform terminology in the form of a structured vocabulary to annotate gene products in genome databases, developed concurrently in the world, e.g., to reach a total of  <dig> in the nar online molecular biology database collection as of november  <dig>  <cit> .
in addition to the rapidly growing amount of database information that the go curators need to account for, they must also resolve such important issues as internal consistency  <cit>  as well as external transparency  <cit> .
due to the dynamic nature of information it addresses, go goes through constant updates whose results are released at monthly intervals as separate versions.
there are a large number of computational tools, such as amigo, dagedit, and go-termfinder, to aid the development process of go  <cit> , but such tools are inherently static, in the sense that they are operating only on a particular version of go.
it is thus up to the go curators to keep a separate record of all the evolutionary changes that go goes through, but it is hard to anticipate the full impact of particular changes along the time axis on the larger scale in this manner, leaving inconsistency inevitably behind.
proposals are also made in the literature to extend go semi-automatically  <cit> , by applying text mining techniques to the literature database such as medline, but they still fall short of establishing the level of confidence that the go curators require.
there is thus clearly a need for an intuitive method to consult the timeline of changes to go, so that go curators would be able to see the full impact of the proposed changes quickly and to identify the direction of future changes readily.
such a service would be useful not only for go curators, who can move back and forth along the different versions of go to examine the possible room for improvement, but also for occasional users of go, who may not have up-to-date information about a particular branch of molecular biology but are puzzled at some of the aspects that are in the middle of important changes.
we present a method for tapping into such an evolutionary aspect of go, by making it possible to keep track of important temporal changes to any of the nodes and relations of go and by consequently making it possible to anticipate and overcome such changes.
to the best of our knowledge, this is the first proposal to visualize the evolutionary aspect of go.
methods
we developed graph construction and visualization methods to monitor the changes in go over time.
the system is a web-based application that is implemented by using graphviz and python.
currently, there are  <dig> go versions  loaded into our system.
given two versions of go, i.e.,  where got <dig> temporally precedes got <dig>  we compute the difference between two gos and keep the go terms with a tagging to distinguish how each term is changed: added, removed, or modified.
this tagged information is used for colour-coding each node of the layered graph, which is constructed by merging some interested parts of the two versions of go.
a node in the graph refers to a go term.
the following is the node colour-coding convention we employed in our visualization.
<dig>  pink nodes indicate go terms that have different concept names but use the same go identifiers in the two versions of go.
<dig>  red nodes indicate go terms that appear in got <dig>  but that do not appear in got <dig> .
<dig>  blue nodes indicate go terms that are newly added to got <dig> .
<dig>  gray nodes indicate go terms that undergo no changes in both concept names and go identifiers between the two versions of go.
in addition, we use the edge colour-coding so that the isa edges and partof edges are coloured blue and orange, respectively.
figure  <dig> shows  <dig> red nodes,  <dig> pink nodes and a number of blue nodes and gray nodes.
for the purpose of clear exposition, the nodes in figure  <dig> and in the following figures are designed to show only go identifiers, but not the relation  type.
we developed graph construction algorithms to merge only those subgraphs of interest from the whole go.
upward/downward graph construction
the procedure upward_graph_construct takes two versions of go, where got <dig> temporally precedes got <dig>  and returns a colour-coded subgraph that contains all the nodes that are added , removed , or modified .
the nodes that are unchanged, colour-coded gray, are shown only when they participate in the graph construction for the leaf nodes to traverse upwards to reach the root node of go.
in line  <dig> of the body of the procedure upward_graph_construct, the subprocedure diff takes the two versions of go and returns the lists m, r, and a, which contain the modified nodes, removed nodes, and added nodes, respectively.
figure  <dig> illustrates the involved subprocesses graphically.
procedure: upward_graph_construct:
- constraint: got <dig> temporally precedes got2
- input: got1// go version 1
got2// go version 2
- output:colour-coded merged graph
<dig> m, r, a = diff
<dig> upward_subgraphs ← null
<dig> for each go_id ∈ m ∪ a ∪ r
<dig>  queue ← insert go_id
<dig>  edge ← null
<dig>  while queue is not empty
<dig>   current ← delete element in queue
<dig>   if current ∈ m ∪ r
<dig>    isa_parents ← { ‘isa’ parent go_ids in got <dig> }
<dig>    partof_parents ← { ‘part-of’ parent go_ids in got <dig> }
<dig>   else if current ∈ m ∪ a
<dig>    isa_parents ← { ‘isa’ parent go_ids in got <dig> }
<dig>    part of_parents ← { ‘part-of’ parent go_ids in got <dig> }
<dig>   for each pgo_id in is a_parents
<dig>    queue ← insert pgo_id
<dig>    edge ← edge ∪
<dig>   for each pgo_id in part of_parents
<dig>    queue ← insert pgo_id
<dig>    edge ← edge ∪
<dig>  upward_subgraphs ← upward_subgraphs ∪ edge
<dig> g ← merge_subgraphs
<dig> return colour_coding
the procedures diff, merge_subgraphs, and colour_coding are shown in the additional file  <dig>
the procedure downward_graph_construct is similarly defined, except that isa_parent and partof_parent should be replaced with isa_children and partof_children, respectively, and that it takes a specific go term as an initial node.
figure  <dig> shows the process of constructing the initial subgraphs that are merged together and colour-coded subsequently.
procedure: downward_graph_construct
- constraint: got <dig> temporally precedes got2
- input: got <dig>  got2
- output:colour-coded merged graph
<dig> m, r, a = diff
<dig> downward_subgraphs ← null
<dig> queue ← insert initial_go_id
<dig> for each go_id ∈ m ∪ a ∪ r
<dig>  queue ← insert go_id
<dig>  edge ← null
<dig>  while queue is not empty
<dig>   current ← delete element in queue
<dig>   if current ∈ m ∪ r
<dig>    isa_children ← { ‘isa’ children go_ids in got <dig> }
<dig>    partof_children ← { ‘part-of’ children go_ids in got <dig> }
<dig>   else if current ∈ m ∪ a
<dig>    isa_children ← { ‘isa’ children go_ids in got <dig> }
<dig>    partof_children ← { ‘part-of’ children go_ids in got <dig> }
<dig>   for each cgo_id in isa_children
<dig>    queue ← insert cgo_id
<dig>    edge ← edge ∪
<dig>   for each cgo_id in partof_children
<dig>    queue ← insert cgo_id
<dig>    edge ← edge ∪
<dig>  downward_subgraphs ← downward_subgraphs ∪ edge
<dig> g ← merge_subgraphs
<dig> return colour_coding
note that the method to keep track of the changes between two versions of go as described above can be naturally extended to the changes among multiple versions of go.
RESULTS
by using visualization methods for viewing the changes between two different versions of go through a layered graph and by colour-coding go entries of addition, deletion and content modification in the two versions, we were able to infer the cause of the evolution as well as to gain new insights into more complex changes.
we demonstrate the utility of our system with several examples.
making hypotheses
we can make useful hypotheses by using the procedure upward_graph_construct and by focusing on coloured nodes that have certain structural properties with their neighbour nodes.
these hypotheses can be checked manually by consulting the involved concept names, and adjusted subsequently for a more fine-tuned hypothesis.
for the purposes of illustration, we use figures  <dig>  and  <dig> to explain possible hypotheses that one can make.
there are two possibilities for the reason that the node go: <dig> in figure  <dig> is modified .
first, when a blue node has a pink node as its parent, it is likely that the parent node, i.e., the pink node, has a revised concept name to accommodate the addition of the blue node as its child node.
the pink node go: <dig>  indeed, has its name changed from l-tryptophan transporter activity to l-trptophan transmembrane transporter activity.
note that the blue node go: <dig> has the concept name low-affinity tryptophan transmembrane transporter activity.
second, it is also likely that the node go: <dig> is coloured pink because of its changed relation with the node go: <dig>  which is removed, and with the node go: <dig>  which is directly linked to the node go: <dig> as its child.
in this particular case, however, it is more likely that the changed content of the go term is due to the blue node, not due to the red node.
when a red node and a blue node share the same parent and the same child, it is likely that the red node is replaced with the blue node.
in figure  <dig>  the nodes go: <dig> and go: <dig> have concept names alpha-type channel activity and wide pore channel activity, respectively.
when the parent node has a big fan-out , as in figure  <dig>  we can think of two cases.
first, there may be similar numbers of red children nodes and blue children nodes.
in this case, it is likely that each red node has been replaced with a blue node.
the fan-out of the node go: <dig> in this figure is  <dig>  and there are equal numbers  of red nodes and blue nodes under it.
as we see in table  <dig>  the concept names of the red nodes are systematically changed to those of the blue nodes.
second, there may be a large number of pink nodes, along with some gray nodes.
in this case, we can also expect that the pink nodes are the result of systematic changes in the concept names.
in both cases, when there is a parent node with a big fan-out, it is possible that it is the result of the agreement among the go curators  <cit> .
even if the fan-out is small, when there are equal numbers of red nodes and blue nodes, the chance is quite high that the red nodes are replaced into the blue nodes.
monitoring the evolutionary behaviour
the following descriptions on figures  <dig> through  <dig> , figures  <dig> through  <dig> , and figure  <dig> through  <dig>  show how to use the procedure downward_graph_construct to gain insights into the evolutionary nature of a subgraph under a particular go node.
as we illustrate in figures  <dig> through  <dig> , the node go: <dig> regulation of protein modification did not exist until the  <dig> .
<dig> version of go, when it was introduced along with the other  <dig> nodes.
since go is represented in a dag form, the two nodes with the same parent node are not necessarily on the same level in the go hierarchy.
nonetheless, it appears that such a level can be assessed in the go hierarchy with respect to the nodes in the subgraph with the node go: <dig> as its root node.
in particular, the node go: <dig> regulation of protein ubiquitination has two sibling nodes go: <dig> positive regulation of protein modification and go: <dig> negative regulation of protein modification, that is, a pair of nodes with the opposing qualifiers positive and negative.
in the case of the concept ubiquitination, which has to traverse down one level to see the opposing qualifiers, the levels of detail for the terms do not appear overall quite adequate, and we can expect that they will undergo a subsequent refinement process.
similarly, the newly introduced node go: <dig> has the concept name positive regulation of protein sumoylation, but the other newly introduced node go: <dig> has the concept name 11-beta-hydroxysteroid dehydrogenase activity, and it is thus likely that one of the nodes will undergo a name change in the future, as they do not follow the naming convention which involves the qualifiers positive and negative.
as another example, we use the node go: <dig> reproductive sporulation to show its evolutionary behaviour over time.
finally, we examine cases that require more reasoning to monitor the evolutionary behaviour.
first, consider the subgraph under the node go: <dig> in the  <dig> .
<dig> version of go .
note that there is no intervening node between the nodes go: <dig> and go: <dig>  figure  <dig>  shows that in the  <dig> .
<dig> version of go, a new node, go: <dig>  along with its subgraph , is added to the graph, though the two nodes go: <dig> and go: <dig> retain their relationship to each other.
table  <dig>  shows the individual concept names of the involved nodes.
note that neural fold formation  is considered a refined concept of both primary neural tube formation  and neural tube formation .
at this point, we may predict that this arrangement for neural fold formation  is not natural, and that one of the two links, most likely the latter with neural tube formation should be disconnected.
note also that the four nodes, go: <dig>  go: <dig>  go: <dig>  and go: <dig>  are introduced at the same time as the parent node go: <dig>
for about  <dig> months afterwards, however, the subgraph under the node go: <dig> did not undergo any changes, until the  <dig> .
<dig> version of go is introduced, where quite a large number of nodes are added to the subgraph of the node go: <dig>  with concept names changes  to accommodate the new addition .
note that our prediction earlier is borne out in the new version of go, where the connection between the two nodes go: <dig> and go: <dig> is no longer maintained.
we have examined several cases to illustrate the process of making hypotheses and validating them with subsequent changes.
we are also examining how often such cases appear, but this requires a semi-automated method to search for similar cases.
we have used cases in the past to make validation possible as well, but the method is surely applicable to cases in the future, where one can make a prediction as to where changes of a particular type are inevitable or imminent.
the use of our colour-coded graphs allows the users to zoom in and out at ease and rapidly focus on a go term or go terms of interest to monitor the evolutionary behaviour.
the software as described in this paper has a web interface, accessible at .
discussion and
CONCLUSIONS
the need to keep track of the changes to go has also been recognized by yeh et al.
<cit> , where two versions of go are compared by the use of a collection of tools called prompt, which generates a list of differences and similarities between the two input ontologies.
in addition, the ontoviz tab generates a graphical representation of concepts in go, facilitating the process of inspecting such changes.
however, the focus of the work by yeh et al.
is on ensuring the consistency of the involved ontologies over possible changes, and not on providing a means to tap into the evolutionary process of go itself.
ensuring the consistency of an ontology is certainly an important aspect for the go development, as there are numerous researchers constantly contributing materials to go, possibly leading to conflicts of various nature.
nonetheless, we find that it is equally important to help developers and users of go to move around different versions of go along the time axis so as to recognize emerging  trends quickly and to determine a course of action to exploit the trends.
such emerging trends cannot be detected if we are to look at only a static snapshot of go.
our contribution in this paper through the implemented software is to make available a means for monitoring changes of go over time, so that both developers and users of go may understand the full impact of such changes on the larger scale.
there are, however, a number of remaining issues that must be overcome.
first, the system may generate a collection of red nodes when it compares two versions of go, or got <dig> and got <dig> where got <dig> temporally precedes got <dig>  but such a collection of red nodes can not be interpreted to have been just removed from the version of got <dig>  especially when there is a big temporal gap between the two versions of go.
to see precisely when such nodes have been removed from a particular version of go, we need to locate two versions, got_i and got_i+ <dig> where got <dig> temporally precedes got_i, got_i temporally precedes got_i+ <dig>  there is no published version of go between got_i and got_i+ <dig>  and got_i+ <dig> temporally precedes got <dig>  such that the nodes are gray in got_i but red in got_i+ <dig>  it is quite unlikely though that the nodes are all gray in got_i and all red in got_i+ <dig>  but more likely that they show individual differences from one another in the points of removal.
in this regard, one can not make a decisive conclusion when one sees red nodes, unless the comparison is made between two consecutive versions of go.
second, we have shown a number of scenarios that demonstrate the utility of the proposed visualization method, but these scenarios are the result of a somewhat unfocused search over random pairs of the available versions of go, mostly guided by the intuition of a system developer.
it would obviously help much if the search process can be automated for the detection of “meaningful” scenarios.
such an automated search process would be particularly useful to help suggest a possible direction for improvement or refinement over the present version of go to go curators.
for instance, we have used a hypothesis with respect to figure  <dig> such that similar numbers of red and blue nodes in a tree with a big fan-out ratio suggest a particular activity.
it is, however, quite possible that there may be disagreements among the go curators on the utility of such a hypothesis.
it would hence be quite tricky to use it as a universal condition for the automated search process, unless such disagreements can be overcome.
it would also help much if we can get a more global perspective over the changes of go, so that we can get a sense of the frequency or the proportion of the meaningful cases in designing the automated search process.
while limitations of this kind must be overcome, we believe that the present system that highlights the differences of two versions of an evolving ontology such as go can be effectively used for the development of the ontology in the future, as well as for the identification of meaningful scenarios in the past.
competing interests
the authors declare that they have no competing interests.
authors' contributions
jcp conceived and directed this work.
jcp also drafted the initial version of the paper.
tk implemented all the modules of the presented system and prepared all the tables and figures.
jp provided advice and feedback to the visualization side of the work.
all authors contributed during the whole length of the project.
all authors read and approved the final manuscript.
supplementary material
additional file 1
appendix a: pseudo code for sub-procedures
this file describes pseudo code for sub-procedures.
click here for file
additional file 2
additional file – figures 7-17
this file contains figures  <dig> to  <dig> and tables  <dig> to  <dig>  which illustrate downward_graph_construct to monitor the evolutionary behavior of a subgraph under a particular go node.
click here for file
acknowledgements
this work has been supported in part by the korea science and engineering foundation through advanced it research center and through grants for interdisciplinary research  and in part by the second stage of the brain korea  <dig> project.
this article has been published as part of bmc bioinformatics volume  <dig> supplement  <dig>  2008: proceedings of the second international symposium on languages in biology and medicine   <dig>  the full contents of the supplement are available online at .

 much organized and sustained effort is currently made to develop the gene ontology. the primary purpose of go is to provide a uniform terminology in the form of a structured vocabulary to annotate gene products in genome databases, developed concurrently in the world, e.g., to reach a total of in the nar online molecular biology database collection as of november. in addition to the rapidly growing amount of database information that the go curators need to account for, they must also resolve such important issues as internal consistency as well as external transparency. due to the dynamic nature of information it addresses, go goes through constant updates whose results are released at monthly intervals as separate versions. there are a large number of computational tools, such as amigo, dagedit, and go-termfinder, to aid the development process of go, but such tools are inherently static, in the sense that they are operating only on a particular version of go. it is thus up to the go curators to keep a separate record of all the evolutionary changes that go goes through, but it is hard to anticipate the full impact of particular changes along the time axis on the larger scale in this manner, leaving inconsistency inevitably behind. proposals are also made in the literature to extend go semi-automatically, by applying text mining techniques to the literature database such as medline, but they still fall short of establishing the level of confidence that the go curators require. there is thus clearly a need for an intuitive method to consult the timeline of changes to go, so that go curators would be able to see the full impact of the proposed changes quickly and to identify the direction of future changes readily. such a service would be useful not only for go curators, who can move back and forth along the different versions of go to examine the possible room for improvement, but also for occasional users of go, who may not have up-to-date information about a particular branch of molecular biology but are puzzled at some of the aspects that are in the middle of important changes. we present a method for tapping into such an evolutionary aspect of go, by making it possible to keep track of important temporal changes to any of the nodes and relations of go and by consequently making it possible to anticipate and overcome such changes. to the best of our knowledge, this is the first proposal to visualize the evolutionary aspect of go. methods we developed graph construction and visualization methods to monitor the changes in go over time. the system is a web-based application that is implemented by using graphviz and python. currently, there are go versions loaded into our system. given two versions of go, i.e., where got temporally precedes got we compute the difference between two gos and keep the go terms with a tagging to distinguish how each term is changed: added, removed, or modified. this tagged information is used for colour-coding each node of the layered graph, which is constructed by merging some interested parts of the two versions of go. a node in the graph refers to a go term. the following is the node colour-coding convention we employed in our visualization. pink nodes indicate go terms that have different concept names but use the same go identifiers in the two versions of go. red nodes indicate go terms that appear in got but that do not appear in got. blue nodes indicate go terms that are newly added to got. gray nodes indicate go terms that undergo no changes in both concept names and go identifiers between the two versions of go. in addition, we use the edge colour-coding so that the isa edges and partof edges are coloured blue and orange, respectively. figure shows red nodes, pink nodes and a number of blue nodes and gray nodes. for the purpose of clear exposition, the nodes in figure and in the following figures are designed to show only go identifiers, but not the relation type. we developed graph construction algorithms to merge only those subgraphs of interest from the whole go. upward/downward graph construction the procedure upward_graph_construct takes two versions of go, where got temporally precedes got and returns a colour-coded subgraph that contains all the nodes that are added, removed, or modified. the nodes that are unchanged, colour-coded gray, are shown only when they participate in the graph construction for the leaf nodes to traverse upwards to reach the root node of go. in line of the body of the procedure upward_graph_construct, the subprocedure diff takes the two versions of go and returns the lists m, r, and a, which contain the modified nodes, removed nodes, and added nodes, respectively. figure illustrates the involved subprocesses graphically. procedure: upward_graph_construct: - constraint: got temporally precedes got2 - input: got1// go version 1 got2// go version 2 - output:colour-coded merged graph m, r, a = diff upward_subgraphs ← null for each go_id ∈ m ∪ a ∪ r  queue ← insert go_id  edge ← null  while queue is not empty   current ← delete element in queue   if current ∈ m ∪ r    isa_parents ← { ‘isa’ parent go_ids in got }    partof_parents ← { ‘part-of’ parent go_ids in got }   else if current ∈ m ∪ a    isa_parents ← { ‘isa’ parent go_ids in got }    part of_parents ← { ‘part-of’ parent go_ids in got }   for each pgo_id in is a_parents    queue ← insert pgo_id    edge ← edge ∪   for each pgo_id in part of_parents    queue ← insert pgo_id    edge ← edge ∪  upward_subgraphs ← upward_subgraphs ∪ edge g ← merge_subgraphs return colour_coding the procedures diff, merge_subgraphs, and colour_coding are shown in the additional file the procedure downward_graph_construct is similarly defined, except that isa_parent and partof_parent should be replaced with isa_children and partof_children, respectively, and that it takes a specific go term as an initial node. figure shows the process of constructing the initial subgraphs that are merged together and colour-coded subsequently. procedure: downward_graph_construct - constraint: got temporally precedes got2 - input: got got2 - output:colour-coded merged graph m, r, a = diff downward_subgraphs ← null queue ← insert initial_go_id for each go_id ∈ m ∪ a ∪ r  queue ← insert go_id  edge ← null  while queue is not empty   current ← delete element in queue   if current ∈ m ∪ r    isa_children ← { ‘isa’ children go_ids in got }    partof_children ← { ‘part-of’ children go_ids in got }   else if current ∈ m ∪ a    isa_children ← { ‘isa’ children go_ids in got }    partof_children ← { ‘part-of’ children go_ids in got }   for each cgo_id in isa_children    queue ← insert cgo_id    edge ← edge ∪   for each cgo_id in partof_children    queue ← insert cgo_id    edge ← edge ∪  downward_subgraphs ← downward_subgraphs ∪ edge g ← merge_subgraphs return colour_coding note that the method to keep track of the changes between two versions of go as described above can be naturally extended to the changes among multiple versions of go.  by using visualization methods for viewing the changes between two different versions of go through a layered graph and by colour-coding go entries of addition, deletion and content modification in the two versions, we were able to infer the cause of the evolution as well as to gain new insights into more complex changes. we demonstrate the utility of our system with several examples. making hypotheses we can make useful hypotheses by using the procedure upward_graph_construct and by focusing on coloured nodes that have certain structural properties with their neighbour nodes. these hypotheses can be checked manually by consulting the involved concept names, and adjusted subsequently for a more fine-tuned hypothesis. for the purposes of illustration, we use figures and to explain possible hypotheses that one can make. there are two possibilities for the reason that the node go: in figure is modified. first, when a blue node has a pink node as its parent, it is likely that the parent node, i.e., the pink node, has a revised concept name to accommodate the addition of the blue node as its child node. the pink node go: indeed, has its name changed from l-tryptophan transporter activity to l-trptophan transmembrane transporter activity. note that the blue node go: has the concept name low-affinity tryptophan transmembrane transporter activity. second, it is also likely that the node go: is coloured pink because of its changed relation with the node go: which is removed, and with the node go: which is directly linked to the node go: as its child. in this particular case, however, it is more likely that the changed content of the go term is due to the blue node, not due to the red node. when a red node and a blue node share the same parent and the same child, it is likely that the red node is replaced with the blue node. in figure the nodes go: and go: have concept names alpha-type channel activity and wide pore channel activity, respectively. when the parent node has a big fan-out, as in figure we can think of two cases. first, there may be similar numbers of red children nodes and blue children nodes. in this case, it is likely that each red node has been replaced with a blue node. the fan-out of the node go: in this figure is and there are equal numbers of red nodes and blue nodes under it. as we see in table the concept names of the red nodes are systematically changed to those of the blue nodes. second, there may be a large number of pink nodes, along with some gray nodes. in this case, we can also expect that the pink nodes are the result of systematic changes in the concept names. in both cases, when there is a parent node with a big fan-out, it is possible that it is the result of the agreement among the go curators. even if the fan-out is small, when there are equal numbers of red nodes and blue nodes, the chance is quite high that the red nodes are replaced into the blue nodes. monitoring the evolutionary behaviour the following descriptions on figures through, figures through, and figure through show how to use the procedure downward_graph_construct to gain insights into the evolutionary nature of a subgraph under a particular go node. as we illustrate in figures through, the node go: regulation of protein modification did not exist until the. version of go, when it was introduced along with the other nodes. since go is represented in a dag form, the two nodes with the same parent node are not necessarily on the same level in the go hierarchy. nonetheless, it appears that such a level can be assessed in the go hierarchy with respect to the nodes in the subgraph with the node go: as its root node. in particular, the node go: regulation of protein ubiquitination has two sibling nodes go: positive regulation of protein modification and go: negative regulation of protein modification, that is, a pair of nodes with the opposing qualifiers positive and negative. in the case of the concept ubiquitination, which has to traverse down one level to see the opposing qualifiers, the levels of detail for the terms do not appear overall quite adequate, and we can expect that they will undergo a subsequent refinement process. similarly, the newly introduced node go: has the concept name positive regulation of protein sumoylation, but the other newly introduced node go: has the concept name 11-beta-hydroxysteroid dehydrogenase activity, and it is thus likely that one of the nodes will undergo a name change in the future, as they do not follow the naming convention which involves the qualifiers positive and negative. as another example, we use the node go: reproductive sporulation to show its evolutionary behaviour over time. finally, we examine cases that require more reasoning to monitor the evolutionary behaviour. first, consider the subgraph under the node go: in the. version of go. note that there is no intervening node between the nodes go: and go: figure shows that in the. version of go, a new node, go: along with its subgraph, is added to the graph, though the two nodes go: and go: retain their relationship to each other. table shows the individual concept names of the involved nodes. note that neural fold formation is considered a refined concept of both primary neural tube formation and neural tube formation. at this point, we may predict that this arrangement for neural fold formation is not natural, and that one of the two links, most likely the latter with neural tube formation should be disconnected. note also that the four nodes, go: go: go: and go: are introduced at the same time as the parent node go: for about months afterwards, however, the subgraph under the node go: did not undergo any changes, until the. version of go is introduced, where quite a large number of nodes are added to the subgraph of the node go: with concept names changes to accommodate the new addition. note that our prediction earlier is borne out in the new version of go, where the connection between the two nodes go: and go: is no longer maintained. we have examined several cases to illustrate the process of making hypotheses and validating them with subsequent changes. we are also examining how often such cases appear, but this requires a semi-automated method to search for similar cases. we have used cases in the past to make validation possible as well, but the method is surely applicable to cases in the future, where one can make a prediction as to where changes of a particular type are inevitable or imminent. the use of our colour-coded graphs allows the users to zoom in and out at ease and rapidly focus on a go term or go terms of interest to monitor the evolutionary behaviour. the software as described in this paper has a web interface, accessible at. discussion and  the need to keep track of the changes to go has also been recognized by yeh et al., where two versions of go are compared by the use of a collection of tools called prompt, which generates a list of differences and similarities between the two input ontologies. in addition, the ontoviz tab generates a graphical representation of concepts in go, facilitating the process of inspecting such changes. however, the focus of the work by yeh et al. is on ensuring the consistency of the involved ontologies over possible changes, and not on providing a means to tap into the evolutionary process of go itself. ensuring the consistency of an ontology is certainly an important aspect for the go development, as there are numerous researchers constantly contributing materials to go, possibly leading to conflicts of various nature. nonetheless, we find that it is equally important to help developers and users of go to move around different versions of go along the time axis so as to recognize emerging trends quickly and to determine a course of action to exploit the trends. such emerging trends cannot be detected if we are to look at only a static snapshot of go. our contribution in this paper through the implemented software is to make available a means for monitoring changes of go over time, so that both developers and users of go may understand the full impact of such changes on the larger scale. there are, however, a number of remaining issues that must be overcome. first, the system may generate a collection of red nodes when it compares two versions of go, or got and got where got temporally precedes got but such a collection of red nodes can not be interpreted to have been just removed from the version of got especially when there is a big temporal gap between the two versions of go. to see precisely when such nodes have been removed from a particular version of go, we need to locate two versions, got_i and got_i+ where got temporally precedes got_i, got_i temporally precedes got_i+ there is no published version of go between got_i and got_i+ and got_i+ temporally precedes got such that the nodes are gray in got_i but red in got_i+ it is quite unlikely though that the nodes are all gray in got_i and all red in got_i+ but more likely that they show individual differences from one another in the points of removal. in this regard, one can not make a decisive conclusion when one sees red nodes, unless the comparison is made between two consecutive versions of go. second, we have shown a number of scenarios that demonstrate the utility of the proposed visualization method, but these scenarios are the result of a somewhat unfocused search over random pairs of the available versions of go, mostly guided by the intuition of a system developer. it would obviously help much if the search process can be automated for the detection of “meaningful” scenarios. such an automated search process would be particularly useful to help suggest a possible direction for improvement or refinement over the present version of go to go curators. for instance, we have used a hypothesis with respect to figure such that similar numbers of red and blue nodes in a tree with a big fan-out ratio suggest a particular activity. it is, however, quite possible that there may be disagreements among the go curators on the utility of such a hypothesis. it would hence be quite tricky to use it as a universal condition for the automated search process, unless such disagreements can be overcome. it would also help much if we can get a more global perspective over the changes of go, so that we can get a sense of the frequency or the proportion of the meaningful cases in designing the automated search process. while limitations of this kind must be overcome, we believe that the present system that highlights the differences of two versions of an evolving ontology such as go can be effectively used for the development of the ontology in the future, as well as for the identification of meaningful scenarios in the past. competing interests the authors declare that they have no competing interests. authors' contributions jcp conceived and directed this work. jcp also drafted the initial version of the paper. tk implemented all the modules of the presented system and prepared all the tables and figures. jp provided advice and feedback to the visualization side of the work. all authors contributed during the whole length of the project. all authors read and approved the final manuscript. supplementary material additional file 1 appendix a: pseudo code for sub-procedures this file describes pseudo code for sub-procedures. click here for file additional file 2 additional file – figures 7-17 this file contains figures to and tables to which illustrate downward_graph_construct to monitor the evolutionary behavior of a subgraph under a particular go node. click here for file acknowledgements this work has been supported in part by the korea science and engineering foundation through advanced it research center and through grants for interdisciplinary research and in part by the second stage of the brain korea project. this article has been published as part of bmc bioinformatics volume supplement 2008: proceedings of the second international symposium on languages in biology and medicine the full contents of the supplement are available online at.
focusing on a specific go term or terms of interest over a period, we demonstrate the utility of our system that can be used to make useful hypotheses about the cause of the evolution and to provide new insights into more complex changes. we present a method for tapping into such an evolutionary aspect of go, by making it possible to keep track of important temporal changes to any of the terms and relations of go and by consequently making it possible to recognize associated trends. a snapshot of go, as presented by each version of go alone, overlooks such evolutionary aspects, and consequently limits the utilities of go. to the best of our knowledge, this is the first proposal to visualize the evolutionary aspect of go. although there are a large number of computational tools to aid the development of go, they are operating on a particular version of go, making it difficult for go curators to anticipate the full impact of particular changes along the time axis on a larger scale. due to the dynamic nature of information it addresses, go undergoes constant updates whose results are released at regular intervals as separate versions. 6– december the second international symposium on languages in biology and medicine singapore the method that highlights the differences of consecutive versions or two different versions of an evolving ontology with colour-coding enhances the utility of go for users as well as for developers. we have developed visualization methods for viewing the changes between two different versions of go by constructing a colour-coded layered graph.
 much effort is currently made to develop the gene ontology. due to the dynamic nature of information it addresses, go undergoes constant updates whose results are released at regular intervals as separate versions. although there are a large number of computational tools to aid the development of go, they are operating on a particular version of go, making it difficult for go curators to anticipate the full impact of particular changes along the time axis on a larger scale. we present a method for tapping into such an evolutionary aspect of go, by making it possible to keep track of important temporal changes to any of the terms and relations of go and by consequently making it possible to recognize associated trends.  we have developed visualization methods for viewing the changes between two different versions of go by constructing a colour-coded layered graph. the graph shows both versions of go with highlights to those go terms that are added, removed and modified between the two versions. focusing on a specific go term or terms of interest over a period, we demonstrate the utility of our system that can be used to make useful hypotheses about the cause of the evolution and to provide new insights into more complex changes.  go undergoes fast evolutionary changes. a snapshot of go, as presented by each version of go alone, overlooks such evolutionary aspects, and consequently limits the utilities of go. the method that highlights the differences of consecutive versions or two different versions of an evolving ontology with colour-coding enhances the utility of go for users as well as for developers. to the best of our knowledge, this is the first proposal to visualize the evolutionary aspect of go. 6– december the second international symposium on languages in biology and medicine singapore 