gmod-ajax — JBrowse list

Re: [Gmod-ajax] Simile::Timeline

[Chris M. <cj...@fr...>]

On Feb 7, 2007, at 5:21 PM, Mitch Skinner wrote:

> Chris Mungall wrote:
>> For example: your doing some history research on wikipedia - you
>> bookmark semantic content as you go along, then you can browse this
>> in piggybank and show the events you've select on a Timeline. Or see
>> the spatial projection on google maps. It's pro-active mashups - why
>> wait for some developer to create a mashup page for you, when you can
>> do your own mashing?
>>
> As I understand it, doing a mashup requires either server-side  
> developer
> help or a client-side plugin with special security privileges (like
> Piggy Bank).  Otherwise the javascript same-source requirement  
> keeps you
> from combining data from multiple sources, right?
>
> I'm certainly up for implementing things with a view toward supporting
> things like Piggy Bank.  But I'm not sure if you're suggesting that we
> should implement some functionality as a browser plugin ourselves.

Nope, just advocating semantic transparency, where it is not  
burdensome to do so. Then hopefully others will come along and do the  
work...

> Mitch
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services,  
> security?
> Get stuff done quickly with pre-integrated technology to make your  
> job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache  
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Gmod-ajax mailing list
> Gmo...@li...
> https://lists.sourceforge.net/lists/listinfo/gmod-ajax
>

Re: [Gmod-ajax] Simile::Timeline

[Mitch S. <mit...@be...>]

Chris Mungall wrote:
> For example: your doing some history research on wikipedia - you  
> bookmark semantic content as you go along, then you can browse this  
> in piggybank and show the events you've select on a Timeline. Or see  
> the spatial projection on google maps. It's pro-active mashups - why  
> wait for some developer to create a mashup page for you, when you can  
> do your own mashing?
>   
As I understand it, doing a mashup requires either server-side developer 
help or a client-side plugin with special security privileges (like 
Piggy Bank).  Otherwise the javascript same-source requirement keeps you 
from combining data from multiple sources, right?

I'm certainly up for implementing things with a view toward supporting 
things like Piggy Bank.  But I'm not sure if you're suggesting that we 
should implement some functionality as a browser plugin ourselves.

Mitch

Re: [Gmod-ajax] Simile::Timeline

[Mitch S. <mit...@be...>]

Chris Mungall wrote:
> All that is required is a trivial amount of data exposure as RDF and  
> minimal coordination on use of URIs (much of what is already in  
> place). I think some work still needs done on the tools side of  
> things, but provision of the datasets will help complete the virtuous  
> circle.
>   
I'm interested in the URI coordination issue.  If we end up with (say) a 
wiki page per feature, how should the URI for the wiki page relate to 
the URI for the feature?  I'm tempted to have them be the same URI and 
serve different content using HTTP content negotiation.  Does anyone 
here have good or bad experience with this?

I understand that in some circles it's considered broken, but these 
people are trying to decide whether the server should send back HTML or 
xhtml, which is a fine distinction in the best of circumstances.  I'm 
hoping that accept: application/x-das-features+xml or accept: 
application/rdf+xml will be easy enough to distinguish from accept: 
application/html.  But my experience here is limited.  Are there any 
browsers that include both RDF and HTML in their accept: headers?

I'm inclined to say that the actual resource (e.g., feature) is the same 
in all those cases, and RDF vs. x-das-features+xml vs 
application/html+xml is just a different representation of the 
resource.  But I'd certainly like to hear any other opinions on this point.

I imagine that the URI coordination on the ontology side is pretty well 
implemented, but for feature URIs I'm not sure where things stand.  Does 
LSID have any relevance to the kinds of URI coordination we want to do?  
What's the state of implementation with LSID anyway?

Mitch

Re: [Gmod-ajax] Simile::Timeline

[Chris M. <cj...@fr...>]

On Jan 27, 2007, at 3:33 PM, Hilmar Lapp wrote:

