dataesr/scientific-paragraphs-categorization huggingface dataset:
Command line interface Each pipeline should have a simple wrapper script used to run it. The script should be a command-line interface and accept the following command-line arguments (minimally): 1. For the participant level (aka map) step: • bids_dir-(positional argument #1) the directory with the input dataset formatted according to the BIDS standard. This directory is read only. • output_dir-(positional_argument #2) the directory where the output files should be stored. This is the only directory the pipeline should write to. Can be used to store intermediate files, but they should be removed after the pipeline finishes. This directory is shared across all of the participant level jobs-it's up to the script to create subfolders for each subject. The overall structure of workflows. Workflows will need to decouple the individual level analysis (process independent subjects) from the group-level analysis.
If this parameter is not provided all subjects should be analyzed. Multiple participants can be specified with a space separated list. Example: Run processing for every subject independently (map step). Each of these operations can be performed in parallel. There are no restrictions or specification of how data should be organized inside the output_dir. /my_pipeline /data/my_dataset /scratch/outputs participant --participant_label 01. /my_pipeline /data/my_dataset /scratch/outputs participant --participant_label 02. /my_pipeline /data/my_dataset /scratch/outputs participant --participant_label 03.
(Optional) For the group level (aka reduce) step: • bids_dir-(positional argument #1) the directory with the input dataset formatted according to the BIDS standard. This directory is read only. • output_dir-(positional_argument #2) the directory where the output files should be stored. This is the only directory the pipeline should write to. Can be used to store intermediate files, but they should be removed after the pipeline finishes. This directory is the same one that was used in the participant level analysis and should be prepopulated with participant level results before running the group level. • "group"-(positional_argument #3) indicates that this is a group level analysis. • --participant_label-(optional) labels of the participants that should be analyzed. The label corresponds to sub-<participant_label> from the BIDS spec (so it does not include "sub-").
If this parameter is not provided all subjects should be analyzed. Multiple participants can be specified with a space separated list. This can be useful if you want to do a group level analysis on a subset of all participants in your dataset Example:. /my_pipeline /data/my_dataset /scratch/outputs group The script can also accept other arguments specific to your pipeline (see for example --template_name in FreeSurfer App). Mind that the same set of extra arguments will be passed to the map (single subject level) and the reduce (group level) stage.
Optionally, a detection step can be introduced before the projection to focus on the reconstruction of layers of interest  5. A variety of software programme as Voxx  6  , NIH's Fiji/ImageJ  7  or VTK  8  propose such options with an interactive visualization. Image stacks are also useful to image flattish or so-called 2. 5D objects such as an epithelium, a monolayered cell culture, a membrane within an in vivo tissue sample or a flat biological structure such as cultured neurons. This is because at high resolution, those objects cannot hold within the depth of field of a microscope and therefore a single 2D image acquisition often suffers from being only partially in focus. In contrast, a 3D stack contains all pieces of information needed to reconstruct a focused 2D image. In this case, a projection in the z direction is often preferred.
Finally, whatever the methodological drawbacks, there seems to also be an accessibility issue as, to our knowledge, the only tool made easily available to end users is the extended depth of field (EDF) method by Aguet et al. 9, 10  implemented as a plugin in the popular software programme NIH Fiji/ImageJ 7. However, this tool was specifically designed for brightfield microscopy images and still suffers from the aforementioned issues. Here we propose a method, smooth manifold extraction (SME), that focuses on what is currently missing in the available toolkits: maintaining spatial consistency in the projection both within one channel and also between channels. Obtaining a spatial consistency between channels is straightforward and just a matter of implementation: it consists in choosing a single reference channel for extracting the index map to apply to all channels.
As in practice we ended up using this option for some of our own applications, we made it available in the NIH ImageJ/Fiji plugin. Selecting a reference channel to compute a unique index map for all channels might be regarded at first as a parameter. However, it is not, it should be a rational choice related to the biological question being tested with a given data set. Indeed, if such a method is used for extraction, it implies that the 3D volume necessarily contains a 2. 5D foreground, which in turn implies that the channel of this 2. 5D foreground of interest must be specified. For example, in Fig. 1b, d , the surface of interest is the apical layer of ependymal cells, not the incomplete blood vessel network located below. Additional examples illustrating the choice of a rational reference channel are provided in Fig.
The apical surface being not planar, it was impossible to avoid imaging (in red channel) the blood vessels targeted by the same antibody used for staining nascent centrioles. Consequently, (b) MIP, by extracting high-intensity voxels, captures a mix of blood vessels located below the apical surface and of nascent centrioles, which makes any further analysis or even visual inspection difficult. (d) SME, by using the cell junction marker channel (blue) as reference, clearly discards the blood vessels that were located below the apical layer, which allow nascent centrioles to be clearly distinguished. Scale bar, 100 mm. A crop of this large slide is presented with more details in Fig. 4d, e. Each data set is further described in Supplementary Table  1. microscopy image stacks. The algorithm is parameter free and is implemented as an NIH ImageJ/Fiji plugin for ease of use.
Methods Survey. We conducted an anonymous online survey of microscope users to review common practices with 3D image volumes in the bio-imaging community. The survey shows that a significant fraction of users frequently use 2D projection for the purpose of visualizing 3D data sets and an overwhelming majority (84. 3%) of them use the freely available and easy-to-use Fiji Plugin for pixel wise intensity-based Z projection (see Supplementary Figs 1 and 2 for further details). Algorithm. The method we propose fit a 'smooth', parameter-free, 2D manifold Z onto the foreground signal of a chosen reference channel while 'ignoring' the background, thus propagating the index map found in the foreground to the local background. This is because, in principle, the foreground is deliberately stained while the background is mostly made of noise and therefore shows random levels of estimated focus.
A uniformly sub-sampled set of 1,000 pixels is also displayed for each method. We can observe that the departure from the original manifold is significantly smaller in general for SME and extreme values are also further apart for existing methods than for SME. reconstructed index map (Z R ). errZ ¼ Z X À Z R j j ð9Þ It is also a way to measure the accuracy of the manifold reconstruction (see Fig. 5d  for results). All of these metrics were applied on synthetic data with various level of noise (see Fig. 5 ). The results show an improvement of SME over the existing methods, whatever the level. Software and code. We make the proposed method available as a compiled ImageJ plugin for direct use with ImageJ/Fiji along with the Java code and the equivalent MATLAB scripts at the following address: https://github.
Acknowledgements We thank  Adel Al Jord ,  Morgane Thion  and  Sandrine Humbert  for providing some of the data sets and  Mary Ann Letellier  for helpful comments on the manuscript. We thank  Agence Nationale de la Recherche   ANR-12-BSV4-0006   CILIASTEM ,  ANR-10-LABX-54   MEMO LIFE ,  ANR-11-IDEX-0001-02   PSL* Research University, FRM ,  ATIP-AVENIR, Fondation Pierre-Gilles de Gennes (FPGG03) ,  INCA  Grant  2014-1-PL BIO-11 ,  European Research Council  (Consolidator Grant  647466 ) and the  Fondation pour la Recherche Medicale (20140329547)  for funding.
For these reasons, inspired by the success of similar events in other areas of computer-aided verification (e. g. , SAT  [59] , SV-COMP  [20] , SMT  [2] , RERS  [53, 54] ), Ezio Bartocci, Borzoo Bonakdarpour, and Yliès Falcone organized the first international Competition on Runtime Verification (CRV 2014) with the aim to foster the process of comparison and evaluation of software runtime verification tools. The objectives of CRV'14 were the following: -To stimulate the development of new efficient and practical runtime verification tools and the maintenance of the already developed ones. -To produce benchmark suites for runtime verification tools, by sharing case studies and programs that researchers and developers can use in the future to test and to validate their prototypes. -To discuss the measures employed for comparing the tools.
-To compare different aspects of the tools running with different benchmarks and evaluating them using different criteria. -To enhance the visibility of presented tools among different communities (verification, software engineering, distributed computing and cyber security) involved in software monitoring. CRV'14 was held in September 2014, in Toronto, Canada, as a satellite event of the 14th international conference on Runtime Verification (RV  '14). The event was organized in three tracks: (1) offline monitoring, (2) online monitoring of C programs, and (3) online monitoring of Java programs. This paper conveys the experience on the procedures, the rules, the participating teams, the benchmarks, the evaluation process and the results of CRV'14. This paper complements and significantly extends a preliminary report that was written before RV'14  [4].
The instrumentation information describes of a mapping from concrete events in the program (for example method calls) to the abstract events referred to in the specification. For instance, if one considers the HasNext property on Java iterators (that a call of the method next on an iterator should always be preceded by a call of the method hasNext that returns true), the mapping should indicate that the hasNext event in the property refers to a call to the hasNext() method on an Iterator object, and similarly for the next event. Several concrete events can be mapped to the same abstract event. Offline monitoring track. In the case of offline track, each benchmark contribution is required to contain the following: -A trace, in either CSV, custom, or XML format, and a description of the event kinds contained in the trace.
Larva Larva  [34]  is a Java and AspectJ-based RV tool whose specification language (DATEs  [33] ) is a flavour of automata enriched with stopwatches. The automata are symbolic in that they allow the use of local state in terms of Java variables and data structures. Furthermore, Larva allows the full use of Java for the specification of conditions which decide when transitions trigger. Similarly, for each transition, an action can be specified so that when it triggers, the local state can be updated, possibly also carrying out actions on the monitored system, e. g. , to handle a detected problem. The tool design and development has been inspired by case studies in the financial industry  [32]  where there are frequent soft real-time constraints such as limits on the amount of money spent within a particular period and entity life-cycles such as limiting the kind of operations users are allowed to perform while suspended.
jUnit RV jUnit RV  [38]  is a tool extending the unit testing framework jUnit with runtime verification capabilities. Roughly, jUnit RV provides a new annotation @Monitors listing monitors that are synthesized from temporal specifications. The monitors check whether the currently executed tests satisfy the correctness properties underlying the monitors. As such, jUnit's concept of plain assert-based verification limited to checking properties of single states of a program is extended significantly toward checking properties of complete execution paths. To support specifications beyond propositional properties, jUnit RV uses a generic approach to enhance traditional runtime verification techniques toward first-order theories in order to reason about data. This allows especially for the verification of multi-threaded, object-oriented systems.
The failure state is an implicit non-accept state with no outgoing transitions; once the failure state has been reached, success (for this binding) is not possible. The MarQ tool implements an incremental monitoring algorithm for QEAs. A structural specialization module attempts to specialize the algorithm based on structural properties of the specification. Singly quantified specifications are directly indexed; otherwise, a general symbol-based indexing approach is used. For monitoring Java programs, MarQ is designed to be used with AspectJ. It also implements mechanisms for dealing with garbage collection and can either use reference or semantic identity for monitored objects.
The stream can be seen as a sequence of timestamped databases, each of them consisting of the events that have occurred in the system execution at a point in time. Each tuple in one of the databases' relations represents a system action together with the involved data. For a given event stream and a formula, MonPoly outputs all the policy violations (Table  4 ). Further details on MFOTL and the tool's underlying monitoring algorithm are given in  [12, 13, 15]. MonPoly has been used in real-world case studies, in collaboration with Nokia Research Lausanne  [11]  and with Google Zurich  [14]. Further performance evaluation and comparison with alternative approaches can be found in  [12]  and  [15].
The language can support propositional events and/or parametric events, depending on whether runtime events cannot carry or, respectively, can carry data values. Generally, more expressive specification languages require more complex monitoring algorithms. The monitoring code can be generated from a high-level specification language or directly implemented in a programming language. Instrumentation The entry own instrumentation indicates that the tool implements its own instrumentation phase of the RV process. The entry relies on AspectJ indicates that the tool uses AspectJ for instrumentation purposes. The entry relies on another technique indicates that the tool uses a third-party technique and/or tool different from AspectJ for instrumentation purposes. Monitored systems The entries in this category have their expected meaning and indicate the kind of systems that the tool can monitor (C programs, Java programs, or traces).
Maximum chunk size in Dropbox connections This benchmark is provided by RiTHM team. Description of the monitored program The program simulates Dropbox connections. The program uses the dataset described in  [43]  to run the simulation. Description of the property The property states that for all connections, it is always the case that chunk size (used to split files) is less than or equal to 999,999. The property is formalized using a fragment of first-order LTL  [68]  as follows: ∀connection : G (chunksize(connection) ≤ 999,999).
Changes in the chunk size of Dropbox connections This benchmark is provided by RiTHM team. Description of the monitored program The benchmark uses the same program as the one in the benchmark described in Sect. 4. 1. 1. Description of the property The property states that for all connections, it is always the case that when the chunk size becomes strictly larger than 10,000, its value eventually becomes less than or equal to 10,000. The property is formalized using a fragment of first-order LTL  [68]  as follows: ∀connection : G(chunksize (connection) > 10,000 ⇒ F chunksize(connection) ≤ 10,000).
Description of the monitored program The program finds the next highest number that is a palindrome after a number provided as input. The program has been modified by adding a heap-based buffer overflow when reading the input number. The number is written with an unbounded string copy to the heap allocated buffer 'k' of size MAX_LEN (300). The program contains a call to strcpy() that copies a single character from the input string to the buffer, and this line is reached multiple times as the program scans over the input string. The program is a test case of the STONESOUP test suite  [17] , a collection of test cases in the C and Java languages produced by the NIST.
A client can invoke a number of actions to access their (money) accounts which they have registered on FiTS-actions which they may invoke through an online interface. Information about each registered client is stored in a database, including information such as the client's name and country of origin, and client classification information. Under FiTS, each client may be associated with a number of money accounts belonging to him. Clients may request the creation of a new account or close down one of their accounts at any point in time. To access accounts, an existing client may open a login session on FiTS to make transfers or manage their money accounts. A user may have multiple sessions open at the same time. The following properties are specified in a guardedcommand language (GCL) as a series of Java-based rules of the form event | condition → action.
HasNext on DaCapo Batik This benchmark is provided by the QEA team. Description of the monitored program The considered program is the DaCapo  [22]  Batik benchmark, which is a single-threaded benchmark that produces a number of Scalable Vector Graphics (SVG) images based on the unit tests in Apache Batik. Description of the property This is the standard iterator based property used frequently as an example for runtime verification of Java properties. Informally, the Java API requires that for each Iterator object the hasNext() method be called and return true before the next() method is called. The following QEA captures the HasNext property. There are two states which capture the status of unsafe and safe iteration, respectively, i. e. , when it is valid to call next() (mapped to donext to distinguish it from the state modifier).
Description of the property The HasNext property often leads to false positives when a collection's size is used to iterate over its contents, as is the case in the following code snippet. int size = collection. size (); Iterator < Object > iter = collection. iterator (); for ( int i =0; i < size ; i ++){ doStuff ( iter. next ()); } A more lenient property is to restrict the number of iterations to the size of the underlying collection. The property can be captured by a QEA with two states. The iterate state is entered when the iterator is created and a donext event can occur as long as the number of previous donext events is no more than csize. As iterate is a next state, if the transition cannot be taken due to the guard csize > 0 failing, then there is a transition to the failure state.
Description of the traces The traces of this benchmark are extracted from a real-world dataset  [43]. The dataset contains various attributes of Dropbox connections. The dataset is preprocessed, and the details of chunksize used for file-transfer are extracted from the connections. Description of the property This property expresses the requirement that for all connections, it is always the case that chunksize is lesser than or equal to 999 999. The property is formalized using a fragment of first-order LTL  [68]  as follows: ∀connection : G (chunksize (connection) ≤ 999999).
Evolution of the chunksize of Dropbox connections This benchmark is provided by the RiTHM team. Description of the traces. This benchmark uses the same dataset of Dropbox traces as the benchmark in Sect. 4. 3. 1. This property expresses the requirement that for all connections, it is always the case that when chunksize becomes strictly greater than 100 00 , its value eventually becomes lesser than or equal to 100 00.
Maximum bandwidth for Youtube connections This benchmark is provided by the RiTHM team. Description of the traces For this benchmark, RiTHM processes a real-world dataset  [85] , which contains logs for Youtube connections on a campus network. The dataset is preprocessed, and the value of bandwidth is calculated for each Youtube connection using various parameters in the original data. Description of the property This property expresses the idea that for all connections, it is always the case that the bandwidth lesser than or equal to 100,000. The property is formalized using a fragment of first-order LTL  [68]  as follows: ∀connection : G (bandwidth (connection) ≤ 100,000).
Description of the property The property expresses requirement that for all processes and for all files, it is always the case that if a file is opened, then it is eventually closed by the process. A similar condition is expressed for sockets. The property is formalized using a fragment of first-order LTL fragment  [68]   Common to all the benchmarks is that the considered properties are policies in IT systems. In the following, we describe the log format and the property of each benchmark. The provided MFOTL formalizations are close to MonPoly's input format. In particular, we use a textual representation of the Boolean connectives and the metric temporal operators. MFOTL's semantics follows the standard semantics of first-order logic and the real-time logic MTL. See  [12] , for details on MonPoly's specification language.
Description of the log The log file is syntactically generated and is provided in CSV format. To represent a sequence of timestamped databases in this format, we have used the conventions explained next, illustrated by the following example. trans,tp=10,ts=32,c=Alice,t=132,a=2035 trans,tp=10,ts=32,c=Bob,t=135,a=2100 trans,tp=11,ts=32,c=Charlie,t=137,a=60 report,tp=12,ts=38,t=132 Each line corresponds to one tuple in one of the timestamped databases. The name of the relation to which the tuple belongs to is given by the first, unnamed field. The next two fields are: 1) the index of the database in the sequence, called time point, and 2) the timestamp of the database. The other fields provide the tuple's value on each attribute of the corresponding relation. For instance, the first line in the previous log excerpt corresponds to a transaction event of the customer c = Alice with the transaction number t = 132 and the amount a = 2035.
Description of the log The description of the log format is presented in Sect. 4. 3. 6. The log file in this benchmark is taken from a real-world case study  [65]  and is publicly available on the MonPoly's web page in an anonymized form. The log is 14GB large. The following property is violated on the log file. Description of the property This property is taken from the case study  [65]. Several policies stipulate restrictions on the usage of data in Nokia's Lausanne data-collection campaign  [65]  in which sensitive data is uploaded by smartphones into the database db1 and propagated to the databases db2 and db3, where it is eventually stored anonymized. The property used for the competition stipulates that data may be inserted into db3 only if it was inserted into db2 within the last minute.
The property's formalization in MFOTL is: ALWAYS FORALL u, p, d. insert(u, db3, p, d) AND d = unknown IMPLIES ONCE[0, 60) EXISTS u , q. insert(u , db2, q, d). The event insert(u, db, p, d) corresponds to a logged SQL insert operation performed on the database db by the database user u, involving the campaign participant p and the data d.