dataesr/scientific-paragraphs-categorization huggingface dataset:
THE ORIGINAL JAVA--APPLICATION In this section, we recall the main features of the original implementation of Java--. As stated in the introduction, the goal of this tool is to allow the user to focus on the basic programming concepts, without encumbering the novice student with unnecessary complex constructs. Indeed, the user may write Java code outside of any method body as shown in Fig. 1. 3 In order to appreciate the advantage of using Java--, the code shown in the figure can be compared with the code that a student should have written if Java-was not used, that is, Apart from the fact that the student is exposed since the very beginning with the object-oriented specific syntax of Java, as stated in  (Westfall, 2001)  the above code can even be "harmful to development of objectthinking", since "it communicates virtually nothing about the concept of user-created objects".
On the contrary, the code shown in Fig. 1  turns out to be very similar to the corresponding Python code, that is, When Java--is asked to execute a code, the tool generates a temporary class where it defines the main method and copies all the methods specified by the user. Successively, the temporary class is compiled and executed: the compilation errors are shown in the Errors pane, while the output and/or the execution error are shown in the output pane. The original implementation of Java--also includes a self-assessment module, that allows the student to write methods solving simple programming problems. The behavior of this module is very similar to other tools available on the web, such as, for example, the CodingBat tool  (Parlante, 2011). The distribution of Java--already includes dozens of pre-defined exercises, but new exercises can be easily added by teachers.
On the Value of an IDE Although an IDE is not a strict requirement to develop applications, it surely helps programmers to increase productivity with features like syntax coloring in the editor, compiler and debugger integration, build automation, code completion and easy navigation to definitions, just to mention a few. In an agile  (Martin, 2003)  and test-driven context  (Beck, 2003)  the features of an IDE like Eclipse become an essential requirement. Indeed, languages such as Smalltalk have been tightly coupled with an IDE from the beginning  (Goldberg, 1984). The ability to see the program colored and formatted with different visual styles (e. g. , comments, keywords, strings, etc. ) gives an immediate feedback concerning the syntactic correctness of the program. Moreover, colors and fonts help the programmer to see the structure of the program directly, making it easier to visually separate the parts of the program.
The programming cycle consisting of writing a program with a text editor, saving it, switching to the command line, running the compiler, and, in case of errors, going back to the text editor is surely not productive. The programmer should not realize about errors too late: the IDE should continuously check the program in the background while the programmer is typing in the editor, even if the current file has not been saved yet. The longer it takes to realize that there is an error, the higher the cost in terms of time and mental effort to correct it. For example, the Eclipse Java plugin highlights the parts of the program with errors directly in the editor: it underlines in red only the parts that actually contain the errors; it also puts error markers (with an explicit message) on the left of the editor in correspondence to the lines with errors, and fills the Problem view with all these errors.
Software Technology: Xtext and Xbase As anticipated in Section 1. 2, we chose Xtext as the framework for implementing the Eclipse IDE for Java--. In this section we will provide some implementation details, and further motivate our choice. Xtext allows to start from a library grammar for the implementation of a language, so that one does not have to define the grammar rules for typical language elements such as strings, integers, comments, etc. One of such grammars to start from is Xbase  (Efftinge et al. , 2012) , an extendable and reusable expression language. Xbase integrates tightly with the Java platform and JDT (Eclipse Java development tools). In particular, Xbase reuses the Java type system without modifications, thus, when a language uses Xbase it can automatically and transparently access any Java type.
For these reasons, Xbase makes it straightforward to develop languages with Xtext that need to interoperate with Java, its type system, all the Java libraries and Eclipse JDT. One of the goals of Xbase is to provide an expression language which is not strictly Java, but a version with less "syntactic noise". For instance, types are not required in Xbase expressions if they can be inferred from the context (e. g. , the type of a declared variable can be inferred from the initialization expression). Moreover, in Xbase everything is an expression, even "if", "while" and "switch" statements. Thus, Xbase aims at providing a readable Java-like code which is smaller and more compact like dynamically typed languages, while retaining all the advantages of statically typed language checks. Indeed, the above advanced and clean features of the Xbase expression language have been a drawback for us, since our main goal is to have the Java syntax for expressions and statements (and Java statements should not be used as expressions).
However, we leveraged the complete customizability of Xtext and modified some of the Xbase grammar rules to comply with Java syntax 4. Moreover, we had to customize some other parts of the Xbase implementation. This required some work, but the advantages of reusing the existing Xbase implementation for the Java type system and all the Xbase IDE tooling payed back. Indeed, implementing Java--from scratch with Xtext without Xbase would have surely been much harder, even without having to deal with Java object-oriented features. To the best of our knowledge, Java--is the first project that customizes Xbase (i. e. , its grammar, type system and code generator) in order to be able to deal with Java expression syntax. Summarizing, our implementation provides all the typical Eclipse features: automatic building, error reporting, Outline view, navigation to declarations (e.
g. , variables, parameters, methods) and debugging, just to mention the main ones, mimicking the same features of Eclipse JDT. This means that Java--will make the transition to the complete Java language and its Eclipse integration easier for the students that already got acquainted with our Java--IDE. Our compiler will then generate Java code, that will be compiled by a standard Java compiler. In Eclipse, this will take place transparently: saving a Java--file in an Eclipse project will generate the corresponding Java code, and this will in turn trigger the compilation of the generated Java code by the Eclipse Java compiler.
The IDE Interface In Figure  3  we show a screenshot of the Java--Eclipse IDE (note the complete integration of our tooling with the Eclipse mechanisms, which are basically the same as Eclipse JDT). First of all, in the Eclipse project, the Java--compiler automatically generates Java code into the source folder src-gen; such generation is integrated with the Eclipse building mechanisms: if a Java--file is modified, re-generation is automatically triggered and if a Java--file is removed, the corresponding generated Java file is automatically removed. Error markers are placed on the editor's left ruler, on the corresponding file in the "Project Explorer", and in the "Problems" view (note that warnings are generated as well, just like in Java, e. g. , when a declared variable is not used). Moreover, the regions in the editor corresponding to the errors are underlined (e.
g. , for a type mismatch error like in the screenshot). The "Outline" view on the right reflects the one of Eclipse JDT. Code completion works as well; with that respect, note that the content assist mimics the one of Java: Javadoc comments, if present, are displayed as well. The use of Xbase implies another important feature: when running the generated Java code in debugging mode in Eclipse, we can choose to debug directly the original Java--code (it is always possible to switch between the generated Java code and the original code). In Figure  4  we show a debug session of a Java program generated by our Java--compiler: we have set break points on the Java--file, and the debugger automatically switches to the original Java-code (note also the file names in the thread stack, the "Breakpoint" view and the "Variables" view).
Indeed a well-known problem with implementations which generate Java code is that for debugging, the programmer has to debug the generated code which is usually quite different from the original program; our implementation does not have this drawback. In our opinion, the debugging feature can also be useful, during a lecture, in order to support explanations (usually done by using the whiteboard) of a program execution. For example, in Figure  5  it is shown how the debugger can be used in order to explain that an array variable is a reference variable and, hence, that the equality between two different array variables cannot be established by simply using the == operator. Indeed, in the "Variables" view it is explicitly shown that the two variables a1 and a2 are distinct, even though the elements of the two arrays they refer to are all the same.
Another example of such a "pedagogical" utilization of the debugger is given in Figure  6. In this case, the "Debug" view explicitly shows the activation records corresponding to the five invocations of the recFactorial method, so that it is easier to explain to the students that recursion (and, in general. method invocation) has a "small" price to be paid, that, in certain cases, can be excessively high (just imagine the invocation of recFactorial with a large integer number as argument). Indeed, we think that this usage of the debugging mode of the Java--Eclipse IDE has another advantage: besides supporting the teacher explanation, it may also allow the stu-  dents to get used to the debugger before using it for developing their own programs. Running or debugging the generated Java code can be done using context menus available directly on the original Java--source, as shown in Figure  7.
Self-assessment Tool The original Java--application had some mechanisms for self-assessment. In our implementation such mechanisms can be straightforwardly implemented by relying on JUnit and its integration in Eclipse. The basic idea is that the teacher provides the students with Java--Eclipse projects with: 1. a Java--file where the student implements his/her solution to the requested problem; 2. the solution of the teacher in binary form (so that the student cannot have a look at it); 3. a JUnit testcase that checks whether the output of the student's implementation corresponds to the teacher's implementation. An example is shown in Figure  9. In this example the student must implement the max function in Java--. Note that the student has made a mistake in the implementation, since within the boolean expression of the if statement the code compares the value of the first parameter with the successor of the value of the second parameter.
The JUnit testcase tests the student's implementation with random inputs using the teacher's implementation as the expected output. The student can then see the failed tests (in case of mistakes in the implementation). In our example, it is shown that when the first parameter is 3 and the second parameter is 2, the answer given by the student's code is 2 instead of 3, because of the wrong comparison performed in the control expression of the if statement. Currently, the setup of such projects has to be done manually by the teacher; Eclipse makes such setup easy, but we are working on a more automatic mech- anism for such setup (e. g. , with wizards and Eclipse commands for exporting the teacher's solution in binary form into the student's project).
Implementation Framework Related Work There are other tools for implementing DSLs and IDEs (we refer to  (Pfeiffer and Pichler, 2008)  for a wider comparison). Tools like IMP (The IDE Meta-Tooling Platform)  (Charles et al. , 2009)  and DLTK (Dynamic Languages Toolkit) only deal with IDE features, thus the compiler of the language has to be implemented separately, while Xtext unifies all the implementation phases. TCS (Textual Concrete Syntax)  (Jouault et al. , 2006 ) is similar to Xtext, but with the latter it is easier to describe the abstract and concrete syntax at once, and it is completely open to customization of every part of the generated IDE (besides, TCS seems to be no longer under active development). EMFText  (Heidenreich et al. , 2009) , instead of deriving a metamodel from the grammar, does the opposite, i.
e. , the language to be implemented must be defined in an abstract way using an EMF metamodel. In general, we chose Xtext since it is basically the main standard framework for implementing DSLs in the Eclipse ecosystem, it is continuously supported, and it has a wide community. Moreover, Xtext is continuously evolving, and the main forthcoming features will be the integration in other IDEs (mainly, In-telliJ), and the support for programming on the Web (i. e. , an implementation with Xtext should be easily portable on the Web, allowing programming directly in a browser).
CONCLUSIONS We have described a new IDE for teaching Java following the object-later approach. In particular, by using Xtext, this IDE combines the "structured programming before object oriented programming" teaching paradigm (already implemented in Java--) with all the powerful features available when using the Eclipse IDE. Observe that our IDE also allows to use all Java types, such as, e. g. , the String and the Java collection classes; furthermore, the syntax for types already supports full Java generics, including wildcards. Finally, the syntax of Java--expressions corresponds to the syntax of Java expressions, except for this, super, anonymous classes and Java 8 lambdas. This means that copying Java expressions into a Java--program is allowed (of course, if the original Java expressions rely on specific OO features, like, e.
This is the subject of future work that would allow us to experiment with the functional programming approach as an intermediate step between object-later approach and the OO paradigm. The final step towards full Java would consist in adding anonymous classes and OO Java constructs such as interfaces and classes. This is feasible in Xtext, as proven by the programming language Xtend 5  , but we think that it would not make much sense, since at that point we can directly switch to the full Java programming language and its Eclipse tooling. As hinted in Section 3. 4 we are working on making the creation of self-assessment exercises easier for the teacher. We are also planning to provide a dedicated DSL for such task, again implementing it with Xtext and Xbase. We will take inspiration from similar testing frameworks implemented in Xtext, such as, e.
Background: Estimating the phylogenetic position of bacterial and archaeal organisms by genetic sequence comparisons is considered as the gold-standard in taxonomy. This is also a way to identify the species of origin of the sequence. The quality of the reference database used in such analyses is crucial: the database must reflect the up-to-date bacterial nomenclature and accurately indicate the species of origin of its sequences. Description: leBIBI QBPP is a web tool taking as input a series of nucleotide sequences belonging to one of a set of reference markers (e. g. , SSU rRNA, rpoB, groEL2) and automatically retrieving closely related sequences, aligning them, and performing phylogenetic reconstruction using an approximate maximum likelihood approach. The system returns a set of quality parameters and, if possible, a suggested taxonomic assigment for the input sequences.
The reference databases are extracted from GenBank and present four degrees of stringency, from the "superstringent" degree (one type strain per species) to the loosely parsed degree ("lax" database). A set of one hundred to more than a thousand sequences may be analyzed at a time. The speed of the process has been optimized through careful hardware selection and database design. Conclusion: leBIBI QBPP is a powerful tool helping biologists to position bacterial or archaeal sequence commonly used markers in a phylogeny. It is a diagnostic tool for clinical, industrial and environmental microbiology laboratory, as well as an exploratory tool for more specialized laboratories. Its main advantages, relatively to comparable systems are: i) the use of a broad set of databases covering diverse markers with various degrees of stringency; ii) the use of an approximate Maximum Likelihood approach for phylogenetic reconstruction; iii) a speed compatible with on-line usage; and iv) providing fully documented results to help the user in decision making.
It is prone to variations due to the quality of the reference and of the unknown sequences  [19] , its length and the method used to compute percentages of identity  [20, 21]. The practical use of this species definition was so important that the Clinical and Laboratory Standards Institute has set-up guidelines for the interpretation of 16S sequence identity percentages  [22]. The bioinformatical identification process is basically a comparison of a nucleotide sequence to a database generally involving a BLAST search  [20, 23]  to find the most similar sequences, and returns pairwise alignments and their statistical analysis. BLAST E-value, estimate the level of similarity between sequence pairs but not their evolutionary relatedness  [24, 25]. As the first BLAST hit is often not the nearest phylogenetic neighbor  [26] , this may lead to erroneous species assignment  [27].
To overcome this problem, the RDP (Ribosomal Database Project) uses a naive Bayesian rRNA classifier and returns the most probable genus given an input rRNA sequence  [21]. For a more accurate identification, it uses a sequence match method that finds sequences most similar to a query sequence using a word matching strategy that does not require prior alignment  [28]. This approach seems more accurate than BLAST to find evolutionarily closely related sequences. Taking results of taxonomic identification from molecular sequence data without perspective may be misleading  [29] , especially if the identification procedure is based on raw BLAST identity ratios computed from partial sequence alignments  [20, 25, 26, 30]. As for other organisms, the delineation of prokaryotic species is phylogenetically-based  [31, 32].
For that purpose, it is possible to use on-line tools  [20, 28, [40] [41] [42] , locally installed user-friendly programs  [43, 44]  or more specialized programs like ARB  [45]. Note that a commercial solution including the construction of a phylogenetic tree is also available  [46, 47]. Applications of taxonomic identification tools are diverse, and their number of citations betrays their everyday use in microbiology laboratories. SSU rDNA is of very common use to identify non-cultivated prokaryotes from various sources and has been validated for environmental or clinical specimens  [6, 8, [48] [49] [50] [51] [52]. LSU rDNA (or 23S) is less frequently used, mainly because of amplification difficulties and of the resulting lack of reference sequences in the databases  [53, 54]. Ribosomal DNA is not the only target gene used for identification purposes, and a wide variety of housekeeping genes have been explored for bacterial identification  [55].
The lack of general primers and universal database limits the use of such markers to a genus or a group of species, with the exception of rpoB  [56]. The use of Multi-Locus Sequence Analysis (MLSA) is promoted to get a more precise identification  [57] [58] [59]  but is not practical in diagnostic (clinical, industrial or environmental) laboratory conditions  [60] [61] [62] [63]. The time and cost for a complete genome sequencing and the lack of available general databases limit the use of complete genome based MLSA even if bioinformatics tools are now available  [64, 65]. Improvement of the efficiency of systems for the identification of prokaryotic organisms requires attention to the quality of the sequences in the reference database, the exact labelling of their species of origin, and a rigorous use of the bacterial nomenclature  [20, 41, 42].
More than ten years ago, we developed BIBI, a BioInformatics Bacterial Identification tool  [42]. This tool combines a BLAST search with the alignment of resulting similar sequences, and proposes an identification of the species of origin of the input sequence through phylogenetic reconstruction. The reference databases used by BIBI contain tags for sequences of Type strains, and this improves the accuracy of sequence identification by this system. An SSU-rDNA database as well as a database of various housekeeping gene sequences were developed and used by BIBI's identification pipeline. Since its introduction, the system has evolved to a more sophisticated version called leBIBI, and it has become widely used for identification of Bacteria and Archaea, with about 150,000 identifications annually.
Because the workflow for database construction, the program pipelines and the post-treatment scripts used by BIBI were extensively changed since the publication of the original paper, we present here a completely new version of this webware called leBIBI QBPP. It is an automated system to produce the phylogenetic analysis of the most closely related sequences in the reference database around a query sequence, using a approximate Maximum Likelihood (ML) approach. It delivers also useful quantitative information to deduce the phylogenetic position of the query sequence in a reference phylogeny.
Databases typology The SSU rDNA databases have five "flavors". (i) The "lax" database contains all bacterial and archaeal SSU rDNA sequences of GenBank except those for which no taxonomical information more specific than Bacteria or Archaea is reported. It is very comprehensive but contains a large amount of not fully identified sequences. The coverage of genovars is maximum in the "lax" database. (ii) The "stringent" database contains sequences that are identified at the species level with a valid name according to the bacterial nomenclature. It also contains sequences of type strains of newly described bacteria or archaea, an indication that their names are under consideration for eventual validation. These two databases contain a lot of identical sequences and are rather frequently affected by erroneous species identifications.
(iii) The "TS-stringent" database contains only sequences of type strains (TS), so that newly described or non validly published species may be missing. This database is less susceptible to be contaminated by erroneous species identifications. (iv) The "superstringent" database is a subset of the previous one where only one or a very small number of sequences is retained for each species. The sequences are those labelled in the List of Prokaryotic names with Standing in Nomenclature (LPSN) as reference sequence for a given species. Identification errors are almost absent there, but newly described species or non validly published species are mostly absent. (v) Lastly, the "genus-level" database is a subset of the "superstringent" database containing only one sequence for each genus: the sequence of the TS of the genus type-species.