> SIMILE (http://simile.mit.edu) is a project MIT consisting of various
> subcomponents dealing with semantic interoperability and metadata.
>
> One of their AJAX/JavaScript-based applications, called Timeline,
> displays temporal data along time axes of different resolutions, and
> the horizontal panel can be smoothly dragged with the mouse, much
> like Google Maps. The time axes move along, with different velocities
> based on resolution. See http://simile.mit.edu/timeline/ and the
> examples linked from there.
>
> Obviously, I thought if you replace the time scales with genomic
> scales, and the temporal events with genomic features, you would
> pretty much have an AJAX-based genome browser.

The Simile group are producing some interesting applications.  
Timeline has some neat ideas for how we can do graphics, but we  
should also be looking to this group and others in the semantic web  
community for ideas about how to do mashups.

For example, Piggy Bank is a firefox plugin that extracts semantic  
content from web pages:
http://simile.mit.edu/wiki/Piggy_Bank

For example: your doing some history research on wikipedia - you  
bookmark semantic content as you go along, then you can browse this  
in piggybank and show the events you've select on a Timeline. Or see  
the spatial projection on google maps. It's pro-active mashups - why  
wait for some developer to create a mashup page for you, when you can  
do your own mashing?

The semantic content can be obtained by screenscraping (a bit messy),  
or, preferably, the developers can make their site semantic-web  
friendly and add links (hidden to the average user) to RDF metadata.

Let's have a look at some scenarios relevant to us:

Zipping along in gbrowse, the user bookmarks genes of interest. They  
then go over to AmiGO and perform a term enrichment analysis on their  
bookmarked genes against the GO database. No cut-n-paste required!  
Perhaps their analysis leads them to an interesting term like  
"regulation of photoreceptor development" - they can find genes  
annotated to this term, bookmark them, then show them in gbrowse.

All that is required is a trivial amount of data exposure as RDF and  
minimal coordination on use of URIs (much of what is already in  
place). I think some work still needs done on the tools side of  
things, but provision of the datasets will help complete the virtuous  
circle.

> Has anyone looked at this? Maybe some of the code there can be reused?
>
> Just an idea ...
>
> 	-hilmar
> -- 
> ===========================================================
> : Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
> ===========================================================
>
>
>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gmod-ajax mailing list
> Gmo...@li...
> https://lists.sourceforge.net/lists/listinfo/gmod-ajax
>

Re: [Gmod-ajax] Community annotation

[Mitch S. <mit...@be...>]

Ian Holmes wrote:
> Can you let us know when you've posted this email up on a biowiki page...
>   
I finally did this:
http://biowiki.org/view/GBrowse/CommunityAnnotation

Mitch

Re: [Gmod-ajax] Synteny

[Mitch S. <mit...@be...>]

Mitch Skinner wrote:
> I had a conversation with Andrew today where we pretty much agreed on 
> the same thing.  I'm currently working on making memory/database a 
> run-time option.  So far I've touched TiledImage.pm and I think I'm also 
> going to need to touch generate-tiles.pl.  So this will probably affect 
> the on-demand rendering code a little as well.
>   
I committed a change that implements this.  There's a new 
generate-tiles.pl option:
  -primdb <dsn>
        optional parameter to use a database to store graphical
        primitives.  Slower, but uses less memory and allows for
        rendering on demand.
        example: -primdb DBI:mysql:gdtile

With the in-memory version, this is how the profile looks now (on the S. 
cerevisiae chr. I named genes track):
Total Elapsed Time = 11.91910 Seconds
  User+System Time = 11.90910 Seconds
Exclusive Times
%Time ExclSec CumulS #Calls sec/call Csec/c  Name
 116.   13.82 15.221 349363   0.0000 0.0000  TiledImage::AUTOLOAD
 45.8   5.464  5.464   2303   0.0024 0.0024  GD::Image::png
 12.6   1.504  1.504 230322   0.0000 0.0000  TiledImagePanel::map_pt
 7.85   0.935  4.260     73   0.0128 0.0584  TiledImage::renderTile
 7.79   0.928  0.928 460682   0.0000 0.0000  GD::Image::line
 7.73   0.920 10.749      1   0.9198 10.748  
BatchTiledImage::renderTileRange
 7.33   0.873  0.873 230702   0.0000 0.0000  TiledImage::__ANON__
 5.11   0.608  0.608 460764   0.0000 0.0000  TiledImage::min
 4.11   0.489  0.489    491   0.0010 0.0010  
Bio::Graphics::Glyph::_collision_k
                                             eys
 4.01   0.478  0.478 460764   0.0000 0.0000  TiledImage::max
 3.39   0.404  0.404   2377   0.0002 0.0002  GD::Image::_new

This is with my modified version of GD.

Clearly, DProf is confused about some things (I'm pretty sure that 
TiledImage::AUTOLOAD isn't taking 116% of the total runtime), but I'm 
hoping that it's right about the general ranking.  I've got some ideas 
and code for reducing the amount of time taken by TiledImage::AUTOLOAD 
and GD::Image::png, but those might wait until after Andrew has 
committed some of the things he's got in mind.  In particular, his 
gridline idea should help a lot with memory usage.

Mitch

Re: [Gmod-ajax] Synteny

[Mitch S. <mit...@be...>]

Ian Holmes wrote:
> We should probably not do away with database approaches entirely. At 
> some point, someone will inevitably try to render some track with 3 
> billion features per base or something crazy like that...
I had a conversation with Andrew today where we pretty much agreed on 
the same thing.  I'm currently working on making memory/database a 
run-time option.  So far I've touched TiledImage.pm and I think I'm also 
going to need to touch generate-tiles.pl.  So this will probably affect 
the on-demand rendering code a little as well.

Mitch

Re: [Gmod-ajax] Synteny

[Ian H. <ih...@be...>]

Mitch Skinner wrote:
> The main obstacle at this point would be that rendering a human or mouse
> genome would take a long time.  I've been working on speeding it up, but
> I haven't checked that stuff into CVS yet, as we've still not made a
> decision about whether or not we need the graphics primitive database,
> which I think may be the wrong approach.  The graphics primitive
> database stores all of the drawing commands (like line, rectangle, text)
> so they can be replayed later in chunks.  I think (but haven't yet
> shown) that we can do it all by storing graphics primitives in memory,
> which is more than an order of magnitude faster.  I've appended the full
> discussion below.
> 
> Maybe Aaron can help us parallelize the rendering
> (MPI-tilerendering?) :-)
> 
> I (and Andrew?) will be exploring the options and taking some
> measurements in the near future.  Rendering some larger chromosomes is
> pretty high on my to-do list, and then we'll have a better idea of how
> to move forward.  I do think being able to handle large chromosomes is
> important functionality to demo, right up there with search and
> community annotation (Ian, Andrew: agree or disagree?).

I agree. Big chromosomes are the top priority. The quick-and-dirty patch 
for this was the "render-on-demand" approach where you populate the 
primitives database but only pull out the primitives and create a tile 
image file when that tile (or one of its near neighbors) is requested by 
a client somewhere.

I had some vague idea that there was already an "in_memory" sort of 
switch somewhere in TiledImage.pm that would bypass the primitives 
database but maybe not. Actually, early on, I did try to store the 
primitives in an R-tree but decided an SQL database was just faster. We 
did try various other things too, like creating a big SVG (which 
crashed) and a big PNG (which ran out of memory).

> Reasons for the primitive DB:
> 1. break up genome by pixel coordinates into smaller chunks for
> rendering--takes less RAM per chunk/can be parallelized.
> On the other hand, we may be able to break up the genome accurately
> without precomputing and storing all of the primitives.  The main
> concern here is that it's sometimes difficult to predict the pixel span
> of a feature from its genomic span (especially with text labels).  One
> option is to do the pixel-level layout of the entire track in each
> rendering job but only store/render the primitives that overlap the part
> of the track that's currently being rendered.  Having each chunk
> recompute the full layout is redundant work, but I'm pretty sure that
> recomputing the layout is faster than fetching all the primitives from
> the database.

I think that the fastest/slimmest solution of all would be if we could 
do the layout once, store the minimal information required to reproduce 
the layout (either in memory if we're generating all the tiles in one 
go, or in a database if we're doing render-on-demand), and then use this 
information to position and render each glyph.

The only reason we didn't do this at first was that it seemed to require 
a slightly more intimate familiarity with the workings of 
Bio::Graphics::Panel than we had at first, and writing a GD interception 
layer seemed reasonably straightforward (and sufficiently "generic" that 
it might conceivably continue to be useful for a while).

We could definitely benefit from having a chat with Lincoln about how 
GBrowse layout works.

Another thing to bear in mind is that the method used to render the 
tracks doesn't *have* to rest entirely on existing GBrowse code. For 
example, we could quite easily write a light & fast C/C++ track renderer 
for uploaded features, similar to UCSC's. Having this extra AJAX layer 
does allow us some flexibility & modularity in the way we choose to do 
rendering on the server.

> BTW: this is one of the reasons to explore client-side labels.
> 
> 2. if a small part of a track changes we may be able to save work by
> re-rendering only a small area.
> As far as I know we're not yet storing which feature each primitive is
> for, so it's difficult to invalidate the right primitives.  Plus, adding
> a new feature to a track can potentially cause a large portion of the
> track to change (if it has to be laid out ("bumped") again).  And at
> this point I'm not sure how much we need to support individual feature
> creation/editing.

I personally am starting to think we should not worry about feature 
creation/editing until we have to, because it raises too many speed 
bumps like this...

> 3. doing only the layout/database fill work up front and then rendering
> tiles from the database on demand reduces the amount of time people have
> to wait between uploading their annotations and seeing them in the
> browser.
> On the other hand, we may be able to do a full in-memory pre-rendering
> in less time than it takes to fill the database.
> 
> Am I missing anything here?

No -- I think this is a pretty succinct & accurate statement of the 
situation, especially #3.

We should probably not do away with database approaches entirely. At 
some point, someone will inevitably try to render some track with 3 
billion features per base or something crazy like that...

Ian


> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Gmod-ajax mailing list
> Gmo...@li...
> https://lists.sourceforge.net/lists/listinfo/gmod-ajax

Re: [Gmod-ajax] Synteny

[Mitch S. <li...@ar...>]

On Thu, 2007-02-01 at 18:56 +1000, Aaron Darling wrote:
> I really liked the demo at http://genome.biowiki.org/ 
> Would it be possible for my friends at Univ. of Wisconsin to set up their
> own instance and load mammalian genome data into it?

The code is in the gmod CVS on sourceforge in
gmod/Generic-Genome-Browser/ajax.  Beyond that, Andrew wrote up how to
install the pre-rendering stuff here:
http://biowiki.org/twiki/bin/view/GBrowse/InstallTileRendering

The main obstacle at this point would be that rendering a human or mouse
genome would take a long time.  I've been working on speeding it up, but
I haven't checked that stuff into CVS yet, as we've still not made a
decision about whether or not we need the graphics primitive database,
which I think may be the wrong approach.  The graphics primitive
database stores all of the drawing commands (like line, rectangle, text)
so they can be replayed later in chunks.  I think (but haven't yet
shown) that we can do it all by storing graphics primitives in memory,
which is more than an order of magnitude faster.  I've appended the full
discussion below.

Maybe Aaron can help us parallelize the rendering
(MPI-tilerendering?) :-)

I (and Andrew?) will be exploring the options and taking some
measurements in the near future.  Rendering some larger chromosomes is
pretty high on my to-do list, and then we'll have a better idea of how
to move forward.  I do think being able to handle large chromosomes is
important functionality to demo, right up there with search and
community annotation (Ian, Andrew: agree or disagree?).

Mitch

Reasons for the primitive DB:
1. break up genome by pixel coordinates into smaller chunks for
rendering--takes less RAM per chunk/can be parallelized.
On the other hand, we may be able to break up the genome accurately
without precomputing and storing all of the primitives.  The main
concern here is that it's sometimes difficult to predict the pixel span
of a feature from its genomic span (especially with text labels).  One
option is to do the pixel-level layout of the entire track in each
rendering job but only store/render the primitives that overlap the part
of the track that's currently being rendered.  Having each chunk
recompute the full layout is redundant work, but I'm pretty sure that
recomputing the layout is faster than fetching all the primitives from
the database.
BTW: this is one of the reasons to explore client-side labels.

2. if a small part of a track changes we may be able to save work by
re-rendering only a small area.
As far as I know we're not yet storing which feature each primitive is
for, so it's difficult to invalidate the right primitives.  Plus, adding
a new feature to a track can potentially cause a large portion of the
track to change (if it has to be laid out ("bumped") again).  And at
this point I'm not sure how much we need to support individual feature
creation/editing.

3. doing only the layout/database fill work up front and then rendering
tiles from the database on demand reduces the amount of time people have
to wait between uploading their annotations and seeing them in the
browser.
On the other hand, we may be able to do a full in-memory pre-rendering
in less time than it takes to fill the database.

Am I missing anything here?

Re: [Gmod-ajax] Synteny

[Aaron D. <a.d...@im...>]

Thanks for the intro Ian,

Yes, Mauve displays synteny and genome rearrangement for two or more genomes
along with sequence annotation and sequence identity plots.  Perhaps the
best way to describe it is by example, there's a few screenshots here:
http://gel.ahabs.wisc.edu/mauve-aligner/mauve-user-guide/mauve-screenshots.h
tml

The viewer program is Java based, relying heavily on BioJava for parsing and
displaying sequence annotations.  However, the core data set being displayed
is a multiple genome alignment computed by progressiveMauve.  The alignment
provides a complete basis for the comparative display, since it contains
both a synteny map and a full multiple sequence alignment for each syntenic
region.  By the way, we don't call them Synteny Blocks, but rather "Locally
Collinear Blocks" or just LCBs.

The progressiveMauve command-line program dumps the alignment out to a text
file in eXtended-Multi-FastA format, so it can be read and displayed in
other genome browsers.  Sockeye and M-GCAT are two others I know of that can
read and display XMFA data.  

A gbrowse/AJAX type of browser would be great to display synteny
information, and would likely be much nicer to use than Mauve's interactive
display in many situations.  Standalone programs like Mauve don't deal well
with large genome comparisons.  For example, a human/mouse/rat genome
alignment weighs in at around 12Gbytes, and the data set is far too massive
for users to download to their computers.  Storing the alignment on a server
and accessing it via a gbrowse/AJAX type client is really the only tenable
solution.

I really liked the demo at http://genome.biowiki.org/ 
Would it be possible for my friends at Univ. of Wisconsin to set up their
own instance and load mammalian genome data into it?

By the way, the mauve home page is
http://gel.ahabs.wisc.edu/mauve
And we've got a sourceforge project for it:
http://sourceforge.net/projects/mauve
The "alignments" web page that Ian linked to is pretty badly out-of-date and
desperately needs to be fixed.  I think the drosophila alignments were
generated by a buggy version of the aligner back in 2004 (yikes!).

-Aaron


-----Original Message-----
From: Ian Holmes [mailto:ih...@be...] 
Sent: Thursday, 1 February 2007 2:14 PM
To: Aaron Darling; gmo...@li...
Subject: Synteny

One of the future applications of the AJAX genome browser that I've been
excited about for some time is the possibility of opening two parallel views
of two related genomes, with one of the views being the "master" 
genome, and the other view displaying a region of the second genome that was
syntenic to the "master" segment currently being displayed. As you slide the
master around, the secondary view would follow.

Up until now, the only tool I knew of that did this was the Artemis
Comparison Tool from Sanger. Well, here I am in Brisbane talking with Aaron
Darling, who worked on MAUVE and the associated MAUVE Java viewer.

http://gel.ahabs.wisc.edu/mauve/alignments.php

I'll let Aaron (CC'd) describe what kind of data it's designed to display
and how you navigate it. I mainly just wanted to point this out as another
tool in the genome browser ecosystem... I also think it's quite similar to
the sort of synteny viewer I (eventually) thought it would be cool to build
out of parts of our browser.


