dataesr/scientific-paragraphs-categorization huggingface dataset:
SqliteMapper SqliteM apper was the first implemented mapper for storing/retrieving objects derived from Object (the root class in our Python basic hierarchy). One of the main requirements for this mapper is flexibility, because SqliteM apper needs to deal with objects that have a variable number of attributes. For example, we have a P article class that could be mapped into an equivalent table, where the basic properties of the particle are stored. If this approach is followed, it would be hard to allow different algorithms to add information to a particle (such as a quality score) specific to the method. Furthermore, we wanted to avoid a complex database with a large number of tables, which is hard to maintain and adapt to changes in the data model. Our approach for this mapper was to create a database with a single table that could allocate all objects and their properties, which is known as the Single T able Aggregation pattern  [117].
The set S 2 can be aligned and classified in 2D, from which one could create a subset (that also preserves the RELAT ION T RAN SF ORM ) S 3. Since we have the transformation path S 1 → S 2 → S 3 , we could extract some properties from The resulting SqliteM apper class fulfilled our requirement of flexibility, since it allows to store and retrieve any kind of objects in a relatively simple way. This mapper is used for the two main databases of a project: project. sqlite and settings. sqlite. The first one stores information related with the different runs in the project while the second maintains tracks of the project GUI status.
SqliteFlatMapper Since we work with many sets in a given EM project (micrographs, CTFs, particles, etc), and they could contains large number of items, we store each set separately of the project database. In this way we could load items on demand and reduce the risk of performance issues if the database grows too much. First we tried to used the same SqliteM apper to store set elements, but soon we realized that it was not particularly well suited for this task. The main problem with SqliteM apper was the persistence strategy, that was focused in flexibility rather than performance. For large sets, storing several rows per object was not affordable and it also reduced the efficiency of iterating over the set. These limitations led us to implement a different mapper, SqliteF latM apper, to be used for datasets management.
At this time, the mapper also computes the IN SERT and U P DAT E SQL statements that will be used for inserting and updating items. For each new object, its attributes are retrieved and stored into the database. This approach requires that all items stored in the set should be of the same class and contain the same attributes. Since this is normally the case for EM sets, this requirement does not represent a problem. Usually, each Set uses a separate Sqlite database file to store the data. For example, a SetOf P articles is commonly persisted in a particles. sqlite file. When storing a set, two tables are created: Classes and Objects. The Classes table contains the list of columns (numbered c 1 , c 2 ,. c n ) that will be present in the Objects table and their mapping to the corresponding object attributes.
In this table the attribute name and class are also stored to allow re-constructing the object from their recorded values in a given row. The Objects table has one row per item in the set, containing the values for the object attributes. The Figure  4. 4a shows the Classes table of a SetOf P articles database where the label property column have the nested names of all attributes of a P article object. It can be seen the corresponding column in the column name column and the Python type in class name. With this information, P article objects can be retrieved from the values of each row in table Objects (shown in Fig. 4. 4a). In some cases, more than one set can be stored into the same physical database to avoid the need of many files. This is the case when storing SetOf Classes2D, where each class.
Web Interface and Online Tools Online web applications and tools are common in Bioinformatics, providing easy access to algorithms without the need of local software installation. This is not the case for EM, mainly because most of the operations involve manipulation of huge datasets that are not easy to transfer. Nevertheless, a few examples already exist for specific tasks of the processing pipeline. The European Bioinformatics Institute hosts the tilt pair validation server (http://www. ebi. ac. uk/pdbe/emdb/validation/ tiltpair/) and the Fourier shell correlation server (http://www. ebi. ac. uk/pdbe/ emdb/validation/fsc/). Maskiton  [118]  is a web interface to facilitate the creation of 2D masks and classification of aligned datasets. Another example is found for Electron Tomography, where a web application was build on top of the existing PyTom package  [119, 120].
Execution engine The whole Scipion framework heavily relies on the underlying execution engine, i. e. , how jobs are setup and launched, or how protocol steps are executed. This section describes the mechanisms used by Scipion to facilitate jobs management for users, as well as for developer during protocols development. To understand the implementation of the execution engine, it may be helpful to analyze a standard use-case. When a user opens a project, related information is loaded from the project database, together with other graphical settings. After that, the user can select any existing protocol (or create new ones), fill its input values and then execute it (Figure  4. 11 1). The P roject process will then load (or create) a protocol instance to generate the parameters form and to validate the input values.
As mentioned in previous sections, if the input validation fails for a protocol, it is not launched and the errors are shown to the user (Figure  4. 11 2). If the validation is passed, Scipion prepares the conditions for the protocol execution. First, the project database is updated with the new state of this protocol (LAUNCHED). Secondly, the necessary folders are created (or cleaned up) to contain the resulting files of the protocol execution. A separate database is created for this run exclusively, which means that it will not need to access the main project database for recording its progress and results. Finally, the protocol is executed, either directly by spawning a new process or by submitting it into a job management system. In the case of a job management system, Scipion will generate the required script to submit the job to the system.
oracle. com/us/products/tools/ oracle-grid-engine-075549. html). Each protocol is executed in an independent process, spawned either by the jobs management system or directly by the P roject process (Figure  4. 11 3). The new process will load input values and the project environment from its own database. Depending on the inputs, the protocol will create the list of steps that needs to be executed. The class StepsExecutor will handle the execution of the steps, ensuring the proper synchronization and their dependencies. In some cases, it is desired not to recompute all completed steps, for example, when continuing a job after an unexpected shutdown or when changing parameters that only affect some steps. Protocols have a Resume mode, in which Scipion only execute steps whose parameters have changed or that have not been executed previously.
For each run, Scipion uses the steps. sqlite database to record the steps, their parameters and their status. When a protocol runs in Resume mode, the current list of steps is compared with the previous list (if exists) stored in steps. sqlite to determine which steps need to be executed. Scipion provides this re-starting mechanism to developers, who only need to care about defining relevant parameters for each Step function, but not about the underlying implementation. Another built-in feature for developers is the parallel execution of steps. As discussed before, the developer can easily specify dependencies among the steps in the insertAllSteps function. Step dependencies make sense when some tasks can be done simultaneously and multiple cores are available for computing. The developer can set the protocol execution mode to ST EP S P ARALLEL for enabling the parallel execution.
In that case, Scipion can use either POSIX threads or MPI processes to execute steps concurrently. When using threads, the T hreadStepExecutor class is instantiated and it will spawn N threads (N is the number of parallel processes selected by the user) to work on the steps until the whole protocol is finished. There is a master thread that manages the work of the other threads and tracks the run progress into its database. The behaviour is similar when using MPI, but in this case N processes are created within the MPI environment. Only one of the processes will execute the protocol steps as usual, but the others will be in a "slave" mode, waiting for commands from the master process. The M P IStepsExecutor class is based on T hreadStepExecutor, but each thread will send the commands to its associated MPI slave instead of executing it itself.
Optimization of CNB Microscope Acquisition Parameters After the Talos-Artica microscope was installed in the CNB, Dr. Daniel Luque used Scipion to run several experiments to calibrate some of the acquisition parameters and to find optimal parameters for the first steps of the workflow. As a test case, he used a Circovirus dataset acquired in the Talos microscope. Following are some of his findings: 1. Comparison between 73k and 92k magnification for image acquisition: The comparison was performed between a dataset of 58k particles extracted from the 73k images (calibrated pixel size of 1. 37 Å/px) and another dataset of 89k particles extracted from the 92k images (nominal pixel size of 1. 14 Å/px). In both cases, 31 frames were averaged using first correlation global alignment plus the optical flow local alignment.
The obtained resolutions were similar at all frequencies, except for higher ones, where the 73k dataset seems to have a better resolution. Moreover, the pixel size was calibrated for the 92K dataset. It was found that from the nominal pixel size of 1. 14 A/px, the calibrated one is 1. 09 A/px. 2. Comparison of the selected frame range for movie alignment: Using the 73k images, the same set of 58k particles was re-extracted and refined using a difference range of frames. For all the tests, the alignment was done using correlation and optical flow. It was found that the maximum resolution was obtained for a subset of frames between 13 and 16.
Comparison of different combination of programs for movie alignment: The same dataset of 58k particles (with 73K magnification) was used to compare the following combinations for movie alignment: (a) correlation plus optical flow, (b) motioncor2 and, (c) motioncor2 with dose compensation. For this comparison, all frames from 1 to 31 were used for the alignment. After the experiments, it was found that both cases (a) and (b) yield similar results, while (c) was slightly better, in terms of the resolution. The possibility to easily repeat branches from the processing pipeline greatly simplified the execution of all these experiments to calibrate the microscope and to find optimal parameters. Moreover, Scipion full track of the parameters and logs allowed a more complete analysis of the results.
Data Processing for 3DEM Map Challenge Another important showcase of the Scipion value was its utilization for the 3DEM Map Challenge which is a community-wide challenge being sponsored by EMDataBank, started in 2015 to critically evaluate 3DEM methods that are coming into use, with the ultimate goal of developing validation criteria associated with every 3DEM map and map-derived models (http://challenges. emdatabank. org/?q=2015_map_challenge). Seven structures (GroEl in silico, T20S Proteasome, Apo-Ferritin, TRPV1 Channel, 80S Ribosome, Brome Mosaic Virus and β-Galactosidase ) were defined as the challenge targets. These targets were based on recently described 3DEM single particle structure determinations with data collected as movies, using the latest generation of detectors. This challenge provided us with an extraordinary scenario for testing Scipion capabilities to carry out several EM processing experiments while keeping track of the different workflows.
Additionally, published structures for each dataset were available, so we could compare the results obtained with Scipion with an official reference. In our case, we were particularly interested in measuring the improvements of the final reconstruction when applying our local movie alignment method based on optical flow  [6]. We submitted 12 maps, coming from six structures (all targets except Apo-Ferritin). For each structure, we obtained two maps resulting from two movie alignment strategies. In one case, we used only the motioncor (MC) program for global alignment. In the other case, after MC we also applied optical flow for local correction (MC+OF). All obtained maps were compared with its corresponding map calculated from the PDB, obtaining a FSC curve. Table  5. 1 shows the results for each processed structure, all reported resolutions corresponds to FSC=0.
This information was used to improve the understanding of the molecular details of vaccine-induced protection against Neisseria meningitidis. In another project, in collaboration with Pascal Albanese and Cristina Pagliano, the target was the Photosystem II (PSII), involved in the water splitting reaction (powered by sunlight) of the photosyntetic process. Although the X-ray crystal structure is available for PSII cores from cyanobacteria at 1. 9 Å  [126] , for the PSII core from higher plants only an intermediate resolution (8 Å) structure has been obtained so far by electron crystallography  [127, 128]. In this case, a dataset of cryo-EM images was previously acquired. The objective of the collaboration was to further refine the 3D reconstruction of this supercomplex toward high resolution by processing a new dataset in the Scipion framework.
In a future, if more developers are engaged in the project, this delay can be minimized, or even removed if we work together in the release timings. Furthermore, Scipion is evolving towards a plug-in system where the release of the workflow and bookkeeping engine will be decoupled from the release of new wrappers for the different programs. Some users also consider Scipion's management of files as an impediment. In Scipion philosophy, users should not deal with files and should only care about the processing input/outputs. This approach sometimes generates a feeling of "loss of control" about the data files. Furthermore, Scipion stores metadata in databases rather than text files. These database metadata files cannot be edited directly without some knowledge of SQL language. Unfortunately, there is no way around here.
Two are the main reasons. First, many processes, sometimes related with different packages, may need to access simultaneously to the same data. Therefore, a locking systems that regulate concurrent access to data and metadata is needed. Second, metadata design should be able to provide extra parameters for some packages that are not required by other packages. Furthermore, metadata should be backwards compatible even if certain modifications needed for new software are incorporated. Although these goals may be satisfied using text files it is much easier to comply with them using a database. Another aspect that can be improved considerably is the documentation. Scipion gives the possibility to easily associate tips with the parameters and a protocol description, but it is up to the developers to provide useful descriptions.
3. 3 Galaxy main windows, divided into three panels: (left) available tools grouped into categories; (middle) fill the parameters of the selected tool or to inspect an output dataset; (right) full history of actions and produced outputs. 3. 4 Galaxy workflow editor. 3. 5 Overview of Vistrails architecture. 3. 6 Graphical interface of Vistrails workflow editor. 4. 1 Protocol classes hierarchy diagram. Arrows represent "inherit from" relations. The dark boxes are the main base classes that inherit from EM P rotocol in which protocols are grouped (some arrows are not shown for clarity). 4. 2 Diagram representing the interaction of V iewers with other components.
Particle with CTFModel and Coordinate attributes. 4. 4 Example of the Classes and Objects tables of a given SetOf P articles database file. 4. 5 Scipion project window divided in three main panels: (left) protocols menu; (top-right) project workflow display as a flowchart; (bottom-right) summary of inputs and outputs, together with logs. 4. 6 (A) Generated protocol form for Spider filter-particles protocol. (B) Dialog showing the citations of this protocol. (C) Dialog to browse input objects from the project database. (D) A wizard displaying the effects of the filter operation before launching the job. 4. 7 Screenshot of the showj application displaying images in the gallery mode. 4. 8 Visualization of images in table mode. In this mode user can select which columns are visible, which one are rendered and also sort by any column.
Pseudocode of SqliteMapper. store functionThe code shown in Listing 5 illustrates how to create a P article object, set some of its properties (including other objects such as CT F M odel or Coordinate), and store the particle using a mapper instance. The database table generated by this code is shown in Figure4. 3. Each row contains an id and a parent id, pointing to the parent object. Moreover, each row has a name property containing all ancestors ids and the attribute.
by Scipion. ISPyB Python requires a MySql module to be able to communicate with the underlying database and makes use of the Anaconda Python distribution. We sorted out this problem by executing a monitor protocol in Scipion, that produces the necessary data and launches an external process (with ISPyB Python) to populate the underlying database. At present Scipion is able to execute in streaming mode a small collection of protocols related with the first steps of image processing. By streaming, we mean that the data can be processed as soon as it has been acquired. In Diamond they were very interested in this feature and we planned to extend Scipion streaming capabilities to other steps in the pipeline such as particle picking or 2D classification. Apart from Diamond, the streaming capabilities in Scipion have attracted the interest of many EM facilities to do on-the-fly processing.
Listing 4 : 4 Pseudocode of SqliteMapper. store functionThe code shown in Listing 5 illustrates how to create a P article object, set some of its properties (including other objects such as CT F M odel or Coordinate), and store the particle using a mapper instance. The database table generated by this code is shown in Figure4. 3. Each row contains an id and a parent id, pointing to the parent object. Moreover, each row has a name property containing all ancestors ids and the attribute.
Over the past decade, technically reliable circulating tumor cell (CTC) detection methods allowed the collection of large datasets of CTC counts in cancer patients. These data can be used either as a dynamic prognostic biomarker or as tumor material for "liquid biopsy". Breast cancer appears to be the cancer type in which CTC have been the most extensively studied so far, with level-of-evidence-1 studies supporting the clinical validity of CTC count in both early and metastatic stage. This review summarizes and discusses the clinical results obtained in breast cancer patients, the issues faced by the molecular characterization of CTC and the biological findings about cancer biology and metastasis that were obtained from CTC.
, 2016). Building on these results, the interventional trial TREAT CTC (NCT01548677), coordinated by the European Organization for Research and Treatment of Cancer (EORTC), is a large phase II study testing the effect of trastuzumab on CTC detection and survival in HER2-negative, M0(iþ) early BC (study design has been reviewed elsewhere  (Bidard et al. , 2013b) ). This clinical utility trial is currently ongoing in several European countries. In the meantime, it is important to note that, in most studies, the amplitude of the CTC-positivity individual risk of BC relapse and death, as measured by hazard ratio, is not inferior to that of the usual prognostic factors (tumor size, grade, proliferation, node involvement. ) that are currently taken into account for the adjuvant treatment decision.
Other comments have been made on the trial's design and concepts  (Alunni-Fabbroni et al. , 2014; Bidard and Pierga, 2015). On the basis of these negative results, the 2015 American Society of Clinical Oncology clinical practice guidelines for CTC count considered reasonable for clinicians to not use CTC count in women with metastatic BC  (Van Poznak et al. , 2015). While this negative trial had a major impact on the use of CTC count by US clinicians, two other clinical utility trials based on CTC count are currently ongoing in France: The "CirCe01" trial (NCT01349842) is also based on the early changes of CTC count, but patients are enrolled before the start of third line of chemotherapy and followed with the CTC test throughout the successive lines of chemotherapy. The "STIC CTC" trial (NCT01710605) investigates the clinical utility of the prognostic value of baseline CTC count.
In the run-in phase of the phase III CirCe01 trial (NCT01349842), which allows for a CTC-based management of chemotherapy in advanced metastatic setting, we observed that among patients with !5 CTC/7. 5 ml at baseline, a composite criteria (<5 CTC/7. 5 ml or relative decrease !À70% of the baseline CTC count) showed better prognostication for early tumor progression (within 4 months) than the proposed <5 CTC/7. 5 ml threshold  (Helissey et al. , 2015). The role played by this threshold-related issue in the SWOG0500 trial failure is potentially critical, as a non-negligible percentage of patients in the CTC arm (around 25%, according to the published progression-free survival curves  (Smerage et al. , 2014) ) have been switched off a first line chemotherapy that would have delayed tumor progression for >6 months.
The German DETECTIII study is a phase 3 study, comparing the lapatinib and chemotherapy combination vs chemotherapy alone in patients having at least 1 CTC with strong HER2 immunocytofluorescence (NCT01619111). A recent update on this study stated that about 19% of HER2-negative metastatic BC patients were screened with at least 1 CTC with strong HER2 fluorescence  (Janni, 2015a). In contrast, the French CirCe T-DM1 study is a single arm phase 2 study in which metastatic BC patients with HER2-amplified CTC (HER2/CEP17 FISH) receive T-DM1 as single therapy (NCT01975142). In this study, the discrepancy rate (patients with HER2-negative BC harboring HER2-positive CTC) is lower than in the DETECTIII trial, around 5e8%  (Bidard, 2015, p. 1). Details on these trials have been published elsewhere  (Bidard et al.
Acknowledgements This work was supported by  JSPS KAKENHI  (grant numbers  15H03837 ,  24104002 ,  24225005 ,  26620133 ) to ME and HS. Financial supports from the  Sekisui Chemical   Research Grant  and the  Kurata Memorial Hitachi Science and Technology Foundation  to ME are also acknowledged. We acknowledge the financial support of the  Aquitaine Regional Government and ANR program VIBBnano  ( ANR-10-NANO-04 ) to  JJT (Bordeaux).
Controls were run in same conditions and same IgG concentration as used for the respective primary antibodies. DAB-stained slides were observed using Zeiss Axioskop microscope and acquired by Kappa Image-Base software. Immunofluorescence staining was studied by an Olympus FV1000 confocal microscope and acquisitions were done with Fluoview FV10-ASW 1. 6 software. NIH Image J software (http://rsb. info. nih. gov/ij/) was used to quantify stained cells and data were analyzed with Prism software. Positive cells were expressed as a percentage of total cells in the tumor core. Immunolabeling has been performed in triplicate for each sample.