[Bioperl-l] common ancestor for ontology terms

[Hilmar Lapp]

On Sunday, March 30, 2003, at 09:33  AM, Matthew Pocock wrote:

> The way we're tying to do this, Ontology is pure-data

So how do you define 'pure data'? Holds and makes accessible all terms 
and relationships? Or only the name and definition of the ontology?

In bioperl we're doing the latter, where the overall OntologyI 
interface does lump data methods and query methods (operations) 
together, but the implementation is by composition with an 
OntologyEngineI object that all query methods are delegated to.

> OntologyOps is an interface that has
> limited-namespace-aware versions of common optimizable
> operations. This includes transient closure. Multiple
> namespaces that shair some backing data (like in
> biosql) can return the same OntologyOps.

Right. Interesting, same here.

The OntologyEngine manages the terms and rel.ships too though (stores, 
makes accessible, allows operations on them). How did you guys decide 
to separate that?


>
> OntoTools has the real methods that users invoke for
> checking inheritance and transient closures and
> things. This tools class is responsible for waling
> between the different ops domains.

Hmm - I guess this is lumped together in bioperl.

	-hilmar

>
> Our first attempt made Ontology 'clever', but that
> realy sucks because you never know what extra external
> info you should be dealing with to answer a lookup.
> For example, if it is provable that _my_inherits_from_
> inherits from _isa_, then in the ontology object, a
> call to something like 'a _isa_ b' on an Ontology will
> fail if they are infact linked by _my_inherits_from_,
> will fail if invoked via an OntologyOps that doesn't
> directly contain both _my_inherits_from_ and _isa_,
> but will succeed if you go via OntoTools.
>
> Particularly if we start to use a implies b, where a
> and/or b are relations themselves (e.g. X has_a Y, x
> is_a X => x has_a Y), it becomes nearly impossible to
> mix up the things we know (have defined as being true)
> and the things we have proven (using some
> graph-walking strategy) without serious brain melt.
>
> YMMV
>
> Matthew
>
>  --- Chris Mungall <cjm at fruitfly.org> wrote: >
>
>> Maybe its
>> better to keep *all*
>> these methods (including common_ancestor_path) out
>> of the classes, and
>> keep the object model focused on modeling the data.
>> I'm not really sure
>> what encapsulation buys you here. The only use I can
>> think of is if you
>> wanted to hide an in-memory/on-disk closure and use
>> that in your
>> calculation behind the scenes. But I don't think
>> that's such a good idea.
>> I guess what I'm suggesting is contrary to the
>> spirit of bioperl and OO in
>> general, but I would like to see more seperation of
>> data from behaviour.
>>
>>
>
> __________________________________________________
> Yahoo! Plus
> For a better Internet experience
> http://www.yahoo.co.uk/btoffer
>
-- 
-------------------------------------------------------------
Hilmar Lapp                            email: lapp at gnf.org
GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
-------------------------------------------------------------