BTW here's the ACT webpage:

http://www.sanger.ac.uk/Software/ACT/

[Gmod-ajax] Synteny

[Ian H. <ih...@be...>]

One of the future applications of the AJAX genome browser that I've been 
excited about for some time is the possibility of opening two parallel 
views of two related genomes, with one of the views being the "master" 
genome, and the other view displaying a region of the second genome that 
was syntenic to the "master" segment currently being displayed. As you 
slide the master around, the secondary view would follow.

Up until now, the only tool I knew of that did this was the Artemis 
Comparison Tool from Sanger. Well, here I am in Brisbane talking with 
Aaron Darling, who worked on MAUVE and the associated MAUVE Java viewer.

http://gel.ahabs.wisc.edu/mauve/alignments.php

I'll let Aaron (CC'd) describe what kind of data it's designed to 
display and how you navigate it. I mainly just wanted to point this out 
as another tool in the genome browser ecosystem... I also think it's 
quite similar to the sort of synteny viewer I (eventually) thought it 
would be cool to build out of parts of our browser.


BTW here's the ACT webpage:

http://www.sanger.ac.uk/Software/ACT/

Re: [Gmod-ajax] Community annotation

[Ian H. <ih...@be...>]

Thanks for this Mitch.

As you say, my opinion is that we should get (crude) prototypes of 
community annotation and search working quickly (ideally by, say, 
RECOMB), if only because people can clearly SEE that we are working on 
GUI development, but community annotation (in particular) is currently 
just a twinkle in the eye (or, less prosaically, a few lines in a grant 
proposal).

If we can get something even quite simple going, like UCSC-style GFF/BED 
upload, I think it will really help in providing some direction.

I'm inclined to agree that drawing features on the genome is difficult 
to do well & better served by Apollo etc, although I don't really know 
enough about who uses GMOD to understand the use case. I recall Lincoln 
was into this at one point so perhaps he has some idea.

Can you let us know when you've posted this email up on a biowiki page...

I suggest we try to set a date to talk about this stuff in more detail 
on a GMOD conference call -- ideally in a couple of weeks or so when I'm 
back in Berkeley (so I don't have to get up at some bleary-eyed hour in 
order to participate from Australia)

cheers
Ian


