[Bioperl-l] Bio::Ontology

[Hilmar Lapp]

On Sunday, September 22, 2002, at 12:51 PM, Chris Mungall wrote:

>
>
> On Sat, 21 Sep 2002, Hilmar Lapp wrote:
>
>> It appears that ideally and as one of the first steps of reconciling
>> the two designs we should be able to merge ChrisM's VocabTermI and
>> ChrisZ's TermI.
>>
>> The following lists the differences and my votes.
>>
>>

<snip>

>> 4) label(). I'm not sure what this would be and whether it is
>> crucial for a Term. ChrisM as the expert, could you comment?
>
> label is just the name/phrase, eg 'transmembrane receptor'

OK, so my mistake - ChrisZ had name() here. To me as an 
ontology-layman name() is more intuitive than label(), which seems 
to be more graph-reminiscent, but I'm fine with both. ChrisZ, what 
do you think? Anyone else want to cast a vote?

<snip>

>> 8) timestamp(). ChrisM, is this crucial to a Term, or does it only
>> pertain to those who created the ontology? Is it rather a version()?
>
> it's not crucial - version would be fine
>

Great - I guess this also makes TermI then eligible for being 
IdentifiableI. Doesn't it?

>> 9) category(). Isn't this in fact a relationship of the Term? Should
>> there or should there not be an each_relationship() method on Term?
>
> this can be viewed as another relationship, between the term, and 
> the top
> level/generic terms in the ontology
>

So it would be like asking 'which ontology does this term belong to?'

> regarding making each_relationship() a method of Term - do you have an
> implementation that doesn't introduce cyclical perl references?

Good point. You mean because the relationship would have a link back 
to the term it was obtained from? If all the relationship objects 
are stored in memory along with the terms, then it's hard to imagine 
how you could avoid cycles.

However, an implementation could choose to keep the relationships in 
another form, and construct the RelationshipI objects only once they 
are requested. Also, the engine underpinning an ontology may be a 
database, and obtaining the relationships for a term may be 
implemented by triggering a query to the database.

I thought it'd be nice if you could transparently get the 
relationships for a term in the same way, independent of the 
underlying engine (graph, database, whatever). One way would be to 
stick the method to get those onto TermI, and the implementation 
makes sure you get the right thing for the particular engine that 
holds your ontology. Another one is to define an interface for an 
'OntologyEngine,' and once you obtained that you go. Or both may be 
useful. The first option appears easier to use to me, but may in 
practice be implemented by delegating to an OntologyEngineI object 
(just fantasizing about the name, but we actually had a discussion 
in this direction here on Friday).


>
>> These are all the differences as far as I see.
>>
>> RelationshipI makes a lot of sense to me, except that I think it
>> should not inherit from Graph::ArcI, and I'm also not sure why
>> Relationships shall have stable identifiers.
>>
>> Comments/thoughts/votes more than welcome.
>
> i'm happy with all the other changes
>

Wow - have you started meanwhile rolling in your code? If not, would 
you mind if I start rolling in at least those of your modules that 
we would need here? Or maybe I or someone can fix the problem that 
you have with cvs?

	-hilmar
--
-------------------------------------------------------------
Hilmar Lapp                            email: lapp at gnf.org
GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
-------------------------------------------------------------