These are chat archives for openworm/ChannelWorm

13th
Mar 2015
Wilson Zhao
@wilzh40
Mar 13 2015 03:35
Checked out PyOpenWorm, installed it on a clean virtualenv
Turns out I needed some additional reqs such as tables and jsonpickle, running setup.py isn't enough
Travis Jacobs
@travs
Mar 13 2015 14:48
@wilzh40 Just did the same and I haven't found an issue.
What system are you running it on?
What are you doing with it when you get the error (ex: is it failing when you try to import the PyOpenWorm module?)
Just checked my venv's pip and jsonpickle and tables are not installed for me either, so you must be running some command I'm not doing. Are you running the tests maybe
Travis Jacobs
@travs
Mar 13 2015 14:54
@miladjafary
Yes, I am extending PyOpenWorm to include things useful for ChannelWorm. This is all done in the channelworm branch of PyOW
Travis Jacobs
@travs
Mar 13 2015 15:00
PyOpenWorm is a way to put data into and pull data out of a binary db
There will be python classes that you interact with directly (ex: ChannelModel, Experiment)
These classes and their parameters define the structure of the data
There will be more extensive documentation here, but I am still defining classes for ChannelWorm, so it is not extremely useful for our purposes yet
Travis Jacobs
@travs
Mar 13 2015 15:05
But the workflow will be something like this:
  1. Get data from experiments
  2. Populate PyOpenWorm objects with the data
  3. Save data to the db
  4. Distribute the db in ChannelWorm/data
Then to use the data it will be somewhat the opposite:
  1. Pull newest db from ChannelWorm/data
  2. Load data from db with PyOpenWorm, which will create python objects
  3. Use data stored in these objects to model/simulate ion channels in other software/formats (ex: lems, neuroml2, gepetto)
