dataesr/scientific-paragraphs-categorization huggingface dataset:
Trait data represent the basis for ecological and evolutionary research and have relevance for biodiversity conservation, ecosystem management and earth system modelling. The collection and mobilization of trait data has strongly increased over the last decade, but many trait databases still provide only species-level, aggregated trait values (e. g. ranges, means) and lack the direct observations on which those data are based. Thus, the vast majority of trait data measured directly from individuals remains hidden and highly heterogeneous, impeding their discoverability, semantic interoperability, digital accessibility and (re-)use. Here, we integrate quantitative measurements of verbatim trait information from plant individuals (e. g. lengths, widths, counts and angles of stems, leaves, fruits and inflorescence parts) from multiple sources such as field observations and herbarium collections.
We develop a workflow to harmonize heterogeneous trait measurements (e. g. trait names and their values and units) as well as additional information related to taxonomy, measurement or fact and occurrence. This data integration and harmonization builds on vocabularies and terminology from existing metadata standards and ontologies such as the Ecological Trait-data Standard (ETS), the Darwin Core (DwC), the Thesaurus Of Plant characteristics (TOP) and the Plant Trait Ontology (TO). A metadata form filled out by data providers enables the automated integration of trait information from heterogeneous datasets. We illustrate our tools with data from palms (family Arecaceae), a globally distributed (pantropical), diverse plant family that is considered a good model system for understanding the ecology and evolution of tropical rainforests.
Introduction The integration and harmonization of data from heterogeneous sources is one of the biggest challenges in current ecological research  (Farley et al. , 2018). Like many other branches in biology, ecology has seen a strong increase in data availability over the past few decades  (Farley et al. , 2018). This increase corresponds to a general trend in the accumulation of data volumes, exponentially increasing in the past decade  (Chen et al. , 2014). Such 'big data' provide many opportunities for studying ecological systems at much larger spatial, temporal and taxonomic scales than has been previously possible  (Dietze, 2017; LaDeau et al. , 2017). Besides massive data volumes, there is also a large number of small datasets gathered within the ecological sciences which are often described as 'long-tail data'  (Heidorn, 2008).
We use unstandardized spreadsheets from palm taxonomists and ecologists containing individual palm trait measurements and develop a metadata form and an R script to automatically integrate and standardize these data. We follow the suggestions from the ETS  (Schneider et al. , 2019)  and provide as output a core table containing species names, trait names, trait values and trait units, and several extension tables containing information about taxonomy, measurement or fact and occurrence. All tables are linked through identifiers and follow semantic standards from the ETS, DwC, TO and TOP. Our workflow enables the semantic integration of plant trait data in a machine-readable way and aims to increase the discoverability, semantic interoperability, digital accessibility and re-use of longtail trait data such as those collected by plant ecologists and taxonomists.
Workflow We developed a workflow for integrating quantitative plant trait data consisting of three main parts: input, data integration and output (Fig. 1 ). The first part ('input') takes information from two types of external sources. The first are (Excel) spreadsheets from domain researchers which contain individual-level measurements of plant traits and its metadata. These spreadsheets have to be provided by the data provider. The second source are open-access ontologies such as the 'Thesaurus Of Plant characteristics' (TOP;  Garnier et al. , 2017)  and the 'Plant Trait Ontology' (TO;  Arnaud et al. , 2012). These provide standardized trait names, metadata information and an unambiguous identifier (URI) for each term described in the final output dataset. Additional metadata information can be linked to the 'Darwin Core'  (DwC; Wieczorek et al.
, 2012)  and the 'Ecological Traitdata Standard' (ETS;  Schneider et al. , 2019). These ontologies are already semantically linked to a metadata form and require no additional input from the data provider. Column headers from the spreadsheets are linked to quantitative trait terms derived from the ontologies through a metadata form (Fig. 1 ). We focus on quantitative traits (i. e. continuous measurements) because they provide numeric trait values to capture intraspecific variation, in contrast to qualitative traits (categorical or binary data) which usually vary less within species than quantitative traits, and often come with many verbatim trait descriptions (e. g. colours) that are difficult to standardize. The metadata form is filled-out by the dataset provider and enables to specify two thesauri (a metadata thesaurus and a units thesaurus).
These thesauri facilitate the automated standardization and integration of each input spreadsheet (Fig. 1 ). The second part of the workflow ('data integration') enables the integration of the different trait spreadsheets. This requires to standardize column headers and to change the table format from a wide to a long table. It further standardizes measurement units (into centimeters) and the taxonomy, e. g. by using the backbone taxonomy from the 'Global Biodiversity Information Facility' (GBIF. org, 2020), from the 'The Plant List'  (Kalwij, 2012)  or from the 'World Checklist of Vascular Plants'  (WCVP, 2020). These three databases identify the use of synonym names and replace them with accepted names. Additionally, the coordinate reference systems are harmonized using the Geodetic Parameter Dataset of the 'European Petroleum Survey Group' (EPSG;  Bivand et al.
, 2019). This is one of the most widely used spatial reference system in geographic information systems. The simple numeric codes of the EPSG make it machine-readable and less prone to errors than other reference systems. This system is also often updated to include the most recent coordinate references. All data integration in the workflow is built on scripts and functions using the open source programming language R (R Core  Team, 2013; v. 4. 0. 2). File reading and saving and data frame manipulations are done using memory efficient functions from the 'data. table' and 'dplyr' packages  (Dowle and Srinivasan, 2019; Wickham et al. , 2019). This allows for fast computation even in the case of many input spreadsheets. The third part of the workflow ('output') divides the obtained long-table dataset into four different tables (following  Schneider et al.
Data sources To illustrate our data integration workflow, we use individual trait measurements of palms as collected by taxonomists and ecologists (Table  1 ). These trait measurements are typically stored in Excel spreadsheets and come from different sources, such as herbarium specimens and ecological field measurements. The datasets cover a wide range of taxa and traits. Data entries, measurements, units, column headers and other metadata are typically not standardized across data providers. Besides using terms from the TOP and the TO, we also summarize the trait measurements in categories ("Whole plant", "Shoot," "Leaves" and "Reproductive organs") that have been used in the context of the TRY plant trait database  (Kattge et al. , 2020). Besides taxonomic information and trait measurements, the spreadsheets often also contain geographic information (e.
Input data The provided input data represented different long-tail palm trait spreadsheets (Table  1 ) which often followed different formats and sometimes contained mistakes which prevented an automated data integration. The most common mistakes included formatting issues such as placeholder values (e. g. 'n. m' or 'NA'), measurement units together with trait values, ranges rather than single values, and the use of different decimal separators within the same spreadsheet (Fig. 2 ). We provide examples and suggestions for how to avoid these common mistakes (Fig. 2 ). Before the spreadsheets are automatically integrated, the filled out metadata forms are validated in the script. This automated step checks for each of the four common mistakes described in Fig. 2. It also checks if the dataset provider has entered column headers in the metadata form that are not present in the measurement spreadsheet, mitigating the risks of typing errors.
Metadata form The metadata form was developed to facilitate the automated integration of individual trait measurements (Fig. 1 ) because manually changing column headers in Excel spreadsheets into standardized terms from ontologies is more prone to errors. The validation step described in the previous section identifies possible mistakes while at the same time matching column headers to standardized trait names. The metadata form also enables to add metadata from the ontologies to the used terms. The dataset providers therefore need to fill out a metadata form consisting of three main parts (Fig. 3a-c ). In the first part (Fig. 3a ), basic information on name of dataset provider, reference, basis of record (e. g. living specimen, preserved herbarium specimen) and coordinate reference system (if known, otherwise "Unknown" is automatically entered) are filled in.
This information facilitates the automated integration of the spreadsheets by providing a reference to the data origin and source (provenance) and specifying the usage of a particular coordinate system. The second part (Fig. 3b ) enables trait data integration and consists of a list of standardized quantitative trait names, to which the names of column headers from the spreadsheets are added, as well as their measurement unit. For the 15 input datasets (Table  1 ), which included a total of 50 trait terms (e. g. "Rachilla_thickness", "Plant_height", "Stem_length" or "Fruit_width"), 25.
, 2019). For those, we asked the dataset providers to match names of column headers (i. e. those not covering traits) to the term with the same definition in the ETS or DwC. Most information (94% of the terms) came from the DwC because the ETS often uses terms from the DwC. The data provider could encounter several issues when filling out the metadata form. For example, a measurement spreadsheet could include traits or metadata terms not included in the metadata form. The solution to this and other issues for both the data provider and workflow user are explained in the accompanying "bookdown" tutorial (see 'Data availability').
Combining datasets using metadata information The original spreadsheets together with the filled out metadata forms result in a metadata thesaurus and a units thesaurus (Fig. 4 ). This results in a core table representing the integrated and harmonized trait data information (Fig. 4 ). This core table consists of standardized scientific names (scientificName), verbatim and standardized trait names (ver-batimTraitName, traitName), standardized trait measurement values and units (traitValue, traitUnit), the URIs linking the traits to the TO or TOP (traitID), and the ID-columns (taxonID, measurementID, occur-renceID) which make the link to the three extension tables ("Taxon", "MeasurementOrFact" and "Occurrence") (Fig. 4 ).
Integrated dataset The integration of the 15 long-tail spreadsheets of individual palm traits (Table  1 ) resulted in a final core table with 138,993 individual trait measurements covering 50 standardized traits and a total of 551 unique standardized palm species names (based on the GBIF taxonomy, and if no match was found with TPL and the WCVP). Although only 17 of the 181 currently recognized genera of palms are captured, the 551 included species represent 22% of the approximately 2500 currently recognized palm species. Species name standardization led to 549 (89%) name matches with the GBIF taxonomy, 483 (78%) with TPL and 539 (87%) with the WCVP for all verbatim species names in this dataset. The 50 standardized trait names were derived from 158 different verbatim trait names. Most traits represented reproductive organs (64,230 trait measurements, i.
This captured the current location of the individual (e. g. record number and herbarium codes) and spatial or contextual information on the origin of each plant (e. g. coordinates, country and elevation). The integrated palm trait dataset held records for 60 different countries, distributed across all tropical regions (Appendix Fig. A. 1). The 'Measurement or Fact' extension consisted of 3146 unique combinations of measurement information, e. g. by whom and when the measurement was made. The basis of record (e. g. preserved specimen or living specimen) and the bibliographic reference was also captured for each record. Of the 50 different trait names present in the final dataset, 25 (50%) were not linked to the TO or TOP by a URI (Fig. 5b ). This reflected a total of 53,787 (39%) individual trait measurements.
Conclusion Our workflow provides an open-access resource for integrating and harmonizing individual-level trait measurements of plants into a machine-readable and interoperable format, and the integrated palm trait dataset gives an example of how new plant trait data can be mobilized. Such efforts contribute to mitigating the big shortfalls in large-scale biodiversity knowledge, namely the Raunkiaeran shortfall which represents our limited knowledge of species traits  (Hortal et al. , 2015) , especially in tropical regions  (Kattge et al. , 2020). The current workflow and metadata form can be applied to other plant taxa for harmonizing and integrating long-tail trait datasets. Moreover, it can also be applied to taxa other than plants. This would require to use an empty metadata form and thesauri as template, to enter trait names from relevant ontologies, and to provide links to databases for taxonomic standardization within the workflow.
Data availability The raw data files, the integrated dataset (core table and extension tables), the metadata form, the thesauri, the R script (workflow) and the bookdown tutorial (https://bookdown. org/timlenters/traitData) are available from GitHub (https://github. com/tlenters/traitData). The integrated dataset (with core and extension tables) is also provided on the Dryad Digital Repository  (Lenters et al. , 2020).
Name (dataset provider): Guilherme Elias QuanƟtaƟve traits Fill in (name) Fill in (unit) Taxon Fill in Date (dd/mm/yyyy): 20-4-2020 Plant_height H m scienƟficName Species Dataset name: Arecaceae#1 S e t m _ l e n g h t g e n u s Reference: Elias, G. A. , Colares, R. , Antu. Stem_width Tree Girth cm specificEpithet e L a _ f s h e a _ t l e n g h t i n f a r p s e c i i f c E p i h t e t verbaƟmCoordinateSystem: h t g n e l _ e l o i t e P e n k c i h t _ e l o i t e P s s a s U e m e p a N y t o l a n i g i r o h p r o m e g P e d u n c l e _ l e n g h t v e r b a i t m T a x o n R a n k verbaƟmSRS: SIRGAS 2000 / UTM zone 22S Peduncle_width Distance_scar_bracteole Measurement or Fact Fill in P o r p h y l l _ l e n g h t m e a u s e r m e n D t e t e r m i n e d D a e t P e d u n c l e _ b a r c _ t l e n g h t e m a s u m e r e n D t e t e r m i n e d B y basisOfRecord: Apical_leaflet_length Apical_leaflet_width Occurrence Fill in A p i c a l _ l e a l f e _ t a n g l e i d e n i t i f c a i t o n I D A p i c a l _ l e a f l e _ t v e i n _ c u o n t e r c o r d N u m b e r B a s a l _ l e a e l f _ t a n g l e i s n i t u t i t n o C o d e B a a s l _ l e a l f e _ t l e n g h t v e r b a i t m a L i t u t d e Y B a s a l _ l e a l f e _ t w i d h t v e r b a i t m o L n g i u t d e X M e d i a n _ l e a f l e _ t l e n g h t v e r b a i t m E l e v a i t o n M e d i a n _ l e a f l e _ t w i d h t c o u n y r t e L a e l f _ t n u m b e r s a t e t P o r v n i c e.
We present the first public version of Caravel, a C ++ 17 framework for the computation of multi-loop scattering amplitudes in quantum field theory, based on the numerical unitarity method. Caravel is composed of modules for the D-dimensional decomposition of integrands of scattering amplitudes into master and surface terms, the computation of tree-level amplitudes in floating point or finite-field arithmetic, the numerical computation of oneand two-loop amplitudes in QCD and Einstein gravity, and functional reconstruction tools. We provide programs that showcase Caravel's main functionalities and allow to compute selected one-and two-loop amplitudes.
With a suitable choice of integrand parametrization  [25] , this directly gives a decomposition of the amplitude in terms of master integrals. Finally, after inserting the value of the integrals at the required phase-space point we obtain the value of the amplitude. The current release of Caravel includes a module for computing products of tree-level amplitudes in several theories through off-shell recursion relations  [28] , and tools that allow the efficient construction and solution of the systems of linear equations that determine the integrand. Whilst these components work for generic multi-loop amplitudes, other components such as the construction of the parametrization are required as input. In this release we showcase the different available tools by providing a series of example programs.
Discussions regarding full automation are left to future work. The example programs give a first-hand account of the procedures employed for the calculations presented in refs. [8, 10, 16, 17, 19, 27]. The rest of this article is organized as follows. Section 2 provides a brief description of our computational methodology, section 3 gives a description of the organization of the internal modules in the Caravel framework, section 4 describes the procedure of installation and setup of the libraries. In section  5  we give details on how to run the example programs that we provide and we conclude in section 6. Appendix A and Appendix B contain technical details about our conventions for color-ordered helicity amplitudes and phase-space parametrizations.
Internal modules The Caravel framework is organized in a modular fashion. The structure of the multi-loop numerical unitarity method outlined in the previous section naturally lends itself to this modular implementation. In fig. 1  we show how the different modules of Caravel relate to the main equations of the numerical unitarity method as well as to each other. The red arrows show which module constructs each of the different components of these equations. A black arrow from A to B represents a dependence of B on A. The blue arrows highlight an input that a module receives. The modules highlighted with red boxes receive external input to operate, either in the form of data files or as machine-generated source code. In the following we list the modules of Caravel, such that the reader gets a general view of the source code of the library.
We do not give details on application programming interfaces, as in this release we only include specific example programs for the user, as presented in section 5. The modules are: • Core: This module implements general tools for debugging, arithmetic, kinematics, as well as utilities for linear algebra, rational reconstruction, type traits, and more general operations such as Laurent expansions. Among the arithmetic tools, we include interfaces to the QD  [55]  library for double-double and quad-double precision floating-point, and the GMP  [56]  library for arbitrary precision floating-point as well as arbitrary size rational numbers. Furthermore, we use an in-house implementation of 32-bit finite fields based on Barrett reduction  [57]  which states i∈T Γ A tree i (ℓ Γ l ) = Γ ′ ≥Γ k∈Q Γ ′ c Γ ′ ,k m Γ ′ ,k (ℓ Γ l ) j∈(P Γ ′ /P Γ ) ρ j (ℓ Γ l ) GraphLibrary allows finite fields of cardinality in the range (2 30 , 2 31 -1].
The module also provides linear algebra facilities for solving the cut equations. These include in-house implementations of linear algebra algorithms for finite fields, as well as interfaces to Lapack  [58]  (for double precision) and to Eigen  [59]  (for the double and the high-precision floating-point numbers provided by QD and GMP). Furthermore, the module contains implementations of D-dimensional vector and spinor representations, designed to work with both floating-point and exact number types. A (L) = Γ∈∆ i∈M Γ c Γ,i • I Γ,i A (L) = k j=-2L i∈B r i,j • h i ǫ j + O(ǫ k+1 ) Forest OnshellStrategies FunctionSpace Coefficient Providers FunctionalReconstruction Integral Providers Core There is also a parser to process headed lists like those employed in Mathematica  [60]. • GraphLibrary: A module for the classification and canonicalization of multi-loop graphs.
• Forest: Implementation of the Berends-Giele off-shell recursion  [28]  for the computation of general tree-level amplitudes and the products of trees on the left-hand side of eq. (  6 ) in arbitrary D s dimensions. The recursions can be constructed from any given set of Feynman rules 2  and can be evaluated over an arbitrary numerical type (e. g. floating point of different sizes, finite fields, etc. ). This release of Caravel includes the Feynman rules for massless QCD and Einstein gravity. • FunctionSpace: Module for the construction of the integrand ansätze of eq. (  3 ), both for tensor bases T Γ and master-surface bases M Γ. The former can be constructed for an arbitrary two-loop diagram Γ, while the latter are provided for arbitrary one-loop diagrams and only for the two-loop diagrams required for the calculations in  [8, 10, 16, 17, 19, 27].
All master integrals are stored in a format that allows on-the-fly expression of an amplitude in terms of a set of basis functions as described in section 2. 3, see eq. (  7 ). In the current version all master integrals are implemented in the Euclidean region. Additionally, Caravel contains the IntegralsBH module, which provides a large collection of one-loop integrals up to O(ǫ 0 ) (including massive and massless propagators) which can be evaluated in up-to quad-double precision using the QD  [55]  package. This library has been adapted from the BHlibMassive library employed in  [65]. • Coefficient Providers: Two different modules perform the hierarchical extraction of master-integrand coefficients via the cut equations (see section 2. 2). The AmpEng provider computes general one-loop integral coefficients, building up the hierarchy of diagrams ∆ in an automated fashion.
All modules in Caravel are implemented according to the concept of generic programming, in which algorithms are designed to operate on any data type satisfying certain (minimal) requirements. In particular, our algorithms are well equipped to work with any numerical type, such as floating point number (of fixed or variable size) or numbers in an algebraic field (the rational numbers or numbers in a finite field). This allows us to perform evaluations of amplitudes with different fixed-size floating point numbers and the reconstruction of their analytic form from exact evaluations over finite fields with essentially a single implementation.
Installation and setup The source code of Caravel can be obtained from a git repository at https://gitlab. com/caravel-public/caravel. git. Caravel employs the meson  [69]  build system, which relies on pkg-config for resolving dependencies. For more details on dependence resolution, configuration options and the installation of optional libraries see the README. md and INSTALL. md files in the repository. To build Caravel in the default configuration and install it to the directory <install dir> one can proceed as follows: 1 > git clone https://gitlab. com/caravel-public/caravel. git 2 > cd caravel 3 > mkdir build 4 > cd build All available test suites can be run with the command > ninja test executed in the build directory. Note that, depending on the hardware and build configuration, running all test suites can take a considerable amount of time.