dataesr/scientific-paragraphs-categorization huggingface dataset:
The path model is converted into a set of equations that describe a measurement model and a structural model  (51). The validity of the measurement model was assessed using internal consistency, convergent validity, and discriminant validity. Composite reliability of the items was used to calculate internal consistency, and the convergent validity was evaluated based on the average variance extracted (AVE) scores for each construct and the outer loading of each indicator. Discriminant validity was assessed by examining the crossloading. Regarding the structural model, the quality of the relationships was measured by the R² metric, which measures the level of the explained variance of the composites. Statistical comparisons of path coefficients among the two groups of subjects were performed using multigroup comparison methods offered by the XLSTAT software within the framework of PLS path modeling presented by  Goles & Chin (2005).
EEG recording and preprocessing Fifty participants, aged between 60 and 84 years (mean age = 69. 77 years ± 1. 26 years; 40 women), were involved in a resting-state study where EEG data were collected. Among them, 26 participants were classified as belonging to the SCD group, while the remaining 24 participants were categorized as the non-SCD group. Each EEG session consisted of a 5-minute period where participants were instructed to close their eyes and relax. Participants were seated in a dimly lit room, were instructed to close their eyes and then to simply relax until they were informed that they could open their eyes. The eyes-closed resting EEG recordings protocol was chosen in order to minimize movement and sensory input effects on electrical brain activity. EEG data were collected using a 64-channel Biosemi ActiveTwo system (Biosemi Instruments, Amsterdam, The Netherlands), following the standard 10-20 system montage.
Additionally, two bilateral electro-oculogram electrodes were employed to track horizontal eye movements. Nasion-inion and preauricular anatomical measurements were made to locate each individual's vertex site. Data were digitized at a sampling rate of 1,024 Hz. The impedance of the electrodes was maintained below 20 kOhm. To preprocess the EEG data, the EEGLAB software was used  (53). The recordings were bandpassed (0. 5-70 Hz) and undersampled to 256 Hz offline. The recorded EEG signals underwent preprocessing following the PREP pipeline described by Bigdely-Shamlo et al. in 2015. Independent component analysis (ICA) was applied to remove artifacts caused by eye blinks, movement, and motion. The independent components (ICs) were classified using the SASICA plugin, which provided detailed information to guide the selection of artifact ICs  (55).
Graph measures Graph measures were obtained using several software, including LORETA_KEY (lowresolution electromagnetic tomography) package, SimiNet (Similarity Network), and BRAPH (BRain Analysis using graPH theory). LORETA_KEY enabled the researchers to estimate the intracerebral electrical sources responsible for generating the recorded scalp activity within each of the examined frequency bands  (Pascual-Marqui et al. , 2002a). The exact (e) LORETA method was employed as an inverse solution, providing precise localization of brain activity with minimal errors even in the presence of measured and structured biological noise. For connectivity estimation between regions of interest (ROIs), eLORETA intracortical lagged phase synchronization was selected. These ROIs were defined based on the available Brodmann areas (BAs) in both the left and right hemispheres, resulting in a total of 58 defined ROIs.
In terms of nodes, the algorithm follows four key steps: (i) identification of common nodes shared between the two compared graphs, (ii) substitution of nodes with a substitution cost equivalent to the distance between the replaced nodes, (iii) insertion of new nodes with an insertion cost equal to a constant value, and (iv) deletion of nodes with a suppression cost equal to the insertion cost. The second step involves calculating the distance between edges. This entails summing the differences in weight between corresponding edges in the two compared graphs. The algorithm generates a normalized similarity index, where 0 signifies no similarity and 1 represents two identical networks with the same properties and topology. Analyses were done for the delta and theta frequency bands. The computation of graph measures in this study was performed using the BRAPH software  (59).
Phylodynamic analyses can generate important and timely data to optimise public health response to SARS-CoV-2 outbreaks and epidemics. However, their implementation is hampered by the massive amount of sequence data and the difficulty to parameterise dedicated software packages. We introduce the COVFlow pipeline, accessible at https://gitlab. in2p3. fr/ete/CoV-flow, which allows a user to select sequences from the Global Initiative on Sharing Avian Influenza Data (GISAID) database according to userspecified criteria, to perform basic phylogenetic analyses, and to produce an XML file to be run in the Beast2 software package. We illustrate the potential of this tool by studying two sets of sequences from the Delta variant in two French regions. This pipeline can facilitate the use of virus sequence data at the local level, for instance, to track the dynamics of a particular lineage or variant in a region of interest.
g. sampling data, sampling location, virus lineage, or sequence quality) to generating a time-scaled phylogeny and an XML configuration file for a BDSKY model  (Stadler et al. , 2013)  to be run in the Beast2 software package  (Bouckaert et al. , 2014). Some pipelines already exist to assess sequence quality, filter data, infer an alignment, and infer a time-scaled phylogeny such as Nextclade  (Aksamentov et al. , 2021)  and Augur  (Huddleston et al. , 2021). However, these do not include a step to perform a phylodynamic analysis from the output files, which requires dedicated skills. The COVFlow pipeline addresses this limitation and integrates all the steps present in separate software packages to go from the sequence data and metadata to the XML to be run in Beast2. Here, we present the architecture of the pipeline and apply it to data from the French epidemic, which has been poorly analysed (but see  Coppée et al.
MAFFT Figure  1  -Structure of the COVFlow pipeline. The input data correspond to FASTA sequences and metadata provided by the GISAID. The data filtering is done using a YAML configuration file. The sequence alignment is performed with MAFFT and the phylogenetic inference with IQ-TREE. The pipeline generates an XML file that can be directly used with Beast2. Bioconda  (Grüning et al. , 2018)  allows for version control of the programs used in the pipeline. Overall, the pipeline is easy to install and avoids dependency conflicts.
Aligning and masking The set of sequences resulting from the data filtering is then divided into temporary FASTA files with a maximum number of 200 sequences per file. For each subset, sequences are aligned to the reference genome MN908947. 3 using MAFFT v7. 305  (Katoh and Standley, 2013)  with the 'keeplength' and 'add' options. All the aligned sequences are then aggregated into a single file. Following earlier studies, the first 55, the last 100 sites, and other sites recommended from https://github. com/W-L/ProblematicSites_SARS-CoV2 of the alignment are then masked to improve phylogenetic inference (http://virological. org/ t/issues-with-sars-cov-2-sequencing-data/473).
Inferring and time-scaling a phylogeny A maximum-likelihood phylogenetic tree is estimated using IQ-TREE v2. 1. 2  (Minh et al. , 2020)  under a GTR substitution model from the alignment. The resulting phylogeny is timescaled using TreeTime v0. 8. 1  (Sagulenko et al. , 2018). By default, the tree is rooted using two ancestral sequences (Genbank accession numbers MN908947. 3 and MT019529. 1) as an outgroup, which is then removed, with a fixed clock rate of 8 • 10 -4 substitutions per position per year  (Rambaut, 2020)  and a standard deviation of the given clock rate of 0. 0004. These parameters can be modified by the user. The output phylogeny is in a Newick format file.
BDSKY XML file generating for BEAST 2 The Bayesian birth-death skyline plot (or BDSKY) method allows the inference of the effective reproduction number from genetic data or directly from a phylogenetic tree, by estimating transmission, recovery, and sampling rates  (Stadler et al. , 2013). This method allows these parameters to vary through time and is implemented within the BEAST 2 software package  (Bouckaert et al. , 2014). Performing a BDSKY analysis requires setting an XML file specifying the parameters for the priors. As in any Bayesian analysis, this step is extremely important. The default settings in BEAST2 have been chosen to minimise the risk of errors. COVFlow builds on most of these with some modifications to fit the needs of large SARS-CoV-2 phylogenies. The most important change has to do with the inference of the phylogeny.
The length of the MCMC chain and the sampling frequency, which are by default set to 10, 000, 000 and 100, 000 respectively, can also be modified. The BEAST 2 inference itself is not included in the pipeline. The reason for this is that a preliminary step (i. e. installing the BDSKY package) needs to be performed by the user. Similarly, the analysis of the BEAST2 output log files needs to be performed by the user via Tracer  (Rambaut et al. , 2018)  or a dedicated R script available on the COVflow Gitlab page. Compared with the Nextclade pipeline  (Hadfield et al. , 2018) , COVflow allows a more flexible filtering stage using the JSON file. For example, it can select data if a column contains a certain word, allowing the user to filter data that may contain spelling mistakes or to select data from a group of laboratories that contain a common word (in our case CERBA) but don't have the same names.
Illustration study with French data We applied COVFlow to analyse GISAID data by downloading sequence data and metadata from the GISAID platform for the GK clade corresponding to the lineage B. 1. 617. 2 available on April 22, 2022, which amounted to 4, 212, 049 sequences. Using the pipeline and the editing of its JSON file, we cleaned the sequence data, selected the data collected by a specific large French laboratory (CERBA), selected the data from two regions of interest (the Ile-de-France region for a first analysis, and the Provence-Alpes-Côte d'Azur region for a second analysis), and sub-sampled the data to keep up to 50 sequences per month. These two regions were chosen because they had some of the highest coverage in the dataset, while being in different parts of France. Our third analysis included the whole country so we sub-sampled the data to keep up to 50 sequences per month per French region.
The other parameters of the pipeline were default except for the number of windows for the effective reproduction numbers in the BDSKY analysis which was set to 9 with a change-point time every month from June 01, 2021, to January 01, 2022. To evaluate the robustness of the inference, we performed 5 independent COVFlow runs for France, using the pipeline configuration described above for the France analysis. For each run, we manually extracted the two major clades representing at least 20% of the leaves from the resulting phylogeny and used a Python script of the COVFlow pipeline to generate two XML files. For each BDSKY analysis, 9 effective reproduction numbers were estimated over the same time periods. To assess the validity of the BDSKY results, we extracted SARS-CoV-2 PCR screening data from https://www.
data. gouv. fr/fr/datasets/r/5c4e1452-3850-4b59-b11c-3dd51d7fb8b5. More precisely, we used the positivity rate at the national level and in the two regions of interest. The effective reproduction number (R e ) was estimated using the EpiEstim R package  (Cori et al. , 2013; Thompson et al. , 2019). The data were smoothed out using a 7-days rolling average, in order to compensate for the reporting delays. of the Delta variant in IdF (red), in PACA (green), and France (orange) estimated using Beast2 from phylogenies in solid lines, and estimated using Epiestim from incidence data in dashed lines. The last panel was generated using Beast2. In panel c, the solid lines show the median values and the shaded area the 95% highest posterior density.
Discussion The COVID-19 pandemic constitutes a qualitative shift in terms of the generation, sharing, and analysis of virus genomic sequence data. The GISAID initiative allowed the rapid sharing of SARS-CoV-2 sequence data, which is instrumental for local, national, and international public health structures that need to provide timely reports on the sanitary situation. At a more fundamental level, this genomic data is also key to furthering our understanding of the spread and evolution of the COVID-19 pandemic  (Martin et al. , 2021) , especially in low-resource countries  (Wilkinson et al. , 2021). We elaborated the COV-flow pipeline, which allows users to perform all the steps from sequence data to phylodynamics analyses. In particular, it can select sequences from the GISAID dataset based on metadata, perform a quality check, align the sequences, infer a phylogeny, root this phylogeny into time, and generate an XML file for Beast2 analysis (we also provide scripts to analyse the outputs).
Furthermore, COV-flow can also readily allow the implementation of subsampling schemes per location and per date. This can help balance the dataset and also be extremely useful to perform sensitivity analyses and explore the robustness of the phylodynamic results. A future extension could consist in including other Beast2 population dynamics models, for instance, the Bayesian Skyline model, which is not informative about R 0 but is potentially less sensitive to variations in sampling intensity. Another extension could be to use other databases to import SARS-CoV-2 genome data, e. g. that published by NCBI, via LAPIS (Lightweight API for Sequences). Beast2 can simultaneously infer population dynamics parameters and phylogenies, which is an accurate way to factor in phylogenetic uncertainty  (Bouckaert et al.
, 2014). However, this global inference is particularly computationally heavy and is out of reach for large data sets. To circumvent this problem, we perform the phylogenetic inference first using less accurate software packages and then impose the resulting phylogeny into the Beast2 XML file. An extension of the pipeline could offer the user to also perform the phylogenetic inference, for instance by using the so-called 'Thorney Beast' (https://beast. community/thorney_beast) implemented in Beast 1. 10 (Suchard et al. , 2018). Finally, it is important to stress that phylogenetic analyses are always dependent on the sampling scheme  (Guindon and De Maio, 2021; Hall et al. , 2016; Karcher et al. , 2020; Louca et al. , 2021). If most of the sequences come from contact tracing in dense clusters, the analysis will tend to overestimate epidemic spread.
Acknowledgement The authors acknowledge further support from the  CNRS , the  IRD  and the  i-Trop HPC (South Green   Platform)  at  IRD Montpellier , which provided HPC resources that contributed to the results reported here (https://bioinfo. ird. fr/). The authors thank the  Experimental and Theoretical Evolution  team from  Maladies Infectieuses et Vecteurs: Écologie ,  Génétique, Évolution et Contrôle, University of Montpellier , for discussion, as well as the EMERGEN consortium (complete member list in Supplementary Materials). 8 Gonché Danesh et al. Peer Community Journal, Vol. 3 (2023), article e101 https://doi. org/10. 24072/pcjournal. 333 This project was supported by the  Agence Nationale de la Recherche Maladies Infectieuses Émergentes  to the  MODVAR  project (grant no. ANRS0151 ).
Introduction: Significant progress has been made in terms of best practice in research data management for nanosafety. Some of the underlying approaches to date are, however, overly focussed on the needs of specific research projects or aligned to a single data repository, and this "silo" approach is hampering their general adoption by the broader research community and individual labs. Methods: State-of-the-art data/knowledge collection, curation management FAIrification, and sharing solutions applied in the nanosafety field are reviewed focusing on unique features, which should be generalised and integrated into a functional FAIRification ecosystem that addresses the needs of both data generators and data (re)users.
True progress will require the joint efforts of all players in the data management cycle (data creators, analysts, curators, managers, customers as well as data stewards and data shepherds)  [6]  and an ecosystem of tools and supports for all stages of the data lifecycle based on machine-actionable metadata. While most researchers see the need for the implementation of open and FAIR data principles, the transition from theory to practice is still very much ongoing. Data management and FAIRness regularly show up as a topic for discussion in round tables targeting strategies to reduce barriers. For example, the NanoRisk Governance conference-the final meeting of the 3 nano-risk governance projects-in January 2023 had a session on reducing barriers to data sharing. Similarly, the EU's working document on "Supporting and connecting policymaking in the Member States with scientific research"  [7]  underlines the ongoing struggle.
Hypothesis 1-Existing solutions need to be re-designed to be both generic and customisable in order to address the broadest set of data provider's needs (the data provider perspective): Most data curation templates and data upload interfaces available currently were designed in the context of very specific projects with their specific goals and/or are based on (meta)data models of specific databases/data warehouses. This makes it very hard to implement/apply these in the standard data workflows of research institutions or individual laboratories (existing or to be established). They are, on one hand, not flexible enough to cover all of the information needed for intra-lab reporting and quality control. On the other hand, work performed for different projects has to be reported in different formats requiring provision of different metadata and, thus, a lab involved in multiple projects cannot commit to one single solution.
However, what is shared and what is considered sufficient metadata is often decided with one specific application or one specific stakeholder group in mind and then implemented in a bespoke data solution without considering further reuse, exploitation, or publication. Even if the (meta)data schema might be optimal for this application, important metadata is often missing and the chosen structure makes it almost impossible to go beyond this primary use. That different tasks need the same data presented differently can be showcased by the fact that the NanoCommons consortium provides two data warehouses as part of its infrastructure (and supports many more): the NanoCommons Knowledge Base and the nanoPharos database for modelling. The first has a material-focused data model, which is well suited for risk assessment and safe-by-design applications since it gives easy access to all information available for the specific material at hand.
The second is optimised to provide training and test datasets for developing nanoinformatics models and tools. Here the goal is not to have all information for a single material but information for one or more specific endpoint(s) for as many materials as possible. As described below in more detail, it is possible to convert one representation to the other but automated solutions for this are only slowly emerging and often data provenance trails  [15]  are destroyed during the process rendering independent data quality control almost impossible and highly impractical. Thus, publicly available data is only available in one or the other format depending on what it was used for in the primary application or, if it is stored in multiple sources, users might not even be aware that they use duplications of the same data.
It is then often seen as easier (or even necessary) to go back and re-curate the data again from the primary literature (see, e. g. ,  [16] ) either because it is not found in the data sources frequently used by the user and/or curation status and metadata such as provenance, internal and external quality control performed and how datasets are updated when new versions of the data become available (i. e. , dataset versioning) is not always clear. Here also, solutions are emerging (e. g. , Data Version Control, https://dvc. org/doc/use-cases/ versioning-data-and-models), but are not yet routinely integrated into nanosafety data warehouses. We believe that solutions to address all issues outlined in the hypotheses above have been proposed and introduced in some form in the nanosafety community.
Even if this sounds contradictory at first, we do this exactly since we acknowledge that the incentives and need for FAIRification are seen as being lower for data providers, but effective data sharing can only work with their commitment. FAIR is, in our opinion, stressing too much the re-use. Harmonisation and interoperability of data is supporting the first time use of data since the data provider can use existing interoperable tools in their analysis and, in this way, save time by avoiding additional data wrangling to just get the data into the format needed by these tools. Additionally, achieving the objective of Safe-and-Sustainable- Schematic illustration of the concept of reusable research and the complexity of (re-)use scenarios: D are various datasets (D-), which are used alone and/or integrated with other datasets and used by different individuals and collaboration teams to address a range of questions (Q) leading to a set of publications (P).
Importantly, characteristics like "character of data," "user," "purpose" and "time" are no longer solid pillars, and the process of data use and re-use is no longer linear as these now occur in parallel and progress at different rates. A key concern of data generators has always been that their findings or datasets will be "scooped" by others if they share the original data before their primary research findings are published. One way to (at least partially) mitigate this, as shown in the modified version of the original figure, is inclusion of one or more data-focussed papers (DataP). These describe the dataset itself and how it was generated as well as give an example of the sort of questions the dataset can be utilised to answer without providing a full interpretation of what the data mean in the specific context in which it was generated.
e. , the data models implemented in these templates should not be defined by what a specific data solution needs but should be customised to provide support in selecting the most appropriate ways to describe the outcomes of studies and experiments according to the consensus of the data producers. Only then will the templates be intuitive enough to be filled in directly by the experimentalist and responsibility for data documentation can be shared between the multiple parties, working together to execute the specific experimental workflow representing individual or combinations of assays that constitute the full study. The NANoREG project templates  [21]  and the corresponding database running on the eNanoMapper data warehouse, are made for standard methods used in regulatory settings, which are well defined in the OECD Guidance Documents and standard Test Guidelines  [22].