dataesr/scientific-paragraphs-categorization huggingface dataset:
The RAMPART trial (NCT03288532) brings together both of these processes in an attempt to improve outcomes for patients with locally advanced renal cell carcinoma (RCC), where no globally acceptable adjuvant strategy after nephrectomy currently exist. RAMPART is led by the MRC CTU at University College London (UCL), in collaboration with other international academic groups and industry. We aim to facilitate the use of data from RAMPART, (dependent on outcomes), for a future regulatory submission that will extend the license of the agents being investigated. We share our experience in order to lay the foundations for an effective trial design and conduct framework and to guide others who may be considering similar collaborations. Trial Registration: ISRCTN #: ISRCTN53348826,.
At the MRC CTU at UCL, we have a rich experience of leading successful large, international collaborative trials in various disease types, including SORCE (NCT00492258) our previous trial in the adjuvant RCC setting  [1]. We also have expertise in the development and evaluation of novel trial designs to streamline the evaluation of new therapies  [6]. We have leveraged both of these capabilities to develop the RAMPART trial (NCT03288532); an international phase III randomised multi-arm, multi-stage (MAMS) platform trial of adjuvant immune checkpoint inhibitors (ICIs) in treatment of locally advanced RCC. In this paper, we describe the clinical rationale behind the agents used in RAMPART. We outline the MAMS design and explain the choice of control arm, study population and primary outcome measures.
Regulatory-future proofing -trial conduct We have implemented sufficient elements from the outset of the trial to enable compliance with International Conference on Harmonisation -Good Clinical Practice (both retrospectively and prospectively). This will enable data from the RAMPART trial to be used as part of a licensing application. We have also put in place a number of notable futureproofing trial conduct features, which will facilitate a future regulatory submission. Firstly, we have set up our clinical records database to be Clinical Data Interchange Standards Consortium (CDISC) compatible. This will help facilitate the submission of standardised data to the regulators and has the added benefit of facilitating data sharing with other organisations. Secondly, we have built a CT scan repository to collect CT scans on an ongoing basis.
Nanopore long-read sequencing We extracted high molecular weight (HMW) genomic DNA using the Masterpure Complete DNA and RNA purification kit (Lucigen), using the protocol for tissue samples, with the modification that worms were frozen and thawed to facilitate lysis prior to extraction. We then prepared 8 kb, 20 kb and unfragmented sequencing libraries using the 1D Ligation Sequencing Kit from Oxford Nanopore Technologies (SQK-LSK109). 8 kb and 20 kb fragmentation was done using g-TUBE (Covaris) following manufacturer protocols. Libraries were loaded on a MinION MK1B device (Oxford Nanopore). Read calling was done using MinKNOW software.
Single nucleotide variant calling Variant calling was done using the variant2 pipeline implemented in the bcbio-nextgen ngs data analysis software suite (https:// github. com/bcbio/bcbio-nextgen). Reads from NIC203 and EG6180 were aligned to the 21 scaffold genome assembly using BWA-mem  48  and variant calling was done using Genomic Analysis Toolkit (GATK Ver 4)  49  as well as Strelka. 50 Only variants that were identified by both tools were kept. Both tools were run with a ploidy setting of 2. Variants were filtered to include only those called as homozygous reference in NIC203 and homozygous alternative in EG6180. These variants were then used for inferring linkage groups using single-worm F 2 sequencing (see below). The process was repeated after generating the final assembly to retrieve a finalized list of variants that include 105,431 single-nucleotide variants (SNVs) and 13,234 indels.
95 across all individuals with a nonmissing genotype. This resulted in 2,547 variants. r/qtl was then used to identify 6 linkage groups (Figure  S2B ). Due to the high completeness of the original assembly, each linkage group only included 2-4 scaffolds. The filtering process was repeated with a more stringent cutoff of 0. 99 keeping a total of 7,356 variants. The variants within each linkage group were then ordered using ASMap R package  52  to determine the orientation and order of the scaffolds. For synteny analysis, the NIC203 genome draft was aligned against C. elegans WBcel235 reference genome using Cactus. 53, 54 The aligned file was converted to the maf format, deduplicated using Maftools  55  and converted to links format using awk. Alignments were read into R, and consecutive alignments that were separated by less than 10,000bp were joined.
Plates that initially contained a single phenotypically WT F 2 hermaphrodite starved after 6-7 days. Following phenotyping, we genotyped each worm by PCR using indels (Table  S4 ). Maternal and paternal backcrosses were scored in an analogous way. For maternal backcrosses, we did not include in our final calculations data from hermaphrodites that did not mate (no males were observed among their progeny) or hermaphrodites with a low outcrossing rate (< 20% of progeny were males). Male progeny from maternal backcrosses for NIC203 Chr. II and NIC203 Chr. III TAs were included in final calculations of affected progeny. That is, we could clearly distinguish developmental delay in males. In the case of EG6180 Chr. II TA and for C. briggsae, we only included hermaphrodites due to uncertainty in male phenotyping.
Images were acquired using a 63x/1. 4 plan-apochromat Oil DIC objective with the following filters: for DAPI Ex 406/15nm, Em 457/50nm and for Quasar 570 Ex 545/30nm, Em 610/75nm. We acquired for each image a Z stack containing 40 slices with a step size of 0. 2 mm. Quantification was performed using a MATLAB script from the Raj lab available at http://bitbucket. org/arjunrajlaboratory C. briggsae maternal-effect incompatibility We studied a previously described genetic incompatibility in a cross between the reference C. briggsae AF16 strain from India and the wild isolate HK104 from Japan (Table  S3 ). 28 In their original study, Ross et al. reported that approximately 20% of the F 2 progeny exhibited a pronounced developmental delay at 20 C. This delay phenotype was strongly associated with AF16 homozygosity for genetic markers in the central region of Chr.
Offspring who did not inherit the TA element from a carrier mother were removed from the population. Penetrance was implemented as a probabilistic modifier for killing (killing of affected offspring would occur at probability p = penetrance). We used penetrance of the TA as a proxy to study TAs that do not kill progeny prior to egg laying but only cause developmental delay, decreasing the fitness of non-carriers. We also simulated a wide range of genetic distances between antagonizing TAs to understand the impact of recombination. For each set of parameters, we simulated 100 populations (Figures  4, S3 , and S4). To run the simulation across many different parameters, we wrote an R script to run SLiM from the command line. We plotted the number of generations required until at least one TA reached fixation in the population, to be able to directly compare the rate of one TA to antagonistic TAs.
We defined a TAs as fixed once it reached 0. 95 allele frequency. The script for the simulation is available at github: https://github. com/eyalbenda/TA_simulations/ QUANTIFICATION AND STATISTICAL ANALYSIS For all worm crosses involving TAs, confidence intervals for proportion of affected worms were calculated using the Agresti-Coull method. 24 Quantification of single-molecule fluorescent in situ hybridization experiments was performed using a MATLAB script from the Raj lab available at http://bitbucket. org/arjunrajlaboratory. All reported sample sizes represent the number of individual worms.
ACKNOWLEDGMENTS We thank members of the  Burga and Kruglyak labs  for their comments. E. B. -D. is supported by the  Israel Science Foundation  (grant no. 2023/20 ) and  NIH  grant  K99-HG010369 ; C. B. is supported by the  Centre National de la Recherche Scientifique (CNRS) ; A. B. is supported by the  Austrian Federal Ministry of Education, Science and Research , the  Austrian Academy of Sciences , the  City of Vienna , and the  European Research Council  under the European Union's  Horizon 2020 research and innovation programme  ( ERC-2019-StG-851470 ); and L. K. is supported by the  Howard Hughes Medical Institute  and  NIH  grant  R01 HG004321.
Data and Code Availability The sequencing data generated for this study and the NIC203 genome assembly are available under NCBI bioproject PRJNA649308. Code for generating the simulations done in the study is available at github: https://github. com/eyalbenda/TA_simulations/ EXPERIMENTAL MODEL AND SUBJECT DETAILS C. tropicalis and C. briggsae maintenance, strains and mutant alleles All experiments were carried out at 25 C unless specified in the text. C. tropicalis and C. briggsae strains were grown on modified nematode growth medium (NGM) containing E. coli OP50, and 1% agar/0. 7% agarose to prevent burrowing of wild isolates using.
In many real datasets such as social media streams and cyber data sources, graphs change over time through a graph update stream of edge insertions and deletions. Detecting critical patterns in such dynamic graphs plays an important role in various application domains such as fraud detection, cyber security, and recommendation systems for social networks. Given a dynamic data graph and a query graph, the continuous subgraph matching problem is to find all positive matches for each edge insertion and all negative matches for each edge deletion. The state-of-the-art algorithm TurboFlux uses a spanning tree of a query graph for filtering. However, using the spanning tree may have a low pruning power because it does not take into account all edges of the query graph. In this paper, we present a symmetric and much faster algorithm SymBi which maintains an auxiliary data structure based on a directed acyclic graph instead of a spanning tree, which maintains the intermediate results of bidirectional dynamic programming between the query graph and the dynamic graph.
PERFORMANCE EVALUATION In this section, we present experimental results to show the effectiveness of our algorithm SymBi. Since TurboFlux  [19]  outperforms the other existing algorithms (e. g. , IncIsoMat  [10] , SJ-Tree  [6] , Graphflow  [18] ), we only compare TurboFlux and SymBi. Experiments are conducted on a machine with two Intel Xeon E5-2680 v3 2. 50GHz CPUs and 256GB memory running CentOS Linux. The executable file of TurboFlux was obtained from the authors. Datasets. We use two datasets referred to as LSBench and Netflow which are commonly used in previous works  [6, 19]. LSBench is synthetic RDF social media stream data generated by the Linked Stream Benchmark data generator  [21]. We generate three different sizes of datasets with 0. 1, 0. 5, and 2. 5 million users with default settings of Linked Stream Benchmark data generator, and use the first dataset as a default.
This dataset contains 23,317,563 triples. Netflow is a real dataset (CAIDA Internet Anonymized Traces 2013 Dataset  [4] ) which contains anonymized passive traffic traces obtained from CAIDA. Netflow consists of 18,520,759 triples. We split 90% of the triples of a dataset into an initial graph and 10% into a graph update stream. Queries. We generate query graphs by random walk over schema graphs. To generate various types of queries, we use schema graphs instead of data graphs to randomly select edge labels regardless of edge distribution  [19]. For each dataset, we set four different query sizes: 10, 15, 20, 25 (denoted by "G10", "G15", "G20", and "G25"). The size of a query is defined as the number of triples. We exclude queries that have no matches for the entire graph update stream. Also, we use the queries used in  [19]  (denoted by "T3", "T6", "T9", "T12", "G6", "G9", and "G12"), where "T" stands for tree and "G" stands for graph (having cycles).
We generate 100 queries for each dataset and query size. One experiment consists of a dataset and a query set of 100 query graphs with a same size. Performance Measurement. We measure the elapsed time of continuous subgraph matching for a dataset and a query graph for the entire update stream Δ. The preprocessing time (e. g. , time to build the initial data graph and the initial auxiliary data structure) is excluded from the elapsed time. Since continuous subgraph matching is an NP-hard problem, some query graphs may not finish in a reasonable time. To address this issue, we set a 2-hours time limit for each query. If some query reaches the time limit, we record the query processing time of that query as 2 hours. We say that a query graph is solved if it finishes within 2 hours. To evaluate an algorithm regarding a query set, we report the average elapsed time, the number of solved query graphs, and the average peak memory usage of the program using the "ps" utility.
Experimental Results The performance of SymBi was evaluated in several aspects: (1) varying the query size, (2) varying the insertion rate, (3) varying the deletion rate, and (4) varying the dataset size. Table  2  shows the parameters of the experiments. Values in boldface in Table  2  are used as default parameters. The insertion rate is defined as the ratio of the number of edge insertions to the number of edges in the original dataset before splitting. Thus, 10% insertion rate means the entire graph update stream we split. Also, the deletion rate is defined as the ratio of the number of edge deletions to the number of edge insertions in the graph update stream. For example, if the deletion rate is 10%, one edge deletion occurs for every ten edge insertions. For an edge deletion, we randomly choose an arbitrary edge in the data graph at the time the edge deletion occurs, and delete it.
SymBi solves most queries for every query set (except 1 query in the T6 query set and 1 query in the T9 query set), while TurboFlux has query sets that contains many unsolved queries. Specifically, TurboFlux solves only 42 queries while SymBi solves all queries for G20. Figure  5  shows the performance results for LSBench. In Figure  5a , SymBi outperforms TurboFlux by 2. 26∼38. 35 times in our generated queries. The reason for the lesser performance gap over Netflow is that LSBench has 45 edge labels, and thus it is an easier dataset to solve than Netflow with 8 edge labels. Also, there is almost no difference in performance for the queries used in  [19]. Unlike our generated queries, most queries from  [19]  are solved in less than one second. For theses cases, SymBi takes most of the elapsed time to update the data graph or auxiliary data structures that takes polynomial time, which is difficult to improve.
It is noteworthy that the update time of TurboFlux for edge deletion is much slower than that for edge insertion, while those of SymBi are quite similar. As noted in Section 1, this happens because the DCG update process of TurboFlux is more complex for edge deletion than for edge insertion. Varying the insertion rate. To test the effect of the insertion rate, we use the G10 query set and vary the insertion rate from 2% to 10% in 2% increments. Note that the size of the initial graph does not change from 90% of the original dataset. Figure  9  represents the results using Netflow for varying insertion rates. Figure  9b  shows that SymBi solves all queries for all insertion rates, while the number of solved queries of TurboFlux decreases from 69 to 54 as the insertion rate increases. In Figure  9a , SymBi outperforms TurboFlux regardless of the insertion rate.
However, as before, the performance gap between two algorithms decreases as the insertion rate increases due to the queries that Tur-boFlux cannot solve. As in Figure  7 , when we measure the average elapsed time with 54 queries that both algorithms solve within the time limit in all insertion rates, the performance ratio increases from 95. 32 times to 276. 60 times as the insertion rate increases from 2% to 10%. Figure  10  shows the results for LSBench. The performance ratio between two algorithms is the largest at 19. 30 times when the insertion rate is 4%. As one query reaches the time limit for TurboFlux at 6% insertion rate, the performance gap starts to decrease from 6% insertion rate. Nevertheless, SymBi is 8. 84 times faster than TurboFlux at 10% insertion rate. Varying the dataset size.
We measure the performance for different LSBench dataset sizes: 0. 1, 0. 5, and 2. 5 million users. The size of the initial data graph increases from 20,988,361 triples (0. 1M users) to 525,446,784 triples (2. 5M users). As shown in the experiment of varying the insertion rate, the number of triples in the graph update stream affects the elapsed time. To test only the effect of the dataset size, we set the same number of triples in the three graph update streams. We fix the number of triples in the graph update streams as 10% of the triples of the first dataset (0. 1M users). In Figure  11 , as the dataset size increases, the elapsed time of both algorithm generally increases and the number of solved queries decreases. SymBi is consistently faster and solves more queries than TurboFlux regardless of the dataset sizes.
1. Since recomputing from scratch takes a long time, we limit the number of update operations to 1000. Figure  14  shows the average DCS update time per update operation (i. e. , average DCS update time / 1000) for Netflow and LSBench. Our proposed update method is faster than recomputing from scratch by up to four orders of magnitude for Netflow and five orders of magnitude for LSBench. Effect of Estimated Size. To evaluate the effect of the estimated size of extendable candidates, we compare the estimated size of extendable candidates and the exact size of extendable candidates through two scores. Also, we compare the elapsed time when using the estimated size and the elapsed time when using the exact size. To define the two scores  1 and  2 for a query graph and a dataset, we consider the query vertex  selected to match according to the estimated candidate size order for each partial embedding  in the search process.
The average  2 score is 0. 830 for Netflow and 0. 966 for LSBench. The  1 score indicates that depending on the dataset, there may be differences between the estimated size and the exact size. However, the  2 score shows that in most cases of both datasets, the estimated candidate size order chooses the same vertex as the exact candidate size order. Although the computational overhead of the estimated size of extendable candidates is negligible, the estimated candidate size order works almost like the exact candidate size order. 15  represents the average elapsed time when using the estimated size and the exact size. In Figure  15b , the algorithm using the estimated size outperforms the algorithm using the exact size for all query sets in LSBench. In particular, the algorithm using the exact size failed to solve 1 and 2 queries in G10 and G20, respectively, while the algorithm using the estimated size solves all queries.
This is because the estimated size in LSBench works almost the same as the exact size, but there is no overhead for updating   (). Effect of Isolated Vertex. To test the effect of isolated vertices, we compare the elapsed time when using the isolated vertex technique and the elapsed time when not using it (i. e. , just using the leaf decomposition technique in  [3] ). Figure  16  shows the results. Since the isolated vertex technique and the leaf decomposition technique are the same in a tree-shape query, we exclude tree-shaped query sets. Due to the characteristics of the datasets, the generated queries are sparse. Because of this, there are not many situations where a query vertex becomes an isolated vertex without being a leaf, so the performance of the two techniques is similar in many query sets.
As noted in Section 1, this happens because the DCG update process of TurboFlux is more complex for edge deletion than for edge insertion. Varying the insertion rate. To test the effect of the insertion rate, we use the G10 query set and vary the insertion rate from 2% to 10% in 2% increments. Note that the size of the initial graph does not change from 90% of the original dataset. Figure9represents the results using Netflow for varying insertion rates. Figure9bshows that SymBi solves all queries for all insertion rates, while the number of solved queries of TurboFlux decreases from 69 to 54 as the insertion rate increases. In Figure9a, SymBi outperforms TurboFlux regardless of the insertion rate. However, as before, the performance gap between two algorithms.
We further proposed an efficient algorithm to update DCS for each graph update operation. We then presented a matching algorithm that uses DCS to find all positive/negative matches. Ex- tensive experiments on real and synthetic datasets show that SymBi outperforms the state-of-the-art algorithm by up to several orders of magnitude. Parallelizing our algorithm including both intra-query parallelism and inter-query parallelism is an interesting future work. 8 ACKNOWLEDGMENTS S. Min, S. G. Park, and K. Park were supported by Institute of In- formation communications Technology Planning Evaluation (IITP) grant funded by the Korea government (MSIT) (No. 2018-0-00551, Framework of Practical Algorithms for NP-hard Graph Problems). W. -S. Han was supported by Institute of Information communi- cations Technology Planning Evaluation(IITP) grant funded by the Korea government(MSIT) (No.
Methods Protein sets. In order to identify WH proteins significantly enrolled in cancer, we analyzed two protein sets. On one hand, we retrieved 347 human proteins related to the "wound healing" term from the Gene Ontology (GO) database (GO:0042060) (http:// www. geneo ntolo gy. org)  15, 16  , and the David Bioinformatics Resource (https:// david. ncifc rf. gov/)  17. On the other hand, to identify which WH proteins were already catalogued as cancer drivers, we retrieved 874 cancer driver proteins from the intOGen framework (https:// www. intog en. org). This analysis helps to identify the mechanism of action of proteins across tumor types  18. Then, we used The Catalogue of Somatic Mutations in Cancer (COSMIC) Cancer Gene Census (CGC) (https:// cancer. sanger. ac. uk/ census), that is an expert-curated description of the proteins driving cancer used in oncology research  19.
According to the Genomics Data Commons of the National Cancer Institute (https:// portal. gdc. cancer. gov/), and the cBioPortal database (http:// www. cbiop ortal. org/)  22, 23  , the copy number variant (CNV) amplifications and CNV deep deletions were identified using GISTIC2. 0, a computational approach that facilitates sensitive and confident localization of CNV in human cancers  24  ; the inframe, truncating and missense driver mutations were identified through whole exome sequencing; the mRNA high and mRNA low alterations were analyzed through RNA sequencing V2 RSEM where the expression Z-scores of tumor samples were compared to the expression distribution of all log-transformed mRNA expression of adjacent normal samples in each cohort  25  ; and the high and low protein expressions were measured by reverse-phase protein array (RPPA)  26.