[Bioperl-l] Bio::Ontology

Ewan Birney birney@ebi.ac.uk
Sun, 22 Sep 2002 17:06:06 +0100 (BST)


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.
> 
> 1) Interface naming. My vote goes for the more general TermI, and 
> VocabTermI can add vocabulary-specific properties if there are any.
> 
> 2) Inheritance. My vote goes for largely if not completely 
> decoupling Ontologies and Graphs, disregarding that of course in 
> many practical cases you will want to execute graph-operations on 
> ontologies. I think this can be easily and more flexibly achieved by 
> composition rather than inheritance, which would mandate it. Hence, 
> my vote is TermI should not inherit from Graph::NodeI or any similar 
> interface.

Which way around does the composition go - Terms have-a Node or Nodes
have-a Term (or both, but then we have memory cycles?)

It the consequence of this that to do any graph operation from a Term you
need to have the graph object passed in?


... basically what operations are we prevent clients of either Term or
Node from not doing by going to composition/delegation in interfaces?

> 
> 3) identifier() vs ontology_id(). As I posted before, my vote is 
> identifier().
> 
> 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?
> 
> 5) definition()'s return value as an object or a string. ChrisM's 
> proposal suggests that if you're serious about ontologies, a 
> definition is much more than just a string. Adds to the complexity 
> though. Nonetheless, I tend to go with the ChrisM's call.
> 
> 6) each_synonym() vs each_alias(). Synonym sounds more like the 
> language of the field, so I'd vote for that. (Actually ChrisM named 
> it synonyms(), which is inconsistent with the each_XXX tradition 
> Ewan introduced.)
> 
> 7) each_dblink() vs each_reference. I vote for dblink because 
> reference is used in bioperl for literature references.
> 
> 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()?
> 
> 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?
> 
> 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.
> 

I'd love you hear Chris' response to this one...



> Comments/thoughts/votes more than welcome.
> 
> 	-hilmar
> 
> On Thursday, September 19, 2002, at 08:11 AM, Chris Mungall wrote:
> 
> > namespace Bio::Ontology
> >
> > typedef string Identifier
> >
> > interface VocabTermI extends Bio::Graph::NodeI
> >   attribute Identifier identifier
> >   attribute string label
> >   attribute VocabDefinition definition
> >   attribute string[] synonyms
> >   add_synonym(string synonym):
> >   attribute DBLink[] dblinks
> >   add_dblink(DBLink dblink):
> >   timestamp(): timestamp
> >   category(): VocabTerm
> >   is_obsolete(): boolean
> >
> > interface RelationshipI extends Bio::Graph::ArcI
> >   attribute Identifier identifier
> >   attribute TermI parent_term
> >   attribute TermI child_term
> >   attribute TermI relationship_type
> >
> > interface VocabDefinitionI extends Bio::Root::RootI
> >   attribute string definition
> >   attribute DBLink reference
> >   timestamp(): timestamp
> >
> >
> --
> -------------------------------------------------------------
> Hilmar Lapp                            email: lapp at gnf.org
> GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
> -------------------------------------------------------------
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
> 

-----------------------------------------------------------------
Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
<birney@ebi.ac.uk>. 
-----------------------------------------------------------------