dataesr/scientific-paragraphs-categorization huggingface dataset:
For the "ALK" and "EGFR" factors, the precision rate was excellent but the sensitivity to retrieve the information was smaller because of very rare occurrence of "nt" (i. e. , "not tested"). As the data of the test set were never used to train the M. L. model, a category that was absent in the train test could not be assigned by the model. Two levels presented very rare observations (i. e. , "tis" and "Ia3") and were considered as outliers and recoded as "no reference" ("nr") for N. B. C. model. Training the model on a larger MTM reports sample could increase the performance and the reproducibility of the machine learning approach to recognize rarest events. Requiring only few data, RegEx are efficiently implemented with help of medical expertise and could be combined to machine learning methods to ease prescreening in oncology on large datasets.
In this article we propose a data model and query language for the visualisation and exploration of topic evolution networks representing the research progress in scientific document archives. Our model is independent of a particular topic extraction and alignment method and proposes a set of semantic and structural metrics for characterizing and filtering meaningful topic evolution patterns. These metrics are particularly useful for the visualization and the exploration of large topic evolution graphs. We also present a first implementation of our model on top of Apache Spark and experimental results obtained for four real-world document archives.
Introduction There is an increasing demand for practical tools to explore the evolution of scientific research published in bibliographic archives such as the Web of Science (WoS), 1 arXiv, 2 PubMed  [39]  or IS-TEX. 3 Revealing meaningful evolution patterns from these document archives has many applications and can be extended to synthesize narratives from datasets across multiple domains, including news stories, research papers, legal cases and works of literature  [33]. The evolution of scientific archives can broadly be studied by adopting a cognitive view or a social view on evolution dynamics. The cognitive view of scientific archive evolution emphasizes the shared knowledge and the change of ideas present in the document contents  [22] , whereas the social view takes account of authorship information and social interactions represented, for example, in co-authorship and citation graphs  [13, 34].
The thickness of the alignment edges reflects the cosine-similarity of the connected topic (term vectors). Several topics in both subgraphs contain the term "database" and we can observe different evolution patterns. The left subgraph shows that in period 2002 -2004, topic 77 ("databases, queries, optimization, integration") splits in two research directions "databases, queries and constraints" (topics 100, 188) and "prediction, probability, random" (topics  104, 191, 152). The right subgraph covers the same period with topics related to "data mining" (83), "data access interfaces" (90), "information retrieval" (92), "logics, semantics" (80) and "knowledge, reasoning" (54). The first three topics converge in 2002 -2004 into a single topic on "object, xml, store, data mining" (146) which splits in the period of 2004 -2006 into "storage servers" (170), "data technique" (168), "data mining and management" (158) and "knowledge and ontologies" (150).
This article addresses two main issues when building and exploring topic evolution networks. First, building "meaningful" topic evolution networks is difficult and often an iterative process where domain experts must tune method-specific hyper-parameters and thresholds with respect to a given dataset and an expected output. This tuning process also includes the threshold-based filtering of topic alignment edges to reduce the network complexity. A second challenge concerns the visual exploration of large topic evolution networks. Whereas existing graph visualisation standards and tools like Gephi  6  or Graphviz  7  can be used to generate high-quality visualizations, their use for exploring large graphs and identifying meaningful evolution patterns is still limited. In  [25] , we proposed a generic framework for the computation and interactive exploration of evolution networks.
This kind of materialization is computation and storage-intensive, but also can directly take advantage from standard big data technologies to achieve scalability. The main benefit of materialization is that even complex structural and temporal topic filters can be implemented by simple value-based selections on the generated topic properties. This article extends this work in different directions: • A pivot topic calculus describing the formal semantics of the query language introduced in  [25]. This extension also includes a formal analysis of the monotonicity properties of pivot filter expressions. • An optimized incremental transitive closure algorithm for the materialization of pivot graphs. This algorithm is the core of the materialization process and implemented using Apache/Spark SQL.
• A detailed experimental evaluation of the performance of the different workflow steps including the L D A topic generation, the pivot graph computation, the topic labeling and the graph metrics computation over four real-world datasets. This evaluation also includes experiments measuring the scalability of our pivot graph generation algorithm over larger synthetic topic evolution graphs. The remainder of this paper is organized as follows. The next section introduces the related work on topic evolution models and is followed by Section 3 which defines the EPIQUE pivot graph model. Section 4 describes our pivot graph query language including pivot topic functions and calculus. Section 5 gives an outline of the algorithms for building topic evolution networks and explains our query evaluation strategy.
Breakthrough research may not be the mainstream area, but can attract a significant amount of citations. For that reason,  [42]  proposes Topical Impact over Time (TIoT) which can be used for detecting trending topics and suggesting impactful papers in a bibliographical database. They applied collapsed Gibbs sampling for approximate inference and citation counts to quantify topical impact. Our work models the evolution of topics by subgraphs connecting similar topics from different time periods without measuring and comparing their distribution, popularity and impact. More generally, trend analysis describes the temporal evolution of the popularity, the utility or the interest of topics, but does not take account of their structural evolution where one topic can evolve into several sub-topics or several topics can merge into a single topic.
[32]  introduces a novel approach to the early detection of research topics by using the Computer Science Ontology 8  to model research topics in the Rexplore system. They apply a Clique Percolation Method (ACPM) for analyzing the dynamics between existent topics. Other examples of science evolution studies apply unsupervised topic modeling to the ACL Anthology to analyze historical trends in the field of Computational Linguistics from 1978 to 2006  [15]. How "cognitive science" as a field has changed over the last three decades has been explored by  [11]. Finally,  [10]  analyzes topic evolution patterns (split, merge and knowledge transfer) in the field of Information retrieval (IR). Our article extends previous works on topic evolution networks by a formal query language based on a set of semantic and structural graph filters to define complex topic evolution patterns.
Pivot topic query language Let D B(T , sim) = {(t, β)|t ∈ T ∧ β ∈ S(t)} be the set of pivot topics defined by a set of topics T and a similarity function sim. We call D B the pivot database defined by T and sim. In the following, we define a query language for extracting pivot topic subsets P ivots ⊆ D B. The semantics of this query language is based on the pivot topic calculus we have introduced in Section 4. 2. Let L denote a set of terms and c be a numerical constant. Atomic filter expressions and their semantics are defined using the topic calculus as shown in Table  2a. The first column corresponds Minus(F 1 ) ¬F 1 see Table  1  F 1. Union(F 2 ) F 1 ∨ F 2 see Table  1  Path(F 1 ) sions can be composed to build complex filter expressions as shown in Table  2b. Finally, the query language defines two projection operators Future and Past (Table  2c ) which modify the future/past parameter δ (δ = f uture by default).
Definition 7 (Pivot query). Let D B be a pivot database (set of pivot topics), Q be a pivot filter and I(Q , t, β) be a truth-functional interpretation of the pivot topic predicate Q given pivot topic (t, β). The expression D B. Q is a query which returns all pivot topics in D B where Q is true. D B. Q = {(t, β)|(t, β) ∈ D B ∧ I(Q , t, β)} Example 5. Our query language allows to filter pivot topics according to some evolution pattern defined by the combination of graph evolution filters. -For example query Q 1 filters all pivot topics with high future relative and high pivot evolution degrees, where each future topic has two child topics in average and there exist future subtopics related to the pivot topic with a minimal distance of 5 periods: Q1: DB. Future. Revol ( > = 0. 5 ). Pevol ( >=0.
9 he next step produces the pivot evolution graphs following the model introduced in Section 3 (right part of Fig. 3 ). The global evolution graph G is transformed into |B| families of pivot evolution graphs defined by a set of alignment thresholds β i ∈ B. Each family contains the future and past pivot graphs of all pivot topics (t, β i ). We only consider pivot graphs with at least one edge and ignore isolated pivot topics (single node graphs). The final database then contains at most |B| × |T | pivot topics with a future and a past pivot evolution graph for pivot topic. The last two steps compute the topic labels and graph metrics as defined in Section 4. The resulting data can then be queried using the filters defined in Section 4. 3. In the following section, we describe in more detail the central task of this workflow concerning the computation of the pivot topic graphs.
Pivot graph computation We use a Datalog-like syntax for presenting our pivot graph generation approach. An efficient algorithm and implementation on top of Apache Spark is discussed in Section 6. This implementation avoids redundant computation by exploiting the monotonicity of pivot graphs where δ ∈ { f uture, past}, G δ (t, β i+1 ) is a subgraph of G δ (t, β i ) for all 0 ≤ i < n. The input of the Datalog program (Algorithm 2) is a topic table T opics(t, p) storing the pivot topic identifiers t with their periods p, a topic similarity matrix Sim(t1, t2, s) where s = sim(t1, t2) is the similarity between topic t1 and topic t2, and a sequence of β i values defined as a binary table Beta(b, i). The first rule (Rule 1) defines the alignment graph table Graph(t1, t2, s) which connects all topics t1 of period p to all topics t2 of period p + 1 where there exists an evolution edge of similarity s = sim(t1, t2).
System architecture Fig. 4  gives an overview of the architecture of our web application implemented on top of Apache Spark and Jupyter Notebook. The entire process to study science evolution over a corpus is split into two applications for building the pivot evolution graphs and for interactively exploring these graphs. Each application corresponds to a separate user interface. The evolution graph generation application is implemented in Scala and executed through the Spylon  11  kernel. The evolution graph exploration application uses a standard Python kernel to take advantage of advanced Python 3 graphical user interface libraries for facilitating user interaction. Fig. 5  displays a screenshot of our intuitive declarative queryby-example interface where users can specify their exploration goal and visualize pivot topic evolution graphs.
Pivot graph generation algorithm Algorithm 3 on Page 11 shows our pivot graph computation implementation using the Spark DataFrame  [2]  model and algebra. A Spark DataFrame is equivalent to a relational database table and can be transformed into a new DataFrames through relational operations including projection (select), filter (where), join, and aggregations (groupBy). Algebraic expressions are built by concatenating the relational operators starting from the input DataFrame. For  example, the expression in line 5, applies the following relational selection on DataFrame Sim: Graph = σ sim β i ∧t 1. period+1=t 2.
Experiment setting We conducted our experiments on four real-world data sets of different scales by using the titles and the abstracts of each document. The smallest dataset contains 4640 documents about research related to the Glyphosate herbicide. The second dataset IS-TEX contains 13423 articles in the domain of ecological economics and environmental economics. The arXiv corpus is a repository of electronic preprints approved for publication after moderation. This repository consists of 1. 15 million scientific publications in the fields of mathematics, physics, astronomy, electrical engineering, computer science (arXiv. CS), etc. The last dataset is a sample of the Wiley online library which contains 1 million documents covering the fields of arXiv and additional fields such as agriculture, art, humanities, etc.
The statistics over these four data sets are summarized in Table  3 , where #Document is the total number of documents and #T is the number of topics per period we used in our experiments. All datasets cover a different period of 20 years which is split into 10 slices by using a sliding 3-year time window with an overlap of 1 year. The number of documents covered by each period is different but remains in the same order of magnitude. In particular, we did not apply any sampling before generating the document-term matrix and executing LDA topic extraction. The EPIQUE workflow is implemented on top of Apache Spark version 2. 4, Scala version 2. 11 and Java version 8. Our experiments have shown that most workflow stages can be efficiently executed on a single node. In the following experiments on the real world datasets, we show the results obtained by the execution on a single machine with a hyperthreaded 3.
The largest TC table is computed from the Wiley topic graph which contains 2000 topics and 360 000 alignment edges and generates 16 364 pivot graphs with 379 428 edges (tuples). Our experiments also showed that the distributed computation on several nodes increases the execution cost due to additional data shuffling and task management overhead. Whereas this  observation questions the choice of using Spark which is mainly designed for parallel data-intensive computations on clusters. In particular, Spark uses the Hadoop file system (HDFS), which is designed to efficiently manage large persistent DataFrames and to reduce distributed data access/storage overhead compared to a standard file system solution. Nevertheless, the previous experiments do not take account of all workflow steps including the document storage, preprocessing (stop-word removal, stemming, term extraction) steps which can benefit of a distributed Spark architecture.
For illustrating the pivot graph performance on much larger graphs, we generated several synthetic datasets (topic graphs) by duplicating the Wiley topic graph. The results of these experiments are shown in Fig. 10(a). Each line corresponds to the execution time of a synthetic topic graph Wx obtained by generating x copies of the initial Wiley graph containing 2 000 topics and 360 000 alignment edges. Thus W1 contains the aforementioned topic graph whereas W2000 is the largest synthetic dataset with 4 million topics and 720 million alignment edges. This last graph generates 32 million pivot graphs with 7, 6 billion edges with a total size of 30 GB on disk. The number of physical worker nodes ranges from 1 to 8 and each worker node contains one Spark executor configured with 4 CPU cores and 40 GB memory.
Fig. 10 (a) illustrates the TC computation time for the synthetic topic graphs W 1, W 50 W 200, W 500, W 1000 and W 2000. The edges of all graphs are distributed randomly on all worker nodes. As we can see, the performance benefit for W 1 and W 50 by increasing the number of worker nodes is very low. As already mentioned, these two datasets cannot benefit from the cluster since the cost of each task is small compared to the Spark task scheduling and data shuffling overhead. For larger graphs, it is possible to achieve a 2x speedup by increasing the number of worker nodes. We also see that a single node is not able to process W 2000. The relative benefit decreases with the number of nodes. This is mainly due to the removal of duplicate edges during the TC computation, which needs data shuffling between nodes and adds communication cost.
t * from PivotFuture t o p i c , PivotLabels l a b e l where t o p i c. t = l a b e l. t and t o p i c. i = l a b e l. i and contains ( l a b e l. emerging , 'deep learning') and contains ( l a b e l. stable , 'database') and t o p i c. l i v e l i n e s s > 8 and t o p i c. s p l i t < 3.
s e l e c t * from PivotFuture t o p i c , PivotLabels l a b e l where t o p i c. t = l a b e l. t and t o p i c. i = l a b e l. i and contains ( l a b e l. emerging , 'deep learning') and contains ( l a b e l. stable , 'database') and t o p i c. l i v e l i n e s s > 8 and t o p i c. s p l i t < 3.
Enrollment started in December 2018; for the analysis in this paper, data from children enrolled through December 2019, when TB was detected in the NGA samples from 10 children, were included. This study, part of the NoPain4kids project, was approved by the EPHI institutional review board (protocol EPHI-IRB-134-2018). Written informed parental consent was obtained from the parents/legal guardians for each child enrolled. Data confidentiality was ensured, and participant names or any other personal identifiers were not included in the data set for analysis and were used only to link laboratory results to children for caretaking when needed, following routine surveillance guidelines for medical records. All children diagnosed with TB according to clinicians' decisions were treated in accordance with national guidelines.
Laboratory staff members were trained and provided with instructions on how to visually pick ;0. 8 g of stool. Data collection and analysis. Semiquantitative Xpert results and the cycle threshold (C T ) values for the sample processing control (SPC) were captured directly from the GeneXpert instrument. We used the semiquantitative Xpert results following the manufacturer's categories, which represented the M. tuberculosis bacterial load detected in the sample  (17)  For comparison of the various protocols during the method development, we calculated the difference (DC T ) between each test's SPC C T value and the reference SPC C T value (obtained by testing undiluted SR). The M. tuberculosis recovery rate of testing spiked samples was defined as the proportion of samples with M. tuberculosis detected among all spiked samples.
ACKNOWLEDGMENTS We acknowledge the study participants and their families for their valuable participation in this study. We acknowledge the personnel at the participating health care facilities for their dedication and motivation. The support of various staff members at EPHI has been instrumental for the projects described in this paper, and we specifically thank  Zemedu Mehamed ,  Abebaw Kebede ,  Ayinalem Alemu , and  Muluwork Getahun. We thank  Degu Dare  and  Agnes Gebhard  for their constructive comments and input during the writing of the manuscript. The in vitro evaluation using spiked samples in Montpellier, France, was part of the  TB-Speed  project funded by  Unitaid  (grant 2017-15-UBx-TB-Speed). The demonstration study for the development of the SOS stool method was supported by funding from the  KNCV Tuberculosis Foundation  in the Netherlands, collected through the kind donations of Dutch people through a local sponsored running event for the  NoPain4Kids  project.
Introduction Deep neural networks (DNNs) have become a cutting-edge research topic owing to their excellent performance in image classification, detection, segmentation, and data prediction. Owing to the remarkable prediction capacity of datasets in a wide range of complex applications, researchers have proposed myriad networks, such as AlexNet  [1] , VGG16  [2] , ResNet152  [3] , Transformers  [4] , General Adversarial Networks (GANs)  [5] , and Variational Autoencoder (VAE)  [6]. The success of DNNs has also attracted attention in the development of industrial platforms, such as Google Deepmind  [7] , Facebook AI  [8] , Amazon Alexa  [9]. Traditionally, in academia and industry, graphics processing units (GPUs) are used to train DNNs, as they provide a high degree of parallelism to process these algorithms  [10, 11].
Virtualizing FPGAs abstracts low-level physical resources and hides hardware design and compilation flow from the software designers' view, providing a high-level applicationdependent architecture. Owing to FPGA virtualization, software designers can deploy DNN accelerators according to different requirements (e. g. , throughput, execution time, and accuracy) without relying on a specific FPGA platform. The collaboration between FPGA virtualization and the FPGA cloud can satisfy the resource requirement, thereby taking advantage of the ''unlimited'' cloud capability to flexibly scale DNN accelerators. While exploring techniques to accelerate DNNs on local physical FPGAs, researchers have also attempted to adopt FPGA virtualization and the FPGA cloud to facilitate the implementation of multiple DNNs at a large scale and achieve flexible deployment in a multi-user environment.
g. , DRAM adapter), interface controller (e. g. , DMA controller), and network interface controller (e. g. , Ethernet core). For instance, the shell in  [47]  includes the user PCIe, management PCIe, card management system, and DDR access channel. -Role: The role is a dynamic region in the FPGA, which can be regarded as a reserved region for deploying DNNs in our context. It runs independently of the shell and can be reconfigured every time for each application to satisfy user requirements. • Software stack: The software stack runs on a host, provides users with an application programming interface, and enables the communication between the host and the FPGA. [40]  introduces three types of software stacks: (1) Operating systems (e. g. , LeapF-PGA OS  [48] , Recon OS  [49] ), which are conceived to support multiple threads for runtime resource management.
(2) The host application, which is written in OpenCL and C++, provides simultaneous access to a shared FPGA for multiple users. (3) Software frameworks (e. g. , OpenStack), which can be used to share resources across multiple users and distribute several partial reconfigurations to one FPGA. • Overlay: The overlay provides an intermediate layer between the hardware stack and the software stack to achieve program portability. It is considered a virtual reconfigurable architecture on top of a physical FPGA. Fine-grained granularity and coarse-grained granularity in overlays are used in various applications  [50, 51].
Another new type of framework is a toolchain that includes a compiler  [65, 71, 80]. The compiler is a DNN architecture-aware tool that can map a wide range of DNN applications to the instruction set architecture (ISA) and control signals  [65]. Fig. 7  presents an example of a compiler-inspired toolchain. Wang et al. [71]  proposed a compiler that transforms a DNN deployment into a graph-level problem. The compiler first takes the software description as input and then transforms the description into directed acyclic graphs of computational operations. The networks generated by the compiler on Xilinx ZU9 reach throughputs of 2. 82 TOPs/s (VGG), 1. 38 TOPs/s (ResNet50), and 1. 41 TOPs/s (GoogleNet). More works are presented in Table  2.