dataesr/scientific-paragraphs-categorization huggingface dataset:
All companies had strict processes that needed to be adhered to when adding new items, which may not be available in CDISC. These were relevant themes in Q2 ('dealing with non CDISC data items') and Q6 ('exceptions'). While company C proposed new fields directly to CDISC, the other three required intra-company permission to add/edit fields. Hence, it was apparent that all companies were committed to interoperability ('affirmation' theme in Q6)-at least at the inter-company level. While data acquired from other companies or older datasets could create challenges to interoperability ('exceptions' theme in Q6), the data being generated currently adhere to strict standards. Three of the companies (A, C and D) maintain one master dictionary (Q3), which aids interoperability. All three the companies have provisions for using more specific versions of the dictionary Companies A and C maintain additional dictionaries for non-CDISC standards terminology.
Company D has provisions to use a subset of the dictionary wherever suitable. Company B was the only company that using multiple dictionaries. The maintenance (Q4) of the dictionaries required multi-disciplinary teams. Several more specific themes regarding expertise emerged from the answers. These included clinicians, statisticians, data managers, governance teams and data standards experts. While the salaries of these employees (at least partially) would be included in the cost for maintaining a dictionary, only company A stated this explicitly. No other information about dictionary maintenance costs was available from any of the companies (Q8). In cases of disagreements in the representation of data items, consensus was reached through discussions between various teams (Q5). These include governance teams (companies A and D), cross-functional teams, medical experts and data collectors (companies A and B).
g. , vital signs), qualifiers (such as subject position), units (e. g. , kg), and CDISC standards referenced wherever available. A drawback of this first version is the development in Microsoft Excel that led to a flat structure with poor visualisation. Hence, c4c has piloted a CMT. 29 The CMT allows data items to be viewed as HTML documents, a tree structure, or be exported in various machine-readable formats (e. g. , XML). The PUG extends the CCPDD to tackle the value-range and questionnaire issues raised during the interviews. This PUG development process started by convening an online meeting last year between paediatricians, statisticians, c4c working group members, CDISC data standards experts and representatives from academia and industry. These guidelines are provided wherever applicable.
The CCPDD partially address the knowledge gap of dealing with non CDISC data items. It provides guidelines on the representation of disease agnostic data items that are commonly used in paediatrics with the intention of generating interoperable data with potential for reuse. The first version took 16 months to develop and was success- fully used to manually create CRFs in three proof of viability (PoV) trials-A New Posaconazole Dosing Regimen for Paediatric Patients With Cystic Fibrosis and Aspergillus Infection (cASPerCF, EudraCT Number: 2019-004511- 31), Kawasaki Disease Coronary Artery Aneurysm Prevention trial (KD-CAAP, EudraCT Number: 2019-004433-17) and Prophylactic Treatment of the Ductus Arteriosus in Preterm Infants by Acetaminophen (TREOCAPA -EudraCT Number: 2019-004297-26). The CCPDD acts as a 'look up table' listing paediatric data items that are commonly collected in clinical trials.
However, the interaction model introduced by  [12]  does not reproduce a commonly observed insight: a small part of the members is responsible for a vast part of the community activity. We propose here an agent-based model of a Community of Practice that exhibits a social dynamic where the activity is unfairly distributed among the members. The significance of our work consists in reproducing this phenomenon according to the principle of parsimony. By reducing the number of parameters and restricting the mechanisms to the simplest and most general ones, we propose an explainable model of this social phenomenon based on a clear understanding of the underlying local solidarity processes built upon a large real-world dataset. Our simulator ABM4DCoP (Agent-Based Modeling for Distributed Community of Practice)  [6]  is built upon NetLogo.
Simulator Our ABM4DCoP simulator  [6]  is based on NetLogo  [9]  which is a multi-agents programming language and an integrated development environment for the design of agent-based simulations. Even if Netlogo is user-friendly, it allows the design of high-level models with complex behaviors. As depicted in Figure  2 , the interface of our simulator consists of three types of components to: configure the simulation parameters; visualize agents, interactions and links; analyze the evolution of the metrics which are computed and displayed in real time during the simulation. The agents are arranged in a circle in a clockwise direction in ascending order of nA(a i ). The graphical representation of the community in Figure  3  allows us to observe the spatial distribution of the productivity of the agents (in purple) and of their links (in grey).
Our future work will focus on the statistical modeling of the distribution of idiosyncratic characteristics in order to calibrate the population of our simulations based on the large dataset we have collected. For now, the population of agents is homogeneous and their expertise is measured by their activities ex post. However, we wish to distinguish the most active individuals whose answers are not necessarily the most relevant ones (sparrows) from the domain experts who are not necessarily the most active (owls)  [10]. In the longer term, we wish study and confront other mesoscopic phenomena such as: (a) the popularitymeasured by the number of views of threads, (b) controversy -measured by the debatability of questions, and (c) the efficiency with the response time.
Replication has been successfully employed and practiced to ensure high data availability in large-scale distributed storage systems. However, with the relentless growth of generated and collected data, replication has become expensive not only in terms of storage cost but also in terms of network cost and hardware cost. Traditionally, erasure coding (EC) is employed as a cost-efficient alternative to replication when high access latency to the data can be tolerated. However, with the continuous reduction in its CPU overhead, EC is performed on the critical path of data access. For instance, EC has been integrated into the last major release of Hadoop Distributed File System (HDFS) which is the primary storage backend for data analytic frameworks (e. g. , Hadoop, Spark, etc. ). In this work, we measure and compare the performance of data accesses in HDFS under both replication and EC.
Testbed Our experiments were conducted on the French scientific testbed Grid'5000  [9]  at the site of Nantes. Two clusters -Econome and Ecotype -are used for the experiments with 21 and 40 machines, respectively. Each machine is equipped with two Intel Xeon E5-2660 8-core processors, 64 GB of main memory, and one disk drive (HDD) at 7. 2k RPM with 1 TB. The machines of each cluster are connected by 10 Gbps Ethernet network. The two TORs switches of both clusters are connected with four 40 Gbps links. The machines run 64-bit Debian stretch Linux with Java 8 and Hadoop 3. 0. 0 installed. All the experiments have been done in isolation on the testbed, with no interference originated from other users. Econome runs HDFS (one node hosts the NameNode (NN) and the remaining 20 nodes act as DataNodes (DNs)) while Ecotype hosts the clients.
Metrics The throughput at the client side is the main metric used to measure the performance of read/write operations from/to HDFS. For one client, it is the amount of data read/written per second. In the case of concurrent reads and writes (by multiple clients), the average throughput per client is shown alongside the standard deviation of the clients' throughput. We also profile disk and network I/O of the nodes using the python library psutil  [6]  version 5. 4. 8.
We further study the impact of concurrency on the performances of both erasure coding and replication. What is the impact of EC on write performance? Writes are pipelined under replication (i. e. , the client sends the data block to the first node which, in turn, pipelines it to the second and then the third). However, under EC, the client encodes the data and then writes the data and parity chunks directly to all the nodes in parallel. This parallelism can provide higher throughput but results in more data sent by the client stressing the link between the clients and the HDFS cluster. Regardless of the HDFS storage policy, the client splits the file into blocks equal to the HDFS configured block size. Under replication, and for each block, the client contacts the NN to get a list of DNs equal to the replication factor (e.
In conclusion, three (number of replicas) DNs will be contributing to a write operation at a time under REP, while 9 DNs ( + ) will be simultaneously writing data under EC. It is important to mention that blocks are written sequentially to HDFS (the second block is sent once the first block is completely stored in a DN, persisted in disk or buffered in the memory). Moreover, when the data is stored completely in all DNs (at least buffered in the memory), the write operation is considered successful.
Results of single write Figure  1a  shows the write throughput of one client with different file sizes. The write throughput is 1. 11x to 1. 3x higher under REP compared to EC when increasing the file sizes from 256 MB to 20 GB, respectively. When writing 20 GB file, REP achieves 363 MB/s write throughput, while EC obtains a throughput of 277 MB/s which is 76% of the throughput under REP. This can be explained due to the larger amount of data which is sent from the client to HDFS in EC (i. e. , 30 GB accounts for the original and parity data) compared to REP (i. e. , 20 GB) and the "low cost" data pipelining under REP. First, data stays in the buffers of the DNs when received from the client or pipelined from other DNs, hence, it is not synchronized to disks directly. As a result, data transfer time -to HDFS -strongly depends on the amount of data sent to the cluster.
Given that the throughputs of inter-cluster traffic (network traffic between the clients and the HDFS cluster) are 444 MB/s and 399 MB/s under EC and REP respectively, the file under EC takes 35% more time to be transferred to HDFS compared to REP (the difference in transfer times between EC and REP is clearer when increasing the file size). Second, (buffered) data can be pipelined as soon as they reach the first DN because the intra-cluster (data transferred inside the HDFS cluster) throughput is almost two times the inter-cluster throughput (i. e. , intra-cluster throughput is 801 MB/s), thus replicating (transferring) data inside the cluster does not introduce an extra cost. Finally, more data is persisted to disk under REP compared to EC (i. e. , 21 GB under EC while it is 29 GB under REP); which in turn slightly slows down the write operation under REP.
Note that, by default, Hadoop client utilizes only one thread to send the data and therefore the inter-cluster throughput may not be fully utilized. In case of REP, data is communicated between two nodes only and thus the inter-cluster throughput is limited to 399 MB/s. In case of EC, despite that the client is sending data to 9 DNs, inter-cluster throughput is limited to 444 MB/s because only one core is responsible for encoding and sending data (in case of 20 GB, we observe that one core is always at 100% utilization). Observation 1. Unlike under replication, more data (i. e. , parity data) goes from the client to HDFS cluster under EC. This extra parity data (0. 5x of the original data in our configuration) results in a loss of throughput compared to replication as data are pipelined (replicated) inside the cluster with minimal cost.
e. , 183 MB/s to 233 MB/s when the files are larger or equal to 5 GB), thus write performance will further degrade under REP. The low disk and intra-cluster performances will limit the arrival rate of data to HDFS cluster under REP (the arrival rate is 1162 MB/s under REP compared to 4535 MB/s under EC). As shown in Figure  2 , the network performance (inter and intra) drops once the buffers are filled and data starts to be synchronized to disks while still not completely replicated (transferred) to other DNs. To further explain the impact of concurrency on the performance of write under both EC and REP, Figure  1d  shows the aggregated write throughput when writing a data set of 100 GB while varying the number of clients and therefore the files sizes. When the number of concurrent clients is 5, REP achieves a throughput of 1410 MB/s while it is 1340 MB/s under EC.
The aggregated throughputs increase by 1. 94x and 3. 25x when increasing the number of clients to 10 and 20 clients under EC, respectively. This increase is mainly due to the increase in the inter-cluster throughputs; On the other hand, the aggregated throughputs increase 1. 2x and 1. 5x under replication when increasing the number of clients to 10 and 20 clients, respectively. Here, the high cost of data pipelining limits the scalability of HDFS under REP when increasing the number of clients. Specifically, buffers under replication are filled faster (original data and replicated data) compared to EC. Thus, the arrival rate of data to a DN is limited by the disk throughput (125 MB/s under EC and 128 MB/s under REP). However, as a DN under replication is receiving data from the clients and from other DNs, this will reduce the inter-cluster throughput and prolong the writing time under REP compared to EC.
Read dataflow in HDFS To read a file in HDFS, the client contacts the NN to get the addresses of the DNs hosting each block of the file. For each block, the DNs are ordered by the network distance to the client and are randomized for the nodes that have the same distance. The client then reads the blocks in order i. e. , sequentially, one by one. Reading one block of data (without any failure) has the same cost under both EC and REP, as the same amount of data (equal to the block size) will be read from disk and transferred over the network. However, under EC the data block can be read in parallel from multiple DNs (6 DNs in our configuration). This parallelization results in better performance especially when the network bandwidth is higher than the disk bandwidth  [8].
e. , 83. 4 MB/s) -which is due to data skew. As shown in Figure  4 , although most of the DNs are serving data, some of them (around 6 DNs) serve more clients a time which in turn results in exploiting the full capacity of the disk (i. e. , 125 MB/s) on those nodes. On the other hand, the majority of nodes were serving 1 client most of the time, thus low utilization of the disk. We observe that disk throughputs are above 100 MB/s during 50% and 18% of the read workload time under REP and EC, respectively. Hence, this, in addition to the increase in the number of contributing nodes (active disks), explains the decrease in the performance difference from 4. 95x to 2. 08x between EC and REP. When 40 clients are reading 40 files, each has a size of 20 GB, we observe that HDFS suffers from obvious load imbalance under both REP and EC.
Conclusion Efficient data access in large-scale storage systems is an important problem with the current rate of data generation. Erasure codes are increasingly deployed in many storage systems as cost-efficient alternative to replication. In this paper, we experimentally evaluate the performance of data read and write operations in HDFS under both replication and erasure coding. Our findings can be summarized as follows: (1) Write operations under replication have higher throughput than under EC for a single client. However, when increasing the number of concurrent clients, the throughput under EC approaches that under replication and even outperforms it under high concurrency. In addition, applying EC as an alternative to replication does not only reduce storage cost and disk overhead but also results in lower network traffic.
Acknowledgments This work was supported in part by the  ANR   KerStream  project ( ANR-16-CE25-0014-01 ), the  Stack/Apollo  connect talent project, and the  Inria Project Lab program  Discovery (see https:// beyondtheclouds. github. io). Experiments presented in this paper were carried out using the Grid'5000 testbed, supported by a scientific interest group hosted by Inria and including CNRS, RENATER, and several Universities as well as other organizations (see http://www. grid5000. fr/).
Introduction Potential threats to human and veterinary public health are usually monitored by specific surveillance systems. Traditionally, these systems have been based on clinical case reports and programmed screening surveillance plans. Since the 1990s, syndromic surveillance (SyS)which initially focused on the detection of bioterrorism events  (Paterson and Durrheim, 2013)  has been added to this list of systems, in order to improve the detection of unexpected/emergent health events (e. g. , climatic events like heat waves), and to monitor endemic and seasonal diseases (e. g. , gastroenteritis, influenza)  (Henning, 2004). SyS is defined as the real-time or near real-time collection, analysis, interpretation and dissemination of health-related data to enable early identification of the impact (or absence of impact) of potential human or veterinary public health threats that require effective public health action  (Henning, 2004; Triple, 2011).
Statistical detection algorithms We tested five families of algorithms, with different tuning parameters, leading to 11 detection algorithms, all available in the R package 'surveillance'  (Höhle, 2007) : • Farrington Flexible: expected values are estimated from a 5-yearlong historical period, using the following quasi-Poisson regression model: log(μ i ) = θ + βt i + δ j(ti) (2) where j(t i ) is the seasonality parameters of the time unit t i with j(t 0 ) = 0 and δ 0 = 0. In this model a trend is always adjusted, even if it is not statistically significant. Then an excess score is calculated. An alarm is raised when the excess score X = y0-μ0 U-μ0 is greater or equal to 1, with y 0 being the observed value, μ0 the expected value, and U the 100(1 -α) quantile of the normal distribution. For the present study, we chose α = 0.
g. , outbreak/anomaly size) as well as the objective of the detection (do we want it to be sensitive, specific, or both?; do we want to obtain good timeliness?, etc. ). The use of simulated times series helped us to control and explore parameters which potentially influence time series and outbreak characteristics. This approach is recognized as the best way to assess the performances of detection algorithms. While previous studies used simulated datasets  (Noufaily et al. , 2012; Enki et al. , 2016; Noufaily et al. , 2019; Bédubourg and Le Strat, 2017; Hutwagner et al. , 2005; Fricker et al. , 2008) , or real data  (Faverjon et al. , 2019; Jackson et al. , 2007)  to create temporal series, all studies specifically looking at outbreaks used only simulated data in order to create a gold standard for calculating performance parameters of detection algorithms.
The matrix S reflects the set of mutational signatures, while the matrix A encompasses the activities of the signatures; an activity corresponds to the number of mutations contributed by a signature in a cancer sample. Algorithmically, de novo extraction of mutational signatures has relied on nonnegative matrix factorization (NMF)  16  or on approaches mathematically analogous to NMF. [17] [18] [19]  The main advantage of NMF over other factorization approaches is its ability to yield nonnegative factors that are part of the original data, thus allowing biological interpretation of the identified nonnegative factors. 16 38, 40  Notably, the majority of existing tools (1) predominately support the simplest mutational classification, viz. , SBS-96, which encompasses single base substitutions with their immediate 5 0 and 3 0 sequence context;  15  (2) lack automatic selection for the number of signatures; (3) do not identify a robust solution; (4) require pre-selection of a large number of hyperparameters; and (5) do not decompose de novo signatures to the set of more than 100 reference signatures available at the Catalog of Somatic Mutations in Cancer (COSMIC) database.
Overview of SigProfilerExtractor SigProfilerExtractor is implemented as a Python package, with an R wrapper, allowing users to run it in both Python and R environments (STAR Methods). By default, the tool requires only a single parameter-the input dataset containing the mutational catalogs of interest. SigProfilerExtractor supports most used formats outputted by variant-calling algorithms, which are internally converted  15  into a matrix, M. By default, the tool decomposes the matrix M searching for an optimal solution for the number of operative signatures, k, between 1 and 25 mutational signatures (Figure  1A ). For each decomposition, SigProfilerExtractor performs 100 independent factorizations and, for each repetition, the matrix M is first Poisson resampled and normalized and, subsequently, factorized with the multiplicative update NMF algorithm  16  by minimizing an objective function based on the Kullback-Leibler divergence measure  44  (Figure  1B ).
To avoid bias in evaluating each tool's performance, three sets of SBS-96 signatures were used in generating the synthetic data: (1) COSMICv3 reference signatures,  12  (2) signatures previously extracted by SignatureAnalyzer (SA),  12  and (3) randomly generated signatures. Most of the noiseless scenarios were designed to mimic the activities of mutational signatures in specific cancer types, with four scenarios emulating a single cancer type, 16 scenarios a combination of two cancer types, and two scenarios mimicking the analysis of a pan-cancer dataset. In addition, randomly generated signatures displaying different distributions and exposures were used in 10 noiseless scenarios and in the noise scenarios, which were generated up to 20 times. Some of the scenarios included combinations of signatures that represent a challenge for de novo extraction, including mutational signatures with overlapping profiles in specific contexts or exhibiting flat featureless profiles.
Precision is defined as Technology TP TP + FP , sensitivity as TP TP + FN , and F 1 score corresponds to a combined metric, defined as the harmonic mean of the precision and sensitivity: 2 Ã PrecisionÃSensitivity Precision + Sensitivity Benchmarking using SBS-96 noiseless WGS data SigProfilerExtractor and 13 other tools (Table  1 ) were first applied to all noiseless WGS scenarios based on the SBS-96 mutational classification. The 13 tools include SignatureAnalyzer (SA) and SigProfiler_PCAWG, a legacy MATLAB/Python version of SigProfilerExtractor, which were jointly used in the PCAWG analysis of mutational signatures and the derivation of the COSMICv3 set of reference signatures. 12 Except for MutSignatures, which can only decompose a matrix for a fixed number of signatures, all other tools were applied to each scenario by using their suggested methods for selecting the number of operative signatures.