dataesr/scientific-paragraphs-categorization huggingface dataset:
This geographical metaphor has certain advantages over the database representations for which no global visual image of pathways' functional proximity and crosstalk exist. A significant achievement of systems biology was in combining both approaches for knowledge formalization into one. For this purpose, it was necessary to develop a graphical language (meaningful to humans), a computer-readable language (onto which the graphical language would be mapped) and a piece of software that would allow charting a large map of molecular interactions and, simultaneously, creating a computer-readable file (serving as a database). This inspired the creation of tools like CellDesigner  [22] , SBGN standard for graphical representation of biological diagrams  [23]  and SBML  [24]  and BioPAX standards for exchanging the content of biological pathway databases  [25].
A number of comprehensive maps of molecular interactions in the form of reaction networks representing various relatively large parts of molecular mechanisms, often disease-associated, were created following this way  [11] [12] [13] [14] [15] [16] [17] [18] [19]. However, large maps of molecular interactions are difficult to exploit, maintain and improve without proper software support for navigation, querying and providing feedback on their content. There are a number of tools recently developed that take care of some of these aspects  [26]  (Table  1 ). Such tools as CellPublisher  [27] , Pathway Projector  [28] , GenMAPP  [29]  and PathVisio  [30]  focus on navigating within the maps, in particular, exploiting the geographical metaphor and using the Google Maps engine. SBGN-ED  [31]  supports all SBGN diagram types.
WikiPathways  [8]  and Payao  [32]  focus on the web-based service for network annotation and curation. Similarly, PathBuilder is an example of a web-based pathway resource including an annotation tool  [33]. The BioUML platform supports SBGN, SBML and enables the maps to connect to other databases as well as collective drawing of maps, similar to the principles of Google Docs. Nevertheless, from our practical experience of map creation, maintenance and curation, we identified the lack of a tool that would offer simultaneously a) easy web-based navigation through the content of comprehensive maps of molecular interactions created according to the systems biology standards; b) visualization of the map at different scales in a readable form; c) possibility to collect the feedback of a user about the map's content in an interactive manner.
Implementations NaviCell architecture and installation NaviCell is a bioinformatics environment which allows the conversion of a large CellDesigner xml file into a set of images and html pages, containing Google Maps javascript code (Figure  1 ). These pages can be placed onto a web-server or used locally through all major flavors of Internet browsers. The procedure of creating map representations in the form of NaviCell pages is straightforward, and, in the simplest case of a browse-only representation, takes only a few clicks and several minutes. Creation of the blog is also straightforward but requires installation of the WordPress server and automatic generation of topics (posts) in the blog (Figure  1 ). NaviCell is supposed to be used by users with two roles: a) a map manager who creates, updates and annotates the map; and b) a map user who navigates the map through the webinterface, and comments its content through the blog.
Preparation of map modules In addition, a user can split the map (master map) into sub-maps called modules, typically defined on functional or structural basis, though any other criteria might be used. An unlimited number of separate simplified map representations that can contain subsets of the master map objects can accompany the master map in NaviCell. Each module can be represented with its own layout in the most clear and readable form. NaviCell allows accessing and shuttling between the map's modules. This option is of the utmost convenience for facilitating the map exploration as it is demonstrated in the Results section on the example of RB/E2F map.
NaviCell annotation format NaviCell is capable to process a structured form of annotations of biological entities, if the CellDesigner xml file contains annotations in appropriate format. According to the NaviCell annotation format, annotations are structured in sections, each grouping specific information (in our examples, we used sections "Identifiers", containing the standard entity's IDs, "Modules" for specifying to which module a particular entity belongs, and "References" for providing links to publication records of the entity and free comments). Different sections are further highlighted by different colors in the NaviCell interface, making them easier to distinguish in the pop-up bubbles and in the blog posts. In addition, NaviCell converts several types of tags into hyperlinks such that a user could immediately access external databases such as HUGO, UniProt, Pubmed, etc.
NaviCell documentation The NaviCell is accompanied by two detailed guides downloadable from the NaviCell web site. There is the 'Guide for map manager and system administrator' describing in details NaviCell installation procedure, recommendations for map construction and structuring entity annotations for the most efficient use of NaviCell, instructions for semantic zooming levels creation, recommendations for preparing map modules and using the map in NaviCell (http://navicell. curie. fr/pages/install. html). For NaviCell users that are interested to explore and comment the existing maps without installing NaviCell and uploading their map to NaviCell, the explanations of NaviCell layout and instructions for efficient navigation and commenting maps in NaviCell can be found in the 'Guide for user and map curator' (http://navicell.
Semantic zooming views of the RB/E2F map in NaviCell The RB/E2F map can be navigated similarly to geographical maps through Google Maps, by several levels of map views (Figure  3 ). The navigation of the map starts from the top-level view (Figure  3A ) where one can identify 16 map modules with their names (analogous to countries or regions), together with the positioning of the most important molecular entities inside them (analogue of country capitals). In addition, the cell cycle phases are indicated. In the next level, a more detailed level of zooming called "Pruned" in Figure  3B , the major or canonical cell signaling pathways are visualized. These pathways were specified by intersecting the content of the RB/E2F map with several pathway databases and selecting those entities and reactions that are "canonically" represented in those databases (see the NaviCell guide for semantic zoom levels generation explanation).
Blogging in NaviCell: commenting the RB/E2F map NaviCell uses the WordPress (http://wordpress. org) web-based blog system to collect feedback from the map users. The blog contains pre-generated posts for each entity of the map (genes, proteins, complexes, reactions etc. ). Each post is composed of a detailed entity annotation (HUGO names, references, etc. ), links to other entities in the network (internal hyperlinks) and links to databases including PubMed, NCBI etc. (external hyperlinks). An example of a pre-generated post is shown in Figure  5  for a molecular complex composed of CDK6, Cyclin D1 and p27Kip1 proteins. The post contains annotation of the complex, list of complex forms (modifications) and reactions in which the complex participates as reactant or product, or catalyzer. Note that each globe icon in the post leads to the map, and allows selecting corresponding objects on it.
Acknowledgments We thank  Camille Barette  for help in setting up the informatics recourses and  Hien-Anh Nuigen  for help with NaviCell guides design. This work is supported by the  APO - SYS  EU  FP7  project under grant n°  HEALTH-F4-2007-200767 , by the grant  INCA LABEL Cancéropole Ile-de-France 2011-1-LABEL-1 , by the grant  INVADE  from  ITMO Cancer  ( Call Systems Biology 2012 ) and by the grant " Projet Incitatif et Collaboratif Computational Systems Biology Approach for Cancer » from Institut Curie. IK, DC, LC, EB and AZ are members of the team " Computational Systems Biology of Cancer ",  Equipe labellisée par la Ligue Nationale Contre le Cancer.
Methodology: Data analysis In order To search for differentially regulated gene networks in the absence of CD36 gene, we performed a comprehensive gene analysis by hybridizing microarray chips with RNA probes prepared from mouse heart CD36-KO and CD36-WT. Two technologies were used. The Affymetrix GeneChip Murine Genome U74 which contains 36. 000 probes (Affymetrix, Santa Clara, CA). Once the probe array had been hybridized, stained, and washed, it was scanned using a GeneArray scanner. A GeneChip Operating System, running on a PC workstation was used to control the functions of the scanner and collect fluorescent intensity data. The second approach used was the Whole Mouse Genome Microarray 4x44K (Agilent Technologies, Santa Clara, CA). Arrays were washed and dried out using a centrifuge according to manufacturer's instructions (One-Color Microarray-Based Gene Expression Analysis, Agilent Technologies).
Arrays were scanned at 5 mm resolution on an Agilent DNA Microarray Scanner (GenePix 4000B, Agilent Technologies) using the default settings for 4x44k format one-color arrays. Images provided by the scanner were analyzed using Feature Extraction software v10. 1. 1. 1 (Agilent Technologies). Raw data files were analyzed using the software R associated to packages of "Bioconductor" project [8]. Developed affymetrix workflows begin with data normalization using Robust Multichip Average Method (RMA) [9], which allows reduction of block effect done at the probset level. The second step consisted in selecting differentially expressed genes between CD36-WT" and CD36-KO using the Significance Analysis of Microarrays (SAM) algorithm [10] with the Fold Change and P-value Cutoffs respectively fixed to at 1.
5 and 0. 002. Agilent workflow begins with data normalization by using Lowess normalization [11] that applied to a two-color array expression dataset. The second step, as in the case of Affymetrix, SAM algorithm was used to identify differentially expressed genes with the same FC and P-value cuttoffs. Class discovery analyzed a given set of genes to produce subgroups that share common features. An analysis method often used for class discovery is ""cluster analysis"" or clustering. It is aimed at dividing the data points (genes or samples) into groups (clusters) using measures of similarity [12, 13] creating hierarchical clustering of co-regulated genes.
Functional Analysis After establishing a differentially expressed gene list common to the two technologies (Affymetrix and Agilent), functional annotation allowed the determination of each gene function in the list. Functional classes were extracted using Gene Ontology tools. Associations, biochemical pathway data were retrieved from the Gene Ontology consortium (GO) [14, 15], Kyoto Encyclopedia of Genes and Genomes (KEGG)  [16]. Gene sets were arranged and associated with different functional categories. Integrated expression data and evolutionary conservation of proteins were used to predict interacting proteins, protein complexes and proteins functions [17, 18, 19]. Table  1  (See supplementary material) showed the first classification leading to the identification of three gene categories: a gene group involved in metabolism, another group involved in the Angiogenesis Table  2  (see supplementary material) and a third one implicated in cellular remodeling Table  3  (see supplementary material) (structural genes).
Acknowledgment: This work was carried out under intramural funding from the  Stony Brook University  and Mohammed the V th Souissi University to AI. We acknowledge support from  Volubilis  ( French-Moroccan Grant ) to AI, BV & AM. This work was also supported by a grant from the  NIH  for  H3Africa BioNet  to AI & AM. We would like to thank  Microarrays facilities in Stony Brook and George Washington Universities  for conducting the arrays hybridization experiments.
We present The Virtual Brain (TVB), a neuroinformatics platform for full brain network simulations using biologically realistic connectivity. This simulation environment enables the model-based inference of neurophysiological mechanisms across different brain scales that underlie the generation of macroscopic neuroimaging signals including functional MRI (fMRI), EEG and MEG. Researchers from different backgrounds can benefit from an integrative software platform including a supporting framework for data management (generation, organization, storage, integration and sharing) and a simulation core written in Python. TVB allows the reproduction and evaluation of personalized configurations of the brain by using individual subject data. This personalization facilitates an exploration of the consequences of pathological changes in the system, permitting to investigate potential ways to counteract such unfavorable processes.
The architecture of TVB supports interaction with MATLAB packages, for example, the well known Brain Connectivity Toolbox. TVB can be used in a client-server configuration, such that it can be remotely accessed through the Internet thanks to its web-based HTML5, JS, and WebGL graphical user interface. TVB is also accessible as a standalone cross-platform Python library and application, and users can interact with the scientific core through the scripting interface IDLE, enabling easy modeling, development and debugging of the scientific kernel. This second interface makes TVB extensible by combining it with other libraries and modules developed by the Python scientific community. In this article, we describe the theoretical background and foundations that led to the development of TVB, the architecture and features of its major software components as well as potential neuroscience applications.
, 2012) , Electroencephalography (EEG)  (Nunez and Srinivasan, 1981; Nunez, 1995; Niedermeyer and Lopes Da Silva, 2005) , Magnetoencephalography (MEG)  (Hämäläinen, 1992; Hämäläinen et al. , 1993; Mosher et al. , 1999) , and functional Magnetic Resonance Imaging (fMRI)  (Ogawa et al. , 1993 (Ogawa et al. , , 1998;; Logothetis et al. , 2001)  to assess brain dynamics and evaluate diagnostic and therapeutic strategies. Hence, there is a strong motivation to develop an efficient, flexible, neuroinformatics platform on this macroscopic level of brain organization for reproducing and probing the broad repertoire of brain dynamics, enabling quick data analysis and visualization of the results. The Virtual Brain (TVB) is our response to this need. On the one hand, it provides a general infrastructure to support multiple users handling various kinds of empirical and simulated data, as well as tools for visualizing and analyzing that data, either via internal mechanisms or by interacting with other computational systems such as MATLAB.
MODELING In line with these previous studies, TVB incorporates a biologically realistic, large-scale connectivity of brain regions in the primate brain. Connectivity is mediated by long-range neural fiber tracts as identified by tractography based methods  (Hagmann et al. , 2008; Honey et al. , 2009; Bastiani et al. , 2012) , or obtained from CoCoMac neuroinformatics database  (Kötter, 2004; Kötter and Wanke, 2005; Bakker et al. , 2012). In TVB, the tract-lengths matrix of the demonstration connectivity dataset is symmetric due to the fiber detection techniques used to extract the information being insensitive to directionality. On the other hand, the weights matrix is asymmetric as it makes use of directional information contained in the tracer studies of the CoCoMac database. Such details are specific to the connectivity demonstration dataset included in the distribution packages of TVB.
As both kinds of users may work within the same framework, the interplay of theory and experiment or application is accelerated. Additionally, users with stronger programming skills benefit from all the advantages provided by the Python programming language: easy-to-learn, easy-to-use, scriptable and with a large choice of scientific modules  (Oliphant, 2006). TVB has been principally built in the Python programming language due to its unique combination of flexibility, existing libraries and the ease with which code can be written, documented, and maintained by non-programmers. The simulation core, originally developed in MATLAB, was ported to Python given its current significance in the numerical computing and neuroscience community and its already proven efficiency for implementing modeling tools  (Spacek et al.
, 2008). Simulations benefit from vectorized numerical computations with NumPy arrays and are enhanced by the use of the numexpr package. Although this allows rather efficient single simulations, the desire to systematically explore the parameter spaces of the neural dynamic models, and to compare many connectivity matrices, has lead to the implementation of code generation mechanisms for the majority of the simulator core-producing C code for both native CPU and also graphics processing units (GPU), leading to a significant speed up of parameter sweeps and parallel simulations (5x from Python to C, 40x from C to GPU). Such graphics units have become popular in scientific computing for their relatively low price and high computing power. Going forward, the GPU implementation of TVB will require testing and optimization before placing it in the hands of users.
Blocks in the back-end are transparently used by different top application layers. TVB-Datatypes, are the common language between different components  (analyzers, visualizers, simulator, uploaders). They represent "active data" in the sense that, when TVB is configured with a database, data contained in TVB-Datatypes instances are automatically persistent. Currently the console interface works without the storage layer, keeping the results just in memory. S-Users need to manually handle data import and export operations. In this deployment model, simulations use the back-end server's computing power while visualization tasks use resources from the client machine. The third is similar to the client-server configuration, but with the additional advantage of parallelization support in the back-end.
The cluster itself needs to be configured separately of TVB. Based on the usage scenarios and user's level of programming knowledge, two user profiles are represented: a graphical user (G-user) and scripting user (S-user). We therefore provide the corresponding main interfaces based on this classification: a graphical user interface (web) and a scripting interface (IDLE). S-users and G-users have different levels of control over different parts of the system. The profile of S-users is thought to be that of scientific developers, that is, researchers who can elaborate complex modeling scenarios, add their own models or directly modify the source code to extend the scientific core of TVB, mostly working with the scientific modules. They do, nevertheless, have the possibility to enable the database system.
In contrast, G-users are relatively more constrained to the features available in the stable releases of TVB, since their profile corresponds more to that of researchers without a strong background in computational modeling. The distinction between these two profiles is mainly a categorization due to the design architecture of TVB. For instance, we could also think of other type of users who want to work with TVB's GUI and are comfortable with programming, and therefore they could potentially make modifications in the code and then see the effect of those when launching the application in a web browser. The development of TVB is managed under Agile techniques. In accord therewith, each task is considered as done, after completing a validation procedure that includes: adding a corresponding automated unit-test, labeling the task as finished from the team member assigned to implement the task and further tagging as closed from a team member responsible for the module, which means a second level of testing.
Before releasing stable packages, there is a period for manual testing, that is, a small group of selected users from different institutions check the main features and functionalities through both interfaces. The navigation and workflows scenarios through the webbased interface are evaluated by means of automated integration tests for web-applications running with Selenium (http://docs. seleniumhq. org/) and Apache-JMeter (http://jmeter. apache. org/) on top of a browser engine. Special effort is being made to provide good code-coverage, including regression tests. Accordingly, the simulation engine of TVB has automated unit-tests, to guarantee the proper and coordinated functioning of all the modules, and simple programs (demonstration scripts), that permit qualitative evaluation of the scientific correctness of results.
The development version of TVB is currently hosted on a private cluster, where we use the version control system svn (subversion). Additionally, as any large collaborative open-source project, it is also available in a public repository, using the distributed version control system git  (Chacon, 2009)  to make accessible the scientific core and to gather, manage and integrate contributions from the community. The distribution packages for TVB come with an extensive documentation, including: a User Guide, explaining how to install TVB, set up models and run them; Tutorials, Use Cases and Script Demos, guiding users to achieve predefined simulation scenarios; and a Developer Guide and API reference. to: the official TVB website, where distribution packages for Linux and Mac OS (32 and 64 bits) and Windows (32 bits) are available for download; the active users group of TVB hosted in Google Groups, where users can ask questions, report issues and suggest improvements or new features; and the public repository, where the source code of both the framework and scientific library (which contains the simulation engine) are available.
TVB FRAMEWORK The supporting framework provides a database back-end, workflow management and a number of features to support collaborative work. The latter feature permits TVB to be setup as a multi-user application. In this configuration, a login system enables users to access their personal sessions; by default their projects and data are private, but they can be shared with other users. The graphical user interface (GUI) is web based, making use of HTML 5, WebGL, CSS3 and Java Script  (Bostock et al. , 2011)  tools to provide an intuitive and responsive interface that can be locally and remotely accessed.
Data management and exchange One of the goals of TVB is to allow researchers from different backgrounds and with different programming skills to have quick access to their simulated data. Data from TVB can be exchanged with other instances of TVB (copies installed on different computers) or with other applications in the neuroscientific community, e. g. , MATLAB, Octave, The Connectome ToolKit  (Gerhard et al. , 2011). Export: A project created within TVB can be entirely exported to a. zip file. Besides storing all the data generated within a particular project in binary files, additional XML files are created to provide a structured storage of metadata, especially with regard to the steps taken to set up a simulation, configuration parameters for specific operations, time-stamps and user account information.