[Go] addition of localization specific process terms ?

Chris Mungall cjm at berkeleybop.org
Tue Mar 24 09:38:35 PDT 2009


On Mar 24, 2009, at 3:32 AM, Jennifer Deegan (nee Clark) wrote:

> Hi,
>
>> I previously addressed this from an end-user point of view. But as  
>> Jim  mentions in the sf tracker item about binding, it's also  
>> important to  consider this from the curation point of view.
>> Jim's point is that increased pre-coordination in the ontology  
>> makes  it harder for curators, because it will take longer to hone  
>> in on the  most appropriate term for an annotation.
>> Whilst I can see that obviously there is some correlation between   
>> ontology size and time to find a term, I'm wondering the extent to   
>> which this is a problem. I would have expected that most  
>> annotation  systems used at the MODs and UniProtKB would utilize  
>> some kind of term  completion rather than the curator manually  
>> traversing down the graph.  Also, if the curators are expected to  
>> post-compose using col 16, then  they have *two* terms to find: for  
>> example to annotate "PEP binding"  they would find the most  
>> specific term in GO *and* the relevant CHEBI  terms (and finding  
>> terms in CHEBI is probably harder than finding  terms in GO)
>> But I don't annotate so I'm not sure.
>> I would like to hear the opinion of some of the annotators here.  
>> Is  excessive pre-coordination a concern for curation?
>
> For some parts of the ontology I have often thought that less pre- 
> composition would be a good thing. It would simplify ontology  
> management a lot for the editors, and at least one annotator has  
> mentioned to me that it would make requesting new terms much simpler.
>
> I think it would also avoid logic errors.

This is what the OBO-Edit reasoner is for. If we have logical  
definitions in one of the cross-product sets, then parts of the graph  
can be managed automatically, as we are (almost) doing for regulation.

> For example in the development area we pre-compose a lot by just  
> combining anatomy and process terms:
>
> Anatomy:
> [i]heart
> ---[p]heart valve
>
> Process:
> [i]development
> ---[p]morphogenesis
>
> Pre-combined terms:
> [i]heart development
> ---[p]heart valve development
> etc.
>
> but what if there are cases where this rule does not hold:
>
> Anatomy:
> [i]A
> ---[p]B
>
> Process:
> [i]X
>
> Pre-combined terms:
> [i]AX
> ---[p]BX
>
> for example, where the development of a part of an organ does not  
> take place as part of the development of the organ. Perhaps that  
> part develops elsewhere and migrates into the organ.

very good example.

you have given a very convincing argument for pre-composition. This  
knowledge is best captured in the ontology by an ontology editor.

this is a good example of the application of the pre-composition rule.  
"development" isn't some generic process that is identical for every  
anatomical entity. Each organ develops in its own unique way. Thus we  
pre-compose organ development terms

> Maybe this is a rare thing, but it seems to me that we don't  
> currently bother to think much about this, and that avoiding pre- 
> composition would allow annotators much more flexibility to capture  
> what actually happens.
>
> The risk is that it would push the burden of capturing difficult  
> ideas onto the annotation step (which is done multiple times) rather  
> than keeping it with the ontology development step (which is done  
> once-ish). It may just make sense to have better tool support for  
> the more difficult pre-composition problems faced by ontology  
> developers.

I agree, and if those tools could be used by annotators to simplify  
requests for new terms it sounds like it would remove one of the other  
complaints.

>
> I would be interested to hear this discussed at the consortium  
> meeting, and I am also particularly interested to hear what the  
> annotators think.
>
> Jennifer
>
>
>
>
>
>
>
>
>
> -- 
> Jennifer Deegan (nee Clark)
> EMBL-European Bioinformatics Institute
> Gene Ontology Consortium
>



More information about the Go mailing list