dataesr/scientific-paragraphs-categorization huggingface dataset:
The KaruBioNet network particularly aims to help researchers in their studies related to 'omics' data, but also more general aspects concerning biological data analysis. This transdisciplinary network is a platform for discussion, sharing, training and support between scientists interested in bioinformatics and related fields. Starting from a little archipelago in the Caribbean, we envision to facilitate exchange between other Caribbean partners in the future, knowing that the Caribbean is a region with non-negligible biodiversity which should be preserved and protected. Joining forces with other Caribbean countries or territories would strengthen scientific collaborative impact in the.
Major common themes shared by laboratories The main purpose of this group is to bring together people who share common problems to better collaborate together. The KaruBioNet network aims to improve the development of bioinformatics at the local or regional level for a better understanding and analysis of reallife data. The major common themes shared by laboratories belonging to the network are microbial evolutionary history, antimicrobial resistance, virulence mechanisms, systems biology, genotyping and data science (Fig. 1 ). The KaruBioNet network particularly aims to help researchers in their studies related to metagenomics, proteomics, genomics (or other 'omics'), as well as more general aspects relating to data analysis, integration and interpretation. In order to structure discussions and exchanges between researchers, we have implemented different topics (which could evolve in the future): (i) omics sciences; (ii) artificial intelligence and machine learning; (iii) biochemical analyses; (iv) geographic information systems; (v) databases and software development; (vi) biostatistics; and (vii) epidemiology.
Bacterial pangenomics A ready-to-use workflow is available for Galaxy KaruBioNet users to process a complete analysis of the bacterial pangenome/coregenome. Starting from a collection of strains for which WGS reads are available, the user will be able to process successively analytical steps from raw reads to fully assembled and annotated genomes, and then a comparative genomics analysis to finally obtain both a pangenome matrix image and a Circos  (Krzywinski et al. 2009)  representation of pangenome ready for publication (Fig. 2 ). The first part of the workflow takes advantage of the Galaxy dataset collections to reconstruct and annotate complete individual genomes for each strain (each program will be executed as many times as there are strains to analyze): 1. De novo assembly of Illumina reads with Unicycler  (Wick et al.
, 2017). The second part of the workflow process is linear (each program will be executed only once) and allows the comparison of genomes: 1. Pangenome analysis using Roary  (Page et al. , 2015). 2. Pangenome matrix representation using roary_plots. 3. Core-genome-based phylogeny using FastTree  (Price et al. , 2010). 4. Circular representation of core genes and strain-specific genes positioned on a reference genome, using Circos.
Mycobacterium tuberculosis genomic analyses Tuberculosis (TB) is an infectious disease caused by bacteria belonging to the Mycobacterium tuberculosis complex (MTBC). Interestingly, several Galaxy tools exist to study MTBC strains from available sequence reads or assembled genomes. Resources related to M. tuberculosis were tentatively listed in the MTBCtools list  (Couvin et al. , 2021)  in which tools were classified into several thematic sections/categories such as biological databases, drug resistance or prediction/classification tools. The Galaxy ToolShed (https://toolshed. g2. bx. psu. edu/) contains several TB tools such as Galru  (Page et al. , 2020) , lorikeet spoligotyping  (Cohen et al. , 2015) , Mykrobe  (Hunt et al. , 2019) , SpoTyping  (Xia et al. , 2016)  and TB-Profiler  (Phelan et al.
, 2019). We have recently added MIRUReader  (Tang and Ong, 2020)  to the Galaxy ToolShed. These tools could be used to produce genotyping information such as An example of a workflow to study the genotyping of M. tuberculosis strains and their association with antibiotic resistance would be as follows: (i) users can analyze their sequence reads using the lorikeet spoligotyping program to obtain spoligotypes matching against their reads. Furthermore, they can use TB-Profiler program to determine the drug resistance profile from reads; (ii) they can then use a de novo assembly program such as Shovill (https://github. com/tsee mann/shovill), SPAdes  (Bankevich et al. , 2012)  or Unicycler; and (iii) MIRUReader tool can finally be used to determine 24-loci MIRU-VNTRs profiles from preassembled data.
Simple phylogeny workflow Phylogenetic analyzes are widely used to study biological data and other scientific data. From a Multi-FASTA file, users can perform a multiple alignment using a multiple alignment program such as MAFFT  (Katoh and Standley, 2013). Users can then perform a phylogenetic analysis with a dedicated program such as FastTree, PhyML  (Guindon et al. , 2010)  or RAxML  (Stamatakis, 2014). Note that user-friendly approaches such as Phylogeny. fr or NGPhylogeny. fr (Dereeper et al. , 2008; Lemoine et al. , 2019)  already exist to perform phylogenetic analyses. The phylogenetic trees obtained can be annotated using iTOL (Letunic and Bork, 2021).
Construction of a variant call format file and single nucleotide polymorphism analyses To construct a variant call format file, users can choose the BWA-MEM  (Li, 2014)  tool to map their sequence reads against a reference genome, then they can use Samtools/mpileup to perform a multi-way pileup of variants  (Li et al. , 2009). Finally, they can use the VarScan  (Koboldt et al. , 2012)  program for variant detection. Other Galaxy pipelines such as Snippy (https://github. com/tsee mann/snippy) could be used for single nucleotide polymorphism analyses.
Automated pipeline for the search for resistance, plasmid and virulence genes We have developed a pipeline called catchSequenceInfo that allows us to get resistance, virulence and plasmids, as well as multilocus sequence typing (MLST;  Jolley et al. , 2018)  information from DNA sequences. This tool uses: (i) ABRicate (https://github. com/tsee mann/abricate) with ResFinder  (Zankari et al. , 2012) , PlasmidFinder  (Carattoli et al. , 2014)  and VFDB  (Liu et al. , 2019)  databases to predict resistance, plasmid and virulence genes; as well as (ii) MLST (https://github. com/tseemann/mlst) to get allele IDs and MLST number. catchSequenceInfo is freely available through the Galaxy KaruBioNet instance and it has been placed in the Galaxy ToolShed. Note that the pMLST tool  (Carattoli et al. , 2014)  has also been installed in our Galaxy instance as well as in the ToolShed.
Databases and data warehouses Some developments are ongoing to construct dedicated databases or data warehouses. The SITVIT databases and other resources  (Couvin et al. , 2017 (Couvin et al. , , 2022 (Couvin et al. , , 2019 (Couvin et al. , , 2020;; Demay et al. , 2012)  developed by researchers at the Institut Pasteur de la Guadeloupe have provided a more complete global view of the molecular epidemiology of MTBC for public health surveillance. These resources are available online and may be of use to researchers working specifically on these bacterial organisms. Bacterial pathogens have evolved specific effector proteins to exploit host cell machinery and hijack the immune responses during infection. Dedicated multiprotein complexes, known as secretion systems, secrete these effectors. Type IV secretion systems (T4SS) are specialized adenosine triphosphate-dependent protein complexes used by many bacterial pathogens for the delivery of Type IV Effectors (T4Es) proteins into eukaryotic cells to subvert host cell processes during infection.
To help biologists to identify putative T4Es from bacterial genomes, S4TE2. 0  (Meyer et al. , 2013; Noroy    The following table shows various tools and databases which are available for studying specific aspects of infectious diseases (such as M. tuberculosis genotyping information or Type IV effector proteins; Table  1 ). The links of all these databases developed inside KaruBioNet are available on the website. The development of collaborations will lead to the creation of new databases or to the use of existing databases. The sensitivity of these data (personal data, health data, genetic data, etc. ) requires compliance with European data protection rules (GDPR).
Machine learning and classification problems Knowledge Discovery from Databases (KDD) is the 'non-trivial process of identifying valid, novel, potentially useful, and ultimately understandable patterns in data'  (Fayyad et al. , 1996). Over the last 30 years, advanced prediction methods and tools borrowed to the KDD field, have contributed to defining new kinds of prediction models, namely data-driven models. They consist of looking for correlations between predictive historical variables and output variables. When the output variables are discrete, the problems considered are referred to as 'classification problems'. Figure  3  presents the different steps of a KDD approach. First, it is important to understand the data and the associated context, then a preparation step (also known as preprocessing) is often necessary in order to overcome problems such as missing data, normalization issues, noise reduction or data transformation, and obtain usable data to feed a dedicated model.
Acknowledgements The KaruBioNet network thanks the  Regional Council of Guadeloupe  for its support. We are also thankful to the 'Projet MALIN' consortium (https:// www. projet-malin. fr/). This work was supported by a  FEDER grant  financed by the  EU. Several computational tests have been performed using Wahoo and Exocet, the clusters of the  Centre Commun de Calcul Intensif  ( C3I ) of the  Universit e des Antilles. We are grateful to  Nalin Rastogi  for helpful discussions. We also thank other people interested or involved in the KaruBioNet team:  Raphae ¨l Pasquier ,  Syndia Sadikalay ,  Pauline Dentika ,  Anubis Vega -.
Developing a reference interpreter is valuable independently of debootstrapping: it may help clarify the language semantics, and can be reused for other purposes such as differential testing of the other implementations. Grounding We present Camlboot, our project to debootstrap the OCaml compiler, version. Once we converged on this final design, the last version of Camlboot took about two human-months of implementation effort, demonstrating feasibility. Using diverse double-compilation, we were able to prove the absence of trusting trust attack in the existing bootstrap binaries of the standard OCaml implementation. Importance To our knowledge, this document is the first scholarly discussion of "tailored" debootstrapping for high-level programming languages. Debootstrapping recently grew an active community of free software contributors, but so far the interactions with the programming language research community have been minimal.
Introduction. Bootstrapped language implementations Programming language designers and implementors devote themselves to creating the best possible programming language, and work hard on turning their language into usable software. What language would they use to implement their ideas? Their own programming language, of course! OCaml is implemented in OCaml, Haskell in Haskell, SML in SML, Scala in Scala, Rust in Rust, the list goes on and on. (For a criticism of the "language implementors should eat their own dogfood" trope, see Laurence Tratt's The Bootstrapped Compiler and the Damage Done. ) But then, newcomers ask, how can you run an OCaml program, if you need an OCaml implementation to run the OCaml implementation? This chicken-and-egg problem is solved by a bootstrap: along with the sources of the compiler, we carry a compiled form of the compiler (typically a slightly older version), which is used to build the compiler itself from sources, and we update this bootstrap binary from time to time.
: Reproducible builds have obvious practical benefits: if you distribute binary packages and people don't know if they can trust you, they can compile the software independently and compare the hashes of their binaries with yours, to know for sure that you are distributing the right binaries. However, even when the software is "reproducible" in this sense, this is achieved in most cases by building using an identical build environment provided by the untrusted provider. If the environment itself contains a version of the software you are trying to rebuild, how can you trust your own results? What if the build environment is corrupted? You would reproducibly get the same compromised result. The Bootstrappable Builds project was started in to solve this issue, trying to eliminate opaque binaries from build paths, aiming for a more trustable operating system that can be built from nothing else than source code, first in assembly language, then in increasingly higher-level programming languages.
Different definitions on what is and is not part of source code result in weaker or stronger conditions for an implementation to be free from non-source bootstrap artifacts. See for example this description of the build path of GNU Guix, the software distribution of choice of the Bootstrappable people, described in by Ludovic Courtès [ ]. : which preferably do not include binaries corresponding to programs of the toolchain itself. To avoid any confusion, we will use a bootstrap binary to mean the self-compilation build artifacts, and to debootstrap to mean the act of removing our dependency on bootstrap binaries, to allow a build from sources. A bootstrapped compiler uses a bootstrap binary, a non-bootstrapped or debootstrapped compiler does not. In this paper, we report on our experience producing camlboot, a debootstrapped implementation of the OCaml programming language.
Key metric: human work required to debootstrap If we assume unlimited work resources, tailored debootstrapping is a trivial problem: just port your programming-language implementation to another language that has already been debootstrapped (for example C). But this is a massive effort that may never happen in practice -especially as you have to first convince your language implementors to work in a different programming language. https://github. com/Ekdohibs/camlboot, visited on --.
OCaml. uses a parser generator, ocamlyacc, written in C. The lexer generator, ocamllex, is written in a small fragment of the language; we extended MiniML to cover it. We still had to "debootstrap" the lexer generator by writing by hand a lexer that could lex ocamllex's own input grammar! The two-stage process (a naive interpreter compiled by a naive compiler) introduces massive inefficiencies in the build chain: we are spending computer time to save human time. On a specific build, we measured that running ocamlopt. opt (the OCaml native compiler, compiled with itself) is x faster than interpreting the same ocamlopt compiler using our interp interpreter compiled with minicomp. In Section. we discuss these performance gaps in detail. Yet the whole debootstrapping process runs in human-reasonable time, completing under four hours on a developer machine.
Related work The Bootstrappable Projects website describes heroic efforts to debootstrap various parts of the free-software ecosystem. It relies on GNU Guix (described in by Ludovic Courtès [ ]), an operating system distribution that tracks dependencies in a fine-grained way, providing a tree of packages that rely on as few bootstrap seeds (nonsource forms of programs required to build the system) as possible. Debootstrapping a bootstrapped programming language means that its bootstrap binary can be removed from the build seeds. Guix is itself implemented in GNU Guile [ ], a nice implementation of Scheme attributed to Andy Wingo, Marius Vollmer, Mikael Djurfeldt, Ludovic Courtés, and Jim Blandy, that started in. The Guix, Guile and Scheme community at large are strong contributors to the Bootstrappable effort.
Scheme is a natural choice for debootstrapping, being arguably the simplest programming language in which you might want to write a programming language implementation. It is interesting to look at how other languages have approached debootstrapping. A short summary is that very few of the higher-level languages that have been relying on a bootstrap for a long time have been debootstrapped, a few exceptions being C, Rust and Java (but not Scheme!). OCaml is joining a select group with our work. For C, Rust and Java, the debootstrapped path can build the most recent version of major implementations at the time of writing: gcc , openjdk. , rustc.
This is provided by the TinyCC compiler, itself running on top of Jan Nieuwenhuizen's GNU Mes. Building gcc, or any modern software, also requires various core utilities (patch, sed), GNU Make, and a working Bash implementation. Building those without a modern C compiler is hard! The Guix project was able to remove them from the bootstrapping base by relying on Gash [ ], a Guile implementation of Bash and core utilities attributed to Timothy Sample and Jan Nieuwenhuizen. Scheme Guile is almost debootstrapped. Many necessary pieces are present in the Guile implementation (it has a Scheme interpreter, written in plain Scheme, that can interpret the Guile compiler, and a plain Scheme interpreter in C that can interpret the interpreter), and the Scheme interpreter of GNU mes seems close to be able to run guile.
Summary We found that the approach of writing entirely new implementations for the purpose of debootstrapping is more rarely used -to our knowledge, the only project to have used it before our work is GNU Mes. In the general case, creating a debootstrapped "build path" to a language implementation may require a mix of legacy implementations, bootstrap replay, and new alternative implementations. New implementations written for debootstrapping may in turn become legacy applications if they are not maintained actively -and become incompatible with newer versions of the reference implementation. The build paths : themselves need to be maintained; they can typically be lengthened by adding extra steps to build more recent versions of the reference implementation (for Rust, for example), or shortened by finding alternative, simpler build paths (by improving mrustc or, in our case, interp and minicomp).
There are interesting maintenance challenges, and only time will tell whether the Bootstrappable community can tackle them. Debootstrapping build plans are currently evolving rapidly; for example the livebootstrap project appears to have recently managed a build of bash and make without relying on Gash/Guile. The global picture may be much improved by the time you read this article. But each bootstrapped programming language, OCaml in our case, still needs to be debootstrapped independently from the rest of the software ecosystem. SqueakVM Some programming language implementations share the commonality of being written in their own language, with a small fragment compiled to a preexisting language. One notable example is the Squeak VM, described in by Dan Ingalls, Ted Kaehler, John Maloney, Scott Wallace, and Alan Kay [ ], which was implemented in pure Smalltalk, with its bytecode interpreter written in a simple fragment of Smalltalk designed to be directly translatable to C.
However, this does not suffice to debootstrap the language: the compilation from Smalltalk to its bytecode, which is a more subtle piece of software, remains implemented in full Smalltalk, and requires a pre-existing VM image to run. ⁶ If the Squeak project wanted to use their "simple fragment" for larger part of the implementations -ideally all of it -they would probably want to add higher-level features of Smalltalk to this fragment. This would require a more elaborate compiler from their mini-Smalltalk to C (or some other target language), and would be closer to our design.
The OCaml compiler implementation OCaml has one reference implementation that evolves along with the language itself, and a few alternative implementations that typically reuse some parts of the reference -to compile to JavaScript, etc. The reference implementation provides two compilers: the bytecode compiler ocamlc, and the native compiler ocamlopt. ocamlc produces executables in a custom portable bytecode format, to be executed by the bytecode interpreter ocamlrun. ocamlopt produces native binaries directly, which are more efficient (typically x-x) but not portable, larger and longer to compile. Back in the days of Caml Light, the bytecode was famous for its efficiency (among the fastest functional programming languages, due to its clever support for curried application), but nowadays people exclusively use the native compiler in production.
Executables produced by the bytecode or native compiler link to a runtime, which is a bunch of C code and some assembly that implement low-level features the language relies on, in particular garbage collection. There is a project to partially debootstrap Squeak: SqueakBootstrapper. Bootstrap To bootstrap itself, the OCaml compiler is distributed with bytecode executables for ocamlc (the bytecode compiler) and ocamllex. They can be executed by ocamlrun, which is built from C. To build the compiler from sources they also need to generate an OCaml parser from the yacc grammar, using ocamlyacc built from C. Before building the compiler sources it first needs to build the OCaml standard library, distributed with the compiler and used within the compiler sources. We present in Figure a schematic view of the usual OCaml build plan, using tombstone diagrams (T-diagrams).
c, and then used to turn the source grammar parser. mly -the OCaml grammar -into a. ml file included in the compiler codebase *. ml. Notice the placement of the gcc and ocamlyacc blocks, indicating that the output of gcc is the machine-code (M) program ocamlyacc. The dotted arrows indicate aggregation: several different code files are included jointly, as inputs to a compiler or included in a larger set of code files. In this diagram, both ocamlyacc and ocamllex output files included in the *. ml source files. The full arrows indicate reuse: the same code files are passed as input to several compilers, or that the same interpreter runs several programs. We use the (o :) marker to indicate sources from the standard OCaml distribution, and the red color and (s :) marker to indicate a bootstrap seed -a non-source program required to build the system.
A global view of our debootstrapped build path Our debootstrapped build path is described in Figure. In addition to the previous conventions, we use the blue color and the (c :) symbol to denote our own Camlboot code, and the "mL" language (small "m") to denote ML sources that must stay within the MiniML fragment. The build starts with both gcc and guile as seeds. Some parts of the build path of OCaml can be reused: we build ocamlrun, ocamlyacc and parser. ml the same way. The first change is the construction of the sources of the compiler, more precisely the lexer, which was previously generated by boot/ocamllex. byte. We replace it by the version of ocamllex packaged with the OCaml sources, and compiled by minicomp. There is a difficulty here as well: these sources contain a lexer themselves, so we wrote a lexer by hand oclex/boot.
minibyte. We use it to interpret the ocamlopt compiler. For performance reasons, the first program we compile with this ocamlopt is our interpreter itself (see Section ). ⁹ Then, with this natively compiled interpreter, we interpret ocamlopt again to compile the sources of ocamlc. With the resulting ocamlc. opt compiler, we can finally produce debootstrapped binaries to replace the OCaml bootstrap binaries. (We only represent the build of boot/ocamlc, but boot/ocamllex is rebuilt similarly. ).