dataesr/scientific-paragraphs-categorization huggingface dataset:
RELATED WORK In this section, we focus on existing tools supporting the design of IoT applications. Node-RED  [7]  and IFTTT  [13]  are two industrial tools that provide graphical support for visually building applications consisting of IoT objects. SmartThings  [16]  platform provides ability to write compound rules for home automation using SmartRules app  [15]. Sharp Tools  [14]  has a visual builder and dashboard to automate and monitor smart homes. webCoRE  [19]  is a community rule engine that allows users to create scripts that are interpreted and executed by SmartThings. openHAB  [12]  is an open source home automation software that allows one to define rules based on events, time and other triggers. Our choice was to propose a more expressive language than those based on rules as IFTTT but avoid to have a full-fledged programming language like webCoRE.
CONCLUSION In this paper, we have presented a solution for supporting endusers when designing new IoT applications using available objects and devices. We have proposed a simple yet expressive enough composition language for describing specific scenarios consisting of successive events and actions organized in a certain order. For simplifying usage of this language by end-users, such compositions can be easily designed using a newly developed graphical user interface. Once the composition expression is defined, analysis techniques can be triggered to check that the intended application fulfils some correctness properties. Once the composition is valid, it can be deployed in a click of a button, through an execution engine. As for implementation, we decided to extend an existing Mozilla WebThings platform, which is a complementary implementation of W3C WoT Candidate Recommendation.
We introduce shallowHRD, a software tool to evaluate tumor homologous recombination deficiency (HRD) based on whole genome sequencing (WGS) at low coverage (shallow WGS or sWGS; $1X coverage). The tool, based on mining copy number alterations profile, implements a fast and straightforward procedure that shows 87. 5% sensitivity and 90. 5% specificity for HRD detection. shallowHRD could be instrumental in predicting response to poly(ADP-ribose) polymerase inhibitors, to which HRD tumors are selectively sensitive. shallowHRD displays efficiency comparable to most state-of-art approaches, is cost-effective, generates low-storable outputs and is also suitable for fixed-formalin paraffin embedded tissues.
We introduce shallowHRD, a software for HRD testing based on the number of large-scale genomic alterations (LGA) obtained from whole genome sequencing (WGS) at low coverage (shallow WGS or sWGS; $1X). sWGS robustly detect copy number alterations (CNAs), even in fixed-formalin paraffin embedded (FFPE) samples and liquid biopsies  (Van Roy et al. , 2017)  at low cost and with easy-storable outputs. The concept of LGAs follows single-nucleotide polymorphism (SNP) array approaches, exploiting an increased number of large-scale intra-chromosomal CNAs characteristic of HRD  (Abkevich et al. , 2012; Birkbak et al. , 2012; Popova et al. , 2012).
ACKNOWLEDGEMENTS This research has been undertaken under a cooperation between CEA and Atos. with the goal of co-designing extreme computing solutions. This research was partly funded by a grant of  Programme des Investissements d'Avenir. This work has been jointly supported by the  Spanish Ministry of Science, Innovation and Universities  under the project  RTI2018-098156-B-C52  and by  JCCM  under project  SBPLY/17/180501/000498. BXI development was also part of  ELCI , the  French FSN (Fond pour la Société Numérique)  cooperative project that associates academic and industrial partners to design and provide software components for new generations of HPC datacenters.
V. PERFORMANCE EVALUATION We carried out extensive experiments to evaluate the PD-CSP framework on two well-known CSP problems (MAXSAT and Job Scheduling). The two problems differ from the input values. The input of MAXSAT is the set of constraints, each of which is a conjunction of Boolean variables, however the input of CSP is the set of constraints, each of which is a relation of continues variables. Therefore, different data instances are used for both problems. For MAXSAT , we used one Random instance ''Ins1'' containing 110 variables and 50 clauses, one Crafted instance ''Ins2'' containing 220 variables and 45 clauses, and two Industrial instances ''Ins3'' containing 360 variables and 685 clauses, and ''Ins4'' containing 675 variables and 1286 clauses. For Job Scheduling we used the large size benchmarks proposed by Taillard  [37].
The different instances are denoted by the number of jobs and the number of machines. We used four instances: ''Ins5'' containing 15 jobs and 15 machines, ''Ins6'' containing 30 jobs and 20 machines, ''Ins7'' containing 50 jobs and 20 machines and ''Ins8'' containing 100 jobs and 20 machines. A. CLUSTERING QUALITY Figure  3  presents the quality of decomposition of three different clustering algorithms: intuitive, multi-objective k-means, and DBSCAN, on different dataset instances (MAXSAT and Job Scheduling). The intuitive clustering is a naive decomposition that partitions constraints directly to the clusters, i. e. , the first block is assigned to the first cluster, the second block is assigned to the second cluster, and so on, until all the blocks are assigned. Many metrics have been developed to measure the quality of the decomposition.
B. RUNTIME Figures 4 and 5 present the runtime of the PD-CSP and the state-of-the art algorithms for both MAXSAT and Job Scheduling. For the MAXSAT , the baseline algorithms are maxine  [14]  and Partial DAGs  [15]. For the Job Scheduling, the baseline algorithms are B&B  [38]  and MILP  [39]. For various data instance sizes, the results reveal that for small number of variables, the baseline algorithms outperform the PD-CSP algorithm. This is explained by the fact that PD-CSP performs further preprocessing step represented by the decomposition step. However, for larger number of variables and with using higher number of workers (GPU-blocks in our context), PD-CSP outperforms the baseline algorithms. This is due to the intelligent parallel strategy employed in the search step. Figure  6  shows the speedup of PD-CSP and the four baseline algorithms by considering 1024 workers (GPU-blocks).
Background: The ChEMBL database is one of a number of public databases that contain bioactivity data on small molecule compounds curated from diverse sources. Incoming compounds are typically not standardised according to consistent rules. In order to maintain the quality of the final database and to easily compare and integrate data on the same compound from different sources it is necessary for the chemical structures in the database to be appropriately standardised. Results: A chemical curation pipeline has been developed using the open source toolkit RDKit. It comprises three components: a Checker to test the validity of chemical structures and flag any serious errors; a Standardizer which formats compounds according to defined rules and conventions and a GetParent component that removes any salts and solvents from the compound to create its parent.
Conclusion: All the components of the structure pipeline have been made freely available for other researchers to use and adapt for their own use. The code is available in a GitHub repository and it can also be accessed via the ChEMBL Beaker webservices. It has been used successfully to standardise the nearly 2 million compounds in the ChEMBL database and the compound validity checker has been used to identify compounds with the most serious issues so that they can be prioritised for manual curation.
Introduction The ChEMBL database is a freely available bioactivity database containing close to 2. 5 million compound records on nearly 2 million unique chemical structures  [1]. The compound structures and associated bioactivity data are extracted on a regular basis primarily from the medicinal chemistry literature. A growing number of researchers are also depositing experimental data directly in order to make these available in the public domain. Furthermore, ChEMBL contains a set of manually curated marketed drugs and clinical candidates as well as selected bioactivity data from other public databases such as BindingDB  [2]  and PubChem  [3]. Bioactivity data on the same compound from all ChEMBL sources (scientific articles, deposited datasets and curated drug sources) are aggregated according to chemical structure.
Compounds may be physically tested in bioassays as the so-called parent molecule or as one of a number of different salt forms. Scientists commonly wish to aggregate the data on these different forms on the basis of the common underlying parent structure, and so it is necessary to link these various forms of the "same" underlying parent molecule. In order to facilitate the use of the database, a key objective of the ChEMBL compound curation process is to standardise the chemical structures stored in the database and to assign a unique identifier to each distinct chemical structure regardless of the source. It is worth noting that there are over 5000 unique compounds in the ChEMBL database with data from ten or more different sources, and four compounds (doxorubicin, ciprofloxacin, chloroquine and paclitaxel) each with data from over 1000 sources.
For each ChEMBL release, more than 50,000 new structures are added to the database, which makes manual curation and standardisation of the chemical structures impracticable. Hence an automated procedure is required. The chemical structures submitted to the ChEMBL database are generally received as molfiles  [4]  but can also be in SMILES format  [5]. There is no universal standard for these formats and the challenges of converting between chemical structure formats is well documented  [6]. Even the simple process of loading molecules into and out of different cheminformatics packages can subtly change the structure, particularly if it was not well drawn in the first place. Chemical structures from the primary scientific literature are mostly manually drawn from the structural information in the papers prior to loading into ChEMBL.
These structures are often represented in the publication as Markush structures with different R-groups shown in SAR (structure-activity relationship) tables. Compounds may also be shown with charges on acidic or basic groups, to indicate the form in which they are likely to interact with amino acid residues in a binding pocket. In some articles the compounds synthesised and reported are isotopically labelled. The ChEMBL compound curation procedure therefore needs to process molecules represented in all these ways (and more) to determine which compounds are the same. Examples of these situations can be found in recent articles where data was extracted for the ChEMBL database  [7] [8] [9]. A standardised V2000 molfile was chosen as the primary chemical structure representation in the database.
The Standard InChI and the corresponding hashed InChIKey  [10, 11]  are used in ChEMBL as the measure of uniqueness for a chemical structure and are calculated from the molfile using software provided by the InChI Trust, currently version 1. 05  [12]. Thus, when compounds from different scientific articles have the same Standard InChI and InChIKey they are considered to be the same compound and are assigned the same ChEMBL identifier (CHEMBL_ID). The use of the Standard InChI has a number of advantages in the context of the ChEMBL database. It was developed as an IUPAC open standard to enable information exchange and interoperability between large databases. The simple format of Standard InChI is also used by many other database providers and hence it is an ideal choice for an open database such as ChEMBL.
Despite these limitations, it is a good compromise for a structural identifier for a public database such as ChEMBL. To aid interoperability, a canonical SMILES is also generated from each primary molfile, but this is considered to be a secondary structure. The challenges of registering compounds in a database and determining chemical uniqueness are not specific to ChEMBL. PubChem, the open chemistry database of over 100 million compounds maintained by the National Institutes of Health (NIH) has developed an automated and publicly available standardisation process based on OpenEye toolkits  [13]. They utilise an isomeric canonical SMILES to identify unique structures and show that their method generates more unique structures than when Standard InChI is used to determine uniqueness. They also generate a canonical tautomer for their compounds.
The ChEMBL group decided against the use of a canonical tautomer, for a number of reasons. Firstly, it is anticipated that the authors of an article in the medicinal chemistry literature will have worked on their compound set for some considerable time, performed docking and molecular modelling studies and will be well placed to assign the most appropriate tautomeric form, for example based on specific interactions with the target protein. Secondly, it is possible for tautomers to interconvert under experimental conditions. Thirdly, changing the tautomeric form of a compound can alter its stereochemistry by removing, or introducing, a chiral centre from a molecule, requiring often difficult decisions to be made about how to "merge" compounds/data with different chirality or which stereo form to create.
Thalidomide is a well-known example of the second phenomenon which interconverts between the therapeutic R-enantiomer and the teratogenic S-enantiomer via the enol tautomer  [14]. The Royal Society of Chemistry (RSC) developed the Chemical Validation and Standardization Platform (CVSP)  [15]  to support compound deposition into their ChemSpider chemical database  [16]  and as a contribution to the Innovative Medicines Initiative (IMI) funded OpenPHACTS project  [17]  which aimed to standardise chemical structures from multiple databases. The CVSP methodology uses sets of SMARTS-based rules that can be tailored by the user. The code is available on GitHub [18] but currently has no obvious documentation and the interface is no longer available  [19]  although it is still possible for depositors to ChemSpider to use the rules to validate their structures.
The United States Environmental Protection Agency (EPA) also strive to have well curated structures in their DSSTox database  [20]. They have described, in detail, the complexity of the task and have undertaken extensive curation of their chemical structures using a combination of manual and automated methods. Much of their focus has been on resolving the mismatches between names, identifiers and structures between their compound set and those in the US National Library of Medicine databases ChemID  [21]  and PubChem. Due to the inability of the V2000 molfiles to distinguish relative and absolute stereochemistry they have chosen to use V3000 molfiles as their preferred structure format. They also use an InChIKey calculated using the ChemAxon JChem toolkit to determine uniqueness, but this differs from the Standard InChIKey discussed above.
SMILES are provided for users not wanting to use V3000 molfiles, but they make the point that this results in a less rich representation of the structures. Their methods are based on a combination of commercial toolkits and their own manual curation tool  [22]. The Global Substance Registration System (GSRS), developed by the regulatory authorities in the USA and Europe, creates a Unique Ingredient Identifier (UNII) for components of medicinal products which includes small molecules but also more complex molecules such as proteins and polymers  [23]. This is a particularly useful resource for identifying the structures of specific pharmaceutically relevant compounds, but it is less useful for the bulk curation of the larger set of bioactive molecules in the ChEMBL database. Many commercial software providers also provide toolkits for standardising compound structures.
These are widely used by large pharmaceutical and agrochemical companies where the precise annotation of a chemical structure is crucial for intellectual property protection. Those produced by ChemAxon and 3DS are examples of these toolkits  [24, 25]. The legacy pipeline for processing compound structures prior to deposition into ChEMBL was based on commercial software and had evolved over more than 10 years. During this time, more and more incorrect, unusual, and exceptional situations were identified and integrated into the pipeline. Unfortunately, these refinements were increasingly making the code difficult to maintain and modify. In reviewing options for a sustainable future solution that also removed the dependence on commercial software it became apparent that none of the existing toolkits fitted the ChEMBL group's requirements.
Methods Three new components have been developed using the RDKit toolkit. Two of these components (Standardizer and GetParent) have been rewritten and adapted from rules originally implemented using a commercial software toolkit. In contrast, the Checker component was developed more recently in an attempt to identify problem structures before they were added to the ChEMBL database. Hence the new ChEMBL curation pipeline comprises three processes: 1. Checker: identifies and validates structures and identifies problems before they are added to the database 2. Standardizer: processes (standardises) chemical structures according to a set of predefined rules 3. GetParent: generates parent structures based on a set of rules and defined lists of salts and solvents.
Checker component The Checker component validates structures prior to the compounds being loaded into ChEMBL. If an error or problem is detected in the structure a score is reported for the molecule; the score increases with the severity of the perceived problem. In the majority of cases compounds are loaded into the database even if a warning flag is identified. The scores are recorded but at this point errors are not corrected. Instead, they are prioritised and subjected to subsequent manual curation, as time and degree of seriousness permits. A summary of the structure checks performed, and the resultant penalty scores assigned are shown in Table  1. It is an individual user's choice what they decide to do with molecules that return specific penalty scores. For ChEMBL, a penalty score of 7 is considered to be a fatal error and the molfile is not loaded into the database.
Examples of illegal input are, for example, unknown elements in the molfile, or molfiles that cannot be read in RDKit due to the inability to process their aromatic bonds. Molecules with a penalty score of 6 are loaded into the ChEMBL database but without a molfile, as it is considered that these have a significant issue with the structure, and it is preferable to fix the problem than have a badly formed molecule in the database. Most of the issues that give rise to a penalty score of 6 are self-explanatory and are described in Table  1. If the penalty score is 5 or 2 the molecule is loaded but the compounds are also prioritised for manual curation. Again, many of the 5 and 2 penalty scores are self-explanatory, but the stereo mismatch errors perhaps need further explanation. These are reported when the number of stereocentres perceived by the following calculation methods differ: • Mol: number of atoms where a wedged bond starts • InChI: number of tetrahedral stereocentres • RDKit: number of atomic stereocentres remaining after calling Chem.
AssignStereochemistry() Hence the "InChi_RDKit/Mol stereo mismatch" warning message indicates that the InChI and RDKit algorithms perceive the number of stereocentres to be the same but different from the molfile. "Mol/Inchi/ RDKit stereo mismatch" means that all three methods perceive different stereocentre counts. The majority of these issues occur in complex molecules such as bridged bicyclic molecules that are badly drawn. As Standard InChI is derived from the molfile, the errors where the molfile and InChI differ in their stereocentre counts are given a higher penalty score  [5]  than when they are the same but different from the RDKit stereo count  [2]. The InChI software may give a number of warnings. These are also reported by the ChEMBL Checker module. Some of these are considered important, but others such as "InChI: Omitted undefined stereo", "InChI: Charges were rearranged", "InChI: Ambiguous stereo", "InChI: Proton(s) added/removed" and "InChI: Not chiral" are generated for large numbers of molecules.
Standardizer component The standardisation rules implemented in the ChEMBL database are based largely on the FDA/IUPAC guidelines  [31, 32]. Whilst the aim is to adhere to these rules as closely as possible, the practical reality is that submitted compounds are sometimes drawn imperfectly or the structures are ambiguously defined in the original publication or by the depositor. An automated standardiser can only safely correct some of the potential issues and the standardisation rules, currently encoded in the Standardizer component, are outlined here. For certain compound types, particularly organometallic and those with a large number of boron atoms, a flag is set (exclude flag) and no attempt is made to standardise them. This is largely due to the V2000 molfile format used by ChEMBL being unable to accurately represent coordination bonds.
For this reason, although the bioactivity data on these compounds is available in ChEMBL, the chemical structures are not curated nor provided in the release version of the database. The first step in the standardisation process is therefore to exclude molecules if they contain more than 7 boron atoms or any of the following atoms: [Sc], [Ti], [V], [Cr], [Mn], [Fe], [Co], [Ni], [Cu], [Ga], [Y], [Zr], [Nb], [Mo], [Tc], [Ru], [Rh], [Pd], [Cd], [In], [Sn], [La], [Hf ], [Ta], [W], [Re], [Os], [Ir], [Pt], [Au], [Hg], [Tl], [Pb], [Bi], [Po], [Ac], [Ce], [Pr], [Nd], [Pm], [Sm], [Eu], [Gd], [Tb], [Dy], [Ho], [Er], [Tm], [Yb], [Lu], [Th], [Pa], [U], [Np], [Pu], [Am], [Cm], [Bk], [Cf ], [Es], [Fm], [Md], [No], [Lr], [Ge], [Sb]. The following standardisations are then made to the molecule (where they occur):   Note that if the Hs could be added to more than one atom an arbitrary choice is made but this is done canonically so the result will always be the same for a given molecule.
GetParent component Many compound registration systems, including the ChEMBL database, identify compounds that are related by virtue of being a salt form of a common parent structure. Therefore, as part of the ChEMBL compound curation pipeline, molecules are identified where the molfile contains more than one connected component as well as molecules containing atoms with specified isotopes. The GetParent module is applied to just those compounds that match one or both of these criteria. All information about isotopes is removed, as are solvents and salts present in the molfile which match any of the components in the defined salt and solvent lists. Having removed all salts (e. g. Na+ that might be included to neutralise a carboxyl group), the resulting molecule is neutralised and a new molfile created as the "parent" molecule.
Compounds containing more than one component that are genuine mixtures (i. e. , all of the components are absent from the salt and solvent lists) has, in the context of the ChEMBL database, its parent registered as the identical mixture. For cases such as sodium chloride and sodium citrate, where both components are in the salt list, the GetParent module does not remove any component and the parent remains the same as the salt. Here again, the parent is registered as the multicomponent mixture. Compounds containing any of the excluded atoms described above have their isotopes and solvents removed and then parents created, so that bioactivity data can subsequently be aggregated. For example, the antimonycontaining compound sodium stibogluconate has two versions in ChEMBL 26, both with bioactivity data: CHEMBL3754364 is a version with water of crystallisation and CHEMBL3764926 is a version without.