dataesr/scientific-paragraphs-categorization huggingface dataset:
Introduction The SPARQL query language offers a powerful way to extract and compute information from RDF datasets. For the most common form of queries, SELECT queries, the results are structured and displayed as a table. Each column corresponds to a projected variable in the SELECT clause, and each row corresponds to a query answer, i. e. a mapping from those variables to RDF terms. Such tables have many advantages. They are universally understood. They can be read in two directions, by row or by column. They make a good use of the screen space, compared for instance to graph visualizations, and can therefore display a lot of information at once. They can be dynamically filtered and ordered according to each column. It is no surprise that they are found in all display and visualization frameworks, from HTML to D3js.
Despite all those advantages, tables in general and SPARQL results in particular have drawbacks due to the fact that they are in first normal form (1NF). 1NF is a notion from relational databases  [1]  that states that table cells only contain atomic values, RDF terms in the case of SPARQL results. It sounds like a reasonable constraint but it has negative consequences on the readability of query results. Imagine that a user wants to retrieve in a touristic dataset all hotels with rating 4 or more in Roma. She also wants to know for each hotel the available services and their cost, as well as reviews on that hotel. Because of the structure of SPARQL results, there will be a row for each combination of a hotel, an available service at that hotel, and a review on that hotel. If on average there are 10 services and 10 reviews per hotel, there will be on average 100 rows per hotel in the table of results, each repeating the same hotel name.
The automated nesting procedure is decomposed into two algorithms. The first algorithm analyzes a SPARQL query to identify a nested schema describing the structure of the nested table to be produced. The second algorithm converts a standard table of results into a nested table, given the nested schema produced by the first algorithm. Together, those algorithms allow for the computation of nested tables with existing query engines, and without any additional requirement from users. Automated nesting has been implemented in Sparklis 2   [2] , a guided query builder that completely hides SPARQL queries behind a natural language interface. This improves further the usability of Sparklis by offering a more natural presentation of results. However, the nesting procedure can also be implemented on any SPARQL querying interface as it only depends on the query and its flat results.
Related Work Nested tables were proposed and formalized in relational databases, where nesting is not only used for query results but also for data tables  [3, 4]. The motivation was to relax the first normal form (1NF) that states that only atomic values are allowed in table cells. The authors extend relational algebra with two operators: nest and unnest. To nest a table is to group a subset of columns into one higher-order column, whose values become nested tables. It is a form of aggregation, and it generally produces a table with fewer rows. To unnest a table is to explode a higher-order column into the set of columns it is made of. It is the inverse of the nest operation, and it generally produces a table with more rows. The authors also introduce a Partitioned Normal Form (PNF) that ensures that every nesting has an inverse unnesting by excluding some form of redundancy.
Querying nested relational databases involves the application of the usual operations of relational algebra  [1]  on nested tables, plus nesting and unnesting operations. Linked Data Query Wizard  [5]  is a tabular interface for the semantic web, where tables have a single row per subject, and possibly several values in cells. However, those tables are limited to the presentation of the direct neighborhood of entities (columns are entity properties, and column values are the objects of those properties) rather than results of arbitrary queries. Table cells can contain sets of values but not multi-column tables like in nested relational databases and what we propose in this paper. A lot of work have proposed various forms of visualization of SPARQL results in order to help their understanding  [6, 7, 8, 9].
Those visualizations generally include maps, charts, timelines, etc. They are definetely useful, especially for numerical data. However we think that they are a complement to a tabular view, and that they cannot fully replace it in the general case. A more general approach consists in supporting the transformation of SPARQL results into a broad set of data structures, e. g. using JSON as output  [10] , where nested tables are one possible output. However, this approach targets web developers, and does not fit end-users that can freely build their own queries, like with Sparklis  [2]. Some features of SPARQL allow to structure query results to some degree. CONSTRUCT queries produce RDF graphs from query answers, hence offering a lot of flexibility in the produced structure but the concrete layout of the graph is left unspecified.
Implementation and Application The automated procedure to lift a flat table into a nested table has been implemented in the Sparklis 45 querying tool  [2]. Sparklis is a SPARQL query builder that hides SPARQL behind a natural language interface, and guides the query construction so that the user does not need to know the schema of the RDF dataset. It works as follows. After each user interaction, the abstract representation of the query is updated, from which a new SPARQL query is derived. Then, the SPARQL query is sent to the SPARQL endpoint, which returns results as a set of mappings from variables to RDF terms. Originally, Sparklis displays those results as a flat table, only improving the display of RDF terms with labels and media contents. The new nesting procedure is applied to the generated SPARQL query and returned results, and feeds the final display process.
In a previous user study  [13] , it was observed that this made it difficult for pharmacovigilance experts to read and interpret the results. Figure  3  shows a screenshot of the first two rows of the nested table that describes patient cases who suffered adverse reactions to chloroquine. It can be observed that there is a single row per patient, and that this row is well organized. For each patient, the table shows its case id, its age, and two nested tables. The first nested table describes the drug event, giving the dose amount, and optionally the dose frequency. The second nested table gives the list of adverse reactions of the patient. The icons on the left of adverse reactions are taken from an iconic language for the graphical representation of medical concepts  [14]. The anonymised patient data are a three-months sample from the FAERS database  [15].
Although the QA process was designed to be automated, we still manually enforced hundreds of the initial outputs, many of which had returned feature names in native languages, to pass the baseline filters. As a result, our QA process yielded more than 16 000 geocoded WRD records, each with the optimal spatial coordinates and the corresponding QA rank. To complement the QA process, we then conducted a rigorous QC to correct and/or remove the remaining geocoding errors. We considered a geocoding error to be a location where (a) no dam or reservoir could be visibly verified from Google Earth or Esri images, or (b) the WRD attribute information is inconsistent with the feature or division labels on Google Maps. In such cases, we usually first attempted to re-geocode the dam manually (such as by directly using the Google Maps interface) before deleting this error.
While this may be true for most cases, we identified at least 88 dams in GRanD with possible location errors. With the help of several references such as regional registers (Table  2 ), the recently published Dataset of Georeferenced Dams in South America (DDSA)  (Paredes-Beltran et al. , 2021) , Google Maps, and other literature and openaccess documents, we were able to correct the locations of 76 of these dams and absorbed the corrected coordinates to the harmonization. The other 12 GRanD dams, including 3 duplicates with other dams and 9 we were unable to correct the locations for, were excluded from the harmonization. What was also excluded are another five dams in GranD that were subsumed or replaced by newer dams. For user convenience, we released these ∼ 90 GranD dams together with the identified issues and suggested coordinates (if possible) in Table  S5  in the Supplement (full spreadsheet available at https://doi.
org/10. 5281/zenodo. 6163413; Wang et al. , 2022). Using the adjusted GRanD data (7303 points), the harmonization (Fig. 5 ) aimed at (a) improving spatial coordinates of the dam points in GeoDAR v1. 0, (b) adding WRD dams that are not georeferenced in GeoDAR v1. 0 but are included by GRanD, (c) reducing storage capacity errors in the georeferenced WRD, and (d) absorbing the remaining GRanD dams that are not documented in the WRD. Detailed processing for each of the objectives is given below. First, when a dam in GeoDAR v1. 0 also exists in GRanD, the spatial coordinates of the former were replaced by those of the latter. We implemented a two-step procedure to identify the overlapping dams between GeoDAR v1. 0 and GRanD. Step 1 was based on attribute association, while Step 2 utilized spatial query.
0. As part of the QC, the attribute values of each pair (one from GRanD and the other from the WRD) were manually compared to determine whether they are indeed the same dam. This step identified another 400 or so overlapping dams between the two datasets. In total, we found that Geo-DAR v1. 0 overlaps 5080 out of the 7303 dams in GRanD, and their spatial coordinates were updated to be consistent with those in GRanD. Second, for the remaining 2223 dams in GRanD that do not overlap GeoDAR v1. 0, we assumed that at least part of them could be matched to the WRD records not georeferenced in GeoDAR v1. 0. Therefore, we performed another round of attribute association between the remaining subsets of GRanD and the WRD. After QC, this process identified another 1414 WRD dams that are included by GRanD.
Thus, to avoid over-filtering, we allowed a certain ambiguity in the geocoded feature types and then relied on manual QC to correct or remove mistaken coordinates as thoroughly as possible. The misplacement of dams to their upstream and downstream river reaches is a major cause of the relatively low geocoding accuracy in Japan. Through experimentations, we noticed that Google Maps labeling for some of the Japanese dams that are homonymous to their impounded rivers were either lacking or more adapted to the Japanese language. The latter further challenged our geocod-ing accuracy using English-based ICOLD information. For one of the errors in Japan, we verified from the JDF register that Google Maps mislabeled Myojin Dam in Horoshima Prefecture (34. 587 • N, 132. 505 • E) as "Nabara Dam", whose correct location is 3 km downstream (34.
Summary and applications We have produced a comprehensive and spatially resolved dam and reservoir dataset, GeoDAR, which complementarily improved the existing global inventories of large dams. We demonstrated that the production of GeoDAR is not a direct compilation or collation of existing dam datasets. Instead, it involved a first known effort to georeference the ICOLD WRD. This was jointly enabled by geo-matching (or tableassociating) multi-source regional registers and geocoding descriptive attributes through the Google Maps API. This georeferencing effort resulted in GeoDAR v1. 0, which contains 22 560 spatially resolved dam points, each associated with a WRD record, with an overall accuracy of 95 %. Each of the georeferenced records was also labeled with a QA score, providing users a reference to the qualities of individual dam locations.
Our georeferencing process and accuracy validation, as we have elaborated in substantive detail, have important methodological value for future expansions of spatial dam inventories using similar approaches, such as Geo-Wiki and OpenStreetMap. To further ensure the optimal inclusion of the world's largest dams, we harmonized the georeferenced WRD (or GeoDAR v1. 0) carefully with GRanD v1. 3. Using the harmonized dam points as spatial identifiers, most of their reservoir boundaries were then retrieved from high-resolution water body datasets. This ICOLD-GRanD harmonization and the subsequent reservoir retrieval resulted in GeoDAR v1. 1, our end product, which holds 24 783 dam points (including 23 974 linked to the WRD) and 21 515 reservoir polygons. This product spatially resolved 44 % of the entire ICOLD WRD by dam count and more than 90 % by reservoir storage capacity.
Since most of the world's largest reservoirs (e. g. , > 0. 1 km 3 ) are already included in GRanD, GeoDAR adds limited improvements (by 4 %-27 %) to the total reservoir area, storage capacity, and catchment area. However, by including many smaller dams particularly in lower and middle latitudes, GeoDAR is triple the size of GRanD in terms of dam and reservoir quantity. For this reason, one of the major improvements of GeoDAR is its unparalleled ability to capture relatively small dams, or in other words, to enhance the spatial detail of global dam and reservoir distributions. Besides an improved quantity and spatial detail, another unique value of GeoDAR is its capability of bridging the locations of dams to a broad suite of attributes that are essential to scientific applications. A standing dilemma of existing global dam datasets is the divergence between the focus on dam quantity or spatial detail and the provision of detailed attributes for a limited dam quantity.
Nevertheless, we have suggested from regional examples that GeoDAR partially complements some of the most extensive global dam inventories such as GOODD, despite GOODD owning a larger number of dams. In this sense, even just with the 25 000 or so geometric dam points, GeoDAR contributes yet another fundamental extension to global water infrastructure databases. If these dam points are rectified to high-resolution hydrographic networks (such as MERIT Hydro;  Lin et al. , 2021; Yamazaki et al. , 2019) , GeoDAR, together with other existing dam and barrier datasets, can help refine our understanding of how human water infrastructure fragmented global rivers and their ecosystems  (Belletti et al. , 2020; Grill et al. , 2019; Yang et al. , 2022) , especially with a more exhaustive inclusion of smaller and/or headwater catchments.
Prior at Virginia Tech for providing information on some of the duplicate dam points in the US during the open-discussion process. The authors are also grateful to Bernhard Lehner at McGill University for his constructive suggestions and comments on data curation, usage, and dissemination. We also acknowledge Google Maps Platform (https://cloud. google. com/maps-platform, last access: 14 February 2022) for providing the geocoding API. Financial support. This research has been supported by the NASA Surface Water and Ocean Topography (SWOT) grant (grant no. 80NSSC20K1143). Review statement. This paper was edited by David Carlson and reviewed by two anonymous referees.
The TFM method was applied to a simple coupled core configuration to generate a numerical benchmark. The Serpent 2 Monte Carlo code was used for the stochastic part of the calculation. The configuration consists of two fuel assemblies placed in a light water tank, with a water blade of varying width between them. TFM, flux and fission results were obtained for varying water blade widths, ranging between 0 cm and 20 cm. The data is then used to analyze the behavior of the system, as well as the effects of the coupling between the two assemblies. As the assemblies move further apart, the system slowly transitions from two tightly coupled assemblies that essentially form a single core, to two almost independent cores. This study enables to produce a benchmark for future calculations and predefine an innovative way of designing high dominant ratio configurations, required for tackling Monte Carlo residual problems.
As part of the benchmark, the full set of fission-to-fission probability TFM matrices is available for prompt and delayed neutrons, alongside the average neutron fission-to-fission time matrices for the prompt-to-prompt case, as well as flux results. For the sake of brevity, this work presents a part of the TFM results for the geometry analyzed in this project. The system utilizes PWR-style fuel assemblies, with reactor grade UOX fuel (UOX -UOX system) and a second version is currently being studied, where one assembly will use MOX fuel (UOX -MOX), in order to investigate the effect between two differently reactive fuels. The effect of control rod insertion is also being studied. The results are obtained with the Serpent 2 Monte Carlo code  [5].
│ Species data The IUCN expert range maps were used to estimate species' geographic range of mammal species  (IUCN, 2020). By overlapping geographic range of species with mainland boundaries and a global vector database of islands (larger than 1 km² and smaller than Greenland;  Weigelt, Jetz, & Kreft, 2013) , we assigned an insularity-mainland status to each species (i. e. if the species occurs on mainland and/or island(s)), and then we only keep species endemic to one (i. e. single-island endemics) or many islands (i. e. multi-island endemics) because of their key interest for conservation  (Fattorini, 2017). A total of 1,000 mammal species distributed among 1,799 islands worldwide from 19 insular regions (based on hotspots biodiversity delimitation; CEPF, 2019) were considered (Figure  S1 ; Table  1 ).
Phylogenetic diversity (PD). We relied on the Faith index that is the sum of phylogenetic branch length of the studied species pool  (Faith, 1992)  to assess phylogenetic diversity represented by threatened species from each insular region. We used a time-calibrated molecular phylogeny of extant mammals  (Upham, Esselstyn, & Jetz, 2019)  to compute phylogenetic diversity. From this phylogeny, 1,000 trees were generated to capture root-to-tip uncertainty in topology and divergence times. Phylogenetic trees were pruned to the 1,000 species of the global pool. The pd() function of the picante package  (Kembel et al. , 2010)  was used to compute, through Faith index, the phylogenetic diversity represented by threatened species of each insular region. Then, the multiple values of Faith index are averaged for each species pool of insular regions.
Functional diversity  (FD). Functional diversity can be seen as the value and range of organism traits that influence their performance and thus ecosystem functioning  (Hooper et al. , 2005; Violle et al. , 2007). It can be estimated through a multidimensional niche space that encompasses all trait values of a species pool  (Villéger, Mason, & Mouillot, 2008). Here, the measure of functional diversity of threatened species from each insular region relied on the measure of functional richness (FRic). This index reflects the proportion of occupied space by the studied pool of threatened species compared to the volume occupied by the global species pool (n=1,000)  (Villéger et al. , 2008). Based on scripts developed by  Villéger (2017) , we computed the FRic index using a matrix of species' presence and absence information within insular regions and a matrix of species' traits information.
, 2014; Faith & Walker, 2002; Herrera, 2017). Such an approach, which integrates multiple sources of information is particularly valuable, especially if it identifies high-priority sites that were undervalued when using species diversity-centric approaches. Also, data-deficient species represent 14. 3% of our dataset. We did not consider data-deficient species as threatened, which can lead to an underestimation of the species considered at risk of extinction, especially that it has been shown that 63. 5% of the datadeficient species can be threatened with extinction  (Bland, Collen, Orme, & Bielby, 2015). Despite these limitations, our study allows to identify priorities of insular endemic mammalian diversity across several facets, and their level of protection and the threats that affect them.
Agricultural research has been traditionally driven by linear approaches dictated by hypothesis-testing. With the advent of powerful data science capabilities, predictive, empirical approaches are possible that operate over large data pools to discern patterns. Such data pools need to contain well-described, machine-interpretable, and openly available data (represented by high-scoring Findable, Accessible, Interoperable, and Reusable-or FAIR-resources). CGIAR's Platform for Big Data in Agriculture has developed several solutions to help researchers generate open and FAIR outputs, determine their FAIRness in quantitative terms 1 , and to create high-value data products drawing on these outputs. By accelerating the speed and efficiency of research, these approaches facilitate innovation, allowing the agricultural sector to respond agilely to farmer challenges.
In this paper, we describe the Agronomy Field Information Management System or AgroFIMS, a web-based, open-source tool that helps generate data that is "born FAIRer" by addressing data interoperability to enable aggregation and easier value derivation from data. Although license choice to determine accessibility is at the discretion of the user, AgroFIMS provides consistent and rich metadata helping users more easily comply with institutional, founder and publisher FAIR mandates. The tool enables the creation of fieldbooks through a user-friendly interface that allows the entry of metadata tied to the Dublin Core standard schema, and trial details via picklists or autocomplete that are based on semantic standards like the Agronomy Ontology (AgrO). Choices are organized by field operations or measurements of relevance to an agronomist, with specific terms drawn from ontologies.
Once the user has stepped through required fields and desired modules to describe their trial management practices and measurement parameters, they can download the fieldbook to use as a standalone Excel-driven file, or employ via free Android-based KDSmart, Fieldbook, or ODK applications for digital data collection. Collected data can be imported back to AgroFIMS for statistical analysis and reports. Development plans for 2021 include new features such ability to clone fieldbooks and the creation of agronomic questionnaires. AgroFIMS will also allow archiving of FAIR data after collection and analysis from a database and to repository platforms for wider sharing.
INTRODUCTION Agricultural researchers are increasingly exploring machine learning and other predictive approaches to formulate appropriate interventions. Technology developments such as Internet of Things and Cloud Computing together with Big Data capabilities are driving "Smart Farming"  (Sundmaeker et al. , 2016; Nidhi, 2020) , enabling decision-making based on location and other contextual and situational data in real-time  (Wolfert et al. , 2017). These capabilities and aspirations require that complex and often inter-disciplinary datasets-small and "big"-be easily queried, mined, aggregated and analyzed to derive insights and actionable options  (Hashem et al. , 2015). By accelerating the speed and efficiency of research, these approaches can facilitate innovation, allowing agile responses to challenges in the agricultural sector.