Menu
▾
▴
gmod-ajax
|
From: Hilmar L. <hl...@gm...> - 2007-01-27 23:33:48
|
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 : =========================================================== |
|
From: Hilmar L. <hl...@gm...> - 2007-01-27 23:43:26
|
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 : =========================================================== |
|
From: Mitchell S. <mi...@ar...> - 2007-01-28 01:21:08
|
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 |
|
From: Mitch S. <li...@ar...> - 2007-01-28 23:04:22
|
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 |
|
From: Andrew U. <and...@gm...> - 2007-01-30 17:11:27
|
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 |
|
From: Hilmar L. <hl...@gm...> - 2007-01-31 03:11:05
|
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 : =========================================================== |
|
From: Andrew U. <and...@gm...> - 2007-01-30 17:35:04
|
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 > |
|
From: Hilmar L. <hl...@gm...> - 2007-01-31 03:16:12
|
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 : =========================================================== |
|
From: Andrew U. <and...@gm...> - 2007-01-31 17:51:27
|
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 |
|
From: Seth C. <sjc...@lb...> - 2007-01-31 21:42:57
|
> 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 |
|
From: Chris M. <cj...@fr...> - 2007-02-07 23:29:20
|
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 > |
|
From: Mitch S. <mit...@be...> - 2007-02-08 01:15:31
|
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 |
|
From: Mitch S. <mit...@be...> - 2007-02-08 01:21:43
|
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 |
|
From: Chris M. <cj...@fr...> - 2007-02-08 02:02:35
|
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 > |
|
From: Seth C. <sjc...@lb...> - 2007-02-08 03:09:57
|
On Wed, 2007-02-07 at 17:21 -0800, Mitch Skinner wrote: > 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 think that there should be ways to get around this security stuff (did I just say that?). Since ajax is going back to the server for data by its nature, it's not that big of a leap to have the server act as a proxy to deliver some other service to the browser for a mash-up. Enter something like "kinase": http://toy.lbl.gov:9002/cgi-bin/amigo2/proxy-client.cgi A system of federated proxies that shared information might be interesting. The trick would then be having the information for each user stored so that different sites would be able to get access. Maybe a system like del.icio.us for biology metadata? -Seth |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X