dataesr/scientific-paragraphs-categorization huggingface dataset:
6). To indicate the importance of iteratively improving a LCA study, Figure  16. 6 shows that the revised assumptions further reduce the environmental impacts of the innovative scenario, improving from -2. 8 to -5. 3 ecopoints per ton of calcium carbonate removed from water. Note that a negative value signifies a positive contribution to the environment -in this case, avoided emissions. The changes in the data inventory are not only a result of new insights (more detailed information regarding calcite production), but also of improved information in the inventory database used (an update to the EcoInvent database) and impact assesment method  (Huijbregts et al. , 2016). Given that these new assumptions lead to an environmental impact that improved almost twice, it is very important to occasionally revise an LCA study and reevaluate the assumptions used.
Completeness and representativeness of database information Conducting an accurate environmental impact study is strongly dependent on the quality of the database. It is critical to use a database that is trustworthy -for example, one that goes through regular and independent review processes. The database should be transparent and well documented, and the origin of the data should be clear. The data in commercially available databases may not always be representative for a given case. Examine the completeness of the process with regard to issues such as whether transport is included, whether the material is packaged, or whether the chemical production method aligns with the specifics of the application. For example, sodium hydroxide can be produced by different methods, resulting in different environmental impacts.
Furthermore, sometimes processes in a database represent the mass of the bulk solution, but at other times the database corrects for the quantity of active substance contained within the solution. Always check if the processes behind the indicator apply to the case at hand, and if not, try to obtain data from the parties in the value chain. Another issue relates to whether all the data required for the impact analysis are available in the database. For example, the ReCiPe method does not include characterization factors for some emissions (i. e. , there is not a default value to normalize an emission to the constituent units, such as kg-CO 2 eq. for global warming potential). According to the ReCiPe method, chloride, sodium, and bromide emissions to water have no environmental impact  (Huijbregts et al.
0 database information of market conform electricity database in 2019). As a result, for a resource recovery method that is highly reliant on electricity, its environmental impacts may vary significantly when estimated for different countries. Another essential parameter that can differ among case studies is the quality of the resource that is recovered. If calcium carbonate is recovered within the drinking water treatment process, the quality of the lime may vary. This variation is a direct result of differences in influent water quality and composition. As a result, one should be conscious of these challenges and avoid drawing general conclusions from specific case studies.
Comparisons with previous studies During research, comparisons with previous studies are both desired and necessary. However, it is crucial to understand that new results cannot always be directly compared to previous studies. For example, differences in the functional unit require that each set of results be reframed using a consistent functional unit. Also, different databases or impact assessment methods may have been used. Furthermore, in the case of ecopoints, it is vital to know that the total annual impact of one person living in Western Europe is defined as 1000 ecopoints  (Baayen, 2000). As per capita environmental impacts change, the values from different years cannot be directly compared.
7 and 10. 8, respectively. Note how the equilibrium data for struvite precipitation has now been added into the model (Figure10. 7) because it was not previously in the model database. In the coding, log_k refers to the common logarithm of the solubility product constant, which in the case of struvite is -13. 26 (K sp,struv= 10 -13. 26 ). The results show that pH of the wastewater will rise to 7. 98. Moreover, the simulation now gives free ions concentrations of [PO4-3 (aq)] = 6. 098 × 10 -7 molal; [Mg +2 (aq)] = 2. 402 × 10 -3 molal; [NH 4 + (aq)] = 6. 890 × 10 -2 molal; and I = 0. 08849 molal, from which IAP struv = 10 -11. 40 > K sp,struv and SI struv = 1. 86. These show that by adding NaOH to increase the wastewater pH, conditions have been.
Figures 10. 10 7 and 10. 8, respectively. Note how the equilibrium data for struvite precipitation has now been added into the model (Figure10. 7) because it was not previously in the model database. In the coding, log_k refers to the common logarithm of the solubility product constant, which in the case of struvite is -13. 26 (K sp,struv= 10 -13. 26 ). The results show that pH of the wastewater will rise to 7. 98. Moreover, the simulation now gives free ions concentrations of [PO4-3 (aq)] = 6. 098 × 10 -7 molal; [Mg +2 (aq)] = 2. 402 × 10 -3 molal; [NH 4 + (aq)] = 6. 890 × 10 -2 molal; and I = 0. 08849 molal, from which IAP struv = 10 -11. 40 > K sp,struv and SI struv = 1. 86. These show that by adding NaOH to increase the wastewater pH, conditions have been.
Processing large cohorts of data is very important to increase statistical power in neuroscience and neuroimaging. The Brain Imaging Data Structure (BIDS) standard has been developed to facilitate this task, but researchers are still facing the challenge of reusing scripts to analyse data coming from different projects or different centres. Here, our goal was to develop a tool, BIDS Manager-Pipeline, to process automated analyses using open-source research software solutions on several subjects at the same time. BIDS Manager-Pipeline builds upon BIDS Manager, a software recently developed in our lab to collect, organise, and manage multimodal multicentre datasets. When processing data, BIDS Manager-Pipeline coordinates the use of several modules originating from different software environments and executable programs and can thus be considered as a bridge between BIDS datasets and software solutions.
Through a graphical user interface, users can filter the subjects of interest in the dataset by ID or by other subject criteria and common input analysis parameters. BIDS Manager-Pipeline first controls whether the selected values can be applied to the selected subset, provided the inputs and the outputs, and then run the process on all selected data. The results of analyses are stored using specifications for BIDS derivatives. In addition, BIDS Manager-Pipeline creates a table gathering the different metrics resulting from the analyses across subjects, for later statistical analyses. In short, BIDS Manager-Pipeline allows processing data from large cohorts, either in basic neuroscience or in clinical research. This framework can take advantage of tools developed by the neuroscience community, by centralizing and facilitating their use.
e. standardized folder structures and easily accessible meta-data, an important re- maining need is to run data analysis pipelines on the whole or on parts of the data structure. For neuroimaging data, the BIDS community developed a way to integrate any BIDS format dataset as a software input by creating a "container image capturing a neuroimaging pipeline"  [9] , which can be distributed to the community as BIDS-App through a website. For example, Freesurfer  [10]  has been implemented as a BIDS App in order to obtain the surface reconstruction from subjects in the BIDS dataset by providing the subject ID and the path of the BIDS dataset directory to the BIDS-APP/freesurfer. However, there is a need to handle the structure as a database i. e. , to select specific subjects by criteria and to handle the outputs in derivatives folder for further statistical processing.
This is the objective of the BIDS Manager-Pipeline (BMP). To develop BMP, we started from the BIDS Manager that creates BIDS datasets  [8] , and developed an extension to analyze these datasets. In a nutshell, BMP allows running programs, called "modules", in executable form or Matlab script with the selected data as arguments. The results are written in the derivatives folder within the BIDS structure. The important point is to be able to run the software on a big amount of data from different subjects without changing/adapting the software. This extension is intended to be user friendly and accessible to computer novices. In this article, we introduce the BIDS Manager-Pipeline framework for selecting a subset of subjects within a BIDS dataset, running signal processing modules, and organizing the results into summary tables.
What is BIDS Manager-Pipeline? BMP is an extension of the BIDS Manager  [8] , and allows launching processes on a BIDS structure. In order to determine the specifications of BMP, we took as examples existing in-house software from GIN (f-tract. eu/software) [11]  and INS laboratories (meg. univ-amu. fr/wiki) [12] [13] [14]. The requirements were i) to run existing modules on multiple subjects at once and ii) to make BMP usable by people with basic knowledge in computer science. As described in Fig. 1 , the developer has to create a software module, a corresponding JSON file and to place them in a BMP package. Then the user can call the module through BMP without knowledge about the architecture of the module. BMP manages the subjects and parameter selection as well as the input and output to the modules.
Different modules can be integrated to BMP, independently of their origin (custom made or obtained from the community), providing that the piece of software or script can be called in command line and accepts input parameters. For example, BIDS APP developed by BIDS community can be run from BMP if Docker is installed on the computer  [9]. If Matlab (MathWorks, Naticks MA) is installed, Matlab scripts (without compilation) can be launched from BMP. The main asset of BMP is to allow performing multiple subject analysis even if the module was not developed for it. BMP manages to launch the module on all selected subjects, and to collect results into a summary table.
For example, "docker run -ti -rm". The key "Intermediate" specifies which environment to use in order to run the module, for example Matlab, Docker or AnyWave  [13]. The key "Callname" is the name of the module used in the command line. The key "Parameters" determines the input, the output and what values have to be passed to the module. "Parameters" is itself a python dictionary with key/value pairs (see Fig. 2  for an example of JSON file). The type of parameters that are accepted are: -Number type: Two values must be specified, the "Default" value and its "Unit". For the duration of interest of a signal, one could write "Default": 10, "Unit": "s". -Value read in the database: Three values must be specified, the "Read" key is to inform BMP which file (in the BIDS Dataset) should be read to extract the value and propose it to the user.
The "ElementsToRead" key is to inform which part of the file should be read. The "MultipleSelection" key is to know if the user can select multiple value for this specific parameter. -Value specific to BIDS: Two values must be specified, the "ReadBids" key is a Boolean to say if BMP should take the value in BIDS key. The "Type" key is to specify which attributes from BIDS data (e. g. , sub, ses, task). -Specific value: Two values must be specified, the "PossibleValue" key should be a list of the value accepted by the module for this parameter. The "MultipleSelection" key is to know if the user can select multiple value for this specific parameter. -Boolean value: Two values must be specified, the "Default" key is the default Boolean value of the module for this parameter. The "InCommandLine" key is to mention if the key to this parameter should appear (in command line) with its value or if only the key should appear its value is true.
-Path to a file: Two values must be specified, the "FileLoc" key will be filled in by the user with the GUI. The "Extension" key should mention the extension of the file. Let us use the Delphos module  [12]  as an example to understand the different parameters. Delphos is an automated detector of epileptic spikes and oscillations used in clinical research  [15]. One version of this module can read a BIDS database and perform the detection, taking as input information the type of data to analyse (e. g. , the attributes of data name: sub, ses, acq, task). Below is an example of how to call it in command line: D:/Software/Delphos4BIDS/Delphos4BIDS. exe bids_dataset_directory sub "01, 02" start 0 duration 10 detection_type "Osc, Spk" freq_band _start 8 artefact "artefact" use_markers "Stim" threshold 40 derivatives "bids_dataset_directory/derivatives/delphos" Here, we wish to detect epileptic spikes and oscillations above 8 Hz during the marker "Stim" while avoiding artefact sections labelled as artefact for subject 01 and 02.
The marker "Stim" should have a minimum duration of 10 s to be analyzed. The associated JSON file (Fig. 3 ) mentions that Delphos needs the BIDS directory as input, the 'sub' parameter is "ReadBids" argument, 'start', 'duration', 'freqband_start' and 'threshold' are number arguments, 'detection_type' and 'use_markers' are specific value arguments, 'artefact' parameter requires to read in the dataset the different events available and the output required is a directory to write the results. The last parameter mentioned in the JSON file is "freqbandfile" which requires a txt file; this parameter is optional. In case the command line for calling the module requires a specific order of input parameters, BMP always write the command line in the order of the arguments given in the JSON file. The command lines used for the analysis are saved in a log file in derivatives/bids_pipeline/command_line folder in the dataset.
A. Module, Subjects and Parameters selection: Once the user has selected a module from BMP list (Fig. 5. a), a verification is made to make sure that the associated JSON has the required attributes, and the module path is specified and valid. Then, an interface is opened to select the subjects and parameters (Fig. 5. b). On Fig. 5. b, the first frame is dedicated to subject selection. The selection of subjects is divided into four options: select all participants, select participants ID, select participants by criteria, or select subjects that were not selected in a previous analysis. The third option is proposed according to the information contained in the participants. tsv file of the BIDS dataset. The participants. tsv file is required by BIDS specifications; it contains the list of participants ID included in the database and their related information.
For example, if the age, sex, and handedness is present in the participants file, the user will be able to ask BMP to perform the analysis on female right-handed participants between the age of Fig. 3. JSON file describing Delphos module. The first keys give the name and the path of the executable on windows machines. The parameters state that the module is in automatic mode, and that it needs to be called as "Delphos4BIDS". The module requires a BIDS directory as input, and a directory to write the results. All keys are described in the main text. 20  and 60. The last option is to select subjects that were not included in a previous analysis made by BMP. The user selects the folder corresponding to the analysis in the derivatives folder and BMP will select the subjects of the dataset that are not present in this folder and fit the criteria of the analysis.
B. Output directory creation/selection The output directory selection is summarised in Figure  4. 2. In the JSON file, there is a key named "Output". If this key is mentioned, it means that the module requires an argument specifying where to write the results. It can be the output files or only the output directory to write the results. Each module has a dedicated directory in the derivatives where to write the results; this directory is structured in the same way as the raw data. The directory name should be the one of the modules (e. g. , "delphos"). We decided to write the parameters and the analysed subjects in the dataset_description. json on the previously mentioned output direc-tory as BIDS requires a dataset_description. json file to be present in the output directory in the derivatives.
Having the parameters in the dataset_description. json file allows the future user to reanalyse the data with the same parameters. In this file, only the name is required by BIDS specifications, but we decided to add the two elements mentioned above to have a better description of the available results. Moreover, the dataset_description. json file is used by BMP to select the output directory for each module it has called. If the module was launched several times on the dataset with different parameters, a different name is used as the output directory, containing a version key (e. g. , v2, v3) to identity the different runs. Once the module name is given, BMP goes through the derivatives folder to check if the module directory is present. If the module is present, the selected parameters and subjects will be compared to the one set in the dataset_description.
The creation or selection of a directory will depend on this comparison. The existing directory is selected as output directory of the module if the parameters selected by the user match the parameters written in the dataset_description of the directory and if the subjects are different that the one written in the dataset_description. This option was introduced to avoid overwriting the results. However, if the selected parameters do not match those in the dataset_description of the directory, a new directory is created for this module. (Figure  4. 2) This step is avoided if the user selected the last option in subject selection because BMP already know the output directory. Another way to avoid this step, it is when the user decides to save the results locally and not in the BIDS dataset. The last step is to run the module according to the selection.
C. Run Pipeline The run pipeline procedure is summarised in Figure  4. 3. Once all arguments are set, BMP creates the command line according to the parameters, the input, the outputs, and the module type (Matlab, executable, AnyWave plugin, BIDS App). If multiple subjects are selected and the module is not able to handle it, BMP creates a command line for each subject and runs it. The command line is created by combining the parameters listed in the json file and the corresponding values as set by the user. Then, BMP searches for the input files and launches the command line on each file. Finally, the output files are created and stored in the desired location Once, BMP get the inputs and outputs values (see Algorithm 1 for details). Finally, when all processes are done, BMP does several verifications.
First, the logs from the module are retrieved to display them in BIDS Manager and to write them in a new log file in the derivatives/bids_pipeline/log directory. Secondly, BMP verifies the content of the output directory. If the output directory is empty, the directory is erased; otherwise, BMP controls which subjects have been fully processed and informs the user. Thirdly, a participants. tsv file is written in the output directory listing the IDs of analysed participants. Fourthly, the dataset_description. json file is updated for the analysed subjects.
Statistics table The last feature of BMP is to create a table for further statistical processing, summarizing the output of the processes run on the dataset. For now, this option is only available for electrophysiological data (electroencephalography -EEG; magnetoencephalography -MEG; stereotactic iEEG -SEEG) as the table is organised around the channels. The goal is to summarize all the processes performed on the dataset in one single table. Each analysed file of each subject is present in the table and the different metrics (i. e. , the results of the processes) are given across channels. As column, the table has the subject ID, the channel, then the different results of the modules. Each raw represents one channel (or bipolar montage) of one subject. To create the table, as there can be several versions of the same module, the user can select the modules and versions that should appear in the table (Fig.
Use case one: HBP project BMP has been tested and integrated to the Medical Informatics Platform and Human Intracerebral Platform of the Human Brain Project, which is expected to be delivered by the end of 2022 (https://www. humanbrainproject. eu /en /medicine /humanintracerebral -eeg -platform/). To create the dataset of this use case, we converted intracranial electrophysiology and anatomical data of the F-TRACT project (f-tract. eu) to BIDS using the BIDS Manager  [8]. The dataset contains fully anonymized data from 217 subjects and is available, without structural imaging information for anonymization purposes, on EBRAINS, the platform of HBP (https:// search. kg. ebrains. eu /instances /Dataset /ebe50517 -41d5 -4029 -9355 -04f1e49e23c8). BMP was used to analyse the baseline before the intracerebral stimulation and to obtain the coordinates of the SEEG electrodes.
To analyse the baseline, three processes were used. The first process is named baseline_marker and is a homemade Matlab script done specifically for this project. It determines the period before the stimulation thanks to the marker "Stimulation" and as output, write in tsv file the marker baseline with its onset time and duration. The second process is named Delphos (see above in Methods section, Integration of processing modules). Delphos is a general process made available for the neuroscience community (available at https://meg. univ-amu. fr /wiki /AnyWave :Plug -ins), it can detect epileptic spikes and oscillations  [12]. The version of Delphos used here was adapted to read BIDS dataset and be callable in command line and is not yet available online. The third process is named Gardel. Gardel is a tool to automatically localize and manually label SEEG contacts  [14].
This module requires two anatomical images as input and was originally not BIDS compatible. The first step for the project engineer (A. J. ) was to create the json files corresponding to the three processes. The inputs of the processes were the BIDS directory, and the parameters ReadBids and Type were used to specify the type of data. Gardel cannot read BIDS dataset, it requires as inputs two anatomical images, one acquired before the SEEG implantation and the second acquired during the SEEG presurgical evaluation. From these inputs, Gardel does the co-registration of the images, localises the electrodes, and as an output, it gives a text file with the coordinate of each contact of the channels. Therefore, the JSON file to describe Gardel is different than the two other modules. Then, these processes have been launched through the graphical interface of BMP one after the other.
Use case two: day hospital One part of our laboratory is dedicated to clinical research and the clinicians decided to use BIDS format to organize their research data. The data acquired are simultaneous EEG and MEG. One state-registered technician of the hospital uses BIDS Manager to import in BIDS format the acquired data and uses BMP to pre-process the data. For pre-processing, four different modules are used, all consisting in homemade plugins. The first module named Temporal_registration allows registering the EEG time to the MEG time due to difference in sampling rate and file duration. The second module named EEGinto4D allows placing the EEG data coming from the temporal_registration process in the 4D Neuroimaging data file along with MEG data. The third module named automatic_cleaning allows detecting bad channels and artefacts on MEG data.