Technical Manual
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 6
| Download | |
| Open PDF In Browser | View PDF |
Technical Manual
Carbon Semantics
”https://github.com/CarboSem”
Department of Computer Science, University of L’Aquila
June 9, 2017
Abstract
CarboSem is a webapp interface for the DIANA project (Data science analysis
to determine the Influence of multiple conjoint mirnAs on caNcer diseAse).
developed with jquery, d3.js, python and the bottle micro-framework.
0.1
File Roles
The webapp comprises of 2 main files, one ”carbosem.py” acts as a minimal server, the other ”carbosem.js” acts as a data visualizer.
.
carbosem . py
js
carbosem . j s
0.1.1
carbosem.py
The main server-side script that handles client requests, fetches files from the
server to be loaded to the client, and relays submitted data from the client to
the 3rd party server-side scripts. It is mainly a skeleton script with routing
subroutines.
One certain routing subroutine that the 3rd party developers should be made
aware of is the one that receives data from the client to be queried:
@route ( ’ / graph ’ )
d e f graph ( ) :
# TODO
r e t u r n True
In the TODO section should go the interface to the scripts that handle
queries.
1
0.1.2
carbosem.js
The main client-side script that handles data manipulation on the returned
JSON file and visualization of said data, it is responsible for the drawing and
handling of the graph canvas, the checkbox area and the ledger area.
We will go in detail over some of the code segments which those who wish to
use this script should pay attention to.
We start off with client events, which include calling the submission routine and the drawing routine on client submission of a string to be queried:
/*
* c a l l i n g f u n c t i o n s a c c o r d i n g t o DOM b i n d i n g s
*/
$ (”# s e a r c h ” ) . submit ( submitQuery ) ;
$ (”# s e a r c h ” ) . submit ( drawGraph ) ;
$ ( window ) . r e s i z e ( drawGraph ) ;
return ;
From here we examine the submission routine, as every submission brings
a new set of relations, we tend to reset the checkbox area (which when an
element of which is active it denotes an active relationship on the screen):
f u n c t i o n submitQuery ( ) {
/*
* r e s e t t i n g t h e checkbox a r e a
*/
checkbox . s t a t e s = [ ] ;
checkbox . v a l s = [ ] ;
checkbox . c o l o r s = [ ] ;
/*
* TODO
* v a r query = $ (”# s e a r c h ” ) . f i n d ( ” i n p u t [ name=s e a r c h ] ” ) . v a l ( ) ;
* $ . g e t ( ” / graph ? mir=” + encodeURIComponent ( query ) ) ;
*/
}
It is also important to note that 3rd party developers take good care in articulating the routing request from the submission routine to the ”graph()”
routine on the server side.
2
Moving on to the drawing routine, we notice that every time we call this
routine the ledger is reset, because this routine is called regardless of any
server submissions sometimes, depending on client change of the checkbox
area, which in turn has the ledger require adjustment according to the new
node types on display and according to the checkbox states.
/*
* r e s e t t i n g the l e d g e r area
*/
ledger . elements = [ ] ;
ledger . colors = [ ] ;
d3 . j s o n ( ” / getJSON ” , f u n c t i o n ( e r r o r , graph ) {
i f ( error ) {
a l e r t ( ” Error , no JSON f i l e found ! ” ) ;
return ;
}
/*
* c l e a n i n g up p r e v i o u s l y r e n d e r e d c h e c k b o x e s and l e d g e r e l e m e n t s
*/
d3 . s e l e c t A l l ( ” d i v #addedCheckbox ” ) . remove ( ) ;
d3 . s e l e c t A l l ( ” d i v #addedLedger ” ) . remove ( ) ;
Also at this stage, the JSON file is reloaded and drawn from according to
the checkbox states, and both the ledger and the checkbox areas are removed
from screen for re-rendering to reflect new or less elements in the ledger area
and the new chosen states of the checkbox area.
As for choosing the colors, we opted in for using the schemeCategory
functions already packaged with d3 to construct our source color arrays, and
we chose different schemes for the checkbox area and the ledger area:
/*
* defining color arrays
*/
v a r l i n k C o l o r = d3 . s c a l e O r d i n a l ( d3 . schemeCategory10 ) ;
v a r n o d e C o l o r = d3 . s c a l e O r d i n a l ( d3 . schemeCategory20 ) ;
Whenever we get the result of a query, we construct our target color arrays
depending on node/link types and the source color arrays.
3
For example, when we submit a query for the first time, as soon as we
get the JSON file we scan through it looking for different types of links to
populate our checkbox area accordingly, we store information about the link
type, its state: whether it’s active or inactive, and we derive its targeted
color according to its index from the source color array:
v a r p u s h S t a t e = checkbox . v a l s . i n d e x O f ( graph . nodes [ i ] . t a r g e t s [ j ] . t y p e ) ;
i f ( p u s h S t a t e == −1) {
checkbox . v a l s . push ( graph . nodes [ i ] . t a r g e t s [ j ] . t y p e ) ;
checkbox . s t a t e s . push ( t r u e ) ;
checkbox . c o l o r s . push ( l i n k C o l o r ( checkbox . s t a t e s . l e n g t h − 1 ) ) ;
}
If one wants fixed colors for certain nodes or links, one can choose a function
with ”if” statements to choose certain colors for certain node/link types.
One other way is getting rid of the target color arrays and depending solely
on one set of color arrays, but that requires using another method to choose
the proper color index for a type, which is embedding this information inside
the JSON file for each link/node type.
One final thing we ought to mention is the recalling of the drawing routine
on checkbox changes by the client, that is done using the following:
addedCheckbox . on ( ” change ” , f u n c t i o n ( ) {
f o r ( v a r i = 0 ; i < checkbox . s t a t e s . l e n g t h ; i ++) {
checkbox . s t a t e s [ i ] = addedBoxes [ i ] . p r o p e r t y ( ” c h e c k e d ” ) ;
checkbox . c o l o r s [ i ] = checkbox . s t a t e s [ i ] ? l i n k C o l o r ( i ) : ”#
FFFFFF ” ;
}
drawGraph ( ) ;
return ;
}) ;
We notice that before the recall of the drawing routine, the checkboxes are
checked for changes and if so, color and state arrays are changed accordingly
to be re-rendered on routine recall.
4
Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.5 Linearized : No Page Count : 6 Page Mode : UseOutlines Author : Title : Subject : Creator : LaTeX with hyperref package Producer : pdfTeX-1.40.16 Create Date : 2017:06:26 00:35:24+02:00 Modify Date : 2017:06:26 00:35:24+02:00 Trapped : False PTEX Fullbanner : This is pdfTeX, Version 3.14159265-2.6-1.40.16 (TeX Live 2015/Debian) kpathsea version 6.2.1EXIF Metadata provided by EXIF.tools