Mitch Skinner wrote:
> On Fri, 2007-01-19 at 11:20 +1100, Ian Holmes wrote:
>> Now that we have a full-time gmod-ajax person (in the form of Mitch) 
>> it's probably about time to kick off a discussion on how to move towards 
>> our goals of community annotation (and what this means exactly) and full 
>> browser functionality including search, rich display, etc (and to what 
>> extent this should be GBrowse-like).
> 
> As far as community annotation goes, I'm going to try and summarize the
> different things I've heard and read and thought so far.  Hopefully this
> is not retreading heavily covered ground too much -
> 
> There are three kinds of community annotation that have been talked
> about:
> 1. Bulk annotation upload. Lots of people have GFF/BED/etc. files that
> they'd like to see rendered.  We ought to make this dead simple.
> Existing examples include Santa Cruz's upload functionality:
> http://genome.ucsc.edu/cgi-bin/hgCustom
> and GBrowse's:
> http://gmod.cvs.sourceforge.net/*checkout*/gmod/Generic-Genome-Browser/htdocs/annotation_help.html
> 
> As I see it, the fundamental difference between "annotation upload" as
> currently implemented and "community annotation" like Ian's talking
> about above is that with annotation upload the uploader is the only one
> looking at their annotations, while with community annotation
> potentially everyone else is looking at them as well.
> 
> This immediately raises a number of questions, like how to manage all
> the uploaded tracks.  These will obviously vary in usefulness, and we
> don't want to clutter up the display too much; on the other hand we
> don't want to make people pick from a huge list as a prerequisite to
> using the browser.  This suggests that we'll want to have a list of
> "blessed" or "default" tracks, but then you have the problem of choosing
> those.  Or we could have a track ranking mechanism where we show the top
> n highest ranked tracks, but then we have the problem of coming up with
> the track rankings.  One option would be a moderation system (e.g.,
> "Digg this track [+/-]").  In the fancy extreme we could even have a
> collaborative filtering mechanism where we "recommend" tracks to people
> based on their previous moderations.
> 
> In any case, making annotation upload work is a prerequisite to
> everything else, so that's the first priority IMO.  The main things we
> have to do differently from current annotation upload are kicking off a
> pre-rendering or primitive database fill operation and coming up with
> some way of notifying the user when their track is ready to view.
> Anything else?
> 
> 2. Individual feature creation/editing.  It would be neat to be able to
> "draw" and "resize" features by clicking and dragging with the mouse.  I
> believe this is possible to do in the browser, but it is fairly fancy
> and might be difficult to do in a cross-browser way.  Suzi Lewis and
> Chris Mungall at Berkeley BOP seem to think that this need is adequately
> served by fatter clients like Apollo.  Can anyone think of a use case
> where someone would want to be able to adjust feature boundaries but
> would be a casual enough user to not want to install Apollo?  I would
> imagine that most people who want to e.g. edit gene models would be
> involved enough to install some software but my experience here is
> limited.  If no one can come up with a compelling use case for having
> this on a web browser I'd be tempted to leave this out entirely, or at
> least leave it until the other community annotation things are
> implemented.
> 
> 3. Feature "commenting".  Not sure what to call this (annotation
> annotation?), but I'm sure there are lots of biologists out there who
> know a lot about a relatively small number of genes.  This is the kind
> of knowledge that wouldn't be a good fit for creating an entire track
> with (so it doesn't fit well into the bulk annotation upload mechanism),
> but would work better for adding information about features on an
> existing track.  Examples that I can imagine include adding GO terms to
> existing annotations, adding information about where a certain gene is
> expressed, what pathways a gene is involved in, literature references,
> etc.  Some of these things could be stored in Chado (how much?) but in
> general the kinds of information that would go here are hard to predict
> IMO, so I'd like to have the option of storing it in something less
> structured.
> 
> On the unstructured side, we could have a wiki with a page for each
> gene, transcript, protein, whatever.  One moderately-structured option
> would be to use a semantic wiki like Semantic MediaWiki:
> http://wiki.ontoworld.org/index.php/Semantic_MediaWiki
> I like the idea of having this information available in RDF, and the
> URI-based named attribute and typed link structure fits fairly well with
> the DAS/2 feature/prop mechanism AFAICS.
> 
> In the short term I'm thinking of generating a semantic wiki page for
> each annotation (directly from Chado or using Bio::DB) and having that
> be (one of) the link(s) in the feature mouseover popup.  Per the
> discussion here from last November, I'd like to implement those popups
> with DAS/2, which ought to be reasonably straightforward to access from
> javascript.
> 
> I'll be putting this up as a page on biowiki.org and updating it with
> any discussion from the list.
> 
> Regards,
> Mitch
> 
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gmod-ajax mailing list
> Gmo...@li...
> https://lists.sourceforge.net/lists/listinfo/gmod-ajax

Re: [Gmod-ajax] Simile::Timeline

[Seth C. <sjc...@lb...>]

> Yeah... an experiment definately should be done where you draw a plot
> using single-pixel divs (or whatever JS libraries like Canvas use), or
> use SVG or VML or whatever to generate tracks like "% conserved" or "%
> GC", and then try to drag it.  Seth has claimed good results with JS
> rendering many features using Canvas, but I wonder how dragging will
> be affected.

Dragging would only useful for a Canvas area itself, not really for the
things within a Canvas (Canvas is more of a plotting/drawing thing).
While canvas can draw quickly, it is not really an interactive object.
You would probably have the same performance as with many divs if you
broke it up.

> Going in the reverse fashion - from a box feature display to a density
> plot - is also good.  If I'm looking at the whole chromosome on a
> single screen, GBrowse will currently filter and display only the
> largest features... but info about small features would be lost.  If I
> saw a feature density plot, I could get insight about how they are
> distributed on the chromosome, which is more useful than having small
> features drop out when zooming out.  THIS component is something that
> the server would have to do, as it is impossible to send a
> chromosome's worth of features to the client and have it figure out
> these things, as JS has too much overhead.

When you're saying that the server would have to do this, do you mean
that the server would have to render an image and send it to the client,
or that that server would compute the renderable information and send it
to the client to be rendered? It would never be necessary to send more
information than can be renderable by the client, unless you were
caching things.

Cheers,

-Seth

Re: [Gmod-ajax] Simile::Timeline

[Andrew U. <and...@gm...>]

On 1/30/07, Hilmar Lapp <hl...@gm...> wrote:

[snip]

> As Mitch's experiments seem to suggest (or my admittedly limited
> understanding of it) though, the rendering approach may still be
> overwhelmed by the number of DIVs to handle in the DOM for a genome
> browser with multiple tracks and dense single-base features?
>
>         -hilmar

Yeah... an experiment definately should be done where you draw a plot
using single-pixel divs (or whatever JS libraries like Canvas use), or
use SVG or VML or whatever to generate tracks like "% conserved" or "%
GC", and then try to drag it.  Seth has claimed good results with JS
rendering many features using Canvas, but I wonder how dragging will
be affected.

There have been a few arguments against this kind of rich
client-intensive rendering (mainly, it adds a lot of complexities, but
do the benefits/features gained justify it?).  There is a good reason
for it in ONE case, though: I think Mitch mentioned this earlier, but
Suzie Lewis said that toggling between a frequency plot and a box plot
is a desired feature.  That is, let's say you have a track plotting GC
content - and you can toggle that track to display all regions above,
say, 50% GC content in box form instead (the threshold would be
arbitrary, of course).  The client would therefore have to know the
values at each X-coord of the plot, so that it could filter out
everything about the threshold and display it as boxes, without
involving the server in this decision-making... or maybe this is
getting too complicated?

To relate this to our lab's work, I can see this being useful in
genome screens for example.  Let's say you have a method which assigns
to each nucleotide (or window) a probability that it is in a gene or
any feature (e.g. in a ncRNA).  Now I want to select all predictions
with P > 0.9 and eyeball the distribution.  I would certainly use
this.

Going in the reverse fashion - from a box feature display to a density
plot - is also good.  If I'm looking at the whole chromosome on a
single screen, GBrowse will currently filter and display only the
largest features... but info about small features would be lost.  If I
saw a feature density plot, I could get insight about how they are
distributed on the chromosome, which is more useful than having small
features drop out when zooming out.  THIS component is something that
the server would have to do, as it is impossible to send a
chromosome's worth of features to the client and have it figure out
these things, as JS has too much overhead.


Andrew

Re: [Gmod-ajax] Simile::Timeline

[Hilmar L. <hl...@gm...>]

I understood that the Timeline demo did this for loading the data  
(since it intentionally kept it simple by not pulling stuff from a  
database on-demand only).

