dataesr/scientific-paragraphs-categorization huggingface dataset:
MOTIVATION Life sciences rely heavily on high-throughput technologies to understand, for example, the functional implications of gene structure, expression, regulation and variation upon human health, well-being and the environment. The outcome is an unprecedented huge volume of complex, highly heterogeneous biological information  (1) , which may span multiple scientific disciplines such as genetics, ecology and agriculture. In response, very many software tools and databases have been developed to manage and analyse the data. This presents a big challenge, not only for scientists, who must find relevant solutions in an ocean of possibilities, but also for 'blue-collar bioinformaticians' (as coined by Brad Chapman, http://bcb. io) who must solve a plethora of technical problems as they build usable protocols and workflows from technically diverse resources.
It is therefore no surprise that bioinformatics help fora such as BioStar (2) are so popular. There have been many efforts (including examples in the next section) that help guide people to find and use relevant bioinformatics software and databases. These include collections provided by individual academic institutes and research infrastructures, specialised formal registries and catalogues, software platforms, toolkits, system distributions, wikis, as well as multiple ad hoc lists on the Web. Although such initiatives serve their target audiences well, there is no single gateway to the available resources providing (i) consistency in the corpus of resource descriptions, (ii) adhesion to a common information standard and not least (iii) the foundation of a sustainable upkeep model that can obtain comprehensive coverage across the whole scientific and technical spectrum, and provide some assurance of quality in the long term.
The strategy of aggregating or warehousing data via some community-driven, crowdsourced or federated effort is hardly new. Notable successes include Wikipedia (3), and many projects hosted on sites such as GitHub and Source-Forge. Within bioinformatics, the strategy has been applied in diverse contexts, e. g. aggregation of database references within the UniProt database (4), the MIntAct (5) platform for curation of molecular interaction databases, data set sharing via BioMart  (6, 7) , code sharing by the O|B|F Bio* libraries  (8) (9) (10) (11) (12) (13) (14) (15) , user fora for questions and answers such as BioStar (2) and SEQanswers  (16)  and sharing of software skills via Software Carpentry  (17). Various initiatives include cataloguing of bioinformatics resources, such as the Molecular Biology Database List published in the Nucleic Acids Research's Database Issues  (18) (19) (20) , the Bioinformatics Links Directory  (21, 22) , the EM-BRACE Registry  (23, 24)  and BioCatalogue (25) of Web services; software sharing and distribution initiatives such as Bioconductor  (26) , Bio-Linux  (27) , Debian Med  (28) , or BioJS  (29) (30) (31) ; and the tools sections at BioStar and SEQanswers--SEQWiki  (32).
REGISTRY CURATION AND DEVELOPMENT In practical terms, registry curation involves the annotation of resources to bring their description up to a mandated minimum standard of information, the registration of those descriptions, subsequent updates of accessions and concomitant ontology development. The information standard is defined by biotoolsXSD 1 , a formalised XML schema (XSD) of key scientific, technical and administrative attributes, including scientific concepts from the EDAM ontology (Figure  1 ). EDAM provides the core vocabulary of well established, familiar concepts that are prevalent within bioinformatics, including types of data and data identifiers, data formats, operations and topics. The remaining required controlled vocabularies, for example for resource type and software licences, are defined internally within biotoolsXSD.
The content includes mostly tools and a significant number of databases, most of which have a Web GUI, with a significant proportion having a command-line interface, or a programmatic API via HTTP or SOAP Web services. The registry content is made available for browsing and searching via an interactive query interface (Figure  2 ). The interface provides features to search the corpus of resource descriptions, display what fields of information are shown and filter and sort the results by various attributes. Thus, a user may formulate a precise query, that addresses a specific bioinformatics task, and quickly retrieve resources that fulfil those exact requirements. The search results are available for viewing in a spreadsheet-like view ('grid') and in a summary form ('pills'). A URL-based API supports programmatic queries.
Thus, the pressing requirement is to build and support the community behind the registry, but we have strong grounds to expect this effort will succeed in the long-term. Firstly, there are natural incentives to contribute to a com- EMBOSS is a free Open Source software analysis package specially developed for the needs of the molecular biology (e. g. EMBnet) user community. The software automatically copes with data in a variety of formats and even allows transparent retrieval of sequence data from the web. Also, as extensive libraries are provided with the package, it is a platform to allow other scientists to develop and release software in true open source spirit. EMBOSS also integrates a range of currently available packages and tools for sequence analysis into a seamless whole. EMBOSS breaks the historical trend towards commercial software packages.
WHAT-IF http://swift. cmbi. ru. nl/whatif A versatile molecular modelling package that is specialized on working with proteins and the molecules in their environment like water, ligands, nucleic acids, etc. Bio-Linux http://environmentalomics. org/bio-linux Bio-Linux is an Ubuntu Linux-based distribution that adds more than 250 bioinformatics packages, providing around 50 graphical applications and several hundred command line tools, as well as the Galaxy environment for browser-based data analysis and workflow construction. Debian Med https://www. debian. org/devel/debian-med/ Debian Med is a project that aims at developing Debian into an operating system that is particularly well fit for the requirements for medical and biological research. The goal of Debian Med is a complete free and open-source system for all tasks in life-scientific research.
To achieve this goal Debian Med integrates applicable software into Debian. Rostlab http://rostlab. org A collection of bioinformatics tools for the prediction and analysis of the aspects of protein structure and function, provided by the Rost lab at the Technical University of Munich and Columbia University of New York. BioJS http://biojs. net A registry and open-source library of JavaScript components to visualise biological data. mon effort in which the curation burden is shared. Secondly, the approach shares a similar philosophy to other community projects such as DebianMed and SEQwiki, making it easy to find like-minded people to work with productively. Finally, the anchoring of the effort within ELIXIR provides a global context and some resources to develop the registry. The Danish node of ELIXIR--the 'tools node'--is coordinating and fostering the effort, and will leverage relevant initiatives such as the ISB International Society of Biocuration.
FUNDING The  BioMedBridges  project is funded by the  European Union Seventh Framework Programme within Research Infrastructures  of the  FP7 Capacities Specific Programme [284209]. ELIXIR-EXCELERATE  is funded by the  European Commission  within the  Research Infrastructures programme of Horizon 2020  [676559]. We gratefully acknowledge the support of the  Danish Infrastructure Roadmap grant  to the  Danish ELIXIR Node , and all European countries that fund the contributing national ELIXIR initiatives. Paola Roncaglia  is supported by a  P41  grant from the  National Human Genome Research Institute (NHGRI)  [grant  5U41HG002273-14 ]. Funding for open access charge:  DTU Horizon 2020 [676559 ].
For these analyses, the dangerous phenomena and the undesirable events resulting from each hazard was evaluated in terms of probability of occurrence and severity. Then, a risk assessment was carried out according to a predefined risk matrix. As several risks were found to be intolerable, a preliminary set of risk mitigation measures were proposed in order to reduce their probability of occurrence and/or their severity level. Afterwards, a new risk assessment was performed, this time considering that the risk mitigation measures were implemented. The results obtained from this new risk assessment showed that it is possible to reduce the probability of occurrence/severity of all the risks associated to the battery life cycle to acceptable or tolerable levels. The probability of occurrence and severity level defined for some risks was based in theoretical reason, since there is still few data available related to large Li-ion batteries risks.
Acknowledgements This work was made in the framework of the  STABALID  project (reference  308896 ), financed by the  European Commission  under the 7 th  RTD Framework Programme. It was also financed by the  North Portugal Regional Operational Programme  (ON. 2 -O Novo Norte), under the National Strategic Reference Framework (NSRF), through the  European Regional Development Fund (ERDF) , and by national funds, through the  Foundation for Science and Technology (FCT) , within the  BEST CASE  project (" NORTE-07-0124-FEDER-000056 ").
Visualization Dashboards Process overview. To design and implement a visualization dashboard, one selects the visualizations applied to refined datasets to achieve some identified goal. This process involves three roles: 1. a Requirement Engineer (RE); 2. a Data Manager (DM); 3. a Dashboard Designer (DD). [Copyright notice will appear here once 'preprint' option is removed. ] Each role is responsible for several tasks: (i) the RE defines what will be the purpose of the dashboard and audit the resulting dashboard according to the initial motivation, (ii) the DM selects data to be visualized and treat it to provide the needed well formatted datasets, (iii) the DD choose visualization for each group of data and arrange them spatially into a dashboard. These roles needs to collaborate, e. g. , the choice of visualization the DD has to make depends on the purpose exposed by the RE.
They rely on distinct domains of expertise and formation, each one bringing its own challenges and none is optional in order to produce a satisfying final product. Thus, each role is usually impersonated by a dedicated stakeholder. Designing dashboard. One could use existing solutions to implement each of the mentioned tasks, for example using SQL would be a suitable choice to query and refine sensor data. The Interaction Flow Modeling Language  [6]  models the wanted organization of the dashboard, and temporal logic or Concurrent Tasks Tree (CTT)  [5]  define the aimed product and the sequence of actions to be performed with it. Those tools were not designed for the visualization field and suffers from their generic approaches by being difficult to use by visualization designers. For example CTT does not offer concepts to characterize visualization needs.
Moreover, there is a lack of interoperability between those tools due to the distinct field they come from. This results in a difficulty for the stakeholders to dialogue and converge toward a solution when a compromise is needed. Implementing dashboard. To implement a given dashboard, one can use visualization widget libraries, either professional solutions such as HighChart 1 and AmChart 2 or community-based libraries such as D3. JS 3. Then, one will add HTML5/CSS code to structure the result. However, those widgets do not allow their integration with a lot of data format, since the development effort is put on the interaction aspect instead of the interoperability. In addition, the huge amount of available widgets (e. g. , D3. js offers 235 widgets on January 2015) increase the difficulty to select a suitable visualization.
Challenges The previous section described how people support the design and implementation of dashboards using a classical development process. In this section, we describe the challenge of isolation that undermine this process, detailing it through two axes: evolution capacities and dashboard integrity. We discuss how separation of concerns and software composition could be helpful to support this process. Isolation challenge. Each stakeholder should be able to work in his domain of expertise, isolated from the other domains. This main challenge implies that each one work without the irrelevant noise of others' contributions, focusing on concepts of her own domain, or, in case of a shared concept, only on the facet of this concept relevant for the task of this role. For example, as a dashboard designer, one can define a link between the visualization being constructed and some data, but should not be requested to be competent as a data manager while working on it.
The relevant information from a data polishing point of view are handled by a specialist of this domain, but not only this specialist would need to reference a specific dataset. Evolution capabilities. Data visualization is a growing, fast evolving field: 6,440,000 Google results for "data visualization" on 01/15, D3. js offered 133 widgets on 04/14 and now 235 on 01/15. Requirement engineering (RE) is a very active research field offering new way to capture needs: more than 730 papers published since 2014 and referenced by Google Scholar contains "requirement engineering", and 640 "goal model". In addition, data scalability is still an open scientific lock. For these reasons, their respective tool or Domain Specific Languages (DSL) used have to evolve in time. Exploiting a composition-based approach to represent the widgets will support the evolution capabilities of the whole design framework.
Conclusions & Perspectives In this paper, we described the domain of visualization dashboard design. This domain crosscuts several research fields, from humancomputer interactions to big data. We highlighted three challenges in this domain where a software engineering approach based on modularity concepts could support it. However, all the challenges triggered by this domain are not yet solved from a separation of concerns point of view. In our upcoming works, we plan to focus on defining a formal way to support exchanges between the different roles involved in the domain by a formal identification of the relations between each stakeholder domain and through integration of domain specific solutions while emphasizing integrity and isolation properties on this composition.
Introduction Singular spectrum analysis as a method of time series analysis has well-elaborated theory and solves various problems: time series decomposition, trend extraction, periodicity detection and extraction, signal extraction, denoising, filtering, forecasting, missing data imputation, change point detection, spectral analysis among them (see examples and references in  Vautard and Ghil (1989) ;  Golyandina et al. (2001) ;  Ghil et al. (2002) ;  Golyandina and Zhigljavsky (2013) ). Since the method does not need a model given a priori, it is called nonparametric and is well suited for exploratory analysis of time series. Additionally, SSA allows the construction of a model during or after exploratory analysis. The underlying parametric model of the signal is the sum of products of polynomial, exponential and sine-wave functions.
General scheme of SSA Let us introduce a general scheme of SSA-like algorithms, including MSSA and 2D-SSA. The SSA-like algorithms decompose the given data X into a sum of different components: X = X 1 + • • • + X m. (1) A typical SSA decomposition of a time series is the decomposition into slowly-varying trend, seasonal components and residual or the decomposition into some pattern, regular oscillations and noise. The input data can be a time series, a multivariate time series, or a digital image. The algorithm is divided into four steps. The first step is generation of a multivariate object on the base of the initial object (time series or image) by moving a window of some form and taking the elements from the window. For one-dimensional time series, this window is an interval that produces subseries of length L of the time series, where L is called window length (in SSA).
As an implementation of the SSA method, Rssa is the only package on CRAN. Let us put attention to several issues related to difference of SSA with many other methods and algorithms implemented in various R packages. SSA-like methods can be applied as model-free approaches that do not need to know parametric models and the periods of possible periodic components in advance. This is their difference from methods like seasonal decomposition and parametric regression. Also, an important point is that in SSA-like methods it is not essential for data to have additive or multiplicative structure. In addition, note that although the model of series governed by linear recurrence relations may seem similar to the autoregressive models, they have nothing in common. The present version of the Rssa package deals with equidistant series and spatial data given on a rectangular grid.
For processing of the data given on an irregular grid, two approaches can be used. Certainly, interpolation to a rectangular grid can be performed (it is not implemented in the current version of the package). For univariate and multivariate series, one can formally deal with non-equidistant data as with equidistant measurements, ignoring the irregularity. For processing of time series or of systems of time series, Rssa can deal with vectors, lists of vectors, matrices and also with input data of classes ts, mts, zooreg  (Zeileis and Grothendieck 2005)  (also, zoo data can be used, but the contents of the index attribute of a zoo object is simply ignored). The package tries to preserve attributes of input data, making operations with the decomposition results convenient: no conversion to the original class is required.
Denote M p,q the set of p × q real matrices. Let M be the linear space of all possible X, where X is an ordered set of real values representing initial data (i. e. , time series or image). Then the embedding T is a one-to-one mapping from M to M (H) L,K ⊂ M L,K , where M (H) L,K is the set of matrices with a Hankel-like structure, which is determined together with L and K by the method parameters. The mapping T puts elements of X in some places of the trajectory matrix X = T (X). Let x k denote the kth element of X. (The index k may be two-dimensional, see e. g. Table  1. ) Then the mapping T determines the set of indices A k such that (X) ij = x k for any (i, j) ∈ A k. Formally, let E k ∈ M be the object with the kth element equal to 1 and all the other elements equal to zero. Then the set A k corresponds to the places of '1' in the matrix T (E k ).
Information for grouping The theory of SSA provides various ways to detect the SVD components related to the series component in order to perform proper grouping in conditions of separability. One of the rules is that the eigenvector produced by a data component repeats the properties of this component. For example, in SSA the eigenvectors produced by slowlyvarying series components are slowly-varying, the eigenvectors produced by a sine wave are sine waves with the same frequencies, and so on. These properties help to perform the grouping by visual inspection of eigenvectors and also by some automatic procedures (see  Alexandrov (2009)  and  Golyandina and Zhigljavsky (2013, Section 2. 4. 5) ). To check separability of the reconstructed components X 1 and X 2 , we should check the orthogonality of their reconstructed trajectory matrices X 1 and X 2.
Typical code The general structure of the Rssa package is described in  Golyandina and Korobeynikov (2013)  and holds for the multivariate extensions. Therefore, let us briefly discuss the base Rssa functions for analysis and forecasting of one-dimensional time series. Implementation of SSA analysis and forecasting is mostly contained in the functions ssa (decomposition), reconstruct (reconstruction), predict, rforecast and vforecast (forecasting), plot (plotting), wcor (weighted correlations for grouping). For demonstration, we consider the series of sales of fortified wines (shortly FORT) taken from the dataset "Monthly Australian wine sales: thousands of litres. By wine makers in bottles <= 1 litre"  (Hyndman 2013). The full dataset contain sales from  January, 1980 , to July, 1995 (187 points).
Formats of input and output data The inputs of SSA can be quite different depending on the kind of SSA used. For example, the inputs can be vectors, ts objects, matrices, data frames, lists of vector-like objects of different lengths, images in the form of matrices. For Shaped 2D-SSA, the images can contain missing NA values. For MSSA the missing values can be used to construct the series of different lengths. The routines in the packages are designed in a such way that they preserve all the attributes (shape, time scale, etc. ) of the input object. So, the result of the Reconstruction step is exactly of the same type as the input object was. This can be seen in Figure  6 , where plot. ts (corresponding to the default plot. method = 'native') was used to draw the result of the Reconstruction step.
MSSA analysis Consider a multivariate time series, that is, a collection {X (p) = x (p) j Np j=1 , p = 1,. , s} of s time series of length N p , p = 1,. , s. Denote X = (X (1) ,. , X (s) ) the initial data for the MSSA algorithm. Since the general scheme of the algorithm described in Section 2 holds for MSSA, we need to define the embedding operator T MSSA (X) = X only. Let L be an integer called window length, 1 < L < min(N p , p = 1,. , s). For each time series X (p) , the embedding procedure forms K p = N p -L + 1 L-lagged vectors X (p) j = (x (p) j ,. , x (p) j+L-1 ) , 1 ≤ j ≤ K p. Denote K = s p=1 K p. The trajectory matrix of the multidimensional series X is the L × K matrix of the form T MSSA (X) = X = [X (1) 1 :. : X (1) K 1 :. : X (s) 1 :. : X (s) Ks ] = [X (1) :. : X (s) ], (7) where X (p) = T SSA (X (p) ) is the trajectory matrix of the one-dimensional series X (p) defined in  (2).
Typical code Here we demonstrate how the MSSA decomposition of a system of time series can be performed by means of the Rssa package. Since the analysis and forecasting for one-dimensional time series by Rssa are thoroughly described in  Golyandina and Korobeynikov (2013) , we put more attention on the difference. In Section 2. 3, we decomposed the one-dimensional series FORT (sales of fortified wines). Here we add one more series, sales of dry wines (shortly DRY), for simultaneous analysis. For loading the data we use the code from Fragment 1. Fragment 5 (FORT and DRY: Reconstruction). > wineFortDry <-wine[, c("Fortified", "Drywhite")] > L <-84 > s. wineFortDry <-ssa(wineFortDry, L = L, kind = "mssa") > r. wineFortDry <-reconstruct(s. wineFortDry, + groups = list(Trend = c(1, 6), + Seasonality = c(2:5, 7:12))) > plot(r.
Simultaneous decomposition of many series In this example, we consider a system of many time series and show that the decomposition by MSSA helps to look at similar patterns of the series. We will use the methodology described in the previous sections. Let us consider the collection of s = 6 series from the 'AustralianWine' dataset, which includes the series of wine sales considered in the typical code from Section 3. 4. A considerable part of this multivariate series can be described as seasonality. Therefore, MSSA can have an advantage over conventional SSA. Since the time series have different scales, namely, the 'Rosé wines' sales have the order of 100 thousand of litres in month, while the sales of 'Fortified wines' are about 30 times larger, the time series should be transformed into the same scale.