[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