I'm sure this can be modified w/o too much trouble to lazy-load (and  
unload) as needed.

As Mitch's experiments seem to suggest (or my admittedly limited  
understanding of it) though, the rendering approach may still be  
overwhelmed by the number of DIVs to handle in the DOM for a genome  
browser with multiple tracks and dense single-base features?

	-hilmar

On Jan 30, 2007, at 12:34 PM, Andrew Uzilov wrote:

> Just to stress something... Timeline loaded ALL the "feature DIVs" for
> the entire timeline, even if they were far off-screen - right?
> Something like this would be difficult to do for large (or even
> decently-sized chromosomes), which is the same reason for why we don't
> load all the tiles at once, but rather cache only the ones close to
> the current view.
>
> We counted up something like <1000 Timeline points (each a DIV or some
> sort of DOM node) yesterday, but there could easily be an order of
> magnitude more features on a chromosome, especially for multiple-track
> views.  I think it reasonable to assume around 10-30 tracks being open
> in a genome browser, so add another order of magnitude to it.  This is
> why I strongly believe that the client should NOT be aware of ALL the
> features - just the local ones - and the server should filter them
> down to keep feature density reasonable in situations where, for
> example, you are looking at the entire chromosome in a single window.
>
> The Timeline demo is also a good reminder that we need to have an
> "Overview" track like GBrowse does, displaying the entire chromosome
> and showing the user what part of it they are looking at.
>
> Andrew
>
> On 1/27/07, Mitchell Skinner <mi...@ar...> wrote:
>> On Sat, 2007-01-27 at 18:33 -0500, Hilmar Lapp wrote:
>>> Obviously, I thought if you replace the time scales with genomic
>>> scales, and the temporal events with genomic features, you would
>>> pretty much have an AJAX-based genome browser.
>>
>> I haven't seen Timeline before, thanks for the link.
>>
>> The boatload-of-divs approach that Timeline takes is nice because the
>> client knows more about what it's displaying, so some  
>> functionality is
>> easier to implement:
>> * clickable features
>> * hightlighting features
>> * keeping labels on the screen
>> * ? there's more, I'm sure
>>
>> The approach does have some downsides.  A large number of DOM nodes
>> slows down the browser.  For me (firefox on linux) dragging in  
>> Timeline
>> is quite slow, though it's unclear how much of this is due to the
>> multi-res scrolling thing they're doing.  I'd be interested to see  
>> how
>> (and whether) it runs in IE.  When I get a chance I'm going to spend
>> some time profiling it.
>>
>> On the other hand, for clickable features we've got a DOM node for  
>> each
>> imagemap area anyway (and the number of those is larger than the  
>> number
>> of features, due to tile-spanning features), so maybe we have to pay
>> that cost in any case.  Currently, we're loading those lazily, which
>> must be part of the reason why our panning is faster than Timeline's.
>>
>> DIVs are also more limited in what they can render.  As far as I can
>> tell it would be impossible to show GBrowse-style transcripts  
>> (with the
>> hats) using just DIVs (actually, thinking about it some more, this  
>> could
>> be done at the cost of several (4?) more DOM nodes per intron).
>> However, it would be fairly straightforward to do Santa-Cruz-style
>> transcripts using CSS background-repeat.  Apparently some people have
>> strong opinions about how those look; would anyone here like to  
>> comment?
>>
>> One difference between us and Timeline is that I think we're  
>> generally
>> going to be dealing with a larger number of much denser tracks.
>> Especially with something like a %conserved track, you've potentially
>> got a data point for each base, and there's no way you're going to  
>> send
>> 300 million data points to the browser.  Again, with lazy loading  
>> this
>> gets a lot easier, though dealing with different zoom levels does  
>> take
>> some extra server-side work.
>>
>> I did a zooming experiment a while ago using DIVs to represent  
>> features;
>> you can see my toy here:
>> http://arctur.us/dasclient/test.html
>> The approach works well in firefox but not really in IE.  That  
>> kind of
>> thing is much easier to do with DIVs than with images, but I haven't
>> really tried to do it with large numbers of DIVs.  And it won't zoom
>> 3-million-fold without a lot of extra work (it's currently in the
>> few-hundred-thousand-fold range as I recall).  But it's an example of
>> the kind of thing you can do.
>>
>> Andrew and I are planning to do some experimenting along these lines.
>> We'd like to see how much the browsers can handle before they really
>> start to bog down, and how cross-browser the DIV approach is.  We'll
>> also be trying out SVG and VML (and some libraries that try to  
>> abstract
>> away the differences between the two).
>>
>> My sense is that Ian thinks that gmod-ajax feature display works  
>> "well
>> enough" for now, and that search and community annotation are more
>> immediate priorities.  If we can use a substantial body of Timeline's
>> work, though, then it might make sense to spend some time on  
>> that.  It
>> looks like they've implemented layout (bumping), and they apparently
>> also have a way to render at different scales.
>>
>> It would be cool if the browser could just pull some DAS/2 from the
>> server and do the rest itself, wouldn't it?
>>
>> Mitch
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to  
>> share your
>> opinions on IT & business topics through brief surveys - and earn  
>> cash
>> http://www.techsay.com/default.php? 
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Gmod-ajax mailing list
>> Gmo...@li...
>> https://lists.sourceforge.net/lists/listinfo/gmod-ajax
>>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gmod-ajax mailing list
> Gmo...@li...
> https://lists.sourceforge.net/lists/listinfo/gmod-ajax

-- 
===========================================================
: Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
===========================================================

Re: [Gmod-ajax] reply-to address mangling

[Hilmar L. <hl...@gm...>]

Just FYI, here's one of the nicer written explanations as for why it  
is a bad practice (not just among GMOD lists):

http://www.unicom.com/pw/reply-to-harmful.html

(Obviously, it is still easy to reply to the list. Just hit reply to  
all, or what your email reader calls it.)

Thanks for making the change, appreciate it.

	-hilmar

On Jan 30, 2007, at 12:11 PM, Andrew Uzilov wrote:

