pyruvate metabolic process

[ValWood]

This seems ( along with the biosynthetic and catabolic process)
seem like unnecessary grouping terms.

It has the following descendants.

Everything annotated would be better described by the appropriate specific pathway terms.

GO:0042866    pyruvate biosynthetic process | is_a
GO:0042867    pyruvate catabolic process | is_a
GO:0046327    glycerol biosynthetic process from pyruvate | is_a
GO:0019272    L-alanine biosynthetic process from pyruvate | is_a
GO:0019450    L-cysteine catabolic process to pyruvate | is_a
GO:0061678    Entner-Doudoroff pathway | is_a
GO:0019244    lactate biosynthetic process from pyruvate | is_a
GO:0006086    acetyl-CoA biosynthetic process from pyruvate | is_a
GO:0006096    glycolytic process | is_a
GO:0061718    glucose catabolic process to pyruvate | is_a
GO:0019617    protocatechuate catabolic process, meta-cleavage | is_a
GO:0061722    sulphoglycolysis

Also, some of the children look suspect

[sjm41]

@ukemi @deustp01 @rozaru

[ValWood]

Actually, this is probably OK as a grouping term, and glycolysis is there.

However, instead, it should be "not for direct annotation", everything can be annotated to a more specific child.

[ValWood]

All of the pyruvate annotations could be annotated more specifically to one of the children

[deustp01]

Pyruvate sits at a junction of many metabolic processes in a network of at least two dimensions. The cartoon highlights the major ones involved in human energy metabolism and its regulation in response to physiological stresses. We are, once again, colliding with an issue of attempting to find unique best pathway boundaries that transcend species and physiological state. Can we put some developer time into giving GO-CAM the functionality it needs to accurately and comprehensively capture causal relationships among models so we can stop hacking together these inadequate workarounds? @cmungall @vanaukenk

[ValWood]

the proposed action is to make
"not for direct annotation", everything can be annotated to a more specific child.
This would improve annotation, but still keep the useful grouping.

[raymond91125]

the proposed action is to make "not for direct annotation", everything can be annotated to a more specific child. This would improve annotation, but still keep the useful grouping.

Agreed. We should work out a complete procedure, similar to that of obsoletion (e.g. annotation review), to handle do-not-annotate grouping terms.