[Bioperl-l] Bio::Ontology
Hilmar Lapp
hlapp@gnf.org
Thu, 19 Sep 2002 17:37:34 -0700
(sorry the previous one slipped through in a premature stage, clicked somewhere and it turns out I had better not clicked ...)
ChrisZ, Peter, and I sat over your proposal and brainstormed.
I'm trying to give a summary below. Chris, I think you've done a
great job with your proposal, please don't take the following as an
offense; it's just that we try to focus on a use case that is
probably much too narrow for what you're doing. Who codes it wins
the argument, so there are only winners here - 'cause all code :-)
So, generally speaking, what we were looking forward to here is one
or very few dumbed-down interfaces, an implementation of which an
ontology parser would return to you. We feel those interfaces should
only contain the minimal set of methods you can't go without given
straightforward use-cases. The implementation that the parser will
return will often be much richer, but it doesn't have to be. I.e.,
it should be as painless as possible to implement those interfaces,
but you can also be infinitely fancy in the implementation. We felt
that your interfaces rather outlined all methods an implementation
could possibly offer.
Also, we felt that your design wasn't very amenable to composition
since the GraphVocabI inherits off of Bio::Graph::GraphI. Although
in practice you could still implement via composition as I realize.
It just isn't encouraged by the interface.
What actually is an ontology parser then supposed to return in your
design? An instance of GraphVocabI or a parent class?
Another point, we felt that it's not necessary here to define possible
algorithms like the GraphIterator. If an implementation wants to use
them, fine. But it can accomplish the base functionality without.
I'd really like to have a very simple interface, and ideally that would
be the common denominator and shared between our implementations. So
people could have the world they choose to have, or can choose not to
care about those different implementations because they only look at
the minimal set of methods as defined by the dumbed-down interface.
Call us ignorants over here and dumb, but we felt for the 'average' use
case implementing and working with all this is way too overcomplicated.
The premise of this is of course that the average use case is dumb.
To make a long story short, I vote for KISS and then expand if you
need to.
So essentially I agree with your comments below, although I believe
that the fancier stuff on ontologies can perfectly live in bioperl as
well.
Do you feel we are missing something here?
Peter and ChrisZ are going to post a proposal for a minimal interface
tomorrow for people to comment. We'll then provide an implementation
via a wrapper to Graph::Directed that just maps this dumbed-down
interface to Graph::Directed methods.
-hilmar
On Thursday, September 19, 2002, at 01:45 PM, Chris Mungall wrote:
>
>
> On Thu, 19 Sep 2002, Hilmar Lapp wrote:
>
>> I agree, great stuff. It'd be even greater if you would have posted
>> some thoughts earlier on. We have an almost working implementation
>> ready to be committed too, ChrisZ posted some thoughts on that
>> couple days ago. And of course it's not the same. That's actually
>> exactly what I was trying to avoid.
>>
>> So I guess we will have two incompatible implementations in parallel
>> for a while <sigh>
>
> oops, sorry. have been incommunicado for much of the last 3 weeks
> (I did
> mention this in the original thread i think).
>
>> Also, our design has been much more bare-bones as that was all we
>> needed.
>>
>> I'll have to look into chris' proposal in more detail.
>>
>> And actually I disagree that requiring to install Graph from CPAN
>> would be bad. We're already requiring tons of dependencies to be
>> installed, and many of them are a true pain in the ass on various
>> platforms. Graph installed out-of-the-box on my machine (Mac OSX),
>> there's no compiled code in it.
>
> i think the important thing is to get our interface how we want
> it - then
> we can plug in any implementation we like, from CPAN or from Bio::Graph
>
> the CPAN graph module looks nice and comprehensive as far as most graph
> theoretic operations are concerned. however, a graph and an ontology
> aren't quite the same thing. for instance, the graph module doesn't
> treat
> arc types as nodes in the graph itself, which can be useful.
>
> I guess this points to another possibility - have a simple ontology
> object
> model in bioperl, which covers the vast majority of use cases, and keep
> the trickier ontology manipulation stuff in the GO codebase.
>
>> -hilmar
>>
>> On Thursday, September 19, 2002, at 10:39 AM, Ewan Birney wrote:
>>
>>>
>>> This is awesome stuff Chris, and as you know I like the basic
>>> layout. I
>>> feel that it is better to have Bio::Graph "inside" Bioperl - I know
>>> there
>>> is a nasty catch-22 here (surely it is generic...) but if we make
>>> this a
>>> hard dependancy --- which I would really like, making sure each
>>> sequence
>>> feature gets automagically attached to a Sequence Ontology term ---
>>> then
>>> asking people to install a separate graph package to get embl
>>> parsing to
>>> work is BAD.
>>>
>>>
>>> I also think that although graphs are seemingly generic, the use of
>>> graph
>>> structures end up being specialised, so the methods (eg, subsumed and
>>> inherieted) become more specific than people think.
>>>
>>>
>>>
>>> Any other thoughts?
>>>
>>>
>>> AnnotableI might == Hilmar's Bio::Entry (or perhaps Bio::Entry is
>>> "just"
>>> an AnnotableI)
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Bioperl-l mailing list
>>> Bioperl-l@bioperl.org
>>> http://bioperl.org/mailman/listinfo/bioperl-l
>>>
>> --
>> -------------------------------------------------------------
>> Hilmar Lapp email: lapp at gnf.org
>> GNF, San Diego, Ca. 92121 phone: +1-858-812-1757
>> -------------------------------------------------------------
>>
>>
>
>
--
-------------------------------------------------------------
Hilmar Lapp email: lapp at gnf.org
GNF, San Diego, Ca. 92121 phone: +1-858-812-1757
-------------------------------------------------------------