dataesr/scientific-paragraphs-categorization huggingface dataset:
Consalvi and V. Saccone (Iannotti et al. , in preparation). Data were aligned on mm10 version of UCSC mouse genome with Tophat2 and quantified with htseq-count. Counts data from all conditions were filtered based on their raw count, keeping only those where the sum of the counts for all samples is higher than 1, then normalized and logged with DESeq2 v. 1. 4. 5 rlog function, and samples were clustered according to the 50% most variable genes with hclust function, using Pearson correlation coefficient as distance and complete as linkage, respectively, in R-3. 1. 0. Histological and immunofluorescence analyses. Muscle cryosections were fixed in 4% paraformaldehyde (Sigma-Aldrich, St. Louis, MO, USA) and stained with Haematoxylin/Eosin solution (Sigma-Aldrich), according to standard procedure.
Fibrosis was measured using Sirius Red staining protocol. Briefly, muscle cryosections were fixed in bouin solution 1 h at 56 °C. Sections were stained in Picro-Sirius red solution for 1 h at RT protected from light. After a brief washing in acidified water, sections were fixed in 100% ethanol and the final dehydration was performed in xylene 100%. Sections were mounted with EUKITT® and visualized using a Nikon Eclipse 90i. Fibrotic index was calculated as the percentage of red positive areas using Image J software. The figures reported are representative of all the examined fields. Statistics. Statistical analysis was performed in GraphPad Prism 7 (GraphPad Software Inc, La Jolla, CA, USA). Comparisons between two groups were tested using an unpaired t-test. Comparisons between multiple groups were tested using one-way ANOVA and Bonferroni post hoc tests.
Acknowledgements This work was supported by  NIH   P30  pilot grant  P30AR061303  and  CIRM  training grant  TG2-01162  to B. M. ;  NIH  grants  R01AR056712 ,  R01AR052779 ,  P30AR061303 ,  MDA ,  AFM  and EPIGEN grant to P. L. P. ; C. N. was the recipient of an EPIGEN travel fellowship for training of young scientists in foreign laboratories. We thank  Emanuela Aleo  at the  Institute of Applied Genomics in Udine, Italy , for the RNA-seq library preparation and sequencing; Sonal Naik at  Sanford Consortium for Regenerative Medicine in La Jolla, CA , for the assistance with the Fluidigm microfluidic platform for single cell gene expression experiments;  Yoav Altman  for flow cytometry related discussions and advice;  Simon Melov  and  James Flynn  for preliminary analysis;  Buddy Charbono ,  Tomi Omel ,  Elizabeth Chappell ,  Diana Sandoval  and  Andy Vasquez  from the  Animal Facility at the SBP , and  Alessandra Dall'Agnese  and  Tom Roberts  for critical discussion.
Data availability RNA-seq data supporting the findings of this study have been deposited in the GEO data repository under the accession code GSE100474. Other data that support the findings of this study are available under the accession codes GSM1223640, GSM1223641, GSM521651, GSM2500874, GSM2500875, GSM2500876, GSM2067698, GSM2067699, GSM2067700, SRR7075694, SRR7075695, SRR7075698, SRR7075699, SRR7075704, SRR7075705, SRR7075706, SRR7075707, SRR7075708, SRR7075709, SRR7075710, SRR7075711.
Orr-Sommerfeld solver To compare the Navier-Stokes solution with the predictions of our linear instability model beyond asymptotics, we have written a simple Matlab solver for the Orr-Sommerfeld eigenvalue problem. The base velocity profile is taken from the interactive boundary layer computations, and the Orr-Sommerfeld problem is solved indepentently as desired for each value of x, k, and t. The y P variable is again truncated at L y P = 64, by using artificial boundary conditions ω(L y P ) = 0 and φ (L y P ) + kν 1/2 φ(L y P ) = 0, which follow from the reconnection with a potential solution at large y P. A second order finite differences scheme is used for spatial discretization, written using sparse matrices for efficiency, which leads to a complex, non-symmetric eigenvalue problem. The six eigenvalues with largest imaginary part are solved for using the Matlab function "eigs", which relies on implicitly restarted Arnoldi method from Arpack.
B. 3. Orr-Sommerfeld solver To validate the Matlab code used to compute Orr-Sommerfeld eigenvalues, we use the Blasius boundary layer as a test case. The obtained marginal stability curve (Fig. 15 ) is in good agreement with Fig. 16. 11 provided by  Schlichting (1979). As the dipole approaches the wall (Fig. 16 , middle), the pressure gradient along the wall becomes more intense and steeper, which causes a strong inward diffusion of vorticity at the wall, as well as increased vorticity gradients within the boundary layer. At time t = 50, we still observe convergence of the Navier-Stokes solution at high Reynolds number towards the Euler flow in the bulk and towards the Prandtl flow in the boundary layer. However, looking at the boundary vorticity (Fig. 18 , top, right) reveals a larger difference between Prandtl and Navier-Stokes flows than at t = 30.
Acknowledgements The authors would like to thank  Claude Bardos ,  David Gérard-Varet ,  Helena Nussenzveig Lopes, Milton Lopes Filho , and especially  Stephen Cowley  for important discussions. RNVY thanks the  Humboldt Foundation  for supporting his research by a postdoctoral fellowship. MF and KS acknowledge support by the  French Research Federation for Fusion Studies  within the framework of the  European Fusion Development Agreement (EFDA).
Introduction The idea for this project comes from our experience with the XMM-Newton  [1]  database interface which we are operating in Strasbourg. XMM-Newton is an X-ray space observatory orbiting since 2000 and working in pointed observation mode. Observations are requested by guest observers who get proprietary access to the data over one year. After this period, the data are made public. Every year or so, all data are compiled in a catalog  [2]  merging all source detections and linking them with other scientific products. The whole catalog is accessible through different interfaces, among those is the XCatDB  [3]  deployed in Strasbourg by the XMM-Newton Science Survey Consortium. In addition to source parameters, XCatDB users can take advantage of accessing technical data such as filter responses, energy band definitions and so on and so forth.
Providing Users with a Rich Contextual Help Scientific data products provided with the XMM-Newton catalog do not contain any significant information about the instruments or the data reduction process. This information is available in separate e-mail: laurent. michel@astro. unistra. fr ORCID: 0000-0001-5702-0019 Figure  1. Implementation concept: the left scrolling list is a partial screen shot of the actual XCatDB interface; it contains all catalog columns available for filtering data. The search engine is invoked after some user action on a list item, to look for information related to that keyword within the documentation. technical documents, Web pages or scientific papers. Our purpose is to make this ancillary data available on demand from the XCatDB interface. For instance, a user selecting sources detected with a given filter might be interested in knowing more about the response curve of that filter (fig.
1 ). The most basic way to proceed would be to put links to those documents somewhere. However this wouldn't help the user get information focused on what he/she is doing. A more advanced possibility would be to extract by-hand information of interest and to feed tooltips  1. This is an interesting solution, but with one major drawback: compiling by-hand such a data corpus is a big and expert job which is to big for our team. The solution we are exploring here is based on the use of a search engine, à la Google, running on a limited text corpus. The user could trigger search queries from different locations on the database user interface. Queries would be automatically setup according to the current users action. What would be returned is a selection of relevant text fragments displayed in their original context, while keeping access to the whole document.
Component Breakdown This project, achieved in the frame of a student internship, is a pathfinder project. It is split into independent modules, listed below, and intended to be put together after validation: • Gathering a corpus of relevant texts • Building an indexer enable to process the whole corpus • Building a rendering tool providing entry points in the corpus from the text fragments found by the search engine • Connecting these modules to the database interface. This last step has not been achieved during this work. This is a critical point. All interesting entities must be described in various aspects (definition, calibration description,. ), but the documents must be close enough to the main topic in order not to pollute the results with irrelevant data. On the other hand it must be rich enough to provide non-trivial information.
The Search Engine A text corpus limited to a few tens of documents does not require high computing performance neither for the index storage nor for the query processing. Assuming we do not need specific features, we choose Elasticsearch  [4] , one of the most popular NOSQL database engine. The installation is easy and the tool comes with a convenient Web interface helpful to check both data ingestion and indexation. It also offers a powerful query language. Basically, Elasticsearch ingests text fragments formatted in JSON. Queries return those messages, still on JSON, matching at best the query. Elasticsearch is schema-free; there is no constraint on the JSON keys present in the ingested messages. Indexes are created for all keys of all ingested messages. Specific types (numerical, text, enumeration,.
PDF Fragmentation PDF is a printer format that maintains the same layout (paging, text location, font, colors,. ) for any device (screen, mobile, printer. ) but ignores the text structure. In fact, extracting text elements from a PDF document is akin to a data mining task more than a parsing task. We were using Grobid  [5]  to achieve this. Grobid is a machine learning tool enable to convert PDF documents into TEI files  [6]. Grobid algorithm relies on knowledge bases built from large document samples. This tool is at the heart of the Science Miner project  [7]. We had to patch the Grobid code to extract data of interest before the TEI generation. Our Grobid version returns a list of text fragments with their natures (section, title,. ) and their exact locations (page number and coordinate within the page).
Rendering Tool Before connecting the search engine to the database interface, we built a Web application to validate the queries and to test different layouts for displaying searched results (Fig  3 ). Searched keywords are typed by the user on the top left search bar. A few buttons are available to setup both query and display. The fragments returned by Elasticsearch are listed below the search bar either ranked by relevance or grouped by documents. On the top of each fragment is an anchor running the display, on the right panel, of the whole text scrolled down to the fragment location. PDF files are displayed by the Mozilla Javascript library PDF. js  [9]. The Javascript code has been patched to open the text at the requested position and to highlight all searched keywords. HTML files are displayed in a simple frame.
Rough Test The initial scope of the project, connecting any meta data displayed on the screen with the search engine, has been limited to the 332 XMM catalog keywords. The reason for this restriction is that the catalog is the main resource exposed by the XCatDB. Catalog quantities are used to both filter scientific queries and to provide additional data to the searched results. We expect that users will be first interested in knowing more about these quantities. To get an idea of the system efficiency, we first submitted all column names to the search engine. The success rate is given in the table below. Although not satisfactory, these results are not that bad. We skip the cases returning either confusing responses or just text fragments mentioning the keyword without further explanation.
Conclusion Our pathfinder project validates the concept of a service that allows access to documentation from a database interface through a search engine. However, it showed the necessity of having an interface between the database metadata and the search engine. This will be the last step before any deployment on a production system. In addition to the XMM catalog, we operated it on the 13,000 Vizier [10] catalogue descriptors and on the IVOA [11] standard corpus with interesting results. This shows that our system could be transposed in other contexts than the XMM catalogue.
, 2014). We use a strategy of contextual reasoning to obtain succinct input and flexible output. The output programs can be specialised to various languages, such as the KaSim flavour of κ  (Danos et al. , 2007; Krivine and Feret, 2017 ), BioNetGen's BioNetGen Language (BNGL)  (Blinov et al. , 2004; Harris et al. , 2016) , other representations such as Synthetic Biology Open Language (SBOL)  (Galdzicki et al. , 2014)  or indeed whichever form is required by robotic laboratory equipment that assembles circuits in vitro. This output flexibility is accomplished using templates that use facts derived by inference rules  (Berners-Lee, 2005 ) from the input model; input terms have meaning defined in terms of inference rules. Figure  1 : High-level data flow through the compiler. The compiler for synthetic gene circuits takes a model description written in GCDL and, using language-appropriate appropriate templates, creates code for simulation and laboratory assembly.
We have implemented templates for annotated-κ for the KaSim software, and envision similar for the BNGL as well as SBOL. There are several reasons to automate the construction of simulation programs for complex genetic circuits over and above the huge design space and associated uncertainties. Writing these programs by hand is timeconsuming and error prone, and there are very few tools available for verification and debugging them. Descriptions of models in terms of simulation code are necessarily tightly coupled to the interpreter of the simulation program's language. This means that using a different interpreter or even different hardware is not possible. We solve these problems by providing a high-level, modular, implementationindependent language for describing gene circuits. Code generation from this high-level description to a low-level language for simulation greatly reduces the scope for error in coding simulations.
If the difference between these representations is large enough and relevant enough to justify the extra computation involved with a larger rule-set, compiler output can be instructed to use different templates. In this way simulations can be tuned to focus the questions of biological interest, abstractions chosen such that more detailed modelling is done where necessary and relevant, and those parts that are uninteresting can simply be appropriately approximated. We now proceed as follows. In Section 2 we give an overview of those aspects of synthetic biology and genetic engineering that are necessary to contextualise our work. Next, in Section 3, we explain the representation of this kind of genetic circuit model in GCDL, this is the main input to the compiler. In order to understand the de-sired output of the compiler, in Section 4 we show how these constructs are represented as rule-based code for the κ language simulator, KaSim.
Biological Parts and Annotation For efficiency, and economy of representation, a computational model should include minimum information necessary for simulation. However, in order to use these models in an automated design process, additional metadata, or annotations, about the meaning of different modelling entities is needed  (Neal et al. , 2014). One might wish to draw specific parts from a database such as the Virtual Parts Repository  (Misirli et al. , 2014). These models are annotated with machine-readable metadata to facilitate their combination into larger models and thereby rendering large parts of the design space for biological systems amenable to automation. Furthermore, Myers and his colleagues have used annotations to derive simulatable models from descriptions of genetic circuits  (Roehner et al.
The use of URIs  (Masinter et al. , 2005)  which can be dereferenced to obtain the required information means that information from different web-accessible databases can be obtained, mixed and matched as desired. The second desideratum is assisted by the use of URIs, albeit with some well-known caveats  (Halpin et al. , 2010). The first and last of the desired features are, therefore, primarily what concerns us in this paper. To begin with, we suggest (but do not require) the use of Turtle  (Prud'hommeaux and Carothers, 2014)  or indeed Notation3 (Berners-Lee, 2005) as the concrete surface syntax for writing models. This goes some way towards a representation that is intelligible by humans. Even then, we aim to minimise what needs to be written and we do this using inference rules -if a needed fact can be derived from the model under the provided rule-set, it is unnecessary to write it explicitly in the model.
That term implies the corresponding skos:prefLabel by means of inference rules supplied with the gcc vocabulary. Importantly, and following the practice in our previous paper on rule annotation  (Misirli et al. , 2015) , a weak identity assertion is made with identifiers in external databases for the parts. This uses bqbiol:is instead of owl:sameAs because the strong Leibniz identity semantics of the latter can yield unwanted inferences when terms are not used perfectly rigorously  (Halpin et al. , 2010). This weaker identify assertion permits the identification of the :P0010 in the example with the identifier for the protein in the well-known UniProt (Consortium  A part will typically have associated rate data. These rates characterise the interaction of the part with RNA polymerase and the production of the corresponding RNA and the RNA's interaction with a ribosome to produce proteins.
Output Representations We now consider the form of the output representation. By using different templates, the compiler can produce output in different languages. We focus on rule-based representations here and use the language of the KaSim simulator  (Krivine and Feret, 2017)  for concrete illustration as it is widely adopted for stochastic simulation of rule-based models  (Wilson-Kanamori et al. , 2015). The rule-based modelling approach is merely outlined here and follows that used in KBBF  (Wilson-Kanamori et al. , 2015)  closely. We stress that the though output as executable program in the KaSim language is demonstrated here, alternative rule-based representations like BioNetGen are equally possible as are descriptions in a language like SBOL as input to an experimental process in the laboratory.
Semantic Inference The input from the user is the model description in the high-level language as described in Section 3. This description uses terms from, and makes reference to the gcc and rbmo vocabularies. The meaning of these terms, in the context of deriving an equivalent version of the program in the low-level language, is given by the companion inference rules. This is a somewhat subtle concept so let us illustrate what it means. Consider the statement, :R0040a a rbmc:Operator. This statement gives the type of :R0040a as rbmc:Operator. The implications of this statement allows to identify the correct template to use for this part, found from information provided by the gcc vocabulary. Indeed, as a background fact, we are told that or in other words that an rbmc:Operator corresponds to the template rbmt:operator.
Internal Representation The output of the first stage of the compiler contains all the information necessary to completely describe the output, but it is not in a convenient form for providing to the template rendering engine. In our case the implementation language for the compiler is in Python and the chosen rendering engine is Jinja2  (Ronacher, 2008). This means that the appropriate data-structure is a dictionary or associative list that can be processed natively by these tools without need of external library. The required internal representation is built up by querying the in-memory RDF storage for the specific information required by the templates. Our implementation does not require modification when new terms are added to the vocabulary and templates. Suppose that a new kind of part is invented.
Template Substitution The templates that produce the bulk of the low-level output are written in the well-known Jinja2 language. This language is commonly used for the server-side generation of web pages. KaSim or BNGL programs are not web pages but they are text documents and Jinja2 is well suited to generating them. It has a notion of inclusion and inheritance that is useful for handling the variations among the different kinds of parts, which typically differ in the rules for one or two of the interactions in which they participate with the others being identical. A full description of the facilities provided by Jinja2 is beyond the scope of this paper, but a flavour is given in Figure  14  which shows an example of a template for a generic part (not having specific functionality like a promoter or operator might) demonstrating substitution of the name variable derived from annotation, and include statements referencing several other templates, one of which is reproduced and shows the actual KaSim code that is produced.
Derivation of Declarations The KaSim language requires forward declaration of the type signatures of agents. This is by design  (Feret and Krivine, 2015)  so that the simulator can check that agents are correctly used where they appear in patterns in the rules. While this design choice can help a modeller that is writing a simulation program in the low-level language by hand, to assist in finding mistakes and typographical errors, it is not possible to know a priori what these declarations should be in the present context. The correct declarations for DNA, RNA and Protein depend on the complete set of parts that make up the model so their correct declarations cannot be known in any template for an individual part. To solve this issue, the compiler implements a post-processing step. The rules that are produced by instantiating the templates for each part are concatenated together with any explicitly written rules that are to be included and then the whole is parsed.
To generate circuits, we use a library of parts from a database that have their rates and other characteristics specified as outlined above. A large class of circuits can be immediately eliminated -those that are ill-formed. We use a Pedersen-style grammar  (Pedersen and Phillips, 2009)  to only generate well-formed circuits. We begin with an arbitrary circuit, perhaps one that is thought to implement a function that is in some way similar to the desired one, or perhaps one that is completely arbitrary. The circuit is then simulated enough times to obtain a distribution of (input, output) pairs -recall that the model is necessarily stochastic. Now substitute one part in the circuit with a different part of the same type from the library and simulate that. If the (empirically) expected result is closer to the specification, adopt the new circuit as the best candidate.