dataesr/scientific-paragraphs-categorization huggingface dataset:
An exception is the LC-ESI-QTOF dataset where it seems the performance after training with 60% of the data could not be improved much. For the LC-ESI-ITFT-HCD, the cross validation testing error approaches zero rapidly. The APCI-ITFT dataset, which is the combination of the APCI-ITFT-CID and the APCI-ITFT-HCD, shows that the merging produces slightly better performance than simply using the APCI-ITFT-CID data but slightly worse result then just using the APCI-ITFT-HCD data. In summary, most of the datasets seem to be large enough to give good average prediction quality for fingerprints. In addition, the metabolite identification performance is seen to correlate with the fingerprint prediction error in a clear way. However, the datasets are too small to represent the whole metabolite space in balanced manner.
Quality of Exact Mass Prediction To understand how accurate the approach of deriving the exact mass from the spectra of the unknown molecules, the difference (measured in ppm) between the exact mass and the predicted exact mass for our training datasets was compared, as shown in Figure  5. Figure  5  shows in most cases, the difference between the predicted and the real exact mass of the molecule is less than 10 ppm, which indicates the suitable mass window width. For the CASMI contest, the mass window width was set to range from 200 ppm to 500 ppm even though in hindsight our data would have supported a much narrower search window. In the APCI-ITFT-CID, APCI-ITFT-HCD and LC-ESI-QTOF-CID datasets, there are some outliers where the exact mass prediction is off by huge amount (1000s of ppms), which need to be investigated in the future.
Effect of Using Multiple Collision Energies As observed from Table  1 , many spectra of the same molecule exist in the training dataset. This is a result of different collision energies used in the measurement, which leads to different fragmentations of the precursor ions. To test if mixing the different collision energies in training data has a positive or negative effect on fingerprint prediction, one fifth of the molecules measured in collision 30 eV in the QqQ dataset were taken as fixed testing data and the rest of the dataset was used for training in two setups: training with 30 eV only and training with all collision energies. The result is shown in a scatter plot in Figure  6. In this experiment, only fingerprints for which the majority class accounts for at most 80% of the data were considered, as achieving high predictive accuracy for those is more challenging than the more biased fingerprints.
Degree of Uniqueness of Fingerprints Molecular fingerprints describe the selected properties of a molecule in the form of a bit vector. In FingerID, the molecular fingerprint is an intermediate representation for identifying candidate molecules. As the ranking of the candidates is based on the fingerprint vector and the mass of the molecule, fingerprint vectors that are shared by large number of molecules cause the candidate lists to grow in size, which is not desirable. In this experiment, for each different fingerprint configuration in KEGG and PubChem, respectively, the duplicates in the database were counted and denoted as N dp. We show the cumulative distribution of N dp (in log scale) in Figure  7. Fingerprints with N dp = 1 are unique in the database. In the versions of KEGG and PubChem databases used, we have 9,399 and 18,043,141 different fingerprint configurations, respectively.
In KEGG (resp. PubChem), among them, 7,454 (resp. 12,829,187) fingerprint configurations are unique, and 1,114 (resp. 3,282,098) fingerprint configurations have one duplicate molecule. The highest number of duplicates in KEGG is 86 and 2,501 in PubChem. In terms of molecules, only 64% of the molecules in KEGG and 43% in PubChem have unique fingerprints. Figure  6. Fingerprint prediction accuracy on QqQ data with single collision energy data versus mixed collision energy data. The x-axis shows the accuracies of training model only using collision energy 30 eV and the y-axis shows the accuracies of training model using all available collision energies. q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q Prediction accuracies comparison.
MS1 data was used for LC-ESI-ITFT and LC-ESI-QTOF datasets as shown in the last two rows of Table  1. Compared with MS2 data, only a few molecules have the MS1 data in the database. FingerID was trained with the MS2 data and the MS1 data was used for isotopic distribution matching. Then the combining method mentioned above was applied to merge two ranked list. Figure  8  shows that FingerID alone achieves top 1 rank for the largest fraction of the data for both datasets. It is also shared best with average rank aggregation on the whole of QTOF data. On ITFT data, FingerID alone is the best until top 5 rank but fades beyond the competing methods in ranking the tail of the data. Reranking with FingerID the candidates with matching isotopic distributions is a better approach than minimum rank.
Using PubChem as the Molecular Database In the CASMI contest, KEGG was used as the underlying database to search candidates. As many of the challenge molecules were not recorded in KEGG, the method failed to identify those molecules correctly. After the challenge deadline, PubChem  [15]  was investigated as the alternative source of candidate molecules. As PubChem contains more than 30 million compounds, several orders of magnitude larger than KEGG, the recall of molecules is improved. At the same time, however, the number of candidates within a mass window increases, making it harder to rank the correct molecules towards the top. Table  3  shows the result for Category 2 when using PubChem as the underlying molecular database. The top three rows show the results obtained when searching PubChem using the same mass window width as was used in the CASMI challenges.
Conclusions The prediction of molecular fingerprints from tandem MS/MS using machine learning methods tackles the molecule identification problem in a brand new way. In this approach, observed MS/MS spectra are not directly compared with an MS spectral database or simulated MS/MS spectra. Instead, molecular fingerprints are predicted and then used to search a molecular database of choice. The CASMI contest results show this machine learning approach is competitive with other current methods. This approach is modular in that the support vector machine used in this paper could be changed to any other machine learning approach. The set of fingerprints generated by OpenBabel can be replaced by others such as PubChem fingerprints. Finally, the molecular database used to retrieve candidate molecules can be changed flexibly.
The presented approach still requires further development. The first issue is that the prediction is highly dependent on the selection of the training dataset. Using merely a few hundred molecules as training data cannot represent the whole relevant chemical space. Hence, some testing molecules that are beyond the learned model domain may be encountered. However, as the results so far suggest, relatively good performance can already be achieved with moderate training sets of a few hundred molecules. Thus, extending the approach to new regions of metabolite space via generating spectral training data for the sparsely populated regions should not prove an insurmountable challenge. The molecular fingerprint prediction also incurs the necessity for studying the properties and structures of the molecular fingerprints.
Choosing the molecular database for candidate retrieval is the final crucial component. A small database will produce shorter candidate lists but with high chance the correct molecule is not in the list, unless the molecules to be identified match the database very well. A much larger database such as PubChem includes the correct molecule in many cases but may produce a prohibitively large candidate lists. Using a small enough mass window can alleviate this problem to significant degree. There are several further directions for improving the metabolite identification framework. First, FingerID does not use information of plausible fragmentation trees, which are effectively used in several competing systems. Second, using domain specific information about the kinds of molecules that are more plausible than others could improve the framework.
In addition, approach number 7 does not allow modification of the system architecture; it is not intended for reconfigurable systems. Approach number 8 is not intended for real-time systems. In  [24] , Ullmann et al. present an adaptation approach based on QoS function allocation. This approach uses a reconfigurable architecture. The proposed work consists in using application and HW layer connected with function allocation management. This layer allows answering the QoS constraints by using HW architecture based on VHDL accelerators. It consists in comparing the similarity of each state with an existing one saved on a case base. The comparison between solutions relies on the Manhattan distance. The proposed SW modelling is developed via MATLAB and the HW accelerators are designed with VHDLgen.
Overview. The proposed adaptation technique is integrated within a framework, which coordinates the adaptation in the three layers. Figure  2  presents an overview of this framework. It is composed of a global manager, a local manager, a task adapter for each task, an OS adaptor, an architecture adapter, a battery monitor, and a configurations database. The global manager coordinates the three layers based on En av and the user preferences (QoS constraint and Lt). It tracks energy evolution using periodic energy measurement with a Pobs period. The local manager coordinates between the application layer and the OS in order to respect the real-time constraint. The task adaptor is in charge of A i k,Im mode change (using parameters, adjustments, or task algorithm choices). The OS adaptor is in charge of CPU budget reallocation due to mode modification, the addition of a new application, or data variations.
Configuration Database Setup. We use QUARTUS software (version 9. 0) as a development environment for the HW design and Nios II 9. 0 IDE for SW implementation. This environment includes also the real-time operating system (RTOS) MicroC OS-II. This development tool allows us to build a set of heterogeneous configurations around the Nios processor. This CPU has a modifiable architecture and can be enhanced with specialized computing units as internal coprocessors or HW accelerators via the Nios Avalon extension bus. Contrary to Xilinx, Altera FPGA does not allow for dynamic reconfiguration. We cannot change the hardware architecture of the system during the system operation by a dynamic reconfiguration involving a complete modification of the architecture. All HW configurations must be embedded on the FPGA (dynamic reconfiguration emulation).
Design and Interfacing of 3D Accelerators. This section presents the design and the interface of 3D HW accelerators on the Altera Stratix development board. It allows for the design of a heterogeneous architecture based system using the Nios II processor and the Avalon bus as shown in Figure  8. We have designed a system composed of a Nios II processor that communicates with HW accelerators through the Avalon bus. The accelerator processes the data while the Avalon bus supports the control and runs the data trade-off between HW blocks and memories. Once HW accelerators are fully tested, we have modified the original  code so that HW and SW version can be supported and controlled with configuration variables.
These coprocessors are directly added in the UAL of the Nios processor. They can only manipulate two input data; (iv) flat: flat shading algorithm; (v) Gouraud: Gouraud shading algorithm; (vi) Acc normal: architecture contains an accelerator, which calculates the normal vector; the accelerator communicates with the Nios processor using the  Avalon bus. It can manage more input data compared to coprocessors. Power Measurements. Pow idl is measured according to the following steps. First, only the IDLE task is executed on the architecture uniquely composed of the main processor without any HW accelerator (SW configuration). Secondly, we use a mixed SW/HW configuration and execute the IDLE task to quantify the impact of added accelerators. Pow conf is equal to the difference between measured value and the consumption of the SW configuration.
Finally, the entire application writing taking account of the used architecture is executed on the configuration to measure the impact of this application on the overall consumption of the system. This value is equal to the difference between measured values and the consumption of the IDLE task on the same architecture. Table  5  reports the measures of consumption for a configuration. The table is updated for each configuration. The measurement of power is possible online using the Stratix III board, that is, without any specific measuring instruments. We use the following definitions. (i) {CPU + MEM}: this is the "standard" (Altera-specific appellation) hardware design which permits executing the software application without any specific hardware unit. It is composed of the Nios processor and its associated memory.
Background: Should an emerging infectious disease outbreak or an environmental disaster occur, the collection of epidemiological data must start as soon as possible after the event's onset. Questionnaires are usually built de novo for each event, resulting in substantially delayed epidemiological responses that are detrimental to the understanding and control of the event considered. Moreover, the public health and/or academic institution databases constructed with responses to different questionnaires are usually difficult to merge, impairing necessary collaborations. We aimed to show that e-commerce concepts and software tools can be readily adapted to enable rapid collection of data after an infectious disease outbreak or environmental disaster. Here, the 'customers' are the epidemiologists, who fill their shopping 'baskets' with standardised questions.
Methods: For each epidemiological field, a catalogue of questions is constituted by identifying the relevant variables based on a review of the published literature on similar circumstances. Each question is tagged with information on its source papers. Epidemiologists can then tailor their own questionnaires by choosing appropriate questions from this catalogue. The software immediately provides them with ready-to-use forms and online questionnaires. All databases constituted by the different EpiBasket users are interoperable, because the corresponding questionnaires are derived from the same corpus of questions. Results: A proof-of-concept prototype was developed for Knowledge, Attitudes and Practice (KAP) surveys, which is one of the fields of the epidemiological investigation frequently explored during, or after, an outbreak or environmental disaster.
Moreover, any important public health problem inherently involves a variety of actors in public health and research. All these players have their own agendas, hypotheses to test, stakeholders to comply with. Each of them designs a different survey, with different questionnaires  (4). Finally, as a consequence, the information collected in the different surveys usually cannot be merged to provide a unified database, because the definitions and questionnaires used are not standardised  (5, 6). The best solution to overcome the above-outlined difficulties would be that a respected international or national agency, or a scientific society, provides THE questionnaire that everybody would agree to use in the case of an epidemiological disaster. That 'top-down' best solution approach is obviously unrealistic.
He can choose his desired elements from each of these categories, put them in a shopping basket, and review and modify his choices before making his final decision. Then, he checks out and his system can be delivered in hours. The success of e-commerce led to the development of powerful software, some of it free, that we used in this project. We show herein that this e-commerce model and its software can be readily adapted to epidemiology. In the proposed EpiBasket concept, epidemiologists are the 'customers'. The 'categories of products' are the categories of questionnaire questions (e. g. , the questions on the outcome of the household, life satisfaction, prevalidated scales for scoring stress). Information on which questions were used in the best high-profile papers published on similar events, information on all 'products' (i.
e. , questionnaire questions), will be available immediately. The epidemiologist devising his questionnaire will therefore be able to select from the 'catalogue' the best possible questions to meet his needs, put them in his 'shopping basket' and, once he has made up his mind, he 'buys' them and immediately gets his order, here the paper and/or the online version of the questionnaire. If the catalogue provides the best products on the 'epidemiological market', and if a community of researchers starts to collectively build and use this system, a positive byproduct should be the increased possibility of database interoperability because, in the future, epidemiologists working on the same subject will choose the questions for their questionnaires from the same catalogue. In this article, we describe the general outline of the 'EpiBasket' concept in three sections: the construction of the catalogue of questions by the developer, the user's point of view and the software that was used.
To facilitate the extraction of those variables, we supposed that they were mentioned in the tables and figures of the papers analysed in the systematic review. The manual extraction of those variables that we performed to build the prototype could subsequently be automated, with natural languageanalysis tools (8) 'reading' the tables, figures and their corresponding legends. A relational database comprising all extracted variables was constituted. It allows tracking of the context of the variable, for example, to immediately find the sets of variables that are usually used together. In a perfect world, the questionnaires used in each reviewed study would be made available to readers. In the real world, very few authors provide their questionnaires, hence the 'question' had to be inferred from the 'variable'.
Therefore, the second stage was to deduce the 'question' from the 'variable' identified in the previous step. For example, the questionnaire may have asked the date of birth, while the paper may report the corresponding results in a table showing age-class frequencies. In addition, EpiBasket can propose a recommendation for a preferred coding, with the aim of maximising the chances of interoperability among databases constituted with EpiBasket-derived questionnaires and their responses. Third, the formulation of questions was generalised, when possible, to make them reusable in broader situations than those in the source papers. It was accomplished by replacing words or patterns found in the reviewed papers by 'root terms' that the user would replace with the specific term that fits the event of interest.
g. , age, sex) get a high value (because they are used in all papers, including those published in journals with very high IF). IF can be systematically obtained from the Journal Citation Reports database, for which a fee must be paid. However, most journals provide their IF on their websites and we used those values in the prototype (see the Supplementary file). The value of 0. 000 was arbitrarily assigned to questions published in journals not indexed in the Journal Citation Reports database. Researchers not wanting to take these IF into account can just ignore the 'values' indicated when they build their questionnaire.
Results Composing a questionnaire is viewed, from the user's point of view, as 'shopping for' questions, that is, filling a 'basket' with the questions he wants to eventually have in the questionnaire. However, while the order in which the items composing the shopping basket were added does not matter in a usual consumer's purchase, here the questions composing a questionnaire must be appropriately ordered. The EpiBasket software helps the user draft a questionnaire and to exchange his draft (that we called a 'wish list') with his collaborators until he decides to obtain a ready-to-use paper questionnaire, for a paperand-pencil survey and/or an electronic file for an online survey. In addition, EpiBasket includes several tools enabling userÁuser and userÁEditorial Committee exchanges to promote collaborative epidemiology.
Five questions are proposed in this subcategory (middle of the window). If the user is also interested in the related question dealing with 'past flight history', clicking on question 4 will open a window giving the reference to the paper with the highest impact factor (IF) in the database that posed that question, and the exact question formulation used in that paper. clicks. Because questions are labelled with keywords and linked to papers in which they were initially mentioned, suggested associations of potential appropriate questions can be easily accessed.
Appropriate parsing of an EpiBasket XML output file greatly facilitates further importation of the questions (including the proposed answers) constituting the generated questionnaire in any popular relational database-management system. The pdf format is available for epidemiologists wanting to conduct a paper-and-pencil survey. The csv format is proposed to those planning an online survey: users can directly import their csv file and initiate the corresponding survey online in EpiBasket (http://www. epibasket. org/limesurvey/admin/index. html). The user can also install on his own server LimeSurvey (9), freeware designed for building and deploying online surveys, and run the survey on this server. The electronic questionnaire imported in LimeSurvey may be modified by the user, if desired.
Software For the present proof-of-concept demonstration of EpiBasket, we used free open-source code. The main components of the EpiBasket-prototype development are described below. The EpiBasket application was built in the Eclipse 3. 6 software-development environment  (10) , using PHP5 language. Development was based on the importation and adaptation/customisation of the freeware part of PrestaShop  (11) , an open-source PHP5-based developed application devoted to the building of online e-commerce sites. PrestaShop, a full-featured cross-platform shopping basket package, was written in PHP5 with an underlying MySQL relational database-management system. PrestaShop can be deployed in the server-side supporting PHP5 and can be customised through the inclusion of modules proposed at the PrestaShop site (free or not, many supplemental module blocks were developed and are available for enhancing PrestaShop functions), or through a developer's initial code modification (i.
e. , code suppression/correction/addition). The main adaptation/customisation features for developing EpiBasket were the following. An initial group of modifications was made to cope with the epidemiological specificity of EpiBasket: the catalogue's offered 'ecommerce products' are 'epidemiological questions'. All 'orders' and 'invoices' are replaced by 'questionnaires'. Moreover, user account-information features used in ecommerce, such as ('my credit slips', 'my vouchers', 'my personal info', and so on) required substantial modifications/suppressions/additions. For example, in EpiBasket, the 'orders' attached to a given user are 'my questionnaires', that is, those ordered since his initial registration in the EpiBasket site. We also developed a specific source code to allow a user account to propose the implementation of a new question in the EpiBasket catalogue.