dataesr/scientific-paragraphs-categorization huggingface dataset:
MS2 affinity purification couples with RNA sequencing (MAPS) The MAPS was performed as described before  [19, 43, 44]. The rne131 background was used to maximize target recovery. Cells grown in the LB medium were harvested at OD 600nm = 0. 5 and 1. 0 following induction of either pBAD-micF or pBAD-MS2-micF expression with 0. 1% arabinose for 15 min. Raw data was analysed as described previously, with the only modification being that due to the low quality of reads in the R2 sequencing dataset, analysis was done single-ended using R1  [43, 44]. Selection of the putative targets was done according to the following cut-offs: RNAs with >25 reads (before normalization) and a ratio ≥3 were selected. Among these, only the RNAs with >50 reads (before normalization) and a ratio of <6. 5 in the pBAD-MS2 control were selected (Supplementary Data Table  S4 ).
GalaxyProject  [45]  and UCSC Microbial Genome Browser  [46]  were used to analyse and visualize the data. MS2-micF GEO accession number is GSE113584. MS2-control was previously published with GEO accession number GSE67606  [47]. For MS2 affinity purification, followed by Northern blot analysis in different backgrounds (WT, ΔgcvB, hfq Y25D), cells were harvested at OD 600nm = 2. 0. Input samples were taken prior to any manipulation of the culture. The output samples result from MS2 affinity purification. RNA was analysed by Northern blot as described below. β-Galactosidase assays β-Galactosidase assays were performed as described previously  [48]. Cells from overnight cultures were diluted 1/ 1000 in 50 ml fresh medium and grown at 37°C with agitation. Antibiotics were used at appropriate concentrations when required.
Statistical analyses The number of biological replicates (N) is indicated for each experiment in figure caption. When applicable, statistical analyses were performed using an unpaired two-tailed Student's t test or a two-way ANOVA multiple-comparison test (adjusted P value) on the GraphPad Prism 9 software, as detailed in each figure caption. For all experiments, P < 0. 05 was considered statistically significant. Specific P values are indicated in the figure caption of each experiment, when applicable.
Acknowledgments We thank  Jörg Vogel ,  Maude Guillier ,  Cari Vanderpool ,  Jingyi Fei  and  Karine Prévost  for useful comments and discussions. M-CC is grateful for the financial support received from the  Natural Sciences and Engineering Research Council of Canada (NSERC)  and from the  Fonds de Recherche du Québec -Nature  et technologies (FRQ-NT) during her PhD. This work was funded by an operating grant BMB 389354 from the  Canadian Institutes of Health Research (CIHR)  to EM.
Data Availability Galaxy is an open source, community-driven and web-based platform accessible at https://usegalaxy. org/ and can be found in a GitHub repository (https://github. com/galaxyproject). The UCSC Microbial Genome Browser is a web-based genome browser hosted by the University of California, Santa Cruz (http://microbes. ucsc. edu/). MicF MAPS data has been deposited to the NCBI Gene Expression Omnibus (GEO) under the accession number GSE113584 (token for reviewers: mpifekaarjsrpsx). MS2-control MAPS data is available on the NCBI Gene Expression Omnibus (GEO) under the accession number GSE67606.
In Section 3 we provide background on code reuse in SPL implementation, then, in Section 4, we motivate and discuss the VM design decisions. We formulate the VM concept as an extension of the standard concept of module for Java-like (i. e. , object-oriented, class-based and strongly typed) languages. To support variability, VMs employ delta-oriented programming (DOP) -see  Schaefer et al. (2010)  and  (Apel et al. , 2013, Sect. 6. 6. 1). Specifically, we contribute (i) a theoretical foundation of VMs, including formal syntax and semantics, in terms of a core calculus; and (ii) an implementation of VMs as an extension of the ABS language  (Hähnle, 2013; Johnsen et al. , 2010). We choose ABS because it features native implementations of DOP and it was successfully used in industrial case studies for variability modeling  (Kamburjan et al.
Introducing variability modules We illustrate variability modules and how they support variant interoperability by way of an example based on the industrial FormbaR case study from railway engineering  (Kamburjan et al. , 2018). 1 We look at the full FormbaR case study during VM evaluation in Section 11. Our scenario contains signals, switches, interlocking systems, that use multiple variants of signals and switches, and a railway station that uses multiple variants of interlocking systems. Fig. 1  shows the feature models for switches and signals. Feature models  (Czarnecki and Eisenecker, 2000)  specify software variants in terms of features. A feature is a name representing some functionality, a set of features is called a configuration, and each variant is identified by a valid configuration (called a product, for short).
Line 9 contains an open product definition for the VM Signal. It is worth observing that open product definitions enable implementing different variants of the VM InterlockingSys even without using deltas. Method testSig of class CILS instantiates classes from two different product variants of Switches and from two different product variants of Signals. All references to nonunique imported classes/interfaces specify a product, by using a with clause. In a with clause, the product can be specified by explicitly listing its features, by using one of the defined product names, or (more generally) by a set-theoretic expression. For example, track is taken from product {Mechanic} of module Switches, while sigNormal uses the product name LSig imported from Signals. In line 19 a switch is added to a track element: since track contains a reference to an instance of the mechanic variant of class CTrack, appendSwitch() will add a mechanic switch.
Code reuse in SPL implementation The example in Section 2 illustrates how DOP supports SPL implementation, and how VMs support both interoperable variants and MPLs. Before we continue with the formalization of VMs, let us briefly recall the bigger picture in software product line engineering as far as code reuse in feature-oriented SPL implementation is concerned. In software product line engineering one aims to develop a family of similar programs, called variants, by managed reuse  (Clements and Northrop, 2001; Pohl et al. , 2005). In featureoriented SPLs  (Apel et al. , 2013)  this amounts to: (i) From the problem space perspective, each variant of an SPL is identified by a set of features, called a product; (ii) from the solution space perspective, code reuse mechanisms for variant implementations have to be flexible enough to capture commonalities in the variants and to realize the desired variants  (Schaefer et al.
, 2012). Consider, for instance, the SPL for signals in Section 2: (i) Concerning the problem space, it has n features and m products; (ii) concerning the solution space, it has programs written in a Javalike language as variants, where each variant represents a signal by means of an interface ISig, which is the same for all variants, and a class, which is different in each variant. A straightforward, but naive, approach to SPL implementation provides the code of all m variants within the same program. Then the SPL for signals is implemented as a program comprising the interface ISig and m classes CSig1,. , CSigm (one for each product). This approach, however, has several issues: 1. The code reuse mechanism of a Java-like implementation language might not be flexible enough to capture commonalities in the variants, so some code might be duplicated.
In particular, the rigidity of class-based inheritance (code reuse can be realized only within a class hierarchy  Mikhajlov and Sekerinski, 1998; Ducasse et al. , 2006)  puts limitations on the reuse of code across variants. 2. Java-like languages possess no construct to explicitly capture the relation between the problem and the solution spaces. To document the relation between features and variants, and to support automatic variant generation, ad hoc external tool support must be added. 3. The approach does not scale: recall that an SPL with n features can have up to m = 2 n products, thus up to 2 n classes CSigi must be defined. Using a Java-like language featuring flexible code reuse mechanisms (for example, traits  (Schärli et al. , 2003; Ducasse et al. , 2006)   2  or the constructs of the JIGSAW framework  (Bracha, 1992)  3 ) addresses the first issue, but not the remaining ones.
To address the second and third issue, programming constructs specifically designed for inter-product (i. e. , across different variants) code reuse have been developed. Following  Schaefer et al. (2012) , we classify programming constructs dedicated to inter-product code reuse into three approaches. First, the annotative approach expresses negative variability: code is marked with those features of an SPL it implements and a variant is obtained by excluding code associated with non-selected features. An example of the annotative approach is CIDE  (Kästner et al. , 2012a). Second, the compositional approach expresses positive variability: variants are built by composing code fragments that implement specific features. A prominent instance is feature-oriented programming (FOP), for example  Batory et al.
, 2014a). Remark 1  (Inter-and Intra-Product Code Reuse in ABS). The original version of the ABS language  (Hähnle, 2013; Johnsen et al. , 2010)  has deltas as a construct for inter-product code reuse and no construct for intra-product code reuse: we refer to this version of ABS as Delta-ABS. Hence, in some Delta-ABS case studies code duplication within the same variant was present. A notable case of a Delta-ABS model with duplicated code is the first version of the FormbaR case study  (Kamburjan and Hähnle, 2016) , where each infrastructure element (for example, a signal) is modeled by a class and (since different variants of the same infrastructure element need to coexist) a separate class is declared for each variant of an infrastructure element. Certain code is duplicated across all variants, for example, the code for a method that models the end of a train passing through an infrastructure element is duplicated in three out of five classes present.
A more recent ABS version  (Damiani et al. , 2017a)  added traits for intra-product code reuse to Delta-ABS: we refer to that ABS version with Delta-Trait-ABS. The second version of the FormbaR case study  (Kamburjan et al. , 2018) , implemented in Delta-Trait-ABS, saves duplicated code by using traits, resulting in 40% fewer lines of code on the named infrastructure alone. The second and third issue noted above, however, are not addressed with traits. To the best of our knowledge, no programming construct for implementing interoperable variants overcomes the second and third issue discussed above. VMs address all three issues and provide proper support for MPLs as well as variant interoperability. In Section 11 we present a refactored version of the FormbaR case study based on VMs. subsequently formulated in a Java-like setting by various authors  (Smith and Drossopoulou, 2005; Nierstrasz et al.
Different variants of the same VM can co-exist and cooperate via unique classes/interfaces. For instance, in the railway station MPL of Section 2, all interfaces are unique and all classes are not unique (which is a common pattern). Then, in line 22 of Fig. 4 , an instance of class CSig in the variant of VM Signal for product {Light} receives an invocation of method eqAspect that declares an argument of type Signal takes as parameter an instance of CSig in the variant of Signal for product {Form}. Variant interdependence. The code of a variant of a VM M 1 can depend on the code of a variant of a VM M 2 (and possibly vice versa). I. e. , the code of M 1 refers to unique classes/interfaces of M 2 (via with-free-dependencies) or to classes/interfaces of a specific variant of M 2 (via with-dependencies).
For all VMs M, M 1 , M 2 ∈ dom(FPrgS), classes/interfaces N ∈ dom(FPrgS(M)), interfaces I i ∈ dom(FPrgS(M i )) (i ∈ {1, 2}): if M. N <: M 1. I 1 and M. N <: M 2. I 2 then for each attribute a ∈ dom(FPrgS(M 1 )(I 1 )) ∩ dom(FPrgS(M 2 )(I 2 )) we have FPrgS(M 1 )(I 1 )(a)=FPrgS(M 2 )(I 2 )(a). An ABS-VM program PrgS is type uniform iff fsig(PrgS) is type uniform. Type uniformity of a program can be checked by inspecting its family signature. Example 5 (Type Uniformity). Consider the program Prg in Fig. 10. The code is type uniform and the program signature fsig(Prg) = FPrgS is such that: FPrgS(M)(export) = ∅ FPrgS(M)(import) = ∅ FPrgS(I)(super) = ∅ FPrgS(J)(super) = {M. I} FPrgS(J)(m) = {() → Unit} The program looses type uniformity, for example, if one adds the code below to module M.
Integration into the ABS tool chain We implemented the VM concept as part of the ABS compiler tool chain with the exception of open product definitions, currently under development. The implementation, together with all case studies and test cases, is available as an open source extension of the ABS compiler. 12 The README file in the repository describes how to access the case studies. To integrate VMs into the ABS compiler tool chain, only the frontend (parser and preprocessor) needed to be changed. This is, because flattening (Section 7. 2) produces variability-free ABS code, keeping ABS code generation and semantic analysis (type checking of single variants) as is. The ABS parser's grammar is extended with the constructs described in Section 5. As expected, ABS's existing delta application mechanism, including original calls, could be fully reused.
Several sanity conditions, specifically those concerned with export and import clauses, boil down to simple checks once normal form is established. The SAT sanity conditions are solved using the Choco 13 solver, which is included in the ABS tool chain and used there already for the µTVL  (Clarke et al. , 2010)  feature modeling language of the global product line system of ABS. Pretyping requires to have a version of the type checker that uses the pre-computed signatures, instead of resolving type names with the class table. The error reporting mechanism is reused from the standard type checker. The VM tool chain implementation has two aspects, several helper classes, and consists of the following components: (i) Sanity condition checking (Section 5. 2) with error reporting in case a condition is violated (current implementation has limitations); (ii) PEV-compliance checking (Section 6) with error reporting in case the PEV is violated; (iii) flattening (Section 7.
Research questions Qualitative and quantitative aspects of VMs are evaluated along the following research questions: RQ 1 Does using ABS-VM provide advantages in terms of reduced implementation effort and code readability for existing models, where variant interoperability is implemented by relying on duplicating code (possibly based on programming constructs for intra-code reuse to reduce code duplication, see To investigate the first two research questions, we use ABS-VM to refactor (possibly extended versions of) legacy models. The source code of the case studies is available at the URL given in footnote 12. The legacy models are as follows: • The industrial FormbaR model of railway operations, available in two versions, see Remark 1. The first version, Form-baR-1  (Kamburjan and Hähnle, 2016) , is implemented in Delta-ABS.
The second version, FormbaR-2  (Kamburjan et al. , 2018) , is implemented in Delta-Trait-ABS. Both versions use one class per infrastructure element and, to achieve variant interoperability, different variants of the same infrastructure element are explicitly defined as separate classes without using DOP for implementing infrastructure elements. • The second version of the Weak Memory Model Family, referred to as WMMF-2 and implemented in Delta-ABS. It is the extension of an ABS model of weak memory (Kamburjan and  Hähnle, 2018) , referred to as WMMF-1 and implemented in Delta-ABS. In sequentially consistent memory models all read-and write-accesses in a piece of code are processed in the stated order. Weakly consistent (for short: weak) memory models permit partial or complete re-ordering of memory access to increase efficiency.
This is achieved (in Delta-ABS) by manually copying the class Memory to four modules MemoryInternaln, and creating two copies of the class DevicePair in two modules DeviceInternaln. • AISCO (Adaptive Information System for Charity Organizations) is a modular web portal supporting the business processes (information, reporting, spending, expenditure) of charity organizations. There are two versions of AISCO. The first, referred to as AISCO-1  (Setyautami et al. , 2019) , consists of an SPL is implemented in Delta-ABS. Its variability reflects differing legal and operational requirements of the supported organizations. Interoperability is not supported, hence variability is encoded using multiple copies of classes. The second version, referred to as AISCO-2  (Setyautami and Hähnle, 2021) , is implemented in Java.
It supports some of the functionalities of VMs by relying on an external tool, also written in Java: Different variants of a module are generated by the runtime structure, using the external tool on top of the Java implementation, see Section 12. 4 for details. The code is used in production at https://amanah. cs. ui. ac. id/. By refactoring the above models to ABS-VM, we illustrate different aspects in using VMs to model interoperable variants: VMs vs. Traits. In FormbaR-2, implemented in Delta-Trait-ABS, traits 16 are used to reduce code duplication across class definitions implementing variants of the same infrastructure element. In the refactoring of FormbaR-2, written in Delta-Trait-ABS, to ABS-VM we show how the relevant parts of FormbaR are re-modeled using VMs. VMs vs. Delta-oriented SPLs.
In the refactoring of WMMF-2, written in Delta-ABS, to ABS-VM we show that in the latter there is no need to manually duplicate modules. VMs vs. External tool chain. We compare AISCO-2, which uses an external mechanism implemented in Java to provide VM functionality, 17 with our re-implementation in ABS-VM. Experiment design. RQ 1 is addressed by manually refactoring the FormbaR-2, WMMF-2, and AISCO-2 model to ABS-VM and comparing conceptually the legacy implementation with the ABS-VM implementation. RQ 2 is addressed by comparing the number of lines of code (LoC) before and after refactoring.
Formbar The partial refactoring of FormbaR-2 to ABS-VM, referred to as FormbaR-3, has one VM with five features: PoV for points of visibility (of signals, etc. ), Speed for signals that announce a speed restriction, Signal for general signals, Main for signals placed at the point, where the signaled aspect holds, and Pre for signals that announce a point where the signaled aspect holds. Hence, the VM contains features (Main, Pre, Speed, Signal, PoV) plus deltas for the five re-modeled kinds of signal. 18   FormbaR-2 uses traits to reduce code duplication in the implementation of the different kinds of signals. FormbaR-3 has no need for traits: a set of operations is encapsulated in a delta and applied to a base TrackElement class. The feature model connects these operations explicitly with products corresponding to relevant infrastructure elements.
Results. The drawbacks of using an intra-product code reuse mechanism (like traits) to implement variants are discussed in Section 3. In consequence, FormbaR-3 is (i) shorter than Form-baR-2 (in terms of LoC), because in the latter there is a separate class for each kind of signal (see Section 11. 4 for details). (ii) FormbaR-3 is also more comprehensible. For once, its feature model makes constraints explicit that were only implicit in Form-baR-2 (for example, that certain traits should not be used in a class at the same time). In addition, it declaratively connects code variability to the domain model. For example, in FormbaR-3 the feature model expresses that a pre-signal has features Pre and Signal in a semantic manner in terms of a general Signal that announces its aspect Pre.
] , it cannot be modeled that different product variants from the same product line co-exist and interoperate within one and the same application. This leads to suboptimal code reuse. '' (Setyautami and Hähnle, 2021 , referring to AISCO-1). In AISCO-2, implemented in Java with the help of an external tool and supporting some aspects of VMs, different report variants are implemented by a VM containing a class Report. The variants of this VM correspond to the different classes defined explicitly in AISCO-1. The auxiliary concept of an Entity is not needed any longer. For the ABS-VM model, referenced to as AISCO-3, the main aspects of AISCO-1/AISCO-2 were re-implemented in ABS-VM in 160 LoC: One VM with four features and five deltas for financial reporting. All variants can interoperate within one and the same program generated from the ABS-VM code, instead of relying on an external framework, as in AISCO-2, that is intertwined with the generated program.
19   Results. The AISCO-2 implementation is distributed between Java and external tools that weave interoperable variants together in the desired manner. This approach has two major drawbacks: first, in contrast to AISCO-3, the various sanity, compliance, and type checks discussed in Section 9 cannot be easily realized. Even for a concrete generated program type-safety cannot be fully statically checked, because the VM implementation mechanism of  Setyautami and Hähnle (2021)  relies on reflection. Second, the distribution of configuration knowledge to different places in the implementation makes maintenance harder and more errorprone than in AISCO-3. A Java-specific limitation also present in AISCO-2 is the impossibility to remove the implementation (method, class) of a functionality, one can only override it.
FormbaR Compared to FormbaR-2, the FormbaR-3 VM version reduces the total number of LoC needed for the signal products from 241 to 180 (-25%). Excluding code required only for variability modeling (configuration knowledge and delta headers), the remodeled part has 163 LoC (-33%). There are various effects that lead to a reduced number of LoC: • FormbaR-2 declares one interface and one class per infrastructure kind 20 In contrast, FormbaR-3 declares a single interface Specific, which is then transformed by deltas concurrently with its corresponding class. This reduces the header for interface declarations, in particular, when the interface needs not be changed (for example, the interface for PoV contains no methods and is only declared to provide a type). This means that one uses, for example, Specific with [PoV] instead of IPoV.
WMMF The WMMF-3 model has 485 LoC, of which 440 LoC are the two variable modules. The WMMF-2 model has 1322 LoC (+272%), of which 620 LoC are concerned with deltas and variability and 582 are the core product of the modules for memory models and devices. We refrained from reducing code duplication through traits to illustrate that product line systems without native support of interoperable variants can only replicate this behavior through massive code duplication. If a module has p products, then in ABS-VM only p configurations are declared, for any number of used variants. Another observation is that to connect n variants, one needs to declare p n products: one for each combination. Hence, in addition to the additional delta declarations, this blows up the feature model unreasonably.