This week I worked on improving the notifications framework based on my mentors’s comments. The notifications framework is pretty much done; https://github.com/Murali-group/GraphSpace/pull/191 . This week I’ll try to implement share graph layouts notifications also as a part of this framework.
This week I need submit code and my evaluations so I will review the GPML uploader once again.
It was a great summer 🙂
Thanks @tmmurali, @adbharadwaj for all the help 🙂
Now we have a working version for share graph events notifications.
The basic layout of the notifications page when the user is logged in.
The page is ‘AJAX ed’ by using the window.location.reload() method, so the user doesn’t need to refresh the page after clicking on
Mark as read on the page. We took inspiration from GitHub notifications for GraphSpace notifications. Once the user marks a notification as read it disappears from the notifications page, but a user can look at all the notifications, read and unread, of a group by clicking at the group link in the left column. More screen shots are uploaded on the notifications framework PR on github. https://github.com/Murali-group/GraphSpace/pull/191 . This week we will work on the review of this PR and get all the documentation and user guide in for GPML uploader as well as Notifications.
Summer flew by really fast 🙂
This week we worked on a prototype of the notifications framework. We are working on finalising the API for the framework and also getting it throughly tested. Right now users can get their notifications after logging in at graphspace.org/notifications (this is not pushed on the website yet) and mark them as read, but this is not ‘AJAX ed’ right now i.e. users need to refresh the page to fetch the updated notifications again. This should be done in the following week.
The GPML uploader script part is now done 🙂 The verdict is:
Out of 2492 pathways present on WikiPathways, 1258 didn’t pass our GPML uploader. Two reasons:
- GraphRefs not available for source and target nodes – 1100
- Shape element type not supported by GraphSpace – 158
NOTE : [‘mim-degradation’, ‘mim-phosphorylated’, ‘sarcoplasmic reticulum’, ‘mitochondria’, ‘endoplasmic reticulum’, ‘golgi apparatus’, ‘mim-interaction’] are not supported by GraphSpace as they can’t be drawn using cytoscape.js
This week involved two tasks; first one was to implement some boiler plate code for the notifications framework and the second one was to test the GPML uploader thoroughly.
As discussed with my mentors during my weekly meetings I have started working on the notifications framework https://github.com/Murali-group/GraphSpace/pull/191 . The users of a group will be notified whenever a graph is shared in a group they are a part of. A initial rough design for it:
Moving on the GPML uploader testing part. I got stuck while installing a new instance of GraphSpace, the current procedure as detailed in README is faulty and Ted is working on fixing it right now. He also helped me to get the instance working as it was desperately needed to run the upload script. Thanks Ted 🙂 As we are using SQLite as our database my script is overloading the database and hence it wasn’t able to handle all the requests sent through the script (1999 out of ~2700 were processed). I have now added a time delay to every CURL request. We guess this should work. I’ll upload a detailed analysis of the results once we go through it.
Summer going really fast!! Looking forward to getting a nice version of the notifications framework merged before the end of official coding period 🙂
After working through the testing script we discussed the failures with Alexander Pico. I am still working on the review of the uploader and the script. While working on this I tried to create a new instance copy of GraphSpace and I got stuck at an issue. (https://github.com/Murali-group/GraphSpace/issues/186) I am working on finding the root of this problem, I suppose it is not related to the GraphSpace codebase.
After discussion with my mentors last week we decided to work on the notification framework for GraphSpace. We started working on a basic model which will alert users of a group if a new graph is shared within the group. For this my mentors helped me to design a new database table. Hoping to get a working notification framework by the end of the summer 🙂
This week we decided to work on testing the GPML uploader feature of GraphSpace.
For this we downloaded all the pathways from the WikiPathways website and uploaded them to GraphSpace using the REST API. The script to do this can be found here. https://gist.github.com/MridulS/2a406ed5c2a465531b5e924af41e3eca
The preliminary results suggest that a total of 970 pathways were able to pass the API call out of 2857. The ones which weren’t able to pass had properties like ‘mitochondria’ for shape and some interactions missed the GraphId, which should be present according to the schema (that’s why the assumption that GraphId is required for all interactions) The uploader will be updated to throw an error in these cases.
Out of the 970 that passed the API call 518 were successfully uploaded on the GraphSpace website and and 452 failed the tests for presence of GraphRefs for interaction. The output can be seen here. https://gist.github.com/MridulS/bbdf0de7b6cec55d00e509e688f40075 it is a dictionary with the API return message keyed by the Pathway ID.
The uploader will be improved further on the results of this test.
This activity helped us discover things like different shapes that wasn’t possible to catch manually.
This week was broadly used to address the comments of my mentors and improving the code. The first major comment was regarding using source and targets while drawing edges. We were using dummy nodes to show edges, by using the start and end coordinates of the given interactions. Now GPML uploader uses the GraphRef attribute to find the source and target nodes. Again there are some problems with this approach as there are files like http://www.wikipathways.org/index.php/Pathway:WP109 which don’t specify the GraphRef for source and target nodes. Currently we are thinking of throwing an error if GraphRefs aren’t present. To test this further I am writing to script to scrape through the wikipathways file and test the GPML uploader for all the files listed there, using http://webservice.wikipathways.org/listPathways and the API http://webservice.wikipathways.org/getPathwayAs?fileType=gpml&pwId=WP4&revision=0 and count the errors we encounter with our GPML uploader.
To use the graphspace interface I did a pretty naive thing, copying the file itself to the folder (dumb I know). I did this beacause the normal way of importing wasn’t working for some reason. To debug this I started looking for namespace collisions, couldn’t find any (technically good for the code, bad for me :/). The solution turns out to be pretty simple, delete the .pyc files because they are still present after you delete the original files and my import was importing the old .pyc file hence wasn’t able to debug.
More to come, thinking of blogging twice a week!
In our meeting on Monday, we decided to start using the graphspace_interface (which basically builds up on a networkx object) rather than building raw nested dictionaries to store the graph/GPML file.
Hence I worked on porting the code of https://github.com/Murali-group/GraphSpace/pull/162 to work with the networkx object. As a result the code is much cleaner and legible 🙂 This was pretty easy, but got stuck in debugging at various points
This week we will work on completing the GPML support with all the documentation update.
Now we have a PR in for review that extends the functionality of GraphSpace with adding support for GPML file format. https://github.com/Murali-group/GraphSpace/pull/162
Thanks to Ted for an initial review of the PR.
Some issues we are still facing:
- Curved edges; it is possible to have curved edges using cytoscape JS but they haven’t be used in GraphSpace yet and are not exposed for edges. We need to further look into this.
- Right now, the starting and ending points of edges are independent nodes (edge end nodes are invisible right now). So if you try to move a node it will move independently without affecting the edge it should have been connected to. We face this issue because the edges in GPML format only have their coordinates position not the source and target nodes. A solution could be look radially outwards from the end points of edges to find the nearest node and bind that edge end point to it.
- Third issue that we are facing, albeit minor, is the rotation of shapes which is not possible in cytoscape JS
Everything else looks good 🙂
Mid terms already here. Summer going really fast. Hoping to get this PR completed by then. 🙂
Now we have something that resembles the GPML file on wiki pathways.
The pathway as shown on wiki pathways.
Right now on GraphSpace
There are still a few issues that need to be dealt with, like with the representation of interaction, example: we can’t have curved edges on GraphSpace, to deal with it right now we have broke it into two different edges, as we have three node points available in the GPML file to draw the interaction.
The GPML functionality will be further improved in coming week 🙂