dataesr/scientific-paragraphs-categorization huggingface dataset:
We used this information to exemplify how MacSyFinder can be used to identify and classify these systems. General model and choice of parameters. In a first round of analysis, we defined a general simple model to identify all possible clusters of Cas proteins in 2643 prokaryotic genomes. In this general definition, all the CRISPR-Cas-HMM profiles available in TIGRFAM database were used whatever their type or subtype specificity (Table  S1 ). At this stage, we used relatively relaxed criteria: all the components were defined as accessory and all clusters with at least 3 different components (min_genes_required = 3) distant from at most 5 genes (inter_gene_max_space ''D'' = 5) were retained. With this procedure, we identified 1628 clusters of Cas proteins and could annotate 10663 Cas proteins (i.
Secondly, we took from the literature the list of CRISPR-Cas with experimentally characterized in vivo effects  [28]. In this list we could detect 100% of the 25 known Cas systems of genomes included in our dataset (Table  S4 ) with our ''general'', ''typing'' and ''subtyping'' models (see command-lines in Text S1). Furthermore, we could assign the correct subtype to 23 of them, and we propose a subtype for the system of Mycoplasma gallisepticum. This suggests a low rate of false negatives. Altogether these results suggest the method is very accurate and that most clusters correspond to CRISPR-Cas systems. Type I systems are more abundant in both bacteria (in ,31% of the bacterial genomes) and archaea (,71%), Type II are only found in bacteria, while Type III are more prevalent in archaea (,38%) (Table  1  and Fig.
Modelling itself can thus lead to new biological findings. MacSyFinder ignores phylogenetic information when putting together components of systems scattered in a replicon or in unordered datasets. In contrast, the preliminary distinction between homologous proteins can often be done using MacSy-Finder without the need for lengthy phylogenetic analyses. This works in two steps. First, one must produce a multiple alignment gathering the different families of homologous proteins. This alignment must be divided into sub-alignments according to the different systems, leading to the production of different profiles for the different sub-families of homologs. Finally, and as a rule, for a given protein, the best-scoring profile corresponds to the relevant homologous family (see Fig. 5 , and Fig.
Often, bioinformaticians produce methods to identify machineries and would like to easily package them for reproducibility and distribution among biologists. This can be easily done with MacSyFinder via the distribution of XML files and the relevant protein profiles. The ''Cas-finder'' we present here is a particularly relevant case. At the time we started the project, there was public information available on the protein profiles and on the genetic organization of the systems. We only had to define the models and use them in such a way that we could identify the systems and class them. The result is a highly accurate application to identify cas operons that can be easily distributed (Data S2). Table  S3  Detection results. (PDF).
Step #1: the co-localization criterion can be used in the ordered datasets. It involves clustering the hits separated by less than D protein-coding genes. The components described as ''loner'' in the XML definition files can be at any distance from other components. Step #2: the components of each cluster are used to fill the occurrences of the systems. Depending on the quorum, a cluster can describe a ''full'' system, or a ''scattered'' system. Step #3: clusters with components belonging to more than one system are split in unique systems and then re-directed separately to step #2. doi:10. 1371/journal. pone. 0110726. g003.
Such dashboards support users while interpreting these data, allowing one to take decisions based on the sensed data. The main challenge to tackle is then to support the intrinsic variability of this domain. This variability is twofold and thus triggers two concurrent challenges: (i) each user wants to use a dashboard dedicated to her very own needs, and (ii) visualisation libraries used at runtime provide different visualisation widgets to be used to implement such dashboards. In this context, model-driven engineering approaches can support the first challenge by capturing concepts used by the dashboard designers and providing appropriate tool support. To tackle the second challenge, Software Product Lines (SPLs) are defined as "a set of software-intensive systems that share a common, managed set of features and that are developed from a common set of core assets in a prescribed way"  [2].
SPL engineering is based on the idea that the reusable artefacts encapsulate common and variable aspects of a family of software systems  [3, 2]. As a consequence, SPLs provide a way to model widget variability, relying on strong logical foundations and configuration support. The contribution of this paper is to describe a tool-supported approach enabling the mass customisation of dashboards. The approach relies on a dedicated meta-model that captures the concepts used to design a dashboard. The variability of the different visualisation libraries is captured using feature models, expressed according to the concepts defined in the meta-model. The tool support implements the link between the meta-model and the feature models, supporting users while designing dashboards and ensuring code generation to reach runtime environments.
Handling the technological variability (C 2 ). The implementation of such dashboards is a complex task. Even if we have restricted the technological stack to web-based interface (it is one of the assumptions made by the SmartCampus Description of Work document), many widget libraries can be used to implement these dashboards, e. g. , AmCharts 3  , Highcharts 4  , D3. js 5. These libraries are heterogeneous, and offer different widgets with their own specificities. For example, (i) AmChart offers 58 different widgets, (ii) Highchart offers 54 widgets and 13 additional widgets dedicated to large datasets (named Highstock), and (iii) D3. js offers 133 widgets. The effervescence around the big data and open data paradigms fosters the frequent publication of new tools and widget libraries to support data visualisation.
Supporting Dashboard Design Variability (C 1 ) This section describes a meta-model that tackles the first challenge identified in Sec. 2: "How one can design a monitoring dashboard according to her very own needs?". To address this challenge, the key idea is to tame the complexity of dashboard design using a dedicated meta-model. This meta-model allows a user to focus on the way she wants to compose her data, and does not require implementation knowledge. It focuses on the different visualisation concerns one can apply to a given datasets, and is not bound to any concrete library implementation. Thus, at this level of abstraction, the user is completely free to work. The binding with existing visualisation libraries, as well as the introduction of new libraries with respect to this meta-model corresponds to C 2 (see Sec.
Thus, one needs to correlate the data collected from the air temperature sensor and the presence counter one to properly analyse the data. This can be done in multiple ways with respect to the user habits, as depicted in Fig. 3  using the AmCharts library. These two datasets can be visualised as charts displayed side by side (Fig. 3a ), or the two datasets can be composed in the same chart (Fig. 3b ). Considering that working at the implementation level is not acceptable for the SmartCampus users (due to a lack of programming knowledge), a dedicated meta-model is provided to focus on the level of abstraction expected by the users. This metamodel is named Ptah 6 and depicted in Fig. 3. We describe the concept it defines according to the three dimensions identified at the beginning of this section.
"What am I visualising?". At this level, the user focuses on the data sets she wants to visualise. Based on the state of practice in the IoT domain, we consider in Ptah that data collected from a given sensor are available as a resource published at a dedicated URL, following the REST paradigm. The DataSet concept allows one to refer to such an URL while modelling a dashboard. Metadata about the collected information are defined by the Field concept: a user expresses that the temperature DataSet is indexed by a Field named t temp typed as a Date, and contains a value (another Field) named temp typed as a Numerical value. If the underlying data format supports meta-data definition (e. g. , the SensorML standard published by the OGC  [4] ), it is possible to automatically infer from the dataset description the different Fields it contains.
Even if it does not happen in this example due to its simplicity, a user often needs to adapt the data she wants to visualise, e. g. , selecting only an excerpt or intersecting a given dataset with another one. To support this task, and considering that the definition of datasets in Ptah is very close to relational algebra, we reified in the meta-model the six classical operators available in database querying systems: (i) projection, (ii) selection, (iii) renaming, (iv) set difference, (v) set union, and (vi) Cartesian product. Considering a mobile sensor (e. g. , a smartphone) collecting both geographical location and Wi-Fi signal strength  [5]  in the campus according to time, one can rely on the previous "classical" relation operators to compose these data in order to bind the signal strength to a given location.
A domain-dedicated operator supports clock synchronisation between datasets (i. e. , the Offset operator is used to modify a time-based key). Thus, to realise the heat regulation use case, a user have to model two datasets: one linked to the presence counter resource, (p ds ) and a second one linked to the temperature sensor resource (θ ds ). "How do I visualise it?". At this level, the user focuses on the different visualisation concerns she wants to compose to the previously modelled datasets. From an abstract point of view, a visualisation is defined as a concern (i. e. , an intention) to be applied to given datasets. The vocabulary used for the concerns is inspired by the Data Visualisation Catalogue 7 , a functional reference for data journalism activities. One may notice that these concerns are not directly linked to concrete elements such as Line Chart or Pie Chart.
At this level of abstraction, the user works on intentions instead of concrete representations. An inference engine is used to bind user's intentions to concrete widgets (see Sec. 4). For example, a user expresses intentions such as Threshold to identify special values (e. g. , temperature exceeding 30 • C) in the datasets, 2D to work on two-dimensional charts. When the user does not know exactly which concern apply to the datasets, a Free concern is used to act as a free variable in logical programming: the inference engine used to bind the concern sets to a concrete widget will unify the Free intention with any concrete widget. In the heating regulation use case, the user wants to visualise a 2D representation, as she is interested by the detection of time-based patterns and more specifically Extremum detection (vis θ ).
As the presence counter collects discrete values, she also specifies that she wants to visualise it as a Discrete dataset (vis p ). vis θ = (data : {θ ds }, concerns : {2D, Extremum}) vis p = (data : {p ds }, concerns : {2D, Extremum, Discrete}) Atomic visualisations can also be composed together to built value-added visualisations. For example, the visualisation depicted in Fig. 3b  is semantically the Superposition of the two previously created visualisations, more specifically an Intersection. Indeed, the Ptah meta-model contains several composition operators that support the creation of CompositeVisualisation, e. g. ,: -Superposition (abstract). The visualisations are superposed, the left operand being stacked under the right one. -Union. This operator also performs a Superposition and keep the integrity of the datasets to visualise both entirely.
-Intersection. This operator performs a Superposition and process the datasets to only keep data within common time range. "Where and when do I visualise it?". Finally, the different visualisation must be composed together from a layout point of view. The Ptah meta-model allows a user to compose visualisation spatially as Boxes (where,  [6] ), and to arrange several Boxes together in a sequence of execution (when). Thus, the dashboard depicted in Fig. 3a  contains two Boxes (one for each visualisation), composed in a CompositeBox that uses the Left spatial organiser. The dashboard depicted in Fig. 3b  contains only one box, bound to the intersection of the two previously created visualisations. Complex dashboards like the one depicted in Fig. 1  requires Transition from one box to another one.
Handling the Technological Variability (C 2 ) The Ptah meta-model was designed as flexible as possible: the concepts defined in this meta-model are intrinsically freed from technical concerns such as concrete widget implementations. As a consequence, there is no immediate link between the meta-classes and concrete widgets. Thus, if one wants to generate concrete visualisation code from a Ptah model, each concept from Ptah must be associated to an implementation pattern that supports it. The challenge addressed here is twofold: (i) there is a tremendous number of available visualisation libraries and (ii) the relationship between concrete widgets and Ptah concepts is not a simple one-to-one mapping. Actually, when the user builds a visualisation in Ptah, she is following a kind of configuration process to obtain a visualisation product, just like in SPLs.
Considering a variability model of a given domain, one can configure a product of the SPL by selecting needed features  [7]. The general idea is that the reusable artefacts encapsulate common and variable aspects of a family of software systems in a manner that facilitates planned and systematic reuse. In our case each Concern concept defined in Ptah is clearly a feature, and each concrete product satisfies (or not) such features. Thus, it is possible to rely on variability modelling techniques and existing configuration tools (formally based on propositional logic and SAT-solving algorithms) to support the realisation of a Ptah model at the concrete level. The main difficulty is now to build the associated variability model. To support this task, we used a tool-assisted methodology that relies on Feature Models (FMs)  [8, 9]  to model variability, and a merging operator (denoted as µ), depicted in Fig.
each column is translated into a tool-ready representation of each descriptor, using the Familiar language  [12]  (see Fig. 6 ). The resulting feature model, based on a simplified version of the AmCharts that only contains 12 widgets is depicted as a feature diagram in Fig. 7  (31 additional constraints not shown). This model is then exploited to support the user while defining models conforms to the Ptah meta-model. For example, the visualisation vis θ refers to the features 2D and Extremum. While configuring the AmCharts feature model with the selection of these two features, the configuration engine results in four potential candidates to realise this intention: Line chart, Smoothed Line, Bar chart or a Column chart, i. e. , 33% of the initial product set. Considering that the second visualisation vis p refers in addition to the feature Discrete, leading to cut the widget dedicated to continuous data and resulting to only offer a Bar chart or a Column chart, i.
We represent in Fig. 8  four different prototype associated to these three datasets. We describe in Tab. 2 the cost of transforming one dashboard into another one, in terms of code instructions. It illustrate the time-consuming aspect of a prototyping process, even on this limited scenario. For example, in order to prototype the figure Fig. 8a , giving that the code of Fig. 8b  is already available, one needs to remove 54,84% of the existing instructions and add 134,41% of new code. Even between two representations that looks close to each other (e. g. , Fig. 8a  and Fig. 8c ), up to 11% of the code needs to be changed. The concrete dashboards depicted in Fig. 8  can be classified into two categories:(i) visualising three graphs at a time (Fig. 8a  and Fig. 8c ) or (ii) comparing the three datasets on the very same graph (Fig.
Related Work The Interaction Flow Modeling Language (IFML,  [13] ) is a standard of the OMG dedicated to model and generate front-end applications and human-computer interactions. IFML's purpose is to model front-end of applications composed of several layers, supporting the compositions required in such domain and the links with other layers of the application. In comparison, Ptah is dedicated to the design of monitoring dashboards thus our approach focuses on sensor data visualisations and related specific compositions. Both approaches are complementary, as our composition model can reify the IFML concept of ViewComponent in order to handle this specific type of visualisation, and we could use IFML expressiveness in terms of events and user actions to define dashboard transitions. The CAMELEON Reference Framework (CRF,  [14] ) offers a methodology for human-computer interfaces design and generation.
Our meta-model can be seen as a specialised implementation of the abstract visualisation layer described in CRF, allowing one to design complex data visualisations that are not yet supported by UsiComp  [15]  (reference implementation of the CRF). Indeed, the support in UsiXML is currently more focused on form-based interfaces, which are not completely adapted to sensor data visualisation. The concept of mashups as "composed applications" has reach the user interfaces domain  [16]. This way of composing User Interfaces (UIs) suffers from a lack of globalisation of their composition process, mainly focused on spatial arrangement and connection between data and widgets, where the Ptah meta-model brings useful concepts to handle the goal through visualisation concerns. Work on spatial composition in mashups is nonetheless an inspiration for further work.
Conclusions & Perspectives In this paper, we described a tool-supported approach used to tame the complexity of monitoring dashboard design. Based on a set of concrete scenarios extracted from a real deployment of sensors in an academic campus, we proposed a meta-model to support the design of monitoring dashboard, so that one can specify the what, how, when and where with no implementation knowledge. As the meta-model has been defined to meet business requirements of dashboard designers, it seems reusable for sensor data visualization in other contexts. We also proposed a variability model to facilitate the configuration of user-specific dashboard product from the obtained dashboard model. Then, code generation mechanisms are used to obtain a concrete dashboard executed at runtime, based on user's intention expressed at the model level.
Acknowledgements. Authors want to thanks  Simon Urli  for his expertise with Familiar and the SmartCampus team:  Romain Alexandre ,  Mireille Blay-Fornarino ,  Cecile Camilieri ,  Adrien Casanova ,  Cyril Cecchinel ,  Joel Colinet ,  Thomas Di'Meco ,  Fabien Foerster ,  Mathieu Jimenez ,  Laura Martellotto ,  Jean Oudot ,  Jérome Rancati ,  Marie-Catherine Turchini  and  Guillaume Zanotti.
, 1991 (Lew et al. , , 2003;; Lew and Bookchin, 2005; Mauritz et al. , 2009). Most modeling efforts have been implemented on a case-bycase basis, without a standardized format, and frequently without incorporating the essential transport circuits needed for overall balance of charge, solute and water fluxes  (Gradmann et al. , 1993; Grabe and Oster, 2001; Shabala et al. , 2006; Cui et al. , 2009). Utilities such as the Virtual Cell  (Loew and Schaff, 2001 ), E-Cell  (Tomita et al. , 1999) , Cellerator  (Shapiro et al. , 2003) , as well as the Berkeley Madonna Environment (BME) and similar commercial software  (Abu-Taieh and El Shiekh, 2007) , provide for modeling intra-and intercellular events that encompass reaction-diffusion processes in arbitrary geometries. These utilities offer standardized platforms for modeling, but many are designed for 'flow-through' (serial) networks, ill-suited to the recursive nature of membrane transport, and few have the scope to define underlying behaviors, for example as dictated by specific transport equations.
Significantly, none of these utilities are flexible in their connections to physiological outputs, most important for plant cells including those of solute content, cell volume, turgor, and non-linear or anisotropic cell expansion. Some of these difficulties are illustrated by the work of  Grabe and Oster (2001) , who utilized BME software to explore the question of vesicular acidification during endocytosis. Their study was able to recapitulate vesicular pH driven by the V-type H + -ATPase, but its prediction of a requirement for a voltage-gated Cl -channel and cation pre-loading was misdirected. Indeed, more recent work has indicated that the Cl -flux essential for vesicular acidification is mediated by CLC-type H + -Cl -antiporters  (Smith and Lippiat, 2010; Novarino et al. , 2010; Weinert et al.
, 2010). These limitations are addressed in the Homeostasis, Transport and Signaling (HoTSig) libraries, an approach developed in this laboratory  (Hills et al. , 2012). HoTSig incorporates an open structure of expandable libraries for transporter kinetics, chemical buffering, macromolecular binding and metabolic reactions, as well as for macroscopic coupling equations such as those relating solute content, cell volume and turgor, all accessible to input and modification by the user. This open structure makes HoTSig adaptable to wide variety of single-cell systems with the potential for its expansion to multicellular situations and problems that must be addressed across scales from the cellular to whole-tissue and organ structures. The first implementation of the HoTSig libraries, in the OnGuard software  (Hills et al.
, 2012). These predictions were confirmed experimentally, with the study demonstrating that experimentally 'clamping' cytosolic pH and [Ca 2+ ] i was sufficient to recover both the K + currents and stomatal opening kinetics. Thus, modeling with the OnGuard software uncovered an entirely unexpected homeostatic network connecting two unrelated ion channels in the guard cell. This study represents a crucial step toward using OnGuard-style modeling to guide the 'flip side' problem of reverse-engineering stomatal function; it is a very short step from OnGuard to future implementations that will enable rapid, in silico design as a guide to altering guard cell physiology, for example in improving water use efficiency during photosynthesis  (Lawson et al. , 2011 (Lawson et al. , , 2012;; Blatt et al.
Simulating the slac1 mutation of Arabidopsis In practice, simulating perturbations that represent new physiological, pathological or experimental conditions is straightforward in OnGuard. To get started, we encourage first-time users to review the 20-min video supplied with the software. This video introduces the basic operation of OnGuard, including, how to access and adjust modeling functions such as temporal minima, maxima and sampling frequencies, how to modify individual transporters, sucrose and malate metabolism, how to change ion and solute concentrations, and how to monitor, interrogate and log OnGuard outputs. Before starting OnGuard for the first time, select 'View' in the main window and choose 'Preferences' from the drop-down list. In the 'Run-Time Limits' tab ensure the 'Minimum T-inc' and 'Maximum Tinc' values are set to 0.