[BioRuby] GSoC - project "Represent bio-objects and related information with images"

Wed Apr 6 21:06:12 UTC 2011

2011/4/6 Raoul Bonnal <bonnal at ingm.org>

>  Hi Michal,
> the time line is more detailed now.
> As Francesco suggested and also reported on our page we suggest RubyVis
> library, Claudio the coder of the binding offers his help and this is a very
> good news for us.
>
> Week 9: what do you mean for browsing images in shell ? I can't grasp the
> benefit now, but we can discuss. The main problem is how to control the
> application which displays  the image; for web browsers there are techniques
> but are not so easy.
>

The idea was to be able to view image right after it's created, not having
to juggle with opened folders, terminals or whatever else someone could use
for that. I thought that it would be useful and in some cases could save us
some mechanic job, but that's not an essential thing for sure.

> I'm just thinking to an add-on for this week: if we have different types of
> data that we can display quite easily on the web(done in the previous weeks)
> , why not spending this time to enrich the images with controls (bars, check
> boxes, interaction in general). This part requires a skill in javascript.
> http://vis.stanford.edu/protovis/ex/cartogram-full.html
> Or another interesting feature would be: adding layers of information to
> the standard image.
> Note: perhaps these ideas are a bit complicate for 1 week but it would be
> interesting to evaluate the feasibility.
>

I really like the enrichment idea, it's both useful and great looking :) The
question is: how exactly should we enrich those images? I think that
depending on what exactly we would like to achieve one week could be enough.
For example some on-demand displaying (from the set of images only those
which we check are currently visible) is not hard to do and quite useful.

>
> I forgot to mention, in some case I think that if there are web services
> which produce images that services could be used. Consider the possibility
> to display Venn diagrams Google has one service
> http://code.google.com/intl/it-IT/apis/chart/docs/gallery/venn_charts.htmlor another one is
> http://bioinfogp.cnb.csic.es/tools/venny/index.html.
> Sets are a kind of data type that in my daily work I have to display with a
> high frequency, specially when the boss needs to make reports :-)
>

Again, I am a little worried about the integrity. I mean, of course, if
implementing any of those would have to take a significant amount of time
than it's probably better not to carry about it so much and spend time
developing a new feature, but otherwise it's just unnecessary complicating
the code. At least that's my opinion.

>
> So we arrived to the which bioruby objects we want to display. This is a
> quite complex question because some are there and other are not.
> This library as been always sequence/feature centric (please correct me if
> I'm wrong), because we were used to demand to R tasks more statistics.
> Main areas are
> * NGS: display create coverage alignemnt for a region with the possible
> annotation that are accessible from bioruby
> * Matrix: display heatmaps, scatter plots, bars ( I wrote a very alpha lib
> for handling real time PCR  and gene expression datasets -not images-)
> * Sets: a seq could be generated from any kind of analysis, enrichment,
> annotation, reports
>  ** reports could be meta-objects for instance the results of an allignment
> or mapping or gene quantification when you need to compare multiple
> populations or technical replicates
> * Phylo (i'm not an expert)
>

I will have some additional questions about that tomorrow, right now my
brain refuses to work properly.

>
> with the idea to produce high quality images ready to be published.
>
> These are a bunch of ideas and words.
> About tomorrow IRC meeting, @work they scheduled a meeting for (my)
> afternoon, I'll do my best to be on IRC. Feel free to contact who is around.
>

I've tried that today, no one from BioRuby was around though. I guess that's
because I am dropping by too late.

>
> Regards.
>
> ------------------------------
> *From:* Christian Zmasek [mailto:cmzmasek at yahoo.com]
> *To:* Michał Koziarski [mailto:michalkoziarski at gmail.com], Chris Fields
> [mailto:cjfields at illinois.edu], bioruby at lists.open-bio.org
> *Cc:* Raoul Bonnal [mailto:bonnalraoul at ingm.it]
> *Sent:* Wed, 06 Apr 2011 20:48:32 +0200
> *Subject:* Re: [BioRuby] GSoC - project "Represent bio-objects and related
> information with images"
>
>
> Hi, Michał:
>
> You timeline is much better now!
>
> I put some comments/question into your text (see below).
>
>
>
> > Week 1:
> > Goal: choose one representative type of BioRuby object and develop class
> > that would convert its data to proposed format. That should come along
> with
> > unit tests.
>
>
> This is a good idea -- to deliver a proof of concept first!
>
> Did you think about how exactly the image(s) will be produced?
>
> Which library (if any) do you plan to use?
>
>
> Also do you plan to produce (interactive) graphics on the fly and/or create
>
> (static) image files (such as .png) to be viewed with other software?
>
>
>
>
> > Week 2:
> > Goal: develop graphical module that would create image files based on
> > data in unified format and provide user interface, write unit tests.
> >
> > On this point it should be possible to fully visualize chosen BioRuby
> > object.
> >
> > Weeks 3 to 8:
> > Goal: basing on first weeks work, prepare similar classes for all of the
> > remaining BioRuby objects. Each class should have unit tests.
> >
> > Week 9:
> > Goal: develop mechanism of browsing images in shell. It should include
> > simple search and a way of opening images.
> >
> > Week 10:
> > Goal: write integration tests.
> >
> > Weeks 11 and 12:
> > Goal: write documentation.
> >
> > I would like to be more specific about what should be done from weeks 3
> to
> > 8, though. It would be nice to plan some time for every object that needs
> > visualization, but I don't know which that would be exactly. Could you
> give
> > me a hand with this?
>
> I think Raoul can answer this better.
>
>
> I guess a good candidate would be sequence objects with features, such as
> intron/exon, mutations, etc.
>
>
>
>
> What about anticipated problems? Can you propose alternatives for things
> which
> might not work as planned?
>
> Christian
>
>