dataesr/scientific-paragraphs-categorization huggingface dataset:
from US Food and Drug Administration (FDA) compiled a database for the maximum recommended daily dose (MRDD) of 1309 pharmaceuticals and proposed some QSAR modelling based on MDL 2D-descriptors  26. We downloaded the dataset from the FDA website, and developed a classification model by using only compounds with clear information on low/high MRDD (with low MRDD considered as potential toxic compounds and high MRDD as nontoxic compounds). For the OCT2 inhibition model, we used the dataset proposed by Kido et al. 28  , who screened a library of 910 prescription drugs and drug-like compounds by using a high-throughput assay. Successively, they detected sub-clusters (i. e. substructures) of OCT2 inhibitors by means of the SOM algorithm applied to structural descriptors. De Bruyn et al. presented an in vitro OATP1B inhibition high-throughput assay, to assess the inhibitory potential of drug candidates for the OATP1B protein  29.
They published data for 2000 molecules, for both 1B1 and 1B3 isoforms; after careful analysis (we observed a large overlap of the datasets), we decided to limit our modelling efforts to the isoform 1B1. Concerning the BCRP datasets (inhibition and recognition), checking more than 100 publications led to the collection of 935 and 385 molecules, respectively. We kept only proved BCRP-binders, and we tuned the activity thresholds for compound categories comparing data for the same molecules, when available in two or more papers. Finally, both BCRP datasets were randomly split into training and test set (see details in Table  1 ). Details for BCRP-categories thresholds (based on IC 50 and percentage of inhibition), as well as the collected data for BCRP recognition and BCRP inhibition is available as Supplementary Information Tables  S8  and S9 , whereas for the other datasets we refer to the original publications.
Experimental data curation: private in-house datasets. In silico prediction of the Blood Brain Barrier (BRAIN PERM) permeability in vivo in rodent is based on experimental measurement of brain to plasma ratio of concentrations (Kp) in vivo at 2 time points after compound administration in rodents. In silico prediction of Caco-2 Permeability (CACO2 PERM) was based on Caco-2 permeability assay which uses an established method for predicting the in vivo absorption of drugs across the gut wall by measuring the rate of transport of a compound across the Caco-2 cell line. The Caco-2 cell line is derived from a human colon carcinoma. The cells have characteristics that resemble intestinal epithelial cells such as the formation of a polarised monolayer, well-defined brush border on the apical surface and intercellular junctions.
Methods: We will include double-or single-blind randomized controlled trials in patients aged less than 18 years. No restrictions will be made by study publication date or language. Several electronic databases will be searched along with secondary sources such as bibliographies and trial registry websites for published and unpublished studies. Response rates to lithium compared with placebo or other active drugs will be the primary efficacy outcome. Primary tolerability and acceptability outcomes will be rates of serious adverse events and dropouts, respectively. Secondary outcomes will include rates of remission, severity of manic symptoms at different time points, and incidence of specific adverse events. Discussion: Findings from this systematic review are critically needed to inform clinical practice.
Search methods for identification of studies We will search EMBASE, MEDLINE, PsycINFO, CINAHL, and the Cochrane Central Register of Controlled Trials (CENTRAL), the trial databases of regulatory agencies and the websites of pharmacological industries for published, unpublished and ongoing randomized controlled trials. No language or study publication date restrictions will be applied. See PROSPERO (CRD42017055675) for full details about the search strategy, including the text words and keywords that will be used and the list of websites.
Data extraction and analysis Two authors (AW and NH) will independently screen titles and abstracts to identify potentially relevant studies retrieved by the search strategy. The full text of the screened studies will be reviewed for inclusion. Agreement rates on the initial assessments will be reported using the kappa coefficient. All reasons for excluding the ineligible studies will be recorded. Any disagreement will be resolved through discussion or, if required, by consulting other authors of the review team (AD, SP, AC). The frequency and nature of all such disagreements will be recorded in a study log. We will identify and remove duplicate records and collate multiple reports that relate to the same study so that each study, rather than each report, is the unit of interest in the review.
Dichotomous data We will calculate the relative risk (RR) with corresponding 95% CI for dichotomous outcomes. We will calculate response rates out of the total number of randomized participants. For statistically significant results, we will calculate the number needed to treat for an additional beneficial outcome (NNTB) and the number needed to treat for an additional harmful outcome (NNTH). For both continuous and dichotomous data, we will only conduct a meta-analysis if pooling is appropriate; that is, if the treatments, participants, and the underlying clinical question are homogenous enough. We will narratively describe skewed data reported as medians and interquartile ranges. If meta-analysis is pursued, log transformation of relative risks will be used to enhance normality of the estimates.
Missing continuous data When there are missing data and the method of 'last observation carried forward' (LOCF) is used to perform an ITT analysis, we will use the LOCF data. When only the standard error or t statistics or p values are reported, we will calculate standard deviations (SD) according to  Altman and Bland (1996). Where SDs are not reported, we will contact the authors for these data but, in the absence of data from the authors, we will borrow SD from other studies in the review  (Furukawa et al. 2006 ). We will examine the validity of this imputation by sensitivity analyses.
The DIRAC project is developing interware to build and operate distributed computing systems. It provides a development framework and a rich set of services for both Workload and Data Management tasks of large scientific communities. A number of High Energy Physics and Astrophysics collaborations have adopted DIRAC as the base for their computing models. DIRAC was initially developed for the LHCb experiment at LHC, CERN. Later, the Belle II, BES III and CTA experiments as well as the linear collider detector collaborations started using DIRAC for their computing systems. Some of the experiments built their DIRAC-based systems from scratch, others migrated from previous solutions, ad-hoc or based on different middlewares. Adaptation of DIRAC for a particular experiment was enabled through the creation of extensions to meet their specific requirements.
Each experiment has a heterogeneous set of computing and storage resources at their disposal that were aggregated through DIRAC into a coherent pool. Users from different experiments can interact with the system in different ways depending on their specific tasks, expertise level and previous experience using command line tools, python APIs or Web Portals. In this contribution we will summarize the experience of using DIRAC in particle physics collaborations. The problems of migration to DIRAC from previous systems and their solutions will be presented. An overview of specific DIRAC extensions will be given. We hope that this review will be useful for experiments considering an update, or for those designing their computing models.
The DIRAC consortium has been established in 2014 as a representing body for the development and maintenance of the DIRAC software. The consortium counts a small set of active members, each of which elects a representative, while consortium members elect a Director, and a technical Director. Institutes that are part of the consortium engage in the maintenance and in the promotion of the DIRAC software. The aim of this paper is to show how DIRAC can satisfy the requirements of different VOs, and which technical solutions have been adopted. This paper is organized as following: in section 2 we will give details on the DIRAC software organization. In section 3 some DIRAC users' experiences will be summarized. Conclusions are given in section 4.
Accommodating requirements Communities that have chosen DIRAC as the distributed system of choice vary greatly: some of them have hundreds of users, others only a few. A community using DIRAC may run concurrently several tens of thousands of "jobs" on grids and clouds, and store and analyze petabytes of data on remote storage; others only run few hundreds of jobs per week, and barely need to interact with storage systems. Requirements vary, and DIRAC should be able to accommodate most of them. A single DIRAC installation can serve one VO, or more than one. Few DIRAC installations can serve dozens of Virtual Organizations (VOs), or even single users. DIRAC needs to be flexible in accommodating the different requirements, while at the same time providing scalability, and a software easy to extend.
In order to accommodate different requirements, DIRAC has been developed with extensibility in mind. We recognize two types of extensibility, that we dub "horizontal" and "vertical". In Figure  1  we show a diagram that explains the so-called "horizontal extensibility": the core project ("DIRAC"), can be extended for accommodating different requirements. Each of the projects in Figure  1  have been created with a specific goal and are independently versioned. At the same time a DIRAC release is composed by all those projects, so there is a strong dependency between them. All the projects in Figure  1  are hosted together on GitHub, share the same license and are maintained by the same set of users. The "DIRAC" software is the "Core project", so it is the glue that keeps the satellite projects together.
It depends on software not maintained by the DIRAC consortium, which we collect in "Externals". The code for the DIRAC web portal sits in "WebAppDIRAC". "RESTDIRAC" extends some DIRAC services by providing a REST (Representational State Transfer) interface. With "VMDIRAC" it is possible to create Virtual Machines on several clouds. "COMDIRAC" extends the DIRAC user interface. The "Pilot" is instead independent from all the other code. Figure  2  shows a graphical representation of vertical extensibility, that enables DIRAC users and VOs to extend the functionalities of the "vanilla" projects. In other words, the projects of Figure  1  can be extended by the communities in order to provide specific functionalities. Coding for DIRAC also requires developing with flexibility in mind. There are several examples of DIRAC's flexibility, and one example regards DIRAC not imposing any computing model on its users.
DIRAC provides the necessary interoperability of heterogeneous computing system such as grids with different middleware, academic/commercial clouds and local computing clusters. DIRAC supports the functionality extension so that experiments can integrate necessary features by themselves. Belle II also developed an extension module, so-called BelleDIRAC, which provides not only the API but also basic tools including remote job submission and data management for the Belle II analysis software framework. On top of that, an automated production system based on DIRAC Transformation System was introduced. In order to evaluate the computing model, Belle II used DIRAC for running Monte Carlo (MC) mass production campaigns. In particular, since the automated production system was introduced (from MC4 in Figure  4 , which shows the history of MC production campaigns), the production conditions drastically improved.
The Linear Collider Community The Linear Collider community consists of several collaborations -CLIC Detector and Physics study (CLICdp 3  ), International Large Detector (ILD 4  ), Silicon Detector (SiD 5  ), working on detector optimisation and physics studies for the Compact LInear Collider (CLIC) or the International Linear Collider (ILC). The iLCDirac extension of DIRAC  [20]  was created to support the linear collider software, and to customize the DIRAC Transformation System. The extension contains Workflow Modules In total, about 11 PB have been transferred. They include all the transfers between the processing sites and the storage locations, both for production and analysis jobs. that offer python interfaces to control the MC generators, simulation, reconstruction and analysis software used in this community.
The workflow modules also allow combining all these steps into a single job. The computing resources are provided by grid sites in the OSG and EGI grids  [21]. There are more than 40 grid sites accessed via iLCDirac. The largest provider of resources are DESY, FermiLab, RAL and CERN (see Figure  6 ). For accessing storage elements the XrootD and SRM protocols are used. The DIRAC file catalog (DFC) is used to store replica and meta data information. The (iLC)DIRAC transformation system is used for centralised productions. The transformation system uses meta data information in the DFC to chain generation, simulation, and reconstruction tasks. In the 12 months leading up to October 2016 the iLCDirac instance was used to run 4 million jobs, which used a total of 2800 CPU years. 2 PB of new files were created.
Most of the computing resources comes from batch systems, while another 35% from Grids and Clouds. With VMDIRAC, the IHEP DIRAC instance is able to integrate cloud in an elastic way since the end of 2014. Besides pilot-based workload management, BESIII also uses the DFC (DIRAC File Catalog) as Replica Catalog, Metadata Catalog and Dataset Catalog to define and manage BESIII data. The BESDIRAC extension contains BESIII-specific services, which include Task Submission and Management System (TSMS), Massive Data Transfer System (MDTS), and Site Monitoring System (SMS), which is based DIRAC's RSS (Resource Status System). The MDTS is used to take care of the transfer of bulk datasets among sites, and includes accounting and error tracking. The SMS can report site status, and send warning messages when there are problems, in order to improve system operations.
It is built upon a bipartite spectral co-clustering method  [1] , and a recent approach of the agglomerative hierarchical clustering  [2] , which allows sparsifying the proximity matrix to reduce computational cost. SHCoClust is capable to organize coclusters in a form of dendrogram, and to discover cluster hierarchies inside co-clusters. We believe this property is valuable in understanding the content of data. However, none of the methods that contributes to establish SHCoClust is able to do so. Furthermore, with inner product at base, SHCoClust can employ kernel functions, which offers it the capability to process non-linearly separable datasets more effectively. To our knowledge, SHCoClust is the first method that is able to reveal cluster hierarchies of and inside co-clusters, and to apply kernel functions in co-clustering tasks.
B. The Agglomerative Hierarchical Clustering There are two principle techniques of hierarchical clustering, the divisive (DHC) and the agglomerative (AHC). Given a dataset D of n instances and m features, DHC begins with splitting D into two sets iteratively and results in clusters of which each is a data instance. AHC performs in the opposite way, it starts with merging two individual instances and eventually outputs a cluster of size n. They output a binary tree-like structure of 2n -1 nodes, named dendrogram. Comparing these two techniques in terms of complexity, AHC is practically preferred as it is of O(N 3 ) in the worst case. However, finding an optimal split in DHC can be NP-hard, if n is large. [7] surveys many works that improve the performance of AHC. In the scope of this paper, we focus on the conventional AHC and its methods.
The computing procedure of AHC is shown in Algorithm 1, where d(, ) is a distance metric, and each data instance is initially considered as a cluster, represented by C. Algorithm 1 Conventional AHC Require: dataset D n×m. ∀x ∈ [1,. , n], C x ← D x 1: distance matrix D ← ∅ 2: for i = 2 to n do 3: for j = 1 to i -1 do 4: D ij ← d(D i , D j ) 5: end for 6: end for 7: while num clusters> 1 do 8: (i, j) ← arg minD x,y 9: C ij ← C i ∪ C j 10: for all C k ∈ D such that C k = C i , C k = C j do 11: D update ← ----d(C ij , C k ) 12: end for 13: end while In the setting of Vector Space Model and the TF-IDF weighting scheme, documents can have a sphere-like projection in the feature space, in such case the Euclidean distance is a suitable choice to compute the distance of two document vectors. In AHC, an essential step, shown as line 11 in Algorithm 1, is to determine d(C ij , C k ).
It is mathematically and experimentally proved to be equivalent to the original LW formula. Input to Sim AHC is the pairwise similarity matrix S of a normalized dataset (that each row has norm 1). As ∀s ∈ S, 1 ≥ s ≥ 0, S can be sparsified by a threshold value, so that less memory is demanded to store S and less time is required to compute on it. This is an advantageous property in terms of efficiency. However, this property cannot be found in the conventional AHC. Because when distances are used, zero and close-to-zero values signify high similarities, which are of the most interest in clustering, thus they have to be stored for computation instead of being ignored. The similarity updating process between a newly-merged cluster C ij and any other cluster C k in Sim AHC consists of two steps, updating the cross-cluster similarity and updating the cluster's self similarity: s(C ij , C k ) = α i s(C i , C k ) + α j s(C j , C k ) + βs(C i , C j ) -γ|s(C i , C k ) -s(C j , C k )|.
Algorithm 2 SHCoClust Require: dataset D n×m 1: R n×n (i, i) ← m j=1 D ij , C m×m (j, j) ← n i D ij 2: D norm ← R -1 2 DC -1 2 3: k ← ⌈log 2 K⌉ + 1 4: U n×k , S k×k , V T k×m ← SV D(D norm , k) 5: if S 11 ≥ • • • ≥ S kk then 6: U ′ n×(k-1) ← U n×[2,. ,k] 7: V ′ m×(k-1) ← V m×[2,. ,k] 8: else if S kk ≥ • • • ≥ S 11 then 9: U ′ n×(k-1) ← U n×[1,. ,k-1] 10: V ′ m×(k-1) ← V m×[1,. ,k-1] 11: end if 12: Z (n+m)×(k-1) ← R n×n U ′ n×(k-1) C m×m V ′ n×(k-1) 13: similarity matrix S ← ∅, ∀x ∈ [1,. , n + m], C x ← Z x 14: Z ′ ← norm(Z) such k-1 c=1 Z ′2 rc = 1, ∀r ∈ [1,. , n + m] 15: for i = 1 to n + m do 16: for j = 1 to i do 17: S ij ← s(Z ′ i , Z ′ j ) 18: end for 19: end for 20: while num clusters> 1 do 21: (i, j) ← arg maxS x,y 22: Shown as line 14 in Algorithm 2, Z is normalized so that if the similarity function s(, ) in line 17 takes a form of inner product, values in matrix S are cosine similarities.
A. Datasets, Preprocessing and Evaluation Metrics Three well-known corpora that have been widely tested in text clustering benchmarks are used in our experiments. These collections are Reuters-21578 1  [9], SMART [1] and 20NewsGroups (20NG) 2  [10]. Table II details six experimented datasets that are sampled from the three collections. In the rest of the paper, theses datasets are referred by their indexes shown in column "Ind. ". Based on the bag-of-words assumption and the Space Vector Model, each dataset is preprocessed into a doc-term matrix, whose rows are document vectors and columns are terms. A few steps are involved in preprocessing, in detail, stop words are removed, terms that have document frequency higher than 20% and lower than 1% are removed, and TF-IDF weighting strategy is applied.
B. Comparisons of Clustering Quality Our first experiment consists of four tests to compare clustering quality among conventional AHC, BSC, SHCoClust with and without sparsification. These tests are: 1) SHCoClust without sparsification v. s. conventional AHC 2) SHCoClust with sparsification v. s. without 3) SHCoClust without sparsification v. s. BSC 4) SHCoClust with sparsification v. s. BSC In tests that concern sparsification, threshold values τ at percentile ranks {10, 25, 50, 75, 90}% of similarities in S are used to sparsify S. In this experiment, we apply linear kernel to obtain S, which is in fact filled with cosine similarities. The results of this experiment are illustrated in Figure  1. From top to down, each row maps to one test that is marked by its index. Each column lists the corresponding results for a tested dataset.
In datasets of S0 and S1, the increase is tremendous, ARI and NMI are raised up to 0. 8 and 0. 7 at maximum. to BSC for all clustering methods, except for single link. Though improvements can be found in R5, R7 and NG8, other datasets do not display any. However, when sparsification is applied in SHCoClust, some noticeable amelioration can be observed. Comparing graphs of test 3) and of test 4), bars generally exhibit a left-to-right drift, diminishing their heights in the left side of the vertical line at x=0, and growing their heights in the right side. This drift is very apparent in R7 and in NG20 datasets, where ARI and NMI bars are noticeably pulled towards the right side. For other datasets, single link seems to be the least affected. To summarize, SHCoClust significantly improves clustering quality compared to the conventional AHC for most clustering methods.
C. Extension to Kernel Functions In our second experiment, we extend the similarity function s(, ) in SHCoClust to Gaussian kernel, given by K(x, y) = exp(-γ xy 2 ) for x, y ∈ D, γ = 1/dim(I) by default 3. Three representative datasets R5, S0 and NG8 are experimented and are compared to their results obtained by linear kernel. The input kernel matrix is sparsified in the same fashion as in the previous experiment. For each threshold value, ARI, NMI, relative memory usage and relative running time are recorded. Figure  2  illustrates the results of this experiment. Indexed by the clustering methods in column and the names of datasets in row, each graph in Figure  2  contains four lines: the solid line with "+" sign denotes the NMI values, the dashed line with triangle sign is for ARI, while the solid line with "o" sign and the solid line with "x" sign represent the relative memory usage and the relative running time, respectively.
Among seven clustering methods, single link is the most peculiar, its ARI and NMI are almost invariant to the effect of sparsification. Exceptionally, in R5 of linear kernel and Gaussian kernel, ARI of single link boosts when percentile rank = 90%, at which point memory usage and running time are largely reduced. Comparing the two kernel functions, overall similar behavior can be observed regarding the four curves. In some cases, Gaussian kernel returns higher metric values than linear kernel, and vice versa. Among the three experimented datasets, results of S0 are globally better, while R5 and NG8 display limited difference in their results. Principle conclusions we can draw from this experiment are that (1) SHCoClust is capable to guarantee the clustering quality even when its input is significantly sparsified, requiring considerably reduced memory usage and running time.
From this table we can see that all ARIs* are higher than those of BSC, implying that better clustering quality is achieved by SHCoClust. Moreover, ARIs* are obtained with substantially reduced memory usage and running time. Except for R5 dataset, in which median method only gains 8% in time and 25% in memory, other datasets obtain up to 86% time gain and on average 75% memory gain. This proves that SHCoClust is good at economizing computing resources, meanwhile preserving clustering effectiveness. In other words, if given limited computing resources, SHCoClust is able to process relatively large datasets. This reflects its scalability.