Vahid Ghayoomie
@VahidGh
Mar 13 2015 15:10
As we discussed before, we need 2 different DBs
Travis Jacobs
@travs
Mar 13 2015 15:11
One for data based on homology and one for data based on patch-clamp studies?
Vahid Ghayoomie
@VahidGh
Mar 13 2015 15:11
One within PyOpenWorm which includes data about C. elegans
and the other includes other type of data
such as experiment specific data, user profile, and data we need specifically in our project
Travis Jacobs
@travs
Mar 13 2015 15:13
Right, I agree with you Vahid
Vahid Ghayoomie
@VahidGh
Mar 13 2015 15:14
So, while designing, make sure you put data only related to the C. elegans in PyOW
Travis Jacobs
@travs
Mar 13 2015 15:15
But I think all of this can be stored in one db, which would simplify distribution and extraction of the data
Vahid Ghayoomie
@VahidGh
Mar 13 2015 15:15
for the other one, we can setup one in our repo
Travis Jacobs
@travs
Mar 13 2015 15:16
The way I imagined it was that we extend PyOpenWorm to encompass our project's data layer entirely.
Vahid Ghayoomie
@VahidGh
Mar 13 2015 15:16
Yes, but when we want to merge data with the master one, we should put related data into the PyOW
Travis Jacobs
@travs
Mar 13 2015 15:17
Sorry, which master are we talking about, PyOpenWorm/master?
Vahid Ghayoomie
@VahidGh
Mar 13 2015 15:17
finally the main objective of the PyOW is to integrate data related to C. elegans
yes
Travis Jacobs
@travs
Mar 13 2015 15:18
Ah I see what you mean
Vahid Ghayoomie
@VahidGh
Mar 13 2015 15:19
What tables have you made till now?
Travis Jacobs
@travs
Mar 13 2015 15:27
@VahidGh
I've made Channel, ChannelModel and Experiment classes so far
Vahid Ghayoomie
@VahidGh
Mar 13 2015 15:29
Great, would you please also name their columns?
Travis Jacobs
@travs
Mar 13 2015 15:29
Note: We can store the data in two separate databases as you described, but PyOpenWorm is independent of any db is uses, so we can design PyOW the same either way. It only defines the structure of the data, and is an access layer only
And yeah one sec
Vahid Ghayoomie
@VahidGh
Mar 13 2015 15:30
Yes, that's right
Travis Jacobs
@travs
Mar 13 2015 15:31
The columns are under attributes in each of those 3 links
So we have:
Channel: name, models
ChannelModel: modelType, gating, ion
Experiment: conditions
These can easily be extended, just give me the columns you want! :D
Vahid Ghayoomie
@VahidGh
Mar 13 2015 15:39
That's great.
What's your idea about having a ChannelWorm class?
I'm thinking about separating our own sub-classes with future merging issues in mind
Vahid Ghayoomie
@VahidGh
Mar 13 2015 15:45
For example if there is a need for a class like experiment, we have separate class for it, but if we can not generalize it for the PyOW purposes, then we should separate it
Travis Jacobs
@travs
Mar 13 2015 15:48
I totally see where you're coming from, and I have been keeping that in mind when designing these classes
As they are now, classes like Experiment are generic enough to be used for any purpose (Conditions could store anything, really)
So they will be safe to merge to PyOW/master
Vahid Ghayoomie
@VahidGh
Mar 13 2015 15:50
yep, I agree with you
Travis Jacobs
@travs
Mar 13 2015 15:52
I am just wondering what data structure could be useful in ChannelWorm but not PyOW?
I get that we don't want to bloat the db on PyOW, but the structure should be pretty generic for both PyOW and CW, so merging would not be an issue in my mind. This is of course, if we (me :scream: ) are vigilant in keeping the structure generic
If we run into anything that seems too specific we can keep in in PyOW/channelworm branch, but not merge that part to master!
Vahid Ghayoomie
@VahidGh
Mar 13 2015 15:54
make sense, that was what I mean :D
Travis Jacobs
@travs
Mar 13 2015 15:54
I guess we need to discuss exactly which columns we need in our data tables, and see if they can/cannot be generalized to PyOW
haha alright, we're in agreement then :)
Vahid Ghayoomie
@VahidGh
Mar 13 2015 15:55
yes, for the specific data structure, we will talk about when we reach out to that point
And that would be the subject @miladjafary is going to work on
Travis Jacobs
@travs
Mar 13 2015 15:56
Excellent.
Vahid Ghayoomie
@VahidGh
Mar 13 2015 15:58
That would be great if @wilzh40 could join us in this part, for #9
Milad Jafary
@miladjafary
Mar 13 2015 16:51
@travs thank you for replay.
I think we can have 2 databases. One of them for storing related data to C. elegans which is handle by PyOW and the other one can store related data to framework(some thing like use profile, config , etc ) that could be a light DBMS like MySQL.
But the main point is we should have only one abstract layer for communication with other layer.
So we need a generic API (Something like JPA in java) for model layer.
Vahid Ghayoomie
@VahidGh
Mar 13 2015 17:10
@miladjafary, great. could you find the alternative for python, and start the abstract based on your design pattern to build other parts, based on that?
Milad Jafary
@miladjafary
Mar 13 2015 17:33
@VahidGh I am researching on it. May be this pattern exist. JAVA has standard called JPA for this purpose but in Python I don't know. I am researching on it.
Wilson Zhao
@wilzh40
Mar 13 2015 18:34
@VahidGh I'm writing a small python script that scrapes the REST API of wormbase into a csv table based on the geneID
I'm using and learning vim on on-the-fly so it might take a while
Wilson Zhao
@wilzh40
Mar 13 2015 18:46
Is it just me or is the documentation for gene empty?
http://www.wormbase.org/about/userguide/for_developers/API-REST/Gene#name
Vahid Ghayoomie
@VahidGh
Mar 13 2015 19:48
@wilzh40, great! and yep, it seems the documentation for gene is empty!
But you can use this: /rest/widget/gene/WBGene00006763/overview as the example describes.
Actually we just need to grab the Gene WB ID from the spreadsheet and other info could be retrieved via this ID, automatically.