dataesr/scientific-paragraphs-categorization huggingface dataset:
Vive sin Tabaco. ¡Decídete! Tablet-Based Software The tablet-based, decision support tool was designed to help smokers create a personalized smoking cessation plan and to collect data that tailored the text messages delivered over the ensuing 12 weeks  [34]. This tool was adapted from 2 smoking cessation Web-based, informed decision-making tools for Latinos in the United States  [35]  and Mexico  [36, 37]. This tablet-based tool consisted of interactive features that lead smokers through various steps in the quitting process. The program included testimonies from ex-smokers and features short video clips (0:21-2:03 min) and narrated graphics on the benefits of quitting while also describing how cessation pharmacotherapy (nicotine replacement therapy [NRT]) can support abstinence. The program also collected basic information about the participants' smoking history, including the number of days they smoke each week and the number of cigarettes smoked per day.
Acknowledgments This study was funded by the  National Institutes of Health   3P30CA168524-04S1. Vive sin Tabaco. ¡Decídete!would not have been possible without the help from the multidisciplinary and multinational teams involved. The authors acknowledge the research teams from (1) The  University of Kansas Medical Center, Kansas, US  ( Jaime Perales, PhD ;  Kendra Cruz , MPH; and  Mitzi Ramírez , BS); (2) The  National Institute of Public Health, Cuernavaca, Mexico (Anabel Rojas-Carmona , MPH;  Moisés Ortíz-Vargas ;  María Guadalupe Flores-Escartín ;  Aurelio Cruz, MD, PhD ;  Janet Pacheco, MD, MPH ;  Steyce Aguilar , RN; and  Rosalba García , RN); and (3) The  National Autonomous University of Mexico, Mexico City, Mexico  ( Guadalupe Ponciano-Rodríguez, PhD ). The authors also acknowledge the software development teams from (1 ) Viva la Gráfica, Bogota, Colombia  ( Catalina Lineros  and  David Gómez-Bonilla ); (2) In Touch Productions,  Mexico City ,  Mexico  ( Marco Polo Ramírez-Bonilla  and  René Navarro ); (3) Assertia Solutions,  Bahia Blanca ,  Argentina  ( Ariel Trellini  and  Fabricio Ziliotto ); (4 ) Agile Health Inc, Chicago, US  ( Gary Slagle ,  Scott Werntz , and  Vova Kagan ); and (5) Auronix,  Mexico City, Mexico  ( Martha Cepeda ,  Isadora Hernández ,  Blanca Ortega ,  Alejandra Rivas , and  Carlos Piña ).
Results BioSCOOP has the form of a well documented JSON API which describes an organized data format for a list of attributes describing the donor with particular emphasis on the phenotype, anthropological measurements, medical data and sample material. The software application of this standard was created using Swagger Editor, a tool for API creation, to be compliant with Open API Specification. BioSCOOP has been deposed on Github, as YAML file and can be easily imported into Swagger Editor or any other text editor as a described JSON. Furthermore, an exemplary data set has also been prepared. It can be downloaded and used for test sample search using the proposed browser -Bioface. It was provided to guide users through sample search based on BioSCOOP standard. The list of features included in BioSCOOP is listed in Table  S1  (supplementary information).
Conclusions and future developments BioSCOOP was created as a communication protocol and aims to facilitate and improve the information transfer in a large network of biobanks. The members of the Polish Biobanking Network will be involved in first implementation of described protocol. On the basis of this, there are further goals such as gathering specialists in many fields of science in one workgroup to create the most accurate way for description data collected by biobanks and scientists. We discuss also future developments. The next step is implementation of BioSCOOP in the BIMS system, currently being created by the Polish Biobanking Network. BioSCOOP will also be used as a data import format in data processing IT software developed by the Polish Biobanking Network.
Acknowledgements We thank  Łukasz Pułaski  for a language correction and a thorough review of the manuscript. Funding: The work was supported by  Polish Ministry of Science and Higher Education  no. DIR/WK/2017/01 :" Biobank network in Poland , within the  BBMRI-ERIC Research Infrastructure of Biobanks and Biomolecular Resources " and by the  Polish POPC  Grant  02. 03. 01-00-0012/17-00  from the  European Regional Development Fund.
Also using logical operators to combine subsequent parts of query is posible. The above examples do not exhaust the possibility of creating queries in the used engine, which are described in more detail in the Apache Solr documentation (https://lucene. apache. org/solr/guide/). numeric_field_name:[lower_limit TO upper_limit]; e. g. bmi:[18 TO 23] 1. Test data set preparation -an exemplary data set was prepared using Microsoft Excel spreadsheet. It contains randomly generated information about 200 database records mimicking samples collected from 200 mock donors. The provided information includes: birth date, place of birth and residence, sex, ethnic origin, skin tone, hair and eye colour, blood group, parameters like WHR (waist hip ratio), BMI (body mass index), CI (Corpu- lence index), some of anthropological features, diseases and medical procedures undergone by the donor and form of sample material (Tab.
Introduction BI system users range from executives to data enthusiasts who share a common way of interaction, i. e. , they navigate large datasets by means of sequences of analytical queries elaborated through user-friendly interfaces. For example, users may express their information needs via keywords, and let the system infer from them the most likely formal queries (generally MDX or SQL) to be sent to the underlying data sources (generally data warehouses or databases). It usually takes many interactions with the system to satisfy an information need, and the overall session is often a tedious process, especially in the case when the information need is not even clear for the user. This bears resemblance with Web Search, where users typically need to repeatedly query the search engine to determine whether there is interesting content.
Related work Analyzing web search sessions for personalizing user experience has attracted much attention, varying in models for session, similarities and clustering algorithms  [10]. As the users information needs span multiple search sessions, state-of-the-art approaches attach importance to both intra and inter-session similarities. Various forms of user interests have been defined, such as contextual intent, task repetition or long term interests, and methods have been proposed to identify them. Sun et al. [11]  are interested in contextual intent. Contextual intent attaches importance to context with a particular emphasis on the external physical environment, and complex context-intent relationships are modeled. Consequently, intent tracking is done in real-time. In our work, we are not interested in modeling the context, nor real-time tracking, but in modeling the user's interest in certain data to answer a particular business question, which is generally context-independent.
While many recent works propose techniques to assist query formulation for the purpose of interactive database exploration  [12] , few works address the issue of discovering user interests based on past queries without asking for explicit feedback. Many approaches are more focused on extracting navigational behavior than user interests. The SnipSuggest approach  [13]  analyzes a log of past queries to extract correlations between SQL clauses, and use them to suggest SQL snippets for auto-completing SQL queries on the fly. In the DICE approach  [14] , the query log is used to prioritize speculative queries transparently sent for the purpose of pre-fetching. With the same pre-fetching motivation, the Promise approach  [7]  builds Markov models out of a query log to represent a user's behavior when querying a data cube.
Like in Promise, this model is used at runtime to find the most likely query to follow a given current query. Perhaps the closest to our interest detection approach is the work of Nguyen et al. [15]  dealing with discovering the most accessed areas of a relational database. Their notion of user interest relies on the set of tuples that are more frequently accessed, and is expressed as selection queries (mostly range queries). They use DBSCAN to cluster user interests. Their similarity metric relies on the Jaccard coefficient of the accessed tables and on overlapping of predicates. Being tailored for range queries, their metric is inappropriate for OLAP queries that are mostly dimensional (i. e. , point based), due to the nature of the hierarchical dimensions used to select data. In particular, consistent with the study by Aligon et al.
It is also well known that the application domain exerts a strong influence over the types of methods that can be successfully applied. Recent approaches value models of users or items that can be described in terms of, e. g. , semantic technologies, concepts and ontologies  [18, 19] , or using contextual information  [20]. Many recent proposals investigated the use of database query logs for query recommendation in the context of interactive database exploration. One of the most prominent proposals is the QueRIE approach  [6] , where collaborative filtering is used to recommend a set SQL queries. Interactions in QueRIE are sequences of SQL queries called sessions. QueRIE constructs a matrix with logged sessions, where all past queries and sessions are vectorized using the database tuples or the SQL fragments (selections, projections, etc.
). When a new session is created and a recommendation for it is sought, a KNN approach is used with classic Jaccard or Cosine similarities to find the queries closest to this session in the matrix. BI can be seen as a prototypical context of interactive database exploration. In OLAP systems, for instance, the typical interaction between the user and the system consists of a sequence of queries answering a business question. Studying such sequences can help in suggesting what the next query of the session could be. A survey of query recommendation approaches for BI is proposed in  [5] , showing that user interest is poorly considered in state-of-the-art approaches. In  [5] , Aligon et al. propose a recommender system tailored for exploratory OLAP over a datacube, whose sessions can be seen as a particular type of BI interactions, where queries are regular dimensional queries  [21].
BI Questions, Suggestions and Queries Let D be a database schema, I an instance of D and Q the set of formal queries one can express over D. For simplicity, in this paper, we consider relational databases under star schemata, queried with multidimensional queries  [22]. Without lack of generality, we consider D to be a global schema resulting from the integration of several data sources. We simply note sources(q) the set of sources used by a query q over D. Let A be the set of attributes of the relations of D. Let M ⊂ A be a set of attributes defined on numerical domains called measures. Let H = {h 1 ,. , h n } be a finite set of hierarchies, each characterized by (1) a subset Lev(h i ) ⊂ A of attributes called levels and (2) a roll-up total order hi of Lev(h i ). Consistent with the literature on database theory  [23] , we denote by adom(I) the set of all constants appearing the instance I of D, i.
e. , the constants that are used to form the tuples of instance I. We call a database entity an element of the set A ∪ adom(I). The result (or answer) of a query q over a database instance I is denoted by q(I). Let T be a countably infinite set of keywords named tokens. A BI question (or question for short), K, is a set of tokens entered by a user. Note that tokens may contain stop words (e. g. "by" or "as") that have no equivalent in formal queries but that the BI system may use in formal queries generation. The reason for including such stop words in our model is that use of stop words may convey a certain user behavior or expertise with the system. Each token may be matched with the entities in A ∪ adom(I) to generate queries. To simplify, we describe a multidimensional query q in Q as a set of query parts, as in  [24].
Given two query parts p 1 and p 2 , F D(p 1 , p 2 ) denotes a functional dependency level(p 1 ) → level(p 2 ). Given two queries q 1 and q 2 , the Boolean expression OP (q 1 , q 2 ) indicates if they differ in at most one query part. This allows for the detection of OLAP operations when users navigate along hierarchies or change selection conditions. As keywords are entered, a BI system might on the fly suggest further tokens to complete the current ones, letting the user choose among them, as in web search engines. The underlying idea is that a suggestion completes the original BI question to obtain a well-formed query over a database. We formalize the notion of suggestions as follows. A suggestion S is a triple K, D, q where K is a BI question, D is a database schema and q is a query over D.
Running example Consider two user interests U 1 and U 2 , with U 1 containing a unique observation o 1 = K 1 , {S 11 }, S 11 of a unique interaction i 1 (described in Example 2), and U 2 containing two observations o 2 = K 2 , {S 21 , S 22 , S 23 }, S 21 and o 3 = K 3 , {S 31 , S 32 }, S 32 that are part of the interaction i 2 (described in Example 3). The observations are summarized in Table  2  by listing questions and suggestions (by means of their questions and query parts). For the sake of readability, Table  2  describes the suggestions only by means of their queries. Assume that all suggestions access the same database and the same underlying source Sales and that all users are beginners. {"Revenue", "Country=France", "Year=2007"} o 2 : K 2 "Revenue for France" S 21 : {"Revenue", "Country=France"} S 22 : {"Revenue", "Market Unit=France"} S 23 : {"Revenue Closed", "Country=France"} o 3 : K 3 "Revenue for France 2010" S 31 : {"Revenue", "Year", 'Country=France"} S 32 : {"Revenue", "Country=France", "Year=2010"} Table  2 : Summary of observations in the running example Table  3  presents the characteristics of both user interests.
Experimental protocol 6. 1. 1. Data set The data used for our experiments consist of navigation traces of 14 volunteers at SAP, covering a range of skills in data exploration, divided into two groups, namely, beginners and experts, based on their position in the company. To evaluate to what extent actual user interests were discovered by our method, we set 10 business needs (named Q 1 to Q 10 ), each corresponding to a specific user interest. Users were asked to analyze some of the 7 available data sources to answer each of the 10 business needs, using an SAP prototype that supports keyword-based BI queries 1. The business needs were grouped in different business cases, such as: "For each European country, detect which genres of films did not reach the expected sales" or "In which income group would you classify a candidate country with a GDP of $6 billion?".
To have several difficulty settings, we also built two reduced data sets named Reduced 1 and 2, each corresponding to 4 business needs and 4 distinct data sources, which in turn removes most of the potential overlap. Each of them contains 225 observations. Importantly, Reduced 1 and 2 are not related to the same business needs. When dealing with these data sets, only 4 well separated clusters are to be found, contrary to the Complete data set in which 10 clusters with overlap are expected.
G2 metric interpretation Several features were proposed to describe the differences between the observations. The first two groups presented in Table  4  are inspired by the features used in the Web while the last one is a new proposal to show specific differences related to the BI context. The succeeding experiments concluded that a particular group of features presented in Table  7 , named G2 in Section 6. 1. 3, principally composed of features related to business objects and formalized queries, in collaboration with PAM, identifies better the user interest. The BI tool used for these experiments assisted juniors to reach the information needed, despite their non-precise questions in natural language, by proposing well formalized query suggestions. The user intent is expressed by the keywords (Tokens (Feature 1)) and the suggestions (Feature 3) proposed, but the real difference between user observations is specified by the chosen suggestion (Feature 9) with the query parts composing it (Feature 7) and their matching tokens (Feature 8).
Handling unseen business needs In this experiment, we study how our method handles previously unseen business needs and how general the metric learned on the G2 features is. To this aim, we consider both Reduced data sets and use one to train the metric and the other to test with PAM clustering. Recall that reduced data sets cover different business needs, with no overlap among them. The results in Table  11  show that our metric is indeed general and can adapt to new business needs as there is no drop in performance between each of the generalization tests. Moreover, the results are comparable to those observed in previous tests, as reported in Table  12. Finally, it can be seen that testing on Reduced 2 leads to better results than with Reduced 1. This is expected, as Reduced 2 contains observations related to business need Q9, which has more relevant queries than Q10 contained in the Reduced 1 data set (see Table  5 ).
Comparative experiments Table  12  shows how our metric compares to a reference metric that Aligon et al. [9]  designed for OLAP queries. This metric has been validated by user tests that showed its effectiveness in grouping queries in accordance with what a human expert would have done. Table  12  reveals 2 distinct behaviors depending on whether we consider the Complete data set or the Reduced 1 (where clusters are well separated). With the Complete data set, our metric with G2 features performs better than the other metrics, as it only relies on the most discriminating features. Indeed, we know from the protocol that the groups of observations heavily overlap. Thus, our metric, based on SVM, cannot find a proper linear separation between observations related to different user interests.
For the Complete data set, this is observed for G2 features that reach the best overall clustering results. In the case of ALL features, queryParts is slightly below, which may explain the small difference in performance with G2 features. Adding the similarity proposed by Aligon et al. [9]  to G2 or ALL decreases the weights of queryParts or tokenQPart, which in turn degrades the results. These observations are coherent with what is observed for the Reduced 1 data set. In this case, adding the similarity proposed by Aligon et al. [9]  to G2 only slightly lowers the score on tokenQPart and queryPart, which again may explain the small difference observed. Finally, with ALL features, it can be seen that adding the similarity proposed by Aligon et al. [9]  causes a drop in the previous important features, but that is compensated by the emergency of new features, such as the OLAP operation.
Comparison with state-of-the-art recommendation algorithms In order to illustrate the added value of user interest detection, as well as to show that our approach is agnostic of the query language used, we compare it with two state-of-the-art, session-based recommendation algorithms, both based on collaborative filtering and kNN. These approaches are i) an OLAP session recommendation approach  [5, 35] , referred to as Falseto in what follows, and ii) a SQL query recommendation approach, QueRIE  [6]. Precisely: 1. QueRIE. We use the fragment-based, non-binary version of QueRIE, which handles queries (both in the log and in the current session) represented by their SQL fragments, i. e. , projected attributes (levels and measures), selections, and group-by expressions, that are easily extracted from the query-parts.
This representation of user sessions based on query fragments is called the signature. The recommended queries are selected from the closest session to the current one based on their respective signatures. As the number of queries to recommend is a parameter in QueRIE, we tuned it and selected the value of the parameter that achieved the best accuracy, precisely 2 queries. Finally, the set of recommended queries is ranked using the similarity to the current session and arranged in a sequence as was done for IbR1. Note that this transformation of QueRIE output is necessary to ensure that it is comparable to the other recommenders and is under the same conditions. 2. Falseto. In order to use Falseto, an OLAP schema (a constellation) was reverse engineered from data sources (schemata and constraints) following DFM methodology  [21] , pruning attributes not accessed by users (based on the query log).
One key finding from a population structure analysis of this dataset showed that the 3,000 accessions can be subdivided into nine subpopulations, where most accessions from close sub-groups could be associated to geographic origin  (Wang et al. 2018). One critical piece of information missing from these analyses is the fact that single nucleotide polymorphisms (SNPs) and structural variations (SVs) present in subpopulation specific genomic regions have yet to be detected because the 3K-RG data set was only aligned to a single reference genome. Therefore, the next logical step, to capture and understand genetic variation pan-subpopulation-wide is to map the 3K-RG dataset to high-quality reference genomes that represent each of the subpopulations of cultivated Asian rice. At present, only a handful high-quality rice genomes for cultivated rice are publicly available  (Kawahara et al.
2013 , Zhang et al. 2016a , Zhang et al. 2016b and Stein et al. 2018) , thus, there is an immediate need for such a comprehensive resource to be created, which is the subject of this Data Descriptor. author/funder. All rights reserved. No reuse allowed without permission. The copyright holder for this preprint (which was not peer-reviewed) is the. https://doi. org/10. 1101/2019. 12. 29. 888347 doi: bioRxiv preprint Here we present a reanalysis of the population structure analysis discussed above  (Wang et al. 2018)  and show that the 3K-RG dataset can be further subdivided into a total of 15 subpopulations. We then present the generation of 12 new and near-gap-free highquality PacBio long-read reference genomes from representative accessions of the 12 subpopulations of cultivated rice for which no high-quality reference genomes exist.
Population structure We extracted 30 subsets of 100,000 randomly chosen SNPs out of the 3K-RG Core SNP set v4 (996,009 SNPs, available at https://snp-seek. irri. org/_download. zul). For each subset, we ran ADMIXTURE  (Alexander et al. 2009 ) with the number of ancestral groups K ranging from 5 to 15. We then aligned the resulting Q matrices using CLUMPP software  (Jakobsson and Rosenberg 2007). Since different runs at a given value of K often give rise to different refinements (splits) of the lower level grouping, we first clustered the runs for each K according to similarity of Q matrices using hierarchical clustering, thus obtaining several clusters of runs for each K. We discarded one-element clusters (outlier runs), and averaged the Q matrices within each remaining cluster. Figure  S1  shows the admixture proportions taken from the averaged Q matrices of the final author/funder.
All rights reserved. No reuse allowed without permission. The copyright holder for this preprint (which was not peer-reviewed) is the. https://doi. org/10. 1101/2019. 12. 29. 888347 doi: bioRxiv preprint end sequenced using an Illumina X-ten platform. Low-quality bases and paired reads with Illumina adaptor sequences were removed using Trimmomatic  (Bolger et al. 2014). Quality control for each library data set was carried out with FastQC  (Brown et al. 2017). Finally, between 36. 52-Gb and 51. 05-Gb of clean data from each accession was generated and used for genome size estimation (Table  S1 ) by Kmer analysis (Figure  S3 ) and the Genome Characteristics Estimation (GCE) program  (Liu et al. 2013).