OBI email 9 Feb 2010
Dear Jane, Dear Michelle,
Like I said, OBI does not aim to replace ECO, rather possibly provide terms to create some kind of cross products to support ECO. So if an ECO term mentions PCR, an xref to OBI could be made in the ECO definition. The (possibly) more advanced representation of inputs and outputs of PCR would live in OBI without over burdening ECO developers. Conversely, ECO may benefit from OBI work. For instance, taking ECO:0000101 "inferred from Affymetrix array" is a child of "inferred from expression pattern". But Affymetrix array could be used for SNP analysis or CNV analysis. Now, when it comes to the 'direct assay' case, I agree with you that it might not be straightforward but again by discussing the use case, I would not rule finding a common ground by using defined classes. In ECO, the definition for direct assay points to a need for caution so by splitting direct assay for localization from direct assay for function assessment, therefore specifying the objective and information produced by an assay could be beneficial.
We could try the use case and carry out a basic 'costs-benefit' analysis. Are there cases where GO annotators are unsure as to which ECO to use? What are the causes for those hesitations? would a better definition of an assay help?
Addressing disruption of practice is essential. So working bottom-up might help here. It would allow to address coverage gaps for specific assay in OBI. As we walk up ECO tree, we could envisage creation of defined classes grouping together specific assay based on their goals, input and output. We don't want to rush things, rather get them right and in a way which facilitate your work.