dataesr/scientific-paragraphs-categorization huggingface dataset:
AGECEP-BASED AUTONOMIC MANAGER This section discusses how existing approaches can be coupled with AGeCEP to tackle the whole MAPE-K loop and thus implement a complete autonomic manager. The focus is on design aspects that must be taken into consideration when using AGeCEP. The presented design is primarily based on FRAMESELF [Alaya and Monteil 2015], an autonomic framework that aims to enable implementation of autonomic managers that rely on the MAPE-K loop. FRAMESELF provides meta-models and mechanisms for implementing inference rules and communication between modules.
This decision is aligned with AGeCEP extensible and generic nature: The monitoring data that CEP systems must provide are tightly linked to the placement procedures and self-management policies implemented by the autonomic manager. Therefore, defining a fixed set of monitoring events would restrict the scope of policies that can be implemented. Instead, AGeCEP allows policies to define the events they need. Analogously to how rule mutators establish a contract that CEP systems must implement, the events required by a policy define a contract of events CEP systems must provide. 7. 2. 2. Monitor, Analyse, and Plan: Inference Rules. Inference rules are central to the monitor, analyse, and plan modules of the MAPE-K loop. In general, these rules are used to infer new information based on the KB and on freshly received information.
In the monitor module, the events received by the autonomic manager are processed by inference rules to infer symptoms. The analysis module uses these symptoms along with the AGeCEP query and environment models that are stored in the KB to generate Request for Changes (RFC). Finally, in the plan module, the RFCs and the KB models are used by another set of rules to create Change Plans (CP). In the FRAMESELF framework, inference rules are implemented by inference engines such as  Jess [2016]  and Drools  [JBoss 2016 ]. This research used Drools. 7. 2. 3. Execute. The execute module is in charge of carrying out the CPs that it receives. In an AGeCEP-based autonomic manager, a CP is simply a sequence of reconfiguration actions modelled by graph rewriting rules that are associated with a set of side-effect mutators.
The execute module enforces each reconfiguration of the CP in two steps involving the application of (1) a graph rewriting rule to update the model and (  2 ) its associated mutators to update the real system. In practice, a mutator is an API call that must be implemented by the CEP system being managed. In cases where the CEP system already exists, API calls can be handled by wrappers encapsulating the legacy components  [Hagimont et al. 2009]. Accordingly, for the feasibility study presented in Section 9, a minimal API has been defined as follows: -startOperator(o, m): deploys and starts an operator o in server m; -stopOperator(o): stops and deletes an operator o; -connect(o 1 , o 2 ): creates a connection between operators o 1 and o 2 ; -disconnect(o 1 , o 2 ): deletes a connection between operators o 1 and o 2 ; -redirect(o 1 , o 2 ): redirects all o 1 input (output) streams to input (output) o 2 ; -migrate(o, s 1 , s 2 ): migrates an operator o from server s 1 to server s 2.
VIABILITY: PERFORMANCE EVALUATION This section discusses the viability of AGeCEP as a formal foundation for developing generic CEP applications and algorithms. The analysis focuses on the time required to transform CEP queries using both simple and complex graph rewriting rules. In the following, the AGG tool  [Taentzer 2004 ] was used to define and apply the graph rewriting rules. The experiments were conducted on a server with two six-core processors (Intel Xeon E5-2630, 2. 6GHz) and 96GB of RAM. The server was running Ubuntu Linux 14. 04 and Java 1. 7. 0_75.
CONCLUSIONS This work has introduced and investigated the feasibility and viability of the AGeCEP formalism. This formalism was developed to overcome the fragmentation of current CEP/SP solutions. AGeCEP proposes a language-agnostic abstraction of CEP queries and a formalism to manipulate them, enabling definition of self-management policies that can be integrated into potentially any CEP system. AGeCEP represents CEP queries using attributed directed acyclic graphs (ADAG) whose vertices and edges have a standardized set of attributes that encode information relevant to self-management. These standard attributes are based on a novel classification of CEP operators that focus on their reconfiguration capabilities and also constitutes a major contribution of this research. Self-management policies may ultimately trigger the execution of query reconfigurations.
CMS allows users to publish information in natural language, without using any programming language. Famously referred to as a part of the "web 2. 0", a CMS restricts the range of possibilities of HTML code in order to simplify the editor's task. They impose a publication standard on the web that users have to accept if they choose this tool. The web designer can then allow users to customise options that contribute to making the technical framework invisible. For example, Wordpress software helps standardise online publication practices by providing an interface in which the same writing constraints apply to all users. CMS specifies some actions and offers users the same content organisation system, the same filtering tools and the same formatting options. However, even if the constraint is important, some users may still take some degree of ownership of the socio-technical resources of the device and change the original settings through its code.
Section 3: Framing online behaviour The third regime of governmentality we want to describe in this paper is the most "robust" of all: framing. Framing refers to the fixing of technical architectures for actions in a digital environment. It is about deciding what can and cannot be done. Operating systems (OS) are good examples of what framing means. An OS is not a software that users handle, it is an environment that rules the way users and software interact through an interface. Mac OS, Windows and Linux are three different OS' that provide their users with different norms of action and interaction, even if they are based on similar logics of interface (mouse, windows, and folders 1). In 2007, the launch by Apple of its iPhone operating system raised many questions about the new logics of action and interaction that were embedded in this technology.
As a closed system in which all processes producing and distributing applications are monitored by Apple, the iOS has been seen as a breakdown with regards to the open standards of the web 2 and a first move towards a more centralised internet -where only a few companies hold strategic "points of control"  (Zittrain, 2008; Benkler, 2016). However if Androïd (first powered by Linux, before being bought by Google in 2005) bears similar logics, these criticisms were mainly addressed to Apple, as a company which historically promotes closed operating systems. The main feature of an operating system like the iOS is to provide a segmentation of users' capacity of action. As Apple presents its iOS on its websites, mobile applications (mentioned as "apps" in the following) are designed "as islands": independent, isolated, without any bridge that could make them interact.
The ATLAS EventIndex is a data catalogue system that stores event-related metadata for all (real and simulated) ATLAS events, on all processing stages. As it consists of different components that depend on other applications (such as distributed storage, and different sources of information) we need to monitor the conditions of many heterogeneous subsystems, to make sure everything is working correctly. This paper describes how we gather information about the EventIndex components and related subsystems: the Producer-Consumer architecture for data collection, health parameters from the servers that run EventIndex components, EventIndex web interface status, and the Hadoop infrastructure that stores EventIndex data. This information is collected, processed, and then displayed using CERN service monitoring software based on the Kibana analytic and visualization package, provided by CERN IT Department.
Introduction The EventIndex  [1]  is a catalogue of the event-related information for the ATLAS experiment  [2]. It is organized in a number of relatively independent modules or subsystems, collecting the event data from the datasets on the CERN central server (Tier-0) and on the Grid, sending this information to CERN, processing and storing it to the Hadoop [3] file system (HDFS) and, finally, exposing an interface for the queries by the users and production system. A smooth operation and interaction of these components is necessary for the effective work of the EventIndex and the success of the analyses depending of its data. We developed a system for automatically monitoring states, critical parameters and performance numbers of the EventIndex components. It provides information to the EventIndex operation team through the Kibana  [4]  visualization package.
Monitoring of the EventIndex components The EventIndex consists of number of components of different type distributed between computers at CERN and on the Grid. Each of these components requires a different approach for data collecting and processing. Monitoring information is collected by jobs running on one of the EventIndex computers automatically at specified time managed by acron scheduler. The gathered information is organised into xml files and then pushed to the ATLAS computing services monitoring server running Kibana. Kibana is a data visualisation software on top of the ElasticSearch engine. It provides a number of tools to display information, like dashboards, queries, filters and time ranges, so information stored in an ElasticSearch cluster can be visualized as interactive plots such as pie charts, histograms, text, maps and other.
The machinery that imports event data on the Grid is called "Open-ended production". It receives from the Atlas Metadata Interface  [5]  (AMI) information on datasets that were produced recently and supplies this information to ProdSys2  [6] , the secondgeneration ATLAS distributed production system, which actually runs the tasks extracting event information. In the corresponding part of the monitoring we display information on the number of datasets of different types found and fed to the processing by the EventIndex jobs, and on any errors found in this process. The information is gathered from the log files. We track the performance of the producers that gather event information  [7] , consumers that receive this information from the producers and the messaging system that provides the transport of data between them by processing monitoring messages that are sent to special queues by the consumers.
Significant degradations of this system are reported. The Hadoop storage system has a storage capacity around 1. 5 PB and host most of the EventIndex data. Its size grew to more than 100 TB including transient files created by the consumers, with information on real data from Run 2 reaching 40 TB in half a year. We gather data volume information using HDFS tools. Figure  4  shows the data growth as presented by the monitoring display. The trigger decision information of each event appears as a bitmask that is decoded using trigger tables replicated from the ATLAS condition metadata database  [8]  (COMA). We monitor the status of replication by processing logs and plot the number of trigger tables replicated and the ranges of run numbers and trigger keys for which the trigger information is available.
The EventIndex can be accessed through the command line interface from any Linux computer running CVMFS (CERN network file system  [9]  optimized to deliver experiment software in a fast, scalable, and reliable way) or using a client package. However, the main way of accessing it is through the web interface and its GUI, or providing plain text commands suitable for the ATLAS distributed analysis system  [10] [11] (PanDA). We monitor the web interface by periodically sending simple curl queries.
Motivation: Collaborative analysis of massive imaging datasets is essential to enable scientific discoveries. Results: We developed Cytomine to foster active and distributed collaboration of multidisciplinary teams for large-scale image-based studies. It uses web development methodologies and machine learning in order to readily organize, explore, share and analyze (semantically and quantitatively) multi-gigapixel imaging data over the internet. We illustrate how it has been used in several biomedical applications.
Introduction In various scientific domains (incl. biology, biomedicine, astronomy, botany, geology, paleobiology, marine research, aerobiology, climatology), projects leading to terabytes of multi-gigapixel images become increasingly common (The data deluge, 2012) e. g. biomedical research studies often rely on whole-slide virtual microscopy or automated volume electron microscopy. In these fields, significant advances could be made by multidisciplinary collaboration involving distributed groups of life scientists and computer scientists exploiting large-scale image networks  (Moody et al. , 2013; Poldrack, 2014) , or eventually by enlisting the help of members of the general public in large imaging surveys  (Clery, 2011)  through interactive games (e. g. EyeWire (http://eyewire. org/) and Brainflight (http:// brainflight.
In recent years, several software have been developed including CellProfiler  (Carpenter et al. , 2006) , CATMAID  (Saalfeld et al. , 2009) , BisQue  (Kvilekval et al. , 2010) , ilastik  (Sommer et al. , 2011) ,  Icy (de Chaumont et al. , 2012) , Fiji  (Schindelin et al. , 2012) , OMERO  (Allan et al. , 2012)  and BigDataViewer  (Pietzsch et al. , 2015). Applications and extensions of these software packages have been proposed in various research fields (e. g. in the context of Drosophila  (Jug et al. , 2014)  and Zebrafish  (Mikut et al. , 2013)  research, or in plant sciences  (Lobet et al. , 2013) ) to address rather specific biological questions (e. g. to map neuronal circuitry in  Schneider-Mizell et al. , 2015). In this work, we present Cytomine, a novel open-source, rich web environment to enable highly collaborative analysis of multigigapixel imaging data.
This tool has been designed with the following objectives in mind: • provide remote and collaborative principles, • rely on data models that allow to easily organize and semantically annotate imaging datasets in a standardized way, • efficiently support high-resolution multi-gigapixel images, • provide mechanisms to readily proofread (Ground-truth data cannot do it alone, 2011) and share image quantifications produced by machine learning-based image recognition algorithms  (de Souza, 2013; Murphy, 2011). While some of these features are available in existing tools, none of these tools provide all these features simultaneously. By emphasizing collaborative principles, our aim with Cytomine is to accelerate scientific progress and to significantly promote image data accessibility and reusability (The data deluge, 2012;  Moody et al.
, 2013; Poldrack, 2014). We want to break common practices in this domain where imaging datasets, quantification results and associated knowledge are still often stored and analyzed within the restricted circle of a specific laboratory. To achieve this goal, the Cytomine platform permits active collaboration between distributed groups of life scientists, computer scientists and citizen scientists. It allows seamless online sharing and reviewing of semantic and quantitative information associated with large images, either produced manually or automatically using machine learning algorithms, as schematically illustrated in Figure  1. The paper is structured as follows. In Section 2 we describe the main design principles and functionalities of Cytomine. In Section 3, we briefly present use cases initiated by our collaborators to help readers to determine how they can use our software to address their own research questions.
System and methods To allow image-based collaborative studies and meet software efficiency and usability criteria (Software with impact, 2014;  Carpenter et al. , 2012; Prins et al. , 2015) , the software is decomposed into four main components (Supplementary Note 1) communicating through web mechanisms (through a RESTful API): Cytomine core (Cytomine-Core), Cytomine Image Management System (Cytomine-IMS), Cytomine web user interface (Cytomine-WebUI) and Cytomine analysis modules (Cytomine-DataMining), designed as follows.
Cytomine-core Cytomine-Core relies on recent web and database software development technologies. Its underlying data models (Supplementary Note 2) allow to create and store projects. Each project can be accessed by multiple users through authentication. A project can contain multi-gigapixel image sequences and a user-defined ontology, i. e. a structured list of domain-specific semantic terms. Each image instance can be annotated by users or software using annotation objects of various shapes for regions of interest (e. g. a cell or a tissue subregion) and labeled with one or multiple semantic terms from the ontology (e. g. a specific cell type or tissue structure). In addition, metadata (key-value properties, associated files and rich descriptions) can be associated to any project, image and annotation.
Cytomine-DataMining Cytomine-DataMining analysis modules currently include variants of machine learning based image recognition algorithms (Maree et al. , 2013a) that can be run on remote servers (Supplementary Note 3). This property facilitates large-scale analysis on distributed cluster systems where expensive computations can be outsourced. We provide an unsupervised, incremental, content-based image retrieval method that searches on-the-fly for visually similar annotations in the database and displays them in Cytomine-WebUI every time a user draws an annotation (see examples in Supplementary Note 4. 2). Variants of supervised image recognition algorithms are also provided for object classification, semantic segmentation and landmark detection (see examples in Supplementary Note 4. 2). Through web communication mechanisms, these analysis modules can be launched from Cytomine-WebUI.
Applications While our first developments were primarily motivated by the analysis of brightfield cytology and histology images (digital slides) in lung cancer research (Maree et al. , 2013b), we have significantly increased our software's versatility and improved its extensibility. Cytomine has now been used on various bio(medical) imaging datasets that involved various types of images and experts in different collaborative operating modes to perform various quantification tasks. In particular, we briefly present here several use cases to help readers to determine how they can use our software to address their own research questions (see illustrative examples in Fig. 3  and Supplementary Note 5 for a user guide). These applications were regrouped into 4 categories corresponding to different image recognition tasks.
In addition, scripts using these web services were implemented to export quantification statistics in standard formats for further statistical analysis. Similarly, experts in sexual maturation research performed manual classification and counting (using point annotations) of thousands of oocytes in whole H&E slides of Chondrostoma nasus (Fig. 3d ). In  Weekers et al. (2015) , semi-automatic counting of immunoreactive cells in regions of interest (cortex, medulla, corticomedullary junction) of tens of kidney sections was performed (Fig. 3i ). Experts (nephrologists, pathologists and biomedical researchers) first provided manual freehand annotations (regions of interest, positive and negative cells) to train semantic segmentation models. These were applied for positive cell detection whose statistics were exported for each region of interest.
, 2015). In Maree et al. (2016), we analyzed tissue components in human renal biopsies (Masson-Trichrome stain). We proposed an automatic glomeruli detection workflow combining image processing operations using Icy  (de Chaumont et al. , 2012)  and variants of our supervised classification algorithms. Icy was registered in Cytomine-Core using our software parameter templating mechanisms and it was therefore able to import and export image and annotation data using our web services (see examples in Supplementary Note 5. 3). To build a large ground truth dataset (almost thirty thousand tissue components), glomeruli candidates automatically detected by Icy were analyzed using our proofreading tools for object classification. These interfaces show galleries of classified objects and allow a user to readily validate or correct (by drag and drop) predictions of ontology terms.
Other large ground truth datasets were collected using manual annotation tools. Several thousands of cells were annotated to build a large ground truth dataset in human thyroid cytology for the (ongoing) development of rare cell detection algorithms (Fig. 3f ), inspired by previous work on cervical cancer screening  (Delga et al. , 2014). We also implemented novel user interfaces (Cytomine-IRIS, see Supplementary Note 5. 2. 7. 2) to enable different users to independently assign ontology terms to objects of interest. In particular, it was used by several pathologists to annotate bone marrow cells in order to study inter-observer agreements and build a large concordant ground truth dataset for the design of cell classification algorithms.
A key advantage of our platform is therefore its extensibility. Indeed, our architecture enables computer scientists to add their novel software, register them to the Cytomine-Core and launch them from Cytomine-WebUI or from the command line. Also, annotation objects created by each instance of a software are stored in the database and are available through web services. These can then be subsequently proofread, or retrieved through the API by other software for further analysis and creation of novelmore precise -annotation objects. This allows to create complex image analysis pipelines based on distributed software. It has to be noted that although the software allows visualization of 5D image planes (x,y,z,c,t), current applications cited in Section 3 have involved independent analysis of 2D image planes only (e.
Conclusion Cytomine is a versatile software for collaborative analysis of multigigapixel images as already demonstrated by its various applications. With our design choices, we also believe our platform will facilitate accessibility, curation and dissemination of imagingrelated data. In the future, it might be extended and tailored to support: (i) the setup of large-scale, multi-centric image repositories or the emergence of an imaging 'data bazaar'  (Poldrack, 2014)  to enable new research questions or validate results on larger cohorts, (ii) the organization of image analysis challenges on unprecedented benchmarks to foster image machine learning research, (iii) the crowdsourcing of image annotation tasks to tackle intractable datasets, (iv) the dissemination of multi-gigapixel imaging data and associated quantification results to support scientific claims of research papers and (v) increase the reproducibility of scientific results by providing a platform where published results are available along the algorithms and the image data.
Funding This work was funded by the research grants  1017072 ,  1217606  and  1318185  of the Wallonia (DGO6). R. M. was also partially supported by the  GIGA  with the help of the  European Regional Development Fund. G. L. was supported by F. N. R. S. , and R. V. by  F. N. R. S Te  ´levie grant.