Epistemic formalism (was Re: [Phenoscape] Re: [go] evidence code ontology)

[Chris Mungall]

On Feb 8, 2008, at 2:30 PM, Jim Hu wrote:

> On Feb 8, 2008, at 4:21 PM, Benjamin Hitz wrote:
>
>>> Or in a real case that I think we'll be annotating at some  
>>> point.  Publication A claims that Protein X is a nuclease and  
>>> this IDA annotation is used to transfer the GO association via  
>>> ISS to other genomes.  A later publication, B, shows that X is  
>>> not a nuclease; the authors of B have purified X more than the  
>>> authors of A, and show that the nuclease activity is a  
>>> contaminant.  In this kind of instance, I think it is not enough  
>>> to drop annotations from A from the list of annotations made,  
>>> because the annotation creep is likely to continue.  I think that  
>>> the MOD wants to make a proactive assertion of NOT as a cry of  
>>> "Please correct those ISS annotations".  In the absence of a NOT,  
>>> the absence of a nuclease annotation might be misinterpreted as  
>>> the MOD hasn't got to that paper yet.
>>
>> In this case - what you really want is for Publication A to be  
>> retracted and the original annotation deleted.    There is no way,  
>> under the current system,  to tell a priori which NOTs are  
>> "retractions" and which are simply altered experimental conditions.
>
> The data were correct for the original samples in Publication A as  
> measured at the time. I don't think that's the kind of thing that  
> ever gets retracted.

Retraction is probably too strong a word here. The data was fine, the  
conclusion was wrong.

I think Ben is correct in that there is no easy way to tell which of  
the NOTs are intended to be "corrections"

Presumably publication B cites publication A? If there was an easy  
way to access the citation graph then we may be able to get a handle  
on the correction-NOTs. Perhaps a project for some CS student.

>>
>> I do agree that NOT annotations or something like them can be  
>> useful - particularly at the curation level - but they are so  
>> RARELY useful and so OFTEN misinterpreted that think they should  
>> be hidden away in a dark and dingy corner of a database.
>
> Since they are used so rarely, I'm not seeing where this dreaded  
> misinterpretation is a problem.  Especially if NOT usage is  
> restricted as much as possible to the cases where it would be  
> useful.  I think that the hiding it away argument is worse than  
> either discarding it altogether or showing it when it's there.  
> YMMV, clearly.
>
> Jim
>
>>
>> Ben
>> --
>> Ben Hitz
>> Senior Scientific Programmer ** Saccharomyces Genome Database **  
>> GO Consortium
>> Stanford University ** hitz at genome.stanford.edu
>>
>>
>>
>
> =====================================
> Jim Hu
> Associate Professor
> Dept. of Biochemistry and Biophysics
> 2128 TAMU
> Texas A&M Univ.
> College Station, TX 77843-2128
> 979-862-4054
>
>