> Hi Hilmar...
>
> On 1/27/07, Hilmar Lapp <hl...@gm...> wrote:
>> BTW I notice that the Reply-To address mangling is enabled for this
>> list. Aside from this being considered bad practice and therefore
>> inconsistent with most other mailing lists, it is also inconsistent
>> with the other GMOD lists (or those I've been on).
>>
>> Was this a mistake or intentional?
>>
>>         -hilmar
>
> A while back, I polled the list about the reply-to address mangling
> issue, and no one had a preference, so I went with my own personal
> preference: replacing the "reply-to" field with the list address.
>
> But since you say this is bad practice among the GMOD lists, I have
> now disabled that.  So everyone, be cautious: replies will now go to
> SENDER, not the list!
>
> If anyone feels strongly about this, please let me know.
>
>
> Andrew
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gmod-ajax mailing list
> Gmo...@li...
> https://lists.sourceforge.net/lists/listinfo/gmod-ajax

-- 
===========================================================
: Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
===========================================================

Re: [Gmod-ajax] Simile::Timeline

[Andrew U. <and...@gm...>]

Just to stress something... Timeline loaded ALL the "feature DIVs" for
the entire timeline, even if they were far off-screen - right?
Something like this would be difficult to do for large (or even
decently-sized chromosomes), which is the same reason for why we don't
load all the tiles at once, but rather cache only the ones close to
the current view.

We counted up something like <1000 Timeline points (each a DIV or some
sort of DOM node) yesterday, but there could easily be an order of
magnitude more features on a chromosome, especially for multiple-track
views.  I think it reasonable to assume around 10-30 tracks being open
in a genome browser, so add another order of magnitude to it.  This is
why I strongly believe that the client should NOT be aware of ALL the
features - just the local ones - and the server should filter them
down to keep feature density reasonable in situations where, for
example, you are looking at the entire chromosome in a single window.

The Timeline demo is also a good reminder that we need to have an
"Overview" track like GBrowse does, displaying the entire chromosome
and showing the user what part of it they are looking at.

Andrew

On 1/27/07, Mitchell Skinner <mi...@ar...> wrote:
> On Sat, 2007-01-27 at 18:33 -0500, Hilmar Lapp wrote:
> > Obviously, I thought if you replace the time scales with genomic
> > scales, and the temporal events with genomic features, you would
> > pretty much have an AJAX-based genome browser.
>
> I haven't seen Timeline before, thanks for the link.
>
> The boatload-of-divs approach that Timeline takes is nice because the
> client knows more about what it's displaying, so some functionality is
> easier to implement:
> * clickable features
> * hightlighting features
> * keeping labels on the screen
> * ? there's more, I'm sure
>
> The approach does have some downsides.  A large number of DOM nodes
> slows down the browser.  For me (firefox on linux) dragging in Timeline
> is quite slow, though it's unclear how much of this is due to the
> multi-res scrolling thing they're doing.  I'd be interested to see how
> (and whether) it runs in IE.  When I get a chance I'm going to spend
> some time profiling it.
>
> On the other hand, for clickable features we've got a DOM node for each
> imagemap area anyway (and the number of those is larger than the number
> of features, due to tile-spanning features), so maybe we have to pay
> that cost in any case.  Currently, we're loading those lazily, which
> must be part of the reason why our panning is faster than Timeline's.
>
> DIVs are also more limited in what they can render.  As far as I can
> tell it would be impossible to show GBrowse-style transcripts (with the
> hats) using just DIVs (actually, thinking about it some more, this could
> be done at the cost of several (4?) more DOM nodes per intron).
> However, it would be fairly straightforward to do Santa-Cruz-style
> transcripts using CSS background-repeat.  Apparently some people have
> strong opinions about how those look; would anyone here like to comment?
>
> One difference between us and Timeline is that I think we're generally
> going to be dealing with a larger number of much denser tracks.
> Especially with something like a %conserved track, you've potentially
> got a data point for each base, and there's no way you're going to send
> 300 million data points to the browser.  Again, with lazy loading this
> gets a lot easier, though dealing with different zoom levels does take
> some extra server-side work.
>
> I did a zooming experiment a while ago using DIVs to represent features;
> you can see my toy here:
> http://arctur.us/dasclient/test.html
> The approach works well in firefox but not really in IE.  That kind of
> thing is much easier to do with DIVs than with images, but I haven't
> really tried to do it with large numbers of DIVs.  And it won't zoom
> 3-million-fold without a lot of extra work (it's currently in the
> few-hundred-thousand-fold range as I recall).  But it's an example of
> the kind of thing you can do.
>
> Andrew and I are planning to do some experimenting along these lines.
> We'd like to see how much the browsers can handle before they really
> start to bog down, and how cross-browser the DIV approach is.  We'll
> also be trying out SVG and VML (and some libraries that try to abstract
> away the differences between the two).
>
> My sense is that Ian thinks that gmod-ajax feature display works "well
> enough" for now, and that search and community annotation are more
> immediate priorities.  If we can use a substantial body of Timeline's
> work, though, then it might make sense to spend some time on that.  It
> looks like they've implemented layout (bumping), and they apparently
> also have a way to render at different scales.
>
> It would be cool if the browser could just pull some DAS/2 from the
> server and do the rest itself, wouldn't it?
>
> Mitch
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gmod-ajax mailing list
> Gmo...@li...
> https://lists.sourceforge.net/lists/listinfo/gmod-ajax
>

Re: [Gmod-ajax] reply-to address mangling

[Andrew U. <and...@gm...>]

Hi Hilmar...

On 1/27/07, Hilmar Lapp <hl...@gm...> wrote:
> BTW I notice that the Reply-To address mangling is enabled for this
> list. Aside from this being considered bad practice and therefore
> inconsistent with most other mailing lists, it is also inconsistent
> with the other GMOD lists (or those I've been on).
>
> Was this a mistake or intentional?
>
>         -hilmar

A while back, I polled the list about the reply-to address mangling
issue, and no one had a preference, so I went with my own personal
preference: replacing the "reply-to" field with the list address.

But since you say this is bad practice among the GMOD lists, I have
now disabled that.  So everyone, be cautious: replies will now go to
SENDER, not the list!

If anyone feels strongly about this, please let me know.


Andrew

Re: [Gmod-ajax] Simile::Timeline

[Mitch S. <li...@ar...>]

I wrote:
> DIVs are also more limited in what they can render.  As far as I can
> tell it would be impossible to show GBrowse-style transcripts (with the
> hats) using just DIVs (actually, thinking about it some more, this could
> be done at the cost of several (4?) more DOM nodes per intron).

Just for the sake of experimenting, I tried this out.  It takes 2 DOM
nodes per intron, in addition to the DOM nodes for each exon.

http://arctur.us/gmod-ajax/test/hat-test.html

This was tested in Firefox 2 and 1.5.  It ought to work in IE 7; if it
doesn't it should be a fixable bug and I'd appreciate hearing about it.
I don't believe it works in IE 6.

The direction arrow would have to be a separate image, for a total cost
of e+2(e-1)+1 DOM nodes per transcript, where e is the number of exons.
That's not including labels.  Of course, we can do semantic zooming with
DIVs as well; when the view is fully zoomed out it should probably be
more like one DIV per transcript with no labels.

Mitch

Re: [Gmod-ajax] Simile::Timeline

[Mitchell S. <mi...@ar...>]

On Sat, 2007-01-27 at 18:33 -0500, Hilmar Lapp wrote:
> Obviously, I thought if you replace the time scales with genomic  
> scales, and the temporal events with genomic features, you would  
> pretty much have an AJAX-based genome browser.

I haven't seen Timeline before, thanks for the link.

The boatload-of-divs approach that Timeline takes is nice because the
client knows more about what it's displaying, so some functionality is
easier to implement:
* clickable features
* hightlighting features
* keeping labels on the screen
* ? there's more, I'm sure

The approach does have some downsides.  A large number of DOM nodes
slows down the browser.  For me (firefox on linux) dragging in Timeline
is quite slow, though it's unclear how much of this is due to the
multi-res scrolling thing they're doing.  I'd be interested to see how
(and whether) it runs in IE.  When I get a chance I'm going to spend
some time profiling it.

On the other hand, for clickable features we've got a DOM node for each
imagemap area anyway (and the number of those is larger than the number
of features, due to tile-spanning features), so maybe we have to pay
that cost in any case.  Currently, we're loading those lazily, which
must be part of the reason why our panning is faster than Timeline's.

DIVs are also more limited in what they can render.  As far as I can
tell it would be impossible to show GBrowse-style transcripts (with the
hats) using just DIVs (actually, thinking about it some more, this could
be done at the cost of several (4?) more DOM nodes per intron).
However, it would be fairly straightforward to do Santa-Cruz-style
transcripts using CSS background-repeat.  Apparently some people have
strong opinions about how those look; would anyone here like to comment?

One difference between us and Timeline is that I think we're generally
going to be dealing with a larger number of much denser tracks.
Especially with something like a %conserved track, you've potentially
got a data point for each base, and there's no way you're going to send
300 million data points to the browser.  Again, with lazy loading this
gets a lot easier, though dealing with different zoom levels does take
some extra server-side work.

I did a zooming experiment a while ago using DIVs to represent features;
you can see my toy here:
http://arctur.us/dasclient/test.html
The approach works well in firefox but not really in IE.  That kind of
thing is much easier to do with DIVs than with images, but I haven't
really tried to do it with large numbers of DIVs.  And it won't zoom
3-million-fold without a lot of extra work (it's currently in the
few-hundred-thousand-fold range as I recall).  But it's an example of
the kind of thing you can do.

Andrew and I are planning to do some experimenting along these lines.
We'd like to see how much the browsers can handle before they really
start to bog down, and how cross-browser the DIV approach is.  We'll
also be trying out SVG and VML (and some libraries that try to abstract
away the differences between the two).

My sense is that Ian thinks that gmod-ajax feature display works "well
enough" for now, and that search and community annotation are more
immediate priorities.  If we can use a substantial body of Timeline's
work, though, then it might make sense to spend some time on that.  It
looks like they've implemented layout (bumping), and they apparently
also have a way to render at different scales.

It would be cool if the browser could just pull some DAS/2 from the
server and do the rest itself, wouldn't it?

Mitch

Re: [Gmod-ajax] reply-to address mangling

[Hilmar L. <hl...@gm...>]

BTW I notice that the Reply-To address mangling is enabled for this  
list. Aside from this being considered bad practice and therefore  
inconsistent with most other mailing lists, it is also inconsistent  
with the other GMOD lists (or those I've been on).

Was this a mistake or intentional?

	-hilmar

On Jan 27, 2007, at 6:33 PM, Hilmar Lapp wrote:

> SIMILE (http://simile.mit.edu) is a project MIT consisting of various
> subcomponents dealing with semantic interoperability and metadata.
>
> One of their AJAX/JavaScript-based applications, called Timeline,
> displays temporal data along time axes of different resolutions, and
> the horizontal panel can be smoothly dragged with the mouse, much
> like Google Maps. The time axes move along, with different velocities
> based on resolution. See http://simile.mit.edu/timeline/ and the
> examples linked from there.
>
> Obviously, I thought if you replace the time scales with genomic
> scales, and the temporal events with genomic features, you would
> pretty much have an AJAX-based genome browser.
>
> Has anyone looked at this? Maybe some of the code there can be reused?
>
> Just an idea ...
>
> 	-hilmar
> -- 
> ===========================================================
> : Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
> ===========================================================
>
>
>
>
>
>
> ---------------------------------------------------------------------- 
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to  
> share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php? 
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gmod-ajax mailing list
> Gmo...@li...
> https://lists.sourceforge.net/lists/listinfo/gmod-ajax

-- 
===========================================================
: Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
===========================================================

[Gmod-ajax] Simile::Timeline

[Hilmar L. <hl...@gm...>]

SIMILE (http://simile.mit.edu) is a project MIT consisting of various  
subcomponents dealing with semantic interoperability and metadata.

One of their AJAX/JavaScript-based applications, called Timeline,  
displays temporal data along time axes of different resolutions, and  
the horizontal panel can be smoothly dragged with the mouse, much  
like Google Maps. The time axes move along, with different velocities  
based on resolution. See http://simile.mit.edu/timeline/ and the  
examples linked from there.

Obviously, I thought if you replace the time scales with genomic  
scales, and the temporal events with genomic features, you would  
pretty much have an AJAX-based genome browser.

Has anyone looked at this? Maybe some of the code there can be reused?

Just an idea ...

	-hilmar
-- 
===========================================================
: Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
===========================================================

[Gmod-ajax] Community annotation

[Mitch S. <li...@ar...>]

On Fri, 2007-01-19 at 11:20 +1100, Ian Holmes wrote:
> Now that we have a full-time gmod-ajax person (in the form of Mitch) 
> it's probably about time to kick off a discussion on how to move towards 
> our goals of community annotation (and what this means exactly) and full 
> browser functionality including search, rich display, etc (and to what 
> extent this should be GBrowse-like).

As far as community annotation goes, I'm going to try and summarize the
different things I've heard and read and thought so far.  Hopefully this
is not retreading heavily covered ground too much -

There are three kinds of community annotation that have been talked
about:
1. Bulk annotation upload. Lots of people have GFF/BED/etc. files that
they'd like to see rendered.  We ought to make this dead simple.
Existing examples include Santa Cruz's upload functionality:
http://genome.ucsc.edu/cgi-bin/hgCustom
and GBrowse's:
http://gmod.cvs.sourceforge.net/*checkout*/gmod/Generic-Genome-Browser/htdocs/annotation_help.html

As I see it, the fundamental difference between "annotation upload" as
currently implemented and "community annotation" like Ian's talking
about above is that with annotation upload the uploader is the only one
looking at their annotations, while with community annotation
potentially everyone else is looking at them as well.

This immediately raises a number of questions, like how to manage all
the uploaded tracks.  These will obviously vary in usefulness, and we
don't want to clutter up the display too much; on the other hand we
don't want to make people pick from a huge list as a prerequisite to
using the browser.  This suggests that we'll want to have a list of
"blessed" or "default" tracks, but then you have the problem of choosing
those.  Or we could have a track ranking mechanism where we show the top
n highest ranked tracks, but then we have the problem of coming up with
the track rankings.  One option would be a moderation system (e.g.,
"Digg this track [+/-]").  In the fancy extreme we could even have a
collaborative filtering mechanism where we "recommend" tracks to people
based on their previous moderations.

In any case, making annotation upload work is a prerequisite to
everything else, so that's the first priority IMO.  The main things we
have to do differently from current annotation upload are kicking off a
pre-rendering or primitive database fill operation and coming up with
some way of notifying the user when their track is ready to view.
Anything else?

2. Individual feature creation/editing.  It would be neat to be able to
"draw" and "resize" features by clicking and dragging with the mouse.  I
believe this is possible to do in the browser, but it is fairly fancy
and might be difficult to do in a cross-browser way.  Suzi Lewis and
Chris Mungall at Berkeley BOP seem to think that this need is adequately
served by fatter clients like Apollo.  Can anyone think of a use case
where someone would want to be able to adjust feature boundaries but
would be a casual enough user to not want to install Apollo?  I would
imagine that most people who want to e.g. edit gene models would be
involved enough to install some software but my experience here is
limited.  If no one can come up with a compelling use case for having
this on a web browser I'd be tempted to leave this out entirely, or at
least leave it until the other community annotation things are
implemented.

3. Feature "commenting".  Not sure what to call this (annotation
annotation?), but I'm sure there are lots of biologists out there who
know a lot about a relatively small number of genes.  This is the kind
of knowledge that wouldn't be a good fit for creating an entire track
with (so it doesn't fit well into the bulk annotation upload mechanism),
but would work better for adding information about features on an
existing track.  Examples that I can imagine include adding GO terms to
existing annotations, adding information about where a certain gene is
expressed, what pathways a gene is involved in, literature references,
etc.  Some of these things could be stored in Chado (how much?) but in
general the kinds of information that would go here are hard to predict
IMO, so I'd like to have the option of storing it in something less
structured.

On the unstructured side, we could have a wiki with a page for each
gene, transcript, protein, whatever.  One moderately-structured option
would be to use a semantic wiki like Semantic MediaWiki:
http://wiki.ontoworld.org/index.php/Semantic_MediaWiki
I like the idea of having this information available in RDF, and the
URI-based named attribute and typed link structure fits fairly well with
the DAS/2 feature/prop mechanism AFAICS.

In the short term I'm thinking of generating a semantic wiki page for
each annotation (directly from Chado or using Bio::DB) and having that
be (one of) the link(s) in the feature mouseover popup.  Per the
discussion here from last November, I'd like to implement those popups
with DAS/2, which ought to be reasonably straightforward to access from
javascript.

I'll be putting this up as a page on biowiki.org and updating it with
any discussion from the list.

Regards,
Mitch

Re: [Gmod-ajax] [Gmod-architecture] AJAX, WebService, Middleware, Chode

[Ian H. <ih...@be...>]

ah, apologies. thank you.


Andrew Uzilov wrote:
> Ian et all...
> 
> I've transferred all our ideas to the wiki a long time ago, they can
> be found here:
> 
> http://biowiki.org/view/GBrowse/WishList
> 
> 
> Andrew
> 
> 
> On 1/18/07, Ian Holmes <ih...@be...> wrote:
>> Now that we have a full-time gmod-ajax person (in the form of Mitch)
>> it's probably about time to kick off a discussion on how to move towards
>> our goals of community annotation (and what this means exactly) and full
>> browser functionality including search, rich display, etc (and to what
>> extent this should be GBrowse-like).
>>
>> Chris, Andrew and I had a tete-a-tete a couple of months ago in which we
>> scribbled some notes on the back of an envelope (or coffeeshop napkin).
>> Andrew, do you have that napkin anywhere? Could we start by reprising
>> those? I am running out the door right now but could dredge up my memory
>> of the meeting if necessary.
>>
>> One thing is that Mitch is away for a week or so. So probably the
>> discussion will have to wait a little while for him to get back, before
>> it gets really productive.
>>
>> I.
>>
>>
>>
>> Chris Mungall wrote:
>>> Hi Xianhua
>>>
>>> Note there is now a gmod-ajax list too.
>>>
>>> I think a RESTFUL architecture makes a lot of sense for an AJAX
>>> application.
>>>
>>> By the way, I think you mean "Chado". (try a google search for
>>> "define: chode" - I do hope chode doesn't catch on as another Chado
>>> mispronounciation!).
>>>
>>> On Jan 18, 2007, at 7:47 AM, Xianhua Liu wrote:
>>>
>>>> I am trying to build web interface to query and view data from
>>>> Chode with extension schema for bio-diversity data. I am planning
>>>> to use a 4-lawyer architecture as following:
>>>>
>>>> 1. AJAX: front-end
>>>> 2. WebService: web lawyer
>>>> 3. XXX: Middleware
>>>> 4. Chode: back-end
>>>>
>>>> Why WebService?
>>>> 1. independency of front-end on middleware.
>>>> 2. loose coupling
>>>> 3. easy data integration over web
>>>> 4. ...
>>>>
>>>> Challenges:
>>>> 1. standardization of web service interface
>>>> 2. federalization of data representation model exchanged through
>>>> the web service (XML Schema, Ontology, ...?)
>>>> 3. Performance?
>>>>
>>>> RESTful or SOAP:
>>>> I prefer to choose RESTful web service, because it is easy, direct
>>>> and light.
>>>>
>>>> If someone have already tried the same and similar thing, please
>>>> share your experience and lessons and tech choises.
>>>>
>>>> Welcome every one to send comments about the idea, and suggestions
>>>> about techniques, software packages and any other sources.
>>>>
>>>> Thanks,
>>>>
>>>> Xianhua
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> ---
>>>> Take Surveys. Earn Cash. Influence the Future of IT
>>>> Join SourceForge.net's Techsay panel and you'll get the chance to
>>>> share your
>>>> opinions on IT & business topics through brief surveys - and earn cash
>>>> http://www.techsay.com/default.php?
>>>> page=join.php&p=sourceforge&CID=DEVDEV________________________________
>>>> _______________
>>>> Gmod-architecture mailing list
>>>> Gmo...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/gmod-architecture
>>>
>>> -------------------------------------------------------------------------
>>> Take Surveys. Earn Cash. Influence the Future of IT
>>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>> opinions on IT & business topics through brief surveys - and earn cash
>>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>> _______________________________________________
>>> Gmod-ajax mailing list
>>> Gmo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/gmod-ajax
>> -------------------------------------------------------------------------
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to share your
>> opinions on IT & business topics through brief surveys - and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Gmod-ajax mailing list
>> Gmo...@li...
>> https://lists.sourceforge.net/lists/listinfo/gmod-ajax
>>
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gmod-ajax mailing list
> Gmo...@li...
> https://lists.sourceforge.net/lists/listinfo/gmod-ajax

Re: [Gmod-ajax] [Gmod-architecture] AJAX, WebService, Middleware, Chode

[Andrew U. <and...@gm...>]

Ian et all...

I've transferred all our ideas to the wiki a long time ago, they can
be found here:

http://biowiki.org/view/GBrowse/WishList


Andrew


On 1/18/07, Ian Holmes <ih...@be...> wrote:
> Now that we have a full-time gmod-ajax person (in the form of Mitch)
> it's probably about time to kick off a discussion on how to move towards
> our goals of community annotation (and what this means exactly) and full
> browser functionality including search, rich display, etc (and to what
> extent this should be GBrowse-like).
>
> Chris, Andrew and I had a tete-a-tete a couple of months ago in which we
> scribbled some notes on the back of an envelope (or coffeeshop napkin).
> Andrew, do you have that napkin anywhere? Could we start by reprising
> those? I am running out the door right now but could dredge up my memory
> of the meeting if necessary.
>
> One thing is that Mitch is away for a week or so. So probably the
> discussion will have to wait a little while for him to get back, before
> it gets really productive.
>
> I.
>
>
>
> Chris Mungall wrote:
> > Hi Xianhua
> >
> > Note there is now a gmod-ajax list too.
> >
> > I think a RESTFUL architecture makes a lot of sense for an AJAX
> > application.
> >
> > By the way, I think you mean "Chado". (try a google search for
> > "define: chode" - I do hope chode doesn't catch on as another Chado
> > mispronounciation!).
> >
> > On Jan 18, 2007, at 7:47 AM, Xianhua Liu wrote:
> >
> >> I am trying to build web interface to query and view data from
> >> Chode with extension schema for bio-diversity data. I am planning
> >> to use a 4-lawyer architecture as following:
> >>
> >> 1. AJAX: front-end
> >> 2. WebService: web lawyer
> >> 3. XXX: Middleware
> >> 4. Chode: back-end
> >>
> >> Why WebService?
> >> 1. independency of front-end on middleware.
> >> 2. loose coupling
> >> 3. easy data integration over web
> >> 4. ...
> >>
> >> Challenges:
> >> 1. standardization of web service interface
> >> 2. federalization of data representation model exchanged through
> >> the web service (XML Schema, Ontology, ...?)
> >> 3. Performance?
> >>
> >> RESTful or SOAP:
> >> I prefer to choose RESTful web service, because it is easy, direct
> >> and light.
> >>
> >> If someone have already tried the same and similar thing, please
> >> share your experience and lessons and tech choises.
> >>
> >> Welcome every one to send comments about the idea, and suggestions
> >> about techniques, software packages and any other sources.
> >>
> >> Thanks,
> >>
> >> Xianhua
> >>
> >>
> >> ----------------------------------------------------------------------
> >> ---
> >> Take Surveys. Earn Cash. Influence the Future of IT
> >> Join SourceForge.net's Techsay panel and you'll get the chance to
> >> share your
> >> opinions on IT & business topics through brief surveys - and earn cash
> >> http://www.techsay.com/default.php?
> >> page=join.php&p=sourceforge&CID=DEVDEV________________________________
> >> _______________
> >> Gmod-architecture mailing list
> >> Gmo...@li...
> >> https://lists.sourceforge.net/lists/listinfo/gmod-architecture
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share your
> > opinions on IT & business topics through brief surveys - and earn cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Gmod-ajax mailing list
> > Gmo...@li...
> > https://lists.sourceforge.net/lists/listinfo/gmod-ajax
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Gmod-ajax mailing list
> Gmo...@li...
> https://lists.sourceforge.net/lists/listinfo/gmod-ajax
>