On Monday, March 24, 2003, at 11:31 PM, Chris Mungall wrote:
Sorry for the tetchy tone of that last email
That's alright, I asked for it. I vented, you vented. Time to go back
to normal :)
I guess we're taking a different approach here, namely a purely applied
one. We built those modules bottom-up (hence the "engine" first),
trying to have something functional quickly, and the overall design as
simple as possible. I deliberately hoped that others (e.g. you) would
sanity check and weigh in to prevent it from becoming simpler than
necessary. So, I didn't actually want to be the only driver, which I
ended up as though.
I still think the current status is not that bad. What I wanted to
achieve with the overhaul that I started is not only to make it biosql
compatible, but also to get an API out into 1.2.1 that can be further
built upon instead of having to obsolete it in half a year. I'd
appreciate your review/comment on this question, but I understand if
you can't afford the time. Maybe since it's simply so young the
necessity to scrap the API down the road is inevitable anyway as we
learn more lessons.
As for the terminology, you're clearly right. Unless someone wants to
keep the existing parent/child naming, I'll change that to
subj/pred/obj, with undocumented aliases parent/child. Ewan, I'm afraid
this better goes into 1.2.1. ETA tomorrow or Wednesday.
<digression to="biosql">
Quite honestly though, I'm not sure why your arguments wouldn't also
apply to bioentry and seqfeature relationships - shouldn't we rename
parent/child there too?
</digression>
Thanks for the pointers, I appreciate that. I was trying to get away
with being ignorant, but probably that's not going to work.
- I don't mean to sound
unappreciative of all the great stuff you & the rest of GNF have done.
I'd be interested in discussing some extensions to the ontology modules
for dealing with some of the things I mentioned at the end. Given that
my
email response rate is rather poor and we're both on the west coast
not a
million miles from each other, what about meeting up to discuss future
plans for the ontology modules?
I'd be glad to. You raise some good points about how frame or DL based
ontologies would fit into the current model, and frankly I don't know.
-hilmar
On Mon, 24 Mar 2003, Chris Mungall wrote:
On Mon, 24 Mar 2003, Hilmar Lapp wrote:
On Monday, March 24, 2003, at 12:55 PM, Chris Mungall wrote:
surely the onus is on you to
justify divergence from both the entire ontology community & bioSQL?
So let me vent some frustration here.
1) We (GNF) have been driving forward the ontology support in bioperl
since September last year. This was the first time ever we ventured
into ontologies, and we were well aware that an "entire ontology
community" had long existed before, but apparently the motivation to
drive ontology support in bioperl was minor to not existent in that
community. I have repeatedly bugged the "ontology community" to
please
weigh in and weigh in early, help, discuss, debate. Search the
mailing
list archives for the result.
I don't think the general ontology community hang out on bioperl much
-
just the subset who are also into biology and perl.
2) The currently "divergent" terminology used in bioperl was the one
that after hours of discussion came out as most understandable to us,
us being at that time entirely new to ontologies. subj/pred/obj was
just incomprehensible, like it or not. When I overhauled the ontology
modules, and, Chris, when we were in Singapore, there were plenty of
pledges I made and plenty of opportunities to chime in and provide
insight from the "entire ontology community". No-one of that
community
apparently even bothered to help ensure that the bioperl ontology
terminologies are sensible on the background of the domain knowledge
too.
3) As for biosql, term relationships to me are no different to
feature
and bioentry relationships. For feature and bioentry relationships we
use parent/child, and everyone seems to be alright with this.
Bottom line is, I said before that I'm willing to change it according
to community input, but the onus if there is any is clearly on the
"entire ontology community" to provide their insight and help, and to
provide that before the last minute, and to continue providing it.
Letting the lay people march ahead and then asking them for
justification why they marched into that evidently stupid direction
is
not a very productive way to get things done and get them done right.
I appreciate all the work GNF has done here. I'm sorry if I can't
always
get my comments in on time to suit your schedule.
Bear in mind that back in september I had a large body of functioning
code
for dealing with ontologies - interfaces, classes, parsers, tests -
all
ready to check in, see:
http://bioperl.org/pipermail/bioperl-l/2002-September/009414.html
You jumped in the drivers seat, checked in your own code, and I was
fine
with that. There were certainly plenty of flaws in my design.
However, now
that you're in the drivers seat it behooves you to get some kind of
roadmap or at least an idea of the lay of the land. There is no
shortage
of introductory documentation out there on ontologies, particularly
W3C
ontology languages such as OWL and its predecessor DAML+OIL. Perhaps
it is
the case that these are not relevant to the particular problems we
face in
bioinformatics (personally I do not believe this to be the case).
Nevertheless, one thing I believe is constant from the latest
description
logics to the earliest semantic networks is the concept of binary
predicates consisting of a subject and an object. I'm sorry this was
incomprehensible to you at first (a bit of cursory research in the
field
would have sorted that out) - I guarantee it will be nowhere near as
incomprehensible as when we eventually have ontologies with this:
parent=X
child=Y
relationship= synthesises
does X synthesise Y or does Y synthesise X? Show me a document that I
can
refer to in order to find the correct interpretation. Presumably this
would have to be some within-bioperl standard, buried deep in pod docs
somewhere. Is this good? (And the mind boggles if the relationship
we're
focused on is 'is_parent_of')
subject=X
object=Y
relationship= synthesises
is completely unambiguous - you can refer to either any document on
semantic webs written in the last thirty years, the W3C RDF standard
or
failing that, basic grammatical rules. X is the subject of the
sentence
(ie it is the thing synthesising), and Y is the object (the thing
being
synthesised). I would prefer the more standard 'predicate' instead of
'relationship'.
I'm sorry I didn't chime in with this sooner (I thought I had done).
(Anyway, can't we just make parent a synonym method of object as a
compromise?). To be honest I don't have the energy to keep up to date
with
everything in bioperl, I can't multitask that well, usually I save it
all
up for a few bioperl days where I try and take it in at once. It's
harder
when a lot of my ontology-related headspace is occupied with the
go-dev
codebase and getting around a lot of the mistakes I made with the
object
model there that I don't want to see replicated in bioperl.
I'm still not sure who the 'entire ontology community' is you are
petitioning for insight and help. I'm giving what help I can, but I
don't
consider myself part of that community, I'm just a dilettante (paying
attention to what Robert Stevens' group is doing helps me a lot -
though I
take full responsibility for any rubbish i may come out with). I'd
urge
you to also search further afield for that insight and help. I would
also
urge you - as I'm sure I have before - to start thinking about
ontologies
that have relationships other than is_a and part_of, cyclical
relationships, and also about how property-based ontologies
(frame-style
systems and full blown description logics) fit into your model.
Thank you.
-hilmar
_______________________________________________
Bioperl-l mailing list
Bioperl-l@xxxxxxxxxxx
http://bioperl.org/mailman/listinfo/bioperl-l
--
-------------------------------------------------------------
Hilmar Lapp email: lapp at gnf.org
GNF, San Diego, Ca. 92121 phone: +1-858-812-1757
-------------------------------------------------------------
|
