dataesr/scientific-paragraphs-categorization huggingface dataset:
Novel methods of merging data and displaying clustered by pathway, process or subcellular location have to be considered. Interaction data are becoming ever-more sophisticated and new ways of visualizing data need to be developed to capture this. One example of this is the generation of dynamic interaction data, in which changes in protein complex composition in response to stimuli, be these biochemical (e. g. in response to increasing concentrations of an agonist such as a growth factor), temporal (such as different phases of the cell cycle) or environmental (dark versus light). IntAct has developed an extension of the CytoscapeWeb viewer  (28)  to present such dynamic changes as an animation driven by radio-buttons, provided data are entered into the database under appropriate annotation topic headings.
The entire potential protein complex is displayed in the viewer, with those interactions relevant under a particular condition, or set of conditions, highlighted with the edge colour in red (http://www. ebi. ac. uk/intact/interaction/EBI-6263088). Future plans include extending this viewer, and indeed the underlying database model, to cope with concomitant changes in expressed protein level within the complex as improvements in mass spectrometry-based quantitative proteomics techniques means that such data become available. We are constantly trying to improve our databases and services in terms of accuracy and representation and actively encourage user feedback. Please contact IntAct if you have any questions via http://www. ebi. ac. uk/ support/index. php or email us directly at intacthelp@ebi.
ac. uk. Information about curation is provided at http://www. ebi. ac. uk/intact/pages/documentation/ data_curation. xhtml and at http://www. ebi. ac. uk/intact/ pages/documentation/data_submission. xhtml about data submissions. Extensive documentation and training material on how to best use our resource is available at http://www. ebi. ac. uk/training/networks. Curation groups interested in capturing interaction data who would like access to the editorial tool are encouraged to contact the IntAct molecular interaction database to discuss this further (intact-help@ebi. ac. uk).
Practical procedure We have written a perl script to compute the symbolic transfer matrix T k+1 using ideas similar to those already explained in  [23, 24]. For 1 ≤ k ≤ 4, we have checked our programs using Mathematica. Further checks were performed with code written in C that allows us to numerically compute the leading eigenvalue for given values of k, ℓ, and λ = (ℓ) = the completely symmetric irreducible representation of S ℓ. The first step is to obtain the relevant diagonal blocks T k+1,ℓ,λ of the transfer matrix T k+1. We first fix the value of ℓ (0 ≤ ℓ ≤ k + 1) and a bottom-row configuration compatible with the chosen value of ℓ and the "no un-marked singletons" condition. Remark. Our choice for the bottom-row partition is the simplest one. We take the partition {{0, 1,. , k}} for ℓ = 0, the partition {{0, 1,.
We always use at least one more prime than needed, in order to check the result. To accelerate the computation of the trace using modular arithmetic, we use a program written in C. • For 1 ≤ k ≤ 6, we are able to compute the traces for many different values of n. However, for k = 7, the computation is so demanding, that we have focused on powers of the type n = 2 q + 1 with integer q ≥ 1. The reason why we consider odd powers for k = 7 will become clear in Section 6. Once the traces are computed, we can form the flow polynomial using (4. 5). Notice that for 1 ≤ k ≤ 7, everything in this formula is exactly known. The zeros of the flow polynomials are then obtained using the program MPSolve  [7, 8]. This software has the advantage that if one requests the zeros with 50-digit precision (as in our case), the results are guaranteed to have at least such precision.
For each value of k in the interval 1 ≤ k ≤ 7, we show the values of n for which we have computed Φ G(kn,k) using a) Maple (second column), b) the Tutte code developed by Haggard, Pierce, and Royle  [18]  (third column), and c) the Tutte code developed by Bedini and Jacobsen  [2]  (fourth column). In all cases, the agreement between these computations and our transfer-matrix results is perfect.
Additional checks Because our results are derived using software, we have performed some tests in order to ensure that the results are correct. First of all, for the smallest members of each family G(nk, k), we have computed the flow polynomial using three different software programs: Maple, the program Tutte developed by Haggard, Pierce and Royle  [18] , and the program Tutte developed by Bedini and Jacobsen  [2]. The pairs (k, n) for which the checks have been performed are shown in Table  1. In all cases, the agreement with our transfer-matrix computations is perfect. For the cubic graphs G(m, k) that we are considering, we may improve on (2. 12) by adding a few more terms: Φ G(m,k) (Q) = Q |E|-|V |+1 -|E|Q |E|-|V | + |E|(|E| -1) 2 -|V | Q |E|-|V |-1 - |E|(|E| -1)(|E| -2) 6 -|V |(|E| -2) Q |E|-|V |-2 +.
Acknowledgments We wish to thank  Gordon Royle  for suggesting us to study the generalised Petersen graphs, and  Alan Sokal  for helpful conversations and for a critical reading of the manuscript that gave rise to many constructive comments. We also wish to thank an anonymous referee for his/her very detailed suggestions and criticisms that helped us to improve the manuscript. Both authors also thank the  Isaac Newton Institute for Mathematical Sciences, University of Cambridge , for hospitality during the programme on Combinatorics and  Statistical Mechanics  ( January-June 2008 ), where this project started. J. S. also thanks the  École Normale Supérieure  for hospitality in June 2009, June 2011, and December 2012. The research of J. S. was supported in part by  Spanish MICINN/MINECO  grants  MTM2008-03020 ,  FPA2009-08785 ,  MTM2011-24097  and  FIS2012-34379 , and by  U.
Phosphorylation of Ser369 leads to structural changes in helix H9 The effect of the S369 phosphorylation on the helix H9 was analyzed by quantifying the helix bend. We estimated the radius of a sphere needed to encircle the Ca atoms of the helix in the nonphosphorylated and phosphorylated forms using the TRAJELIX module  [30]  in the Simulaid software  [31]. A bent helix with a particular sequence requires a smaller sphere than a perfectly extended helix of the same sequence. The average radii of the encircling spheres are 18. 2060. 45 A ˚in the unp-RARa LBD and 18. 4360. 34 A ˚in the p-RARa LBD simulations (see Figure  5 ). The p-value calculated on these two ensembles using a Student's test is ,2. 2e 216 , supporting the subtle differences between the values of the phosphorylated and the non-phosphorylated forms.
In one study, point mutations that were shown to change the specific volume of the protein cyclic AMP receptor protein led to more significant changes in protein compressibility and flexibility as measured by H/D exchange. The changes in specific volume for cAMP were on the order of 0. 1%; we estimated changes in RARa from our simulations to be on the same order, around 0. 13%. In addition, we also measured an increase in the number of cavities in the average structures of the phosphorylated receptor as measured by the program FPOCKET  [53]  (data not shown). These fine structural alterations induced by phosphorylation affects, in turn, the internal dynamics of the receptor by altering the collective motions as shown by the quasi-harmonic analysis of our simulations. The small changes in conformation that occur upon phosphorylation can not be attributed to a specific quasiharmonic mode, as is often the case for large-scale conformational change, but the change in dynamics of loop L8-9 is captured by changes in the ensemble of low frequency modes.
Structure preparation The X-ray crystal structure of the heterodimeric complex RXR/RAR complexed to all-trans RA and a 13-mer peptide from the Nuclear Receptor Coactivator 2 protein was used (PDBid: 3A9E)  [34]. The calculations presented here were limited to the RARa LBD monomer (Figure  1 ). All heavy atoms were present in the experimental coordinate files. Prior to hydrogen atom placement, the protonation states of all His residues at physiological pH (7. 4) were obtained using two different methods of pKa calculation: an empirical method related to the protein structure, PROPKA  [56]  and the H++ server method  [57]  based on the Poisson-Boltzmann equation. Both methods yield the same results for protonation states. The final construction of the proton positions, enforcing the protonation states determined in the above continuum dielectric calculations, was done using the HBUILD facility  [58]  in the CHARMM program  [59, 60].
Simulation setup and equilibration Explicit solvent molecular dynamics simulations of RARa were done using the NAMD program  [61]  and the all atom force field CHARMM27  [62]  with CMAP corrections  [63]. After the energy minimization described above, a cubic box of equilibrated TIP3P water molecules with a box length of approximately 75 A ˚per side was centered on the protein center of mass. Waters overlapping the protein complex were removed. These explicit solvent systems were neutralized by Na + /Cl 2 counterions, additional ion pairs were added to yield a final physiological ionic strength of approximately 0. 15 M. Simulations were carried out under periodic boundary conditions and the long-range electrostatic interactions were treated with the Particle Mesh Ewald (PME) algorithm  [64].
Quasi-harmonic analysis To characterize the low frequency, collective motions of RARa, as well as changes in these motions as a function of phosphorylation, a quasi-harmonic analysis (QHA) of the molecular dynamics trajectories was performed. The QHA was carried out over the final 40 ns of the simulation using the quasi-harmonic command in the VIBRAN module of the CHARMM program  [62] ; all the modes were calculated in this analysis (3xN atoms) corresponding to 12,285 modes for the phosphorylated form and 12,276 modes for the unphosphorylated one.
From this, their relative orientations were determined over the course of the simulations. A second analysis of helices, which quantified the bend of a helix as the radius of a circle needed to fit the a-carbons  [68] , was done; the smaller the radius, the larger the helix bend. The software SIMULAID  [31] , and specifically the TRAJELIX  [30]  tool, was used to calculate this radius. Histograms of the distances and the angles obtained are plotted using the R project package  [69]. After evaluating the normality of the angles and distances distributions using the Shapiro-Wilk test, we performed a Student's test to assess the statistical difference between the averages of values obtained from the non-phosphorylated and phosphorylated simulations. In supplementary material, we show the distributions of the helix radii from the individual simulations of the un-phosphorylated and phosphorylated LBD (Figure  S3 ).
The average radii for the individual simulations are 18. 4, 17. 8 and 18. 4 A ˚for the unphosphorylated receptor and 18. 5, 18. 5 and 18. 3 A ˚for the phosphorylated LBD (Figure  S3 ). For reference, the radius calculated using the X-ray structure of helix H9 is 18. 5 A ˚and the value for an ideal alpha-helix of the same sequence built by the PyMol program is 16. 6 A ˚. Thus, in the crystal structure environment, helix H9 of the unphosphorylated receptor is more extended than that of an ideal helix. This is likely due to the alpha-helical sandwich organization of the ligand binding domain of nuclear receptors. One simulation of the unphosphorylated receptor showed a clear shift toward lower values, while the other two show a more subtle shift of the radius toward the ideal value.
Acknowledgments We thank  Dr. Dino Moras  and  Prof. Bruno Kieffer  of the  Institut de Genetique et de Biologie Moleculaire et Cellulaire (IGBMC)  and  Dr. Katia Zanier  from the  IREBS (Institut de Recherche de l'Ecole de Biotechnologie de Strasbourg)  for fruitful discussions. We thank all group members for their helpful discussion.
This work was supported by funds from the  Centre National de Recherche Scientifique (CNRS) ,  Institut National de la Santeet de la Recherche Medicale (INSERM) ,  Universitede Strasbourg, Agence Nationale pour la Recherche  ( ANR-05-BLAN-0390-02  and  09-BLAN-0127-01 ) and the  Institut National du Cancer (INCa -PL09-194 ). Computing resources were provided by the  Institut du Developpement et des Ressources en Informatique Scientifique (IDRIS) , the  Centre Informatique National de l'Enseignement Superieur (CINES)  and the  Meso-centre de Calcul de l'Universitede Strasbourg. The funders had no role in study design, data collection and analysis, decision to publish, or preparation of the manuscript.
Software projects produce a wealth of data that is leveraged in different tasks and for different purposes: researchers collect project data for building experimental datasets; software programmers reuse code from projects; developers often explore the opportunities for getting involved in the development of a project to gain or offer expertise. Finding relevant projects that suit one needs is however currently challenging with the capabilities of existing search systems. We propose Orion, an integrated search engine architecture that combines information from different types of software repositories from multiple sources to facilitate the construction and execution of advanced search queries. Orion provides a declarative query language that gives to users access to a uniform interface where it transparently integrates different artifacts of project development and maintenance, such as source code information, version control systems metadata, bug tracking systems elements, and metadata on developer activities and interactions extracted from hosting platforms.
I. INTRODUCTION Software programmers, managers, and researchers often have the need to search for software projects for various reasons, such as looking for good pieces of code to reuse, looking for a good project to join, looking for good subjects for analysis, etc. However, their activities are often challenged by the difficulties in identifying appropriate software projects satisfying their needs. For example, in software engineering research, developing evidences to validate one's results often requires empirical evaluation with real-world datasets that are collected on the basis that they hold properties relevant to the evaluation. To this end, researchers usually resort to existing software project repositories where large amounts of data are publicly available for use to answer an enquiry like "what projects produce source code with more than 1,000 test cases and where more than 10,000 bugs have been reported?".
Unfortunately, identifying and collecting such data, while lacking any scientific value, is an obligatory passage which is commonly recognized to be a tedious exercise  [7] -  [9]. Indeed, the dispersion of datasets in various repositories as well as the heterogeneity of their representations complicate extensive analysis of data from multiple sources. Furthermore, extracting knowledge from the large sets of information is challenging as it requires time, computational power, and an understanding of the correlations that exist among the data. Consequently, researchers who undertake to collect software data for their studies usually spend a significant portion of their time searching across different platforms to look for the few software systems that meet their requirements. Simplifying software data collection and manipulation as well as improving navigation across those data may save much research time and yield a positive impact on the strength and the validity of research studies.
The aforementioned challenges also apply to developers and users. For example, a developer wishing to participate in collaborative development projects can hardly determine beforehand which project would benefit the most from his expertise while being a "friendly" environment for him. It is indeed challenging to answer, e. g. , to the question What projects are developed in Ocaml by less than 10 people who have produced over 100,000 lines of code and are still maintaining the code with a high-bug fixing rate? A user in a quest for the "right" software may also experience the frustration of settling for the less relevant ones that web search engines may lead him to. In this work, we propose Orion, a search engine architecture where information extracted from source code, versioning repositories, bug tracking systems, collaborative development platforms, etc.
are merged to build a knowledge database that can easily be queried through a user-friendly language, the Orion DSL. To this end, we have acquired and curated large amounts of data from a number of popular project hosting platforms. We have then defined and isolated a number of software system characteristics and their corresponding development artifacts that we have furthermore linked to enable advanced queries that may span over multiple information sources. Orion combines the data sources and integrates the information so as to allow the linked data to be searched in a unified platform. Related work to ours has mainly focused on making the data readily available by means of centralization  [1] ,  [9] , or aimed at regularly delivering snapshots and statistics on monitored projects  [12].
While these efforts have enabled researchers to more easily study the data globally, they do not expose any new combinations of data to yield richer datasets, nor do they allow for advanced queries across data sources. We extend these work by building a search engine on top of a knowledge database. A more recent work by  Dyer et al. proposes the BOA  [6]  infrastructure for mining software repositories. Their approach however is targeted for computing statistics across software repositories, while Orion aims at facilitating the selection of a set of software projects satisfying various criteria based on properties of their development artifacts (e. g. , source code size, programming languages, bug fix rate, team size, etc. ). BOA only analyzes information available on SourceForge. Our approach however integrates information from various sources including GitHub, Google Code, JIRA, etc.
The main contributions of this paper are as follows: • We discuss the opportunities and challenges in the context of project search and propose the Orion integrated search engine for empowering users, developers and researchers in their quests for relevant software projects. • We explore the design of the Orion system, including the DSL, the mapping of raw data to domain-specific types, and the crawling step of project data for translation into a common format. • We highlight, with a few query examples, the capabilities of our prototype implementation with datasets from a large variety of sources, such as bug reports, source code versioning information, and developer activities, from tens of thousands software projects. We also provide an assessment based on a user-study for estimating the need, the usability and effectiveness of Orion.
The rest of this paper is organized as follows. Section II motivates this work, by illustrating the need for an integrated search engine, and by outlining the challenges that we face in its design. Section III discusses our approach through a presentation of the design of the Orion DSL and an overview of the construction of Orion knowledge database. In Section IV, we propose an assessment of the Orion approach. Finally, Sections V and VI discuss related work and conclude with future work respectively.
A. Search Scenarios A researcher on a quest for datasets. Research fellow Robert is interested in bug localization. To assess his latest approach, he is in need for datasets from several programs with specific development properties:  (1)  The programs must have had a significant number of bugs during their development cycle; (2) the programs should include test cases as, commonly, test cases allow to detect many bugs and thus can be used to replay software faults; (3) finally, to reduce the threats to validity and ensure that his approach can be generalized, Robert is seeking for programs from different software development teams. Unfortunately, this search scenario requires information that is dispersed and may even be hidden in the deep web (e. g. , in the source code). Thus, to retrieve such a set of programs, Robert must visit numerous websites, potentially downloading several software programs that will later be dismissed, before settling for a set of datasets that is smaller than he hoped for or whose development artifacts do not properly fit Robert's goals.
A programmer searching for a good and suitable project to reuse. Mark is a programmer whose latest assignment involves the implementation of a visualization software. He has opted for OpenGL, but for bootstrapping reasons, he is seeking code samples for understanding the internals of the API and potentially for reuse. Mark thus seeks (1) a project dealing with OpenGL, that is (2) still actively maintained and that (3) other people have tested before and contributed with feature requests and bug reports. In addition, Mark has an obligation to (4) respect his company restrictions on licenses. As in the case of the previous scenario, using the traditional approach, this search is challenging. It consists of scanning programmer forums, and visiting several development websites. To address these challenges, we build an extensible and maintenable knowledge database of software projects that will deliver rich query capabilities for users.
This dispersion of data complicates any search that leverages a combination of criteria. Even on hosting platforms, such as GitHub 1  and Freecode 2  , where these information appear together in the project page, they are still not integrated in a way that allows a search using criteria based on multiple information types. 2) Flat Queries: Traditional search engines like the Google TM search engine, index web pages based on the appearance of terms and rely on information retrieval techniques to return query results. Consequently, a project seeker who enters a flat query, e. g. , "project in Ocaml", can only expect search engines to return pages containing the provided keywords without any guarantee that the terms appearing in the pages bear the same meaning as intended by the user. Thus, while having been proven powerful and scalable, current search engines are simply not data aware  [3].
Information Integration The first step for improving the effectiveness of project search should consist in limiting the impact of the heterogeneity of software repositories as well as resolving the difficulties imposed by the dispersion of the data in various locations. Figure  1  illustrates the information types that should be leveraged to process the queries for the previously described search scenarios. We detail in the following the variety of information that are mentioned in the above figure to infer the terms and types that can be used to build the semantics of project search queries: Project metadata: A software project is initiated by an individual/company, often referred to as the owner, and may be supported by an organization (e. g. , the Apache Software Foundation). These types of information are important as they can be used to infer the developing community and the programming and management styles that are prevalent in the project development.