Skip to content
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

Direct linking to graphs #18

Open
almereyda opened this issue Apr 21, 2016 · 13 comments
Open

Direct linking to graphs #18

almereyda opened this issue Apr 21, 2016 · 13 comments

Comments

@almereyda
Copy link

Coming from erabug/wikigraph#2 and fedwiki/wiki#63 we know that linking to certain states of the graph would be interesting.

Similar to what CoGraph allows, but by using URL fragments known from @fedwiki lineups.

If I searched for Space and Time, they'd automatically be added to the URL and therefore create a stable view onto the data. Those nodes should be expanded by default on load.

@controversial
Copy link
Owner

controversial commented Apr 21, 2016

I'll look into it, and report back if I implement it. Data would need to be stored about each expanded node, which I don't think it would be reasonable to store in the URL, especially since which articles are linked is something liable to change in a wiki.

On Thu, Apr 21, 2016 at 12:06 PM jon r notifications@github.com wrote:

Coming from erabug/wikigraph#2
erabug/wikigraph#2 and fedwiki/wiki#63
fedwiki/wiki#63 we know that linking to
certain states of the graph would be interesting.

Similar to what CoGraph https://github.com/willzeng/cograph allows, but
by using URL fragments known from @fedwiki https://github.com/fedwiki
lineups.

If I searched for Space and Time, they'd automatically be added to
the URL and therefore create a stable view onto the data. Those nodes
should be expanded by default on load.


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#18

@controversial
Copy link
Owner

I've been thinking more about how to do this. I don't want to store data for people's networks on my server, because I have very limited storage. The implementation I'm thinking about now is:

  1. Implement a method to save data as JSON, and a method for loading that JSON back in. This should be as simple as storing nodes and edges by converting vis.DataSets as JSON
  2. Use a service like Dropbox to get a small amount of free storage, and store JSON files there.
  3. Use a URL shortener to get a short link to the file stored in Dropbox.
  4. Get the ending to the shortened URL, and use it as a form parameter in the URL. Wikipedia Map would look up this text with the URL shortener to get the path to the JSON.

So an example shared URL would look like
http://luke.deentaylor.com/wikipedia/?graph=QtQET. Wikipedia would then look to http://bit.ly/QtQET for the JSON file, assuming that link pointed to a Dropbox file.

What do you think?

(Sorry I accidentally pressed "close" before, didn't mean to)

@almereyda
Copy link
Author

I thought just delivering attached data via the URL would be enough? Why caching a graph on the client side if it can be regenerated at any time? The server could then do optimisations in keeping responses available.

Else I believe @remotestorage or @scripting's nodestorage.io could be simple JSON storage options? Or even GitHub Gists.

@controversial
Copy link
Owner

controversial commented May 7, 2016

I've since given this a little more thought. I think I'll store nodes and edges as files on my server with random names, somewhere like luke.deentaylor.com/wikipedia/graphs/Igy5Kj. That's where JavaScript will look to find the JSON.

The reason that the network can't be automatically generated is that:

  1. This would only ever be possible for edges, nodes is constructed in part through user actions.
  2. Regenerating edges would involve visiting every wikipedia page for which an expanded node exists on the graph. That would take a while, the graph could take several minutes to fully reconstruct for very large networks, and would probably still take ~10 seconds on smallish networks.

The reason the data can't be passed in the URL is that large networks can have many hundreds of nodes. Not practical to pass that through a URL, unless I misunderstand what you're saying.

@almereyda
Copy link
Author

It sounds reasonable to me to cache parts of the Wikipedia link graph locally. But will I be able to request wikipedia-map/Spacetime/Complexity, for example?

@controversial
Copy link
Owner

What would your intended behavior be for that? Would it be adding two
nodes, "spacetime" and "complexity"? Wikipedia Map doesn't have
functionality for connecting those together automatically, if that's what
you're thinking.

On Sat, May 7, 2016 at 5:14 PM jon r notifications@github.com wrote:

It sounds reasonable to me to cache parts of the Wikipedia link graph
locally. But will I be able to request wikipedia-map/Spacetime/Complexity,
for example?


You are receiving this because you modified the open/close state.

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

controversial added a commit that referenced this issue May 8, 2016
This is the first step towards implementing #18
controversial added a commit that referenced this issue May 8, 2016
I still have to write one to undo it, but this is a step towards #18
controversial added a commit that referenced this issue May 8, 2016
This does *not* currently reconstruct "floating edges," or edges that are not between a node and its parent. Floating edges only occur at the intersections between two separate graphs (only in large networks with multiple start nodes). This is pretty much an edge case (no pun intended 😛

This is also a step towards implementing #18
controversial added a commit that referenced this issue May 9, 2016
(getting close to #18 now)
controversial added a commit that referenced this issue May 9, 2016
The only thing missing froom #18 is a GUI
@controversial
Copy link
Owner

In case you hadn't noticed, I implemented this whole thing more than a month ago, I just haven't implemented a UI. I'm working on an interface now. This will replace the twitter button.

@almereyda
Copy link
Author

No, I didn't get to running it locally, yet. But am impressed how you
picked up this suggestion.

On 17 June 2016 at 16:55, Luke Deen Taylor notifications@github.com wrote:

In case you hadn't noticed, I implemented this whole thing more than a
month ago, I just haven't implemented a UI. I'm working on an interface
now. This will replace the twitter button.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#18 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABka_FZXDmS2VGrzBFTltrrBP3m7B18uks5qMrVTgaJpZM4IM1XE
.

controversial added a commit that referenced this issue Jun 17, 2016
Doesn't actually do anything though. (See #18)
@controversial
Copy link
Owner

Sorry that I still haven't gotten to this. I've got everything except the button to share it, but I've been pressed for time. Hope to get this finished soon. I'm kind of embarrassed I've taken so long on this.

@duncanawerbuck
Copy link

@controversial, this tool is amazing, so firstly, thanks for sharing your work with the community!

The ability to share predefined graphs would be a very powerful way to share ideas, both general and specific and can be the perfect introduction to a talk or training session to give people a visual idea of the scope of the content being discussed.

Can't wait to try it!

@controversial
Copy link
Owner

controversial commented Nov 27, 2016

@duncanawerbuck This is entirely implemented except for a physical share button on the GUI. There's a short console command one can type to save one's graph and get a shareable link, and the links work. There's a progress bar for loading and everything. I just have to stick the button on the app. I'll try to get to it at some point soon, I've kind of been prioritizing other projects

@scripting
Copy link

scripting commented Nov 27, 2016 via email

@controversial
Copy link
Owner

controversial commented Nov 27, 2016 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants