dataesr/scientific-paragraphs-categorization huggingface dataset:
cbs. umn. edu/CGC). ICeE offers the possibility of updating this list and of importing a custom list of strains from a tab-delimited text file. Many laboratories use proprietary software, such as Filemaker TM to record their strain collections. Most allow data export in a tab-delimited format and so are easily compatible with ICeE. Strains can be picked from a pull-down menu; the first few characters of a strain's name or genotype will be autocompleted to give the user a more and more refined list of the corresponding strains. As individual users may frequently use the same nematode strains, these can be added simply to an easily accessible list of "favorites. " The database entries for strains from the CGC are directly linked to Wormbase; users can access the corresponding Wormbase strain report page with a click (Fig.
1 ). Having chosen the strain, the particular experimental conditions are defined. These include different types of "treatment," such as "chemical exposure. " The details of the chemical treatment, the compound(s) used and their concentration, the time of exposure and the developmental stage can be defined from specific menus. Users have the possibility of adding compounds to the menu. Since researchers frequently apply RNAi to inactivate the expression of specific genes in C. elegans, "RNAi" is included as a possible treatment. RNAi is often performed by feeding nematodes with individual bacterial clones expressing a defined dsRNA. The clones generally come from large collections (e. g. reference 4). The main ones come pre-loaded in the database, and can be updated if required. Otherwise, users also have the possibility of adding their own clones, singly or by importing descriptions of multi-well plates (Fig.
The user is then prompted to add the entire experiment (protocol, conditions, results and comments) to the database. In line with common practices, once an experiment has been entered, it can only be deleted by the database administrator. Users on the other hand can modify entries. In this case, both the original and edited versions are recorded in the database. Figure  1. Initial data entry in ICeE. Screen-grabs of data entry for an imaginary experiment. Having specified a name for the experiment and defining its nature (A), users are prompted to list the strains used, by entering either the strain genotype (B) or strain name (C). In both cases, pull-down lists of strains containing the typed text appear. Once a strain is chosen, its name and details of its genotype appear. (D) For strains that are at the CGC, clicking on the "Strain Report" button links to the relevant strain report page at Wormbase (E).
In the above, we have described the typical sequence for entering an experiment, but ICeE is designed to allow the different elements to be entered in the most appropriate order. Indeed, to upload result files, it is sufficient to have defined the experiment's name. All other details can be added subsequently, and there is the possibility to edit any and all fields up until the point when the experiment is added to the database. Since researchers may perform the same type of experiment repeatedly, an existing experimental protocol can be duplicated as a template for a new experiment, simply by clicking "Insert similar" (Fig. 5 ), alleviating the need to reenter all the experimental details. In this way, data entry becomes increasingly simple and rapid as more types of experimental protocols are included.
Further, once an experiment has been entered into ICeE, users can return to the corresponding entry in the database and add additional files at any time. Thus, for example, having initially entered the raw data, a user can subsequently upload any number of files of data analysis; an initial raw text or CSV data file from the Biosort can be complemented with graphical representations or statistical analyses generated in software such as Open Office TM , or using dedicated tools. 5 Comments can be added to the stored experiment to explain the contents of the different files. In addition to serving as a data repository, ICeE gives users the possibility of performing searches to retrieve experiments and the associated data sets. An intuitive interface provides the possibility of searching globally or in defined fields, using exact or inexact queries.
Discussion The database described here simplifies and rationalizes the storage of disparate electronic data files. While its conception was largely influenced by the needs of a laboratory using C. elegans and a COPAS TM Biosort (see for example, refs. Defining experimental conditions. Screen-grabs of data entry for an imaginary experiment. (A) Having chosen "RNAi" by clicking on the left-hand icon, the user can search for a specific clone within the preloaded libraries. Here, the query "sup-9" returns one clone. The details of the experiment are then added (time of exposure and starting stage). The other icons correspond to (from left to right), exposure to a chemical, infection, wounding, heat-shock and control. For each, dedicated sub-menus appear. (B) Once a treatment has been defined, a summary is shown.
(C) Any number of treatments can be added. In the example here, RNAi treatment is associated with exposure to tunicamycin. 6-10), it is designed to be readily adaptable; the code is Open Source. Currently, ICeE is a stand-alone tool, but it can be integrated into a broader system, for example, with a laboratory information management system (LIMS) to ensure sample traceability (unpublished results). It allows a summary document to be produced automatically and could clearly be modified if minimal reporting standards, such as those used for microarrays and proteomics, become more generally applied, to facilitate submission to the appropriate public data repositories. By default, the metadata and data entered into ICeE is accessible to all users. With the system's search facilities, this means that all members of a laboratory can recall the details and results of any experiment (Fig.
Acknowledgments We thank  J erôme Belougne ,  Frederic Garcia ,  Juliette Hayer ,  Mathilde Pellerin ,  Thierry Molina  and  Eric Vercherat  for their active participation in the elaboration and implementation of ICeE,  Ian Hope  for constructive criticisms, and  Don Moerman ,  Mike Simpson ,  Mark Edgley ,  Angela Miller  as well as members of the  Ewbank lab  for beta-testing.
• Cross references in the object structure are resolved using declarative paths in the Object Grammar. • Complex mappings can be further controlled using predicates. • We show that Object Grammars are both compositional and bidirectional. • We present an interpretative implementation of the general parsing algorithm GLL  [56]. • The entire system is self-describing and bootstrapped within itself. The form of Object Grammars presented in this paper is one of the foundations of Ensō, a new programming system for the definition, composition and interpretation of external DSLs. At the time of writing, Ensō is implemented in the Ruby programming language  [21]. For more information and links to the source code, the reader is referred to http://www. enso-lang. org. This paper extends and revises  [59]  with an extended introduction motivating the design of Object Grammars, additional details on the implementation of Object Grammars in Ensō (Section 5), an additional case-study to evaluate Object Grammars (Section 6), and additional directions for further research (Section 8).
Ensō is self-hosted so that all aspects of the system (models, interpreters) are open for modification and extension. It is not a goal to provide a definitive set of DSLs for building application software. Rather, Ensō is a platform for the creation, adaptation and extension of DSLs, including the foundational languages, like schema and grammar. It is therefore important to realize that the version of Object Grammars in this paper is not aimed at parsing all (existing) languages. The capabilities of Object Grammars as described here represent the current state in the evolution of the Ensō system. Although the concepts to be developed later in this paper are general, the current implementation makes trade-offs that reflect our current needs for defining languages in Ensō. The self-describing aspect of Ensō allows the way the structure of models is described using schemas to be modified if needed, and the same is true of Object Grammars.
Grammars and Models In textual modeling  [44]  models are represented as text, which is easy to create, edit, compare and share. To unlock their semantics, textual models must be parsed into a structure suitable for further processing, such as analysis, (abstract) interpretation or code generation. Many domainspecific models are naturally graph structured. Well-known examples include state machines, work-flow models, petri nets, network topologies, class diagrams and grammars. Nevertheless, traditional approaches to parsing text have focused on tree structures. Context-free grammars, for instance, are conceptually related to algebraic data types. As such, existing work on parsing is naturally predisposed towards expression languages, not modeling languages. To recover a semantic graph structure, textual references have to be resolved in a separate name-analysis phase.
Object Grammars invert this convention, taking the semantic graph structure (the model) rather than the parse tree as the primary artifact. Hence, when a textual model is parsed using an Object Grammar, the result is a graph. Where the traditional tree structure of a context-free grammar can be described by an algebraic data type, the graphs produced by Object Grammars are described by a schema. There is, however, an impedance mismatch between grammars and object-oriented schemas. Grammars describe both syntactic appearance and syntactic tree structure. Schemas, on the other hand, describe semantic graph structures. As a result, any attempt at bridging grammars and models, has to make certain trade-offs to overcome the essential difference between grammars and models. Previous work has suggested the use of one-to-one mappings between context-free grammar productions and schema classes  [1, 71].
However, this leads to tight coupling and synchronization of the two formats. A change to the grammar requires a change to the schema and vice versa. As a result, both grammar and schema have to be written in such a way that this correspondence is satisfied. Another trade-off is concerned with how graph structures are derived from the essentially tree-based grammar. In traditional style parser generators, such as Yacc  [31]  or ANTLR  [49] , the semantic structure is created by writing general purpose code. The flexibility of such semantic actions has the advantage that any desired structure can be created, including graph-like models. However, general purpose code is generally not invertable and as a result constructed trees or graphs cannot be automatically transformed back to text. The language workbench Xtext provides a generic lookup mechanism to resolve references based on globally unique identifiers  [20].
This basic lookup mechanism can be used to automatically derive formatters. However, it also restricts the name resolution rules of a language implemented in Xtext. The lookup rules can be customized by providing name resolution code in Java. However, the semantics of references is then external to the grammar specification itself and bidirectionality is compromised. Object Grammars, on the other hand, allow more flexibility than one-to-one mappings, richer name lookup semantics than, e. g. , Xtext, while still preserving bidirectionality. As such they represent a unique point in the design space, -inspired by earlier work, but motivated by a unique combination of requirements.
For instance, there is no implicit relation between non-terminals and rule alternatives on the one hand, and concepts of the schema (types, fields, etc. ) on the other hand. Additional semantic predicates can be used to further customize the mapping. Asynchronous data binding and predicates promote separation of concerns and loose coupling: the structure of the grammar can be optimized for readable syntax, whereas the structure of the schema can be optimized for conceptual integrity. Finally, to further customize the output of formatting an object graph to text, Object Grammars can be decorated with formatting directives. This set of directives is not aimed at providing complete control over the output, as in general pretty printing frameworks, but are sufficient to produce readable, indented renderings.
Organization This paper is organized as follows. Section 2 introduces Object Grammars from the perspective of how they are used to define the syntax of languages. This provides an overview of the features for mapping text to object graphs, including object construction, field binding, path-based references and predicates. Section 3 describes common language composition scenarios and how they are addressed in Ensō by merging Object Grammars. We identify three use cases for composition, which are illustrated using Object Grammar examples. Section 4 elaborates on how object Grammars (and schemas) are described within their own formalism. Section 5 presents the Object Grammar implementation details. We first elaborate upon the notion of interpetation for executing models. Examples of such model interpreters are parsing, formatting, object graph building, and merging, which are presented in detail.
The section is concluded by detailing the bootstrap process of Ensō. In Section 6 we evaluate the formalism based on how it is used and reused throughout Ensō. An external case-study in domain-specific modeling serves as a separate evaluation benchmark. Related work is surveyed in Section 7. We position Object Grammars in the area of bridging modelware and grammarware and provide pointers to related work on language composition and self-describing systems. Finally, we conclude the paper in Section 8.
Interpretation In contrast to most DSL systems, which are based on code generation, Ensō exclusively uses dynamic interpretation of models. An example is a factory object to interpret a schema to dynamically create objects and assign fields  [41]. Parsing and formatting are no exception and are implemented as (a combination of) interpreters of Object Grammars. These are the three interpreters relevant for the purpose of this paper:  The parse function takes a grammar (compatible with schema S), and a string, and returns a parse tree labeled with constructors and field bindings interpreted in the context of schema S. The build function then interprets the parse tree in terms of the schema S (provided as a first argument), resulting in an object graph conforming to S. Note that build is dependently typed: the value of the first argument determines the type of the result, namely S.
e. , f is true). When a reference is encountered (Ref) the special keyword it is substituted for the name that has been parsed, and the resulting path expression is added to ps. Finally, Code predicates are asserted in the context of the current object using an expression interpreter assert. The fields of ob are assigned so that the expression s. code becomes true. In the second step, the path-based references are resolved in an iterative fix-point process. This is shown in the bottom, right-hand side of Figure  12. The fix-point process ensures that dependencies between references are dynamically discovered. If in the end some of the paths could not be resolved-for instance because of a cyclic dependency-an error is produced.
The object stream represents a cursor over the object graph, containing a single (Stream1) or a collection of objects (StreamN). After formatting, the output stream will consist of sequence of strings and formatting objects (NoSpace, Ident, and Break). This result is then rendered to text in a straightforward way. For rules and non-terminal calls, format recurses to the arg and rule fields, respectively. The formatting symbols are simply added to the output stream; they will be interpreted when the output stream is rendered to text. Code objects do not contribute any output, but might indicate failure, namely when the code expression s. expr evaluates to false in the context of the current object. When encountering an Alt symbol, format tries every alternative with a clean output stream sub, and on first success appends the result to out, and returns true.
In particular, the schema of schemas conforms to itself, so its schema _ class points to itself. Let x L designate the contents of a file x. L, where the file extension L indicates the language of the model, then the following recursive equation captures how Ensō models are loaded: load(x L ) = load gs (x L , load(L grammar ), load(L schema )) (4) Where load gs is defined as: load gs (x L , g, s) = build(parse(g, x L ), factory(s)) (5) Bootstrapping the Ensō system requires computing the fixed point of Equation  4. For instance, to load a state machine model doors. statemachine, we first try to load the statemachine. grammar and statemachine. schema. Then, the input is parsed using the grammar and the result is passed to a factory initialized with the schema. But of course, loading statemachine.
Unlike other systems that do have this goal, such as Rascal  [35] , Object Grammars are targeted solely at defining new DSLs. The cross-linking feature of Object Grammars is also not to be considered as a substitute for full name-analysis of such languages (which is, for instance, the key goal of NaBL  [36] ). As we hope to have shown in the course of this paper, Object Grammars can be used to define practical languages. Both the foundational schema and grammar languages are defined using Object Grammars. In addition, the Ensō system currently features a language for defining GUIs (Stencil), security policies (Auth) and Web applications (Web). The Stencil and Web languages are languages to transform arbitrary Ensō models to a GUI resp. Web interface. Of the current set of languages in Ensō, these languages are most like a ordinary programming language in that they feature control-flow statements and expressions.
The Command language can now be used to create diagrams. A similar extension is realized in the Web language: here a language for XML element structure is mixed with the statement language of Web. The extension works in both directions: XML elements are valid statements, statements are valid XML content. The Piping and Controller languages are from a domain-specific modeling case-study in the domain of piping and instrumentation for the Language Workbench Challenge 2012  [19, 40]. Figure  16  only shows the Controller part which reuses Expr. An overview of the number of non-empty, non-comment source lines of code (SLOC) is shown in Table  2 (a). We show the number for the full languages in Ensō as well as the reused language modules (Command, Expr and XML). A language consists of a schema, a grammar and an interpreter.
This means that the non-terminals of the grammar introduces classes and syntactic categories at the same time. Grammar alternatives are declared by non-terminal "inheritance". As a result, the defined schema is directly tied to the syntactic structure of the grammar. The formalism supports the specification of associations and how they are established in separate sections. The default resolution strategy assumes file-wide unique identifiers, or syntactically hierarchical namespaces. This can be customized by programming if needed. The Textual Concrete Syntax Specification Language (TCSSL) is another formalism to make grammars meta-model-aware  [23]. It features three kinds of syntax rules: CreationRules which function like our [Create] annotations,-SeekRules, which look for existing objects satisfying an identifying criterion,-and SingletonRules, which are like CreationRules, but only create a new object if there is no existing object satisfying a specified criterion.
To our knowledge, Object Grammars represent the first approach to mapping between grammars and meta-models that supports modular combination of languages. Xtext, EMFText, TCS, MontiCore, and TCSSL are implemented using ANTLR. ANTLR's LL(*) algorithm, however, makes true grammar composition impossible. Object Grammars, on the other hand, are compositional due to the use of the general GLL parsing algorithm  [56]. Moreover, the use of a general parsing algorithm has the advantage that there is no restriction on context-free structure. For instance, the designer of a modeling language does not have to worry about whether she can use left-recursion or whether her grammar is within some restricted class of context-free grammars, such as LL(k) or LR(k). As a result, Object Grammars can be structured in a way that is beneficial for resulting structure, without being subservient to a specific parsing algorithm.
Subsequent data exploration and visualization methods can assist to extract meaningful biological information from the data. However, despite the increasing interest in combination perturbation screens, no user friendly open-source program exists that combines statistical analysis, data exploration tools and visualization. Results: We developed TOPS (Tool for Combination Perturbation Screen Analysis), a Java and R-based software tool with a simple graphical user interface that allows the user to import, analyze, filter and plot data from double perturbation screens as well as other compatible data. TOPS was designed in a modular fashion to allow the user to add alternative importers for data formats or custom analysis scripts not covered by the original release. We demonstrate the utility of TOPS on two datasets derived from functional genetic screens using different methods.
Dataset 1 is a gene-drug interaction screen and is based on Luminex xMAP technology. Dataset 2 is a gene-gene short hairpin (sh)RNAi screen exploring the interactions between deubiquitinating enzymes and a number of prominent oncogenes using massive parallel sequencing (MPS). Conclusions: TOPS provides the benchtop scientist with a free toolset to analyze, filter and visualize data from functional genomic gene-gene and gene-drug interaction screens with a flexible interface to accommodate different technologies and analysis algorithms in addition to those already provided here. TOPS is freely available for academic and non-academic users and is released as open source.
Indeed, many cancer mutations can be tested systematically against drugs to uncover selective resistance/sensitivity mechanisms, or against small interfering RNAs to find potential new drug targets  [4] [5] [6]. A pairwise wise interaction screen yields a matrix of interaction (or fitness-) scores. For two non-overlapping sets of perturbations A and B the number of measurements and statistical tests T required to evaluate all unique pairwise combinations is given by: T ¼ A j j Â B j j In practice, the number of data points typically generated is further increased to T x n by the requirement of n replicate measurements. Thus, a screen of, for example, 100 genes against 100 drugs measured in quadruplicate requires 40,000 measurements. A Dataset of this size is usually beyond the limits of what can be conveniently analyzed without the use of dedicated statistics software.
To generate these large datasets, multiplexing strategies greatly improve the throughput of the experiment, by combining genetic perturbations in a single well (multiplexing drug treatments is typically not feasible). A convenient multiplexing strategy is to introduce DNA barcodes into the genome of mutant cell lines such that each genetic perturbation corresponds to a single barcode sequence. In this scenario DNA barcodes act both as unique identifiers for each genetic perturbation and as a proxy for cell number/ fitness. Barcodes can be encoded by short hairpin (sh)RNA sequences themselves or introduced into the genome as non-transcribed DNA sequences using lentiviral vectors  [7, 8]. Practically, a set of barcoded cell lines (A) can then be pooled together and divided into aliquots that are then screened against the second set (B) of perturbations.