New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create embeddable widget or thumbnail for other databases to embed #221

Closed
cmungall opened this Issue Nov 20, 2015 · 5 comments

Comments

Projects
None yet
2 participants
@cmungall
Member

cmungall commented Nov 20, 2015

Attached is a super-fake mockup of how a page like http://flybase.org/reports/FBgn0000490.html may be enhanced with a noctua thumbnail. The example is fake (gene is dpp, but dpp doesn't appear in the example model)

screen shot 2015-11-20 at 1 03 51 pm

Is this the right approach?

Some genes may be in multiple models. What do we do here?

If there are no models for the gene, we could also show models 'one hop along' - e.g. to an ortholog, to an interacting gene...

Gene pages would have highest impact, but we of course could have BP pages. Most groups don't do this though, and just like to amigo, where we would have the models on a per GO-term basis.

@cmungall cmungall self-assigned this Nov 20, 2015

@cmungall cmungall added this to the wishlist milestone Nov 20, 2015

@kltm

This comment has been minimized.

Show comment
Hide comment
@kltm

kltm Nov 21, 2015

Member

Some points for consideration:

  • any ability here will be predicated on loading models into a GOlr index; easy to do, but we're not doing it yet and minerva cannot support being a general access point. this could be done at the epione level, but it's probably best handled with the OWLTools loader
  • this functionality almost already exists as the cytoscape-based workbenches and AmiGO cytoview
  • I'm not sure the full graph editor view is the way to go here, especially as it is very heavy and finicky; again, variations and expansions of cytoview might work better (to be seen)
  • another question is who hosts this
    • embedders download a JS file and use it in their pages, along with a little JS to make the view
    • embedders get the JS from a CDN which we can update
    • both of these have their pros and cons, but I think the first may be more tenable, with the serious downside that the API would have to be functionally frozen :(
    • another tack would be an embedded image service a la amigo's embeddable visualize, which might give us the best balance--simple API for embedders and control of API and code changes upstream.
Member

kltm commented Nov 21, 2015

Some points for consideration:

  • any ability here will be predicated on loading models into a GOlr index; easy to do, but we're not doing it yet and minerva cannot support being a general access point. this could be done at the epione level, but it's probably best handled with the OWLTools loader
  • this functionality almost already exists as the cytoscape-based workbenches and AmiGO cytoview
  • I'm not sure the full graph editor view is the way to go here, especially as it is very heavy and finicky; again, variations and expansions of cytoview might work better (to be seen)
  • another question is who hosts this
    • embedders download a JS file and use it in their pages, along with a little JS to make the view
    • embedders get the JS from a CDN which we can update
    • both of these have their pros and cons, but I think the first may be more tenable, with the serious downside that the API would have to be functionally frozen :(
    • another tack would be an embedded image service a la amigo's embeddable visualize, which might give us the best balance--simple API for embedders and control of API and code changes upstream.
@cmungall

This comment has been minimized.

Show comment
Hide comment
@cmungall

cmungall Dec 9, 2015

Member

embedded image: if we went this route we would probably want imagemaps, with genes going to right page etc

Member

cmungall commented Dec 9, 2015

embedded image: if we went this route we would probably want imagemaps, with genes going to right page etc

@kltm

This comment has been minimized.

Show comment
Hide comment
@kltm

kltm Dec 9, 2015

Member

It will almost certainly be images; not sure if the package I'm thinking
of supports imagemaps, will check.

On 12/09/2015 12:34 PM, Chris Mungall wrote:

embedded image: if we went this route we would probably want imagemaps,
with genes going to right page etc


Reply to this email directly or view it on GitHub
#221 (comment).

Member

kltm commented Dec 9, 2015

It will almost certainly be images; not sure if the package I'm thinking
of supports imagemaps, will check.

On 12/09/2015 12:34 PM, Chris Mungall wrote:

embedded image: if we went this route we would probably want imagemaps,
with genes going to right page etc


Reply to this email directly or view it on GitHub
#221 (comment).

kltm added a commit to geneontology/amigo that referenced this issue Jan 29, 2016

kltm added a commit to geneontology/noctua-models that referenced this issue Jan 29, 2016

@kltm

This comment has been minimized.

Show comment
Hide comment
@kltm

kltm Jan 30, 2016

Member

To add to the above list of possible methods, we could also have the client sites use JS as we do. This would allow for better API freezing (although we don't version GOlr itself, so hm) through npm, at the cost of putting more effort at their end.

Further considering image generation, it would probably have to be a service that passed over the current contents of the index and added/updated the images where model information was found.

Member

kltm commented Jan 30, 2016

To add to the above list of possible methods, we could also have the client sites use JS as we do. This would allow for better API freezing (although we don't version GOlr itself, so hm) through npm, at the cost of putting more effort at their end.

Further considering image generation, it would probably have to be a service that passed over the current contents of the index and added/updated the images where model information was found.

@kltm kltm modified the milestones: 2016-02-push , wishlist Feb 4, 2016

@kltm

This comment has been minimized.

Show comment
Hide comment
@kltm

kltm Feb 4, 2016

Member

With discussion by @vanaukenk and others, it looks like the system is now in place to deliver data (via AmiGO) and manage/parse it (via the usual JS request, response, and manager libraries). It seems likely that the heavy lifting, at least initially, may be done by consumers. But we may fold any useful patterns back into this upstream code.

The initial plan is to just get the data, create the graphs (these first two items are us), and then render it in cytoscape (downstream embedder).

Member

kltm commented Feb 4, 2016

With discussion by @vanaukenk and others, it looks like the system is now in place to deliver data (via AmiGO) and manage/parse it (via the usual JS request, response, and manager libraries). It seems likely that the heavy lifting, at least initially, may be done by consumers. But we may fold any useful patterns back into this upstream code.

The initial plan is to just get the data, create the graphs (these first two items are us), and then render it in cytoscape (downstream embedder).

@kltm kltm closed this Feb 4, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment