Skip to content

Direct linking to graphs #18

Open
Open
Direct linking to graphs#18

Description

@almereyda
almereyda
opened on Apr 21, 2016

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.

Activity

  1. controversial commented on Apr 21, 2016

    @controversial
    controversial
    on Apr 21, 2016
    Owner

    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

  2. controversial
    closed this as completedon May 3, 2016
  3. controversial
    reopened this on May 3, 2016

  4. controversial commented on May 3, 2016

    @controversial
    controversial
    on May 3, 2016
    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)

  5. almereyda commented on May 7, 2016

    @almereyda
    almereyda
    on May 7, 2016
    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.

  6. controversial commented on May 7, 2016

    @controversial
    controversial
    on May 7, 2016
    Owner

    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.

  7. almereyda commented on May 7, 2016

    @almereyda
    almereyda
    on May 7, 2016
    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?

  8. controversial commented on May 7, 2016

    @controversial
    controversial
    on May 7, 2016
    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)

  9. controversial
    added 5 commits that reference this issue on May 8, 2016

    Add backend for storing JSON

    5324158

    Add method for serializing network

    69aea7a

    Add deserialization methods

    41472fe

    Correctly handle floating edges

    e9369ff

    Add full API for saving and loading graphs 🎉

    ecd01ef

  10. controversial commented on Jun 17, 2016

    @controversial
    controversial
    on Jun 17, 2016
    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.

  11. almereyda commented on Jun 17, 2016

    @almereyda
    almereyda
    on Jun 17, 2016
    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
    .

  12. controversial
    added a commit that references this issue on Jun 17, 2016

    Add a share button and a popout

    d7a1c10

  13. controversial commented on Oct 7, 2016

    @controversial
    controversial
    on Oct 7, 2016
    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.

  14. duncanawerbuck commented on Nov 27, 2016

    @duncanawerbuck
    duncanawerbuck
    on Nov 27, 2016

    @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!

  15. controversial commented on Nov 27, 2016

    @controversial
    controversial
    on Nov 27, 2016
    Owner

    @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

  16. scripting commented on Nov 27, 2016

    @scripting
    scripting
    on Nov 27, 2016 via email

  17. controversial commented on Nov 27, 2016

    @controversial
    controversial
    on Nov 27, 2016 via email
    Owner
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions