Hi Suzi,
I added Apollo as a category in the GMOD feature request tracker:
http://sourceforge.net/tracker/?func=3Dbrowse&group_id=3D27707&atid=3D391=
294
Scott
On Wed, 2007-08-22 at 06:58 -0700, Suzanna Lewis wrote:
> Yes, please do.
>=20
> I thought we had a request tracker already, but I can't locate it... =20
> Definitely something that is needed
>=20
> There is (was) a GFF adapter, but it needs to be upgraded to GFF3. =20
> I'm not sure how usable it is in it's current state (unused code =20
> tends to degrade). It is on the list as a part of the overall =20
> specific aim of better usage of the SO.
>=20
> But if someone wants to see what happens if they try the old GFF =20
> adapter it might be worth a shot.
>=20
> -S
>=20
> On Aug 21, 2007, at 11:02 AM, Scott Cain wrote:
>=20
> > I very much agree that a GFF3 adaptor would be good--that with
> > integration of ontology annotations would really be great. Of course,
> > there won't be time (I'm guessing) to work on that during the =20
> > hackathon.
> > I wonder if there is a feature request tracker for Apollo? I imagine
> > Suzi already has a list of things for the new Apollo developer to work
> > on, but giving them more ideas would be good too :-) There is not a
> > feature request tracker for Apollo on the GMOD sourceforge site, but I
> > could create one if Suzi thinks it would be useful.
> >
> > Scott
> >
> >
> > On Tue, 2007-08-21 at 10:54 -0700, cwilks wrote:
> >> Like Mark said, TAIR's not using chado (at all) and so we're =20
> >> interested
> >> in alternative methods of loading/writing. So a GFF3 (which we are
> >> using) adapter would be really great since we may be potentially =20
> >> hitting
> >> a wall with our own mostly homegrown adapter as far as performance =20
> >> and
> >> complexity is concerned.
> >>
> >> I would think from the community standpoint, a GFF adapter would be a
> >> good idea since as Chris points out it's pretty widespread, and is =20
> >> used
> >> for GBrowse.
> >>
> >> Of course I'm yet another apollo user/developer who won't be at the
> >> hackathon.
> >>
> >> just my two cents...
> >> Chris
> >>
> >> Christopher Smith wrote:
> >>
> >>> Mark,
> >>>
> >>> This came up briefly in a previous thread, but since GFF3 a wide-
> >>> spread standard, it would be -awesome- if Apollo could read/write =20
> >>> this
> >>> format. Having this available would greatly ease use Apollo in
> >>> classroom settings and for 'less advanced' users who do not =20
> >>> regularly
> >>> parse between all these formats. Once in GFF3 format, it seems like
> >>> there are plenty of 3rd party (i.e. BioPerl and other) adapters that
> >>> could then be used to meet the MOD-specific needs.
> >>>
> >>> It seems like the current Ensembl GFF adapter could be adjusted to
> >>> accommodate the syntax changes, but I am naive about how involved it
> >>> is to tweak the adapters. I won't be at the hackathon, but would not
> >>> have been much use if I was anyway :)
> >>>
> >>> Cheers,
> >>> Chris
> >>>
> >>> On Aug 21, 2007, at 9:30 AM, Mark Gibson wrote:
> >>>
> >>>> Hi all -
> >>>>
> >>>> So I know we are going to talk about this on Thursday, but I =20
> >>>> thought it
> >>>> might be good to talk a little before we got to Chicago. In =20
> >>>> particular
> >>>> Im wondering about apollo - as im an apollo developer (well ex- =20
> >>>> apollo -
> >>>> havent worked on it in a year & a half to be honest).
> >>>>
> >>>> So I guess Im wondering who is wanting improvements for apollo, =20
> >>>> and what
> >>>> those improvements are, and will you be at the hackathon?
> >>>> On scotts list I see apollo - chado round tripping. Let me try to
> >>>> summarize the current state (which unforutnately is all over the =20
> >>>> map) of
> >>>> where I think that round trip is at - and folks who know better =20
> >>>> should
> >>>> correct me:
> >>>>
> >>>> 1) There a chado xml adapter (read/write) nomi harris made for =20
> >>>> flybase
> >>>> that I believe is actively used by flybase(?). I also believe the
> >>>> requirements at the time for this adapter were to have it work for
> >>>> flybase, so I think it may not generalize too well outside of =20
> >>>> flybase at
> >>>> the moment. this relies on xort to then read & write chadoxml to =20
> >>>> chado -
> >>>> and i believe xort is generic & generalizable beyond flybase.
> >>>>
> >>>> [Jdbc adapters:]
> >>>>
> >>>> 2) Jdbc read: this was developed by jonathan crabtree at (ex)=20
> >>>> tigr (who
> >>>> unfoturnately cant make it) and i subsequently tweeked it - theres
> >>>> various configurations to deal with all the chado variations we
> >>>> encountered (tigr was initially using an early version of =20
> >>>> chado). the
> >>>> one bummer here is that this is slow - at least for rice on =20
> >>>> postgres - i
> >>>> think for tigr on sybase its not bad according to crabtree. but
> >>>> otherwise this works well - the other bummer is the jdbc code is a
> >>>> little unwieldy as jdbc code can get, but its not horrendous. this
> >>>> adapter has been used a fair amount by tigr, rice, berkeley, &
> >>>> paramecium.
> >>>>
> >>>> 3) apollo jdbc writeback adapter using postgres triggers. so =20
> >>>> guanming wu
> >>>> & i developed this for rice at cold spring harbor. I think it is =20
> >>>> still
> >>>> used by rice but im not positive about that. scott wrote postgres
> >>>> triggers that this adapter relies on. the upside is that the =20
> >>>> adapter
> >>>> didnt have to worry about certain things like id creation, =20
> >>>> cascading
> >>>> deletes,... - the downside was that the triggers were only for =20
> >>>> postgres,
> >>>> and also if there was an issue with them one either had to get =20
> >>>> scott to
> >>>> modify them or learn trigger coding in postgres. beyond rice i dont
> >>>> think this is used - cyril pommier was trying it out (and =20
> >>>> improved it)
> >>>> but moved on to his own solution below, same with crabtree at =20
> >>>> tigr &
> >>>> paramecium. also this solution is apollo-transaction based - it =20
> >>>> records
> >>>> every transaction the user makes in apollo. it then attempts to =20
> >>>> coalesce
> >>>> these transactions - getting rid of spurious transaction in an =20
> >>>> attempt
> >>>> to not bog down writeback - the coalescing was definitely a =20
> >>>> source of
> >>>> bugs - especially with merges & splits - and perhaps the coalescing
> >>>> thing should be scrapped and just let all the spurious transactions
> >>>> commit(see #4). Also this adapter took apollo transactions and made
> >>>> chado transactions out of them. those chado transaction could then
> >>>> either be used to to write out jdbc OR chado-xml for xort. the =20
> >>>> chado
> >>>> transaction xml for xort i believe was never used but it coud be =20
> >>>> and it
> >>>> ends up being helpful for debugging purposes and in theory it =20
> >>>> should be
> >>>> general(but it hasnt been tested?). so really theres 2 prongs here.
> >>>>
> >>>> 4) crabtree tried out #3, and scrapped it for a direct jdbc =20
> >>>> writeback -
> >>>> what i mean by direct is that it doesnt rely on db triggers at =20
> >>>> all - so
> >>>> all the trigger code was basically rewritten in java(id creation,
> >>>> cascading deletes...). This takes advatadge of the apollo =20
> >>>> transactions
> >>>> used in #3. olivier at paramecium i believe was having issues =20
> >>>> with the
> >>>> triggers of #3 (but made a bunch of improvements to #3) and =20
> >>>> jumped over
> >>>> to #4. crabtree also took out the chado transactions and i =20
> >>>> believe just
> >>>> goes straight from apollo transactions to jdbc. also scrapped the
> >>>> coalescing (which is probably wise in hindsight) so it writes =20
> >>>> back every
> >>>> apollo edit - spurious or not. this adapter is probably the most
> >>>> "current" in that its being actively developed by crabtree and =20
> >>>> olivier.
> >>>> though now it sounds like with tigr funkiness that tigr may not use
> >>>> apollo anymore(??? or more accurately start to use it?).
> >>>>
> >>>> note: both 3 & 4 use #2 for reading
> >>>>
> >>>> [others]
> >>>>
> >>>> 5) cyril pommier in france (at INRA-URGI? not sure if hes still =20
> >>>> there)
> >>>> took up #3 and made a bunch of improvements and then had postgress
> >>>> trigger issues of some sort (he was on a newer version of =20
> >>>> postgres that
> >>>> wasnt jibing with the older triggers or something like that), so he
> >>>> scrapped #3 - and went the route of apollo <-> gamexml <-> =20
> >>>> hibernate <->
> >>>> chado. I believe he just commited his hibernate layer to chado
> >>>> sourceforge. i believe his hibernate layer was generated from =20
> >>>> uml - and
> >>>> i think the uml was generated from the chado schema - or =20
> >>>> something like
> >>>> that. but this counts on gamexml (and apollos game adapter) =20
> >>>> being the
> >>>> intermediary here.
> >>>>
> >>>> 6) dictybase - my understanding is that this is:
> >>>> apollo <-> genbank file <-> dicty perl chado-genbank layer <-> =20
> >>>> chado
> >>>> this uses apollos genbank adapter and genbank file as an =20
> >>>> intermediary.
> >>>>
> >>>> 7) tair doesnt use chado but just thought id mention them =20
> >>>> anyways - tair
> >>>> wrote their own apollo adapter - they are using some sort of java
> >>>> object-relational mapping - im blanking on the details here - i =20
> >>>> think
> >>>> its at least partially homegrown (i dont think its hibernate)- =20
> >>>> and they
> >>>> also put their database ids into the apollo objects - which ive =20
> >>>> come to
> >>>> believe is an excellent idea - as it deals nicely with the whole
> >>>> coalescing/spurious thing
> >>>>
> >>>> one big headache i should mention in the chado-apollo =20
> >>>> interaction is
> >>>> shared exons vs unshared exons. apollo has unshared exons, chado is
> >>>> suppose to have shared exons - this mapping is extremeley =20
> >>>> tedious but i
> >>>> think its more or less working in #3 at least.
> >>>> from what i gathered for chado implementations i think flybase uses
> >>>> shared exons and so does rice, but i think dicty is unshared, =20
> >>>> paramecium
> >>>> i dont think has alternate splicing(?)(if they do i think they are
> >>>> unshared), not sure about tigr(crabtree?), i think cyrils is =20
> >>>> unshared as
> >>>> well. certainly an interesting issue.
> >>>>
> >>>> 8) future proposal - so apollo doesnt have a lot of resources at =20
> >>>> the
> >>>> moment - but there is a new hire coming into berkeley in a month =20
> >>>> or so
> >>>> (very exciting!) - one notion ive heard for yet another apollo =20
> >>>> chado
> >>>> adapter - as apparently there arent enough already - would be to =20
> >>>> go with
> >>>> hibernate - and there are 2 hibernate chado mappings out there =20
> >>>> if not
> >>>> more - i think they are both in sourceforge. i would also recommend
> >>>> putting chado ids into apollo (like tair does) and just submit
> >>>> new,deleted,& updated annotations (and scrapping shared exons - =20
> >>>> yes i
> >>>> know this is a scandal but several groups already have lets face =20
> >>>> it -
> >>>> practicality vs pure modeling) - so one question for this future =20
> >>>> apollo
> >>>> developer (and perhaps for the hackathon though it just 2 days) is
> >>>> should they work on this future proposal or work on one of the =20
> >>>> ones that
> >>>> is working - like 3 or 4 - since 4 seems to be the most worked on &
> >>>> tested these days that may be the way to go. unfortunately the main
> >>>> developer of 4 - crabtree - wont be at the hackathon but that =20
> >>>> shouldnt
> >>>> prevent us from jumping into it and crabtree is doing some docs =20
> >>>> for it
> >>>> this very nanosecond.
> >>>>
> >>>>
> >>>> oh and some comments on scotts other 2 apollo hackathon ideas:
> >>>>
> >>>> apollo-ensembl roundtripping - this is i believe steve searles =20
> >>>> realm (?)
> >>>> - ive noticed steve has lately been doing a bunch of commits to =20
> >>>> apollo
> >>>> with ensembl/sanger stuff presumably - unfortunately i dont =20
> >>>> think steve
> >>>> is coming to the hackathon
> >>>> steve - are you coming to the hackathon? and do your recent =20
> >>>> commits to
> >>>> apollo commits address this apollo-ensembl issue?
> >>>>
> >>>> and then theres annotating GO terms in apollo. olivier & linda =20
> >>>> (also
> >>>> wont be at hackathon unfortunately) want this for paramecium. =20
> >>>> they have
> >>>> proposed incorporating phenote (i didnt even prompt this - =20
> >>>> honest) into
> >>>> apollo - which im all for (phenote is my current project that is =20
> >>>> used to
> >>>> make ontological annotations like phenotype & GO & expression =20
> >>>> data).
> >>>> this would take some work but we could probably make some =20
> >>>> progress at
> >>>> the hackathon. olivier - have you done any work with this? and =20
> >>>> if so is
> >>>> it committed to apollo?
> >>>>
> >>>>
> >>>> looking forward to the hackathon! cheers - mark gibson
> >>>>
> >>>> Scott Cain wrote:
> >>>>
> >>>>> Hi All,
> >>>>>
> >>>>> Seven days and counting. I put together a short list of things
> >>>>> attendees could do before the meeting starts to make it go a =20
> >>>>> little
> >>>>> smoother. Please see the hackathon page on the GMOD wiki for more
> >>>>> information:
> >>>>>
> >>>>> http://www.gmod.org/wiki/index.php/Hackathon_2007_info#Preparation
> >>>>>
> >>>>> See you all in a week!
> >>>>> Scott
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------=20
> >>>> ---
> >>>> ---
> >>>> This SF.net email is sponsored by: Splunk Inc.
> >>>> Still grepping through log files to find problems? Stop.
> >>>> Now Search log events and configuration files using AJAX and a =20
> >>>> browser.
> >>>> Download your FREE copy of Splunk now >> http://get.splunk.com/
> >>>> _______________________________________________
> >>>> Gmod-schema mailing list
> >>>> Gmod-schema@...
> >>>> https://lists.sourceforge.net/lists/listinfo/gmod-schema
> >>>>
> >>> _______________________________________________
> >>> apollo mailing list
> >>> apollo@...
> >>> http://mail.fruitfly.org/mailman/listinfo/apollo
> >>
> > --=20
> > ----------------------------------------------------------------------=20
> > --
> > Scott Cain, Ph. D. =20
> > cain.cshl@...
> > GMOD Coordinator (http://www.gmod.org/) =20
> > 216-392-3087
> > Cold Spring Harbor Laboratory
> >
> > _______________________________________________
> > apollo mailing list
> > apollo@...
> > http://mail.fruitfly.org/mailman/listinfo/apollo
>=20
--=20
------------------------------------------------------------------------
Scott Cain, Ph. D. cain.cshl@...
GMOD Coordinator (http://www.gmod.org/) 216-392-3087
Cold Spring Harbor Laboratory
|