dataesr/scientific-paragraphs-categorization huggingface dataset:
This bundle, initially, is published in a Marketplace so as to be purchased by BPaaS customers. While originally in template form, due to missing customer-specific information, once bought, this bundle becomes concretised and is then forwarded to our environment for execution. Our environment does not provide a concrete output in the form of a file that can be consumed by another component or environment. However, it does supply REST APIs and databases out of which suitable information can be retrieved and exploited. The information is mainly of a deployment and monitoring nature and is consumed by the BP evaluation environment in the CloudSocket prototype platform to facilitate the evaluation of Key Performance Indicator (KPIs) and other types of analysis (e. g. , best BP deployment). In the following, we analyse first the overall architecture of the BP Execution Environment and then we move to the analysis of each of the major components that provide support for the cross-level and cloud adaptive BP provisioning.
g. , BPaaS analysis purposes in CloudSocket's BP evaluation environment. This composite component follows a three-tier architecture, as depicted in Fig. 7 , involving the UI, the backend and the database layer. Some of its subcomponents extend functionalities exhibited by the BPMN engine actually exploited, Activiti 42 , such as the APIs offered, the multitenancy, the impersonalisation of integration services and the UI usability. At the UI level, three main sub-components are provided. The REST Workflow is a RESTful service component exposing an API for the programmatic management of workflows and their instances as well as the retrieval of workflow execution history information. This API also 42 https://www. activiti. org/ extends the basic functionalities of Activiti with capabilities to deploy workflows with dynamic endpoints.
The backend layer involves three main sub-components. The Core Workflow Engine manages the whole functionality exposed by the Workflow Engine which can be invoked by using a certain interface. This sub-component also handles the storage of workflows, their instances plus of other entities at the underlying database. The Workflow Parser sub-component can parse BPMN workflows and update their endpoints. It is can also generate service task tags for invoking both SOAP and RESTful SaaS services. The Bind Proxy, finally, enables interacting with the underlying database in the context of the storage and retrieval of service task to SaaS bindings/mappings. At the database layer lies the Workflow Database, which is a relational database, is responsible for the storage and retrieval of any information related to the workflows, such as roles, tenants, and workflow (instances).
The output is the events generated which can be consumed by other components (i. e. , the adaptation and SLA engines). Indirectly, the measurement database(s) enables any component to, e. g. , perform additional analysis on its content. This indeed takes place in the CloudSocket's BP evaluation environment, as indicated in the beginning of this section, for supporting KPI evaluation. The Monitoring Engine's internal architecture is depicted in Fig. 9. It comprises level-specific agglomerations of monitoring components, called level-specific monitoring mechanisms, plus an evaluation component. At each level, three component kinds are employed: (a) the Measurement Database (MDB) for the storage and retrieval of monitoring information; (b) the sensors deployed for measuring and storing such information in the MDB; (c) the Aggregator for aggregating measurement information according to the CAMEL-based specification of respective high-level metrics.
This specification is the concretised by the Concretiser, which accesses the service registry to support the needed service discovery and selection. The completed service-based workflow specification is then deployed in the Adaptation Workflow Engine, a normal workflow engine responsible for executing (adaptation) workflows. While executing these workflows, this engine also handles the storage of their execution information in the underlying Adaptation Database. 44 www. bpmn. org An adaptation workflow involves the execution of service-based adaptation actions, which map to services offered via an adaptation library. These services are organised into different levels and rely on interfaces offered by other components in the execution environment. The workflow level involves services that modify the currently running BP workflow and thus cooperate with the Workflow Engine.
Most core components of the Adaptation Engine can be distributed. The only components which can be mostly centralised are the UI plus the two types of databases, the KB and the Adaptation Database. This is due to the fact that we do not expect much load to be incurred to the latter components. In any case, we do not expect that the Adaptation Engine will be much overloaded thus requiring its appropriate distribution as the respective adaptation-triggering events will be not so frequent per each BP workflow.
12 , both SaaS will be allocated to certain BP workflow tasks. We have omitted from the analysis configuration details for "Invoice Ninja" as they are quite technical. These can be inspected in the respective CAMEL model available online 45. In this CAMEL model, there exist two main adaptation rules which will drive the BPaaS adaptation behaviour. These rules are depicted as follows. The first rule attempts to re-start the "Invoice Ninja" component if it is unavailable. Its main rationale is that many software bugs are transient and can be easily fixed by restarting the software. However, in case that the bug insists, the second rule will compensate for this by migrating the component in another VM. This migration has the rationale that possibly either the component has become corrupted and/or reached an inconsistent state such that it needs to be redeployed from scratch.
Radiocarbon is a critical constraint on our estimates of the timescales of soil carbon cycling that can aid in identifying mechanisms of carbon stabilization and destabilization, and improve forecast of soil carbon response to management or environmental change. Despite the wealth of soil radiocarbon data that has been reported over the past 75 years, the ability to apply these data to global scale questions is limited by our capacity to synthesis and compare measurements generated using a variety of methods. Here we describe the International Soil Radiocarbon Database (ISRaD, soilradiocarbon. org), an open-source archive of soils data that include data from bulk soils, or "whole-soils"; distinct soil carbon pools isolated in the laboratory by a variety of soil fractionation methods; samples of soil gas or water collected interstitially from within an intact soil profile; CO2 gas isolated from laboratory soil incubations; and fluxes collected in situ from a soil surface.
The core of ISRaD is a relational database structured around individual datasets (entries) and organized hierarchically to report soil radiocarbon data, measured at different physical and temporal scales, as well as other soil or environmental properties that may also be measured at one or more levels of the hierarchy that may assist with interpretation and context. Anyone may contribute their own data to the database by entering it into the ISRaD template and subjecting it to quality assurance protocols. ISRaD can be accessed through: (1) a web-based interface, (2) an R package (ISRaD), or (3) direct access to code and data through the GitHub repository, which hosts both code and data. The design of ISRaD allows for participants to become directly involved in the management, design, and application of ISRaD data.
The synthesized dataset is available in two forms: the original data as reported by the authors of the datasets; and an enhanced dataset that includes ancillary geospatial data calculated within the ISRaD framework. ISRaD also provides data management tools in the ISRaD-R package that provide a starting point for data analysis. This community-based dataset and platform for soil radiocarbon and a wide array of additional soils data information in soils where data are easy to contribute and the community is invited to add tools and ideas for improvement. As a whole, ISRaD provides resources that can aid our evaluation of soil dynamics and improve our understanding of controls on soil carbon dynamics across a range of spatial and temporal scales.
5 m of soil or less, despite deeper soils contributing a significant proportion of SOM storage  (Rumpel and Kögel-Knabner, 2010). There is an urgent need to synthesize a wide variety of soils data to model the role of soil in the climate system  (Bradford et al. , 2016) , to develop more data driven estimates of soil health  (Harden et al. , 2017) , and to extend our detailed understanding of soil developed from observations made at the profile scale to both regional and global extents. Here we describe a new open-source database for the synthesis of soils data with a particular focus on soil radiocarbon data. Radiocarbon (i. e. , 14 C) content of SOM is a useful estimate of the timescales of SOM cycling including the turnover time, residence time, or mean age of carbon in soil -defined as the time it has been isolated in soil from the atmosphere  (Sierra et al.
The advent of accelerator mass spectrometry in the 1980's allowed for radiocarbon analysis using milligrams of carbon instead of grams, while simultaneously increasing sample throughput. This development enabled analysis of small amounts of archived soils to track the incorporation of 14 C derived from atmospheric testing of nuclear weapons, as well as making it far easier to analyze physically and chemically isolated soil fractions (e. g. ,  Trumbore 1993). These applications have led to an explosion in the number of publications with radiocarbon measurements from soil. This database is an attempt to provide an archive for all the previously published data but also a repository for organizing new data as it is published. Two recent soil radiocarbon synthesis efforts demonstrate the utility of these data for improving predictions of SOM dynamics  (He et al.
There have been previous efforts to develop a soil radiocarbon database  (Becker-Heidmann, 1996; 2010; Trumbore et al. 2011) , separately or integrated with a general-purpose soil carbon database  (Harden et al. , 2017). However, a challenge remains: to compile and organize soil radiocarbon data that has been collected in many different and complex ways (e. g. , using various fractionation methods or including fluxes as well as organic matter pools). Addressing this challenge will provide new opportunities to leverage existing soil radiocarbon data for critical research such as developing practical and theoretical insights into the information contained in various fractionation methods and how they relate to one another, expanding our understanding of controls on soil carbon dynamics, and facilitating broader integration of radiocarbon constraints on soil carbon turnover in Earth surface models.
For example,  He et al. (2016)  leveraged a synthesis of bulk-soil radiocarbon data to better constrain the age of carbon in five Earth system models, demonstrating that without this added constraint, these models overestimate soil carbon sequestration potential by an average of 40%. Here we present a flexible database spanning broad spatial scales and capturing a range of data types including diverse soil fractionation methods, incubations, fluxes, interstitial measurements and spanning a range of spatial scales. Our goal is to provide an open-access data resource that will encourage the scientific community to apply the database for a variety of synthesis studies or metaanalyses and also contribute data to the repository.
The Soil Radiocarbon Database (ISRaD) ISRaD (v1. 0) is designed to be an open-source platform that (1) provides a repository for soil radiocarbon and associated measurements, (  2 ) is able to accommodate data collected from a large variety of soil fractionation techniques, and (3) is flexible and adaptable enough to accommodate new variables and data types. The ISRaD v1. 0 data is archived and freely available at https://doi. org/10. 5281/zenodo. 2613911 (Lawrence et al. , 2019). Access to additional information as well as the various ISRaD resources described below is provided through the ISRaD web interface (soilradiocarbon. org).
Database and Dataset Structure In its most general form, ISRaD is an implicitly relational database. It consists of a linked hierarchical list of tables that contain soil measurements, i. e. variables (Fig. 2 ). The fundamental unit of organization in ISRaD is the entry, which corresponds to a unique dataset i. e. , a dataset with a digital object identifier (DOI), while each subordinate table corresponds to data from that entry with a particular spatial or temporal dimension (Fig. 1 ). Transparency and traceability are fundamental tenants of ISRaD. Accordingly, each entry, whether ingested individually or as a compilation, must have a DOI. For data from published studies, the DOI of the publication is acceptable. Data from unpublished studies must be registered for a DOI through a DOI registration agency (e.
g. , zenodo. org, www. pangaea. de/, etc. ) prior to ingestion into ISRaD. As it is equally important to be able to reconstruct prior data compilations e. g. , synthesis studies, the specific references for individual datasets making up a synthesis are ingested as part of the synthesis entry and the entry is flagged with a reference the synthesis study itself. For example, several of the major data sources added to ISRaD were synthesis studies (e. g. ,  He et al. , 2016; Mathieu et al. , 2015) , and users can generate reports of data from these prior syntheses by constructing a query that utilizes this synthesis flag.
Site Data Table Site-level data are limited to the geospatial details defining the coarsest scale of the study area(s) included in each entry. We define a site as a spatially defined location that includes one or more soil profiles. By convention, we define a site as having ≥ 5km radius, i. e. , samples collected within 5 km of each other should be grouped under the same "site" designation. However, the 5 km radius is a convention only, as the distinction between site and profile may be study-specific, and geospatial data at this resolution is not always available for legacy datasets. The required fields at the site level are limited to the site name (site_name), latitude, and longitude. In other words, spatial coordinates are required to designate a site. Every entry must specify a minimum of one site location, but can include multiple sites that do not need to be located in close proximity.
For entries that do not report spatial coordinates, the data curator may estimate latitude and longitude based on the description of the study area using any of the widely acceptable mapping software (e. g. , Google Earth, Google Maps, etc. ). The site level does not include fields for reporting site properties. Such directly measured variables are reported at the profile level. The intended purpose of the site level data is to provide at least coarse-scale geospatial coordinates for extracting consistently sourced parameters from geospatial datasets, which can then be compared against the range of measurements reported at the profile level.
Flux Data Table Soil flux data present a special case of observations that correspond to the profile level of the database hierarchy. Flux-level data allows for reporting of temporally explicit measurements of mass or energy transfer occurring at the profile scale. Both gas and liquid analytes (e. g. CO2, CH4, dissolved OC, particulate OC, etc. ) may be reported in flux data. In addition to the profile name, records with flux data must also include the observation date (flx_obs_date). Data measured at multiple time points in a single location will have identical profile names but unique temporal data.
Fraction Data Table Compared with most other soil databases, the fraction data table of the ISRaD is unique. The fraction data fields are designed to accommodate and allow for fair comparison of the wide-ranging methodologies utilized to partition soils into discrete fractions. As such, there are more required fields for the fraction level compared with the other hierarchical levels. These required fields include fraction name (frc_name); the input source (frc_input), which can be the name of another fraction or bulk (unfractionated) soil layer fraction scheme (frc_scheme), which is a controlled set of terms describing the general class of fractionation procedure used; the fractionation agent (frc_agent), which provides additional detail for methods that have multiple options; the upper and lower boundaries (frc_lower and frc_upper), which allow for description of the fractionation thresholds used in the fractionation procedure; and finally the fraction scheme units (frc_scheme_units), which describes the units of reference for the cut-off thresholds.
Data Ingestion New data entries are added, or ingested, into ISRaD through a user-initiated process. The most common means of ingesting entries is via a template provided on the ISRaD web interface (ISRaD_Master_Template. xlsx). The template is intended to be used in combination with the data dictionary (ISRaD_Template_Info. xlsx). These files and other supporting documentation (user guide and FAQ) are also available at the web interface. Completed entries that have been formatted for ingestion must also pass the automated QA/QC test before the ingestion process can proceed. Users can initiate QA/QC using the ISRaD-R package (described below), or directly from the ISRaD web interface. If the entry fails QA/QC, the report from the test can be used as a guide to make corrections. Once an entry passes QA/QC, it can be submitted for the final two steps of the ingestion process: expert review and final ingestion.
Data templates that have passed QA/QC should be submitted via email to ISRaD at info. israd@gmail. com. These templates are then distributed to ISRaD expert reviewers who inspect template files to ensure proper completion of the more complex aspects of the template, such as classification of soil fractionation methods. If problems are identified with a submitted dataset during the expert review process, reviewers will work with the data curator to ensure these problems are corrected. Once the expert reviewer signs off on a submitted template, it will be ingested into the database.
ISRaD v1. 0 The current version, v1. 0, of ISRaD includes a total of 195 individual data entries and 503 sites spanning the globe (Fig. 3 ). The current distribution of data across the various levels of the database hierarchy are shown in Table  1 , and a full list of data entry references is provided in Supplemental Table  1. Users may access ISRaD and its supporting information three ways: (1) the web interface, (2) the ISRaD-R package, and (3) the GitHub repository. Each of these access points is described in more detail below.
The ISRaD Web Interface Most simply, users can access ISRaD data and associated resources by way of the web interface (https://soilradiocarbon. org). From the web interface users can download pre-compiled versions of the database in a simple file format (. csv), which can be easily ingested into graphical or database software. The web interface also provides access to the most recent versions of the ISRaD entry template, the template information file, an up-to-date list of the datasets included in the latest version of ISRaD, the QA/QC tool, and a variety of other resources for assisting with filling out data templates and interacting with ISRaD data.
The ISRaD-R package All ISRaD users, but especially those already familiar with the R computing environment (R Foundation for Statistical Computing, Vienna, Austria), are encouraged to download the ISRaD-R package (also called ISRaD and available at the CRAN repository, https://cran. r-project. org/). At present, we provide some basic tools for compiling data in the ISRaD template format into an ISRaD-structured database, and downloading both archived and current versions of the database from the ISRaD github repository as an R list object (. rda file), or. xlsx file. The ISRaD-R package includes two data objects: (1) ISRaD_data, which includes only data entered from the original source studies and (2) ISRaD_extra, which includes the original source data as well as gap-filled and additional variables that have been calculated or filled from external geospatial data sources.
Value-added data included in the current implementation of ISRaD_extra are described in Table  2. The ISRaD-R package also includes support for an R-Shiny application that provides a simple graphical user interface (GUI), with which users can perform several basic functions. The GUI allows for preliminary data visualization, which is intended for quick assessment and/or filtering of the database. A few simple report functions are built into the ISRaD-R package that can be used to produce basic data summaries and visualizations for the full dataset or user-defined subsets. However, ISRaD has been designed for ease of use in the R environment in order for users to be able to take advantage of the full suite of R capabilities and functionality to manipulate and analyze ISRaD data. A number of vignettes including R scripts for some commonly used data manipulations or plotting are given on the web site and are also included in the ISRaD-R package installation.
The ISRaD GitHub Repository The source code for the ISRaD-R package is hosted under version control on the GitHub repository ISRaD (https://github. com/International-Soil-Radiocarbon-Database/ISRaD) (GitHub Inc. , San Francisco, CA). This platform is used to facilitate the open-source collaborative development of ISRaD data and additional database tools. Through the GitHub interface, users may (1) access data entries included in the compiled database; (2) evaluate and suggest modifications of the underlying code used for compilation, QA/QC, and calculation of the additional variables included in either the compiled ISRaD data object (ISRaD_data) or in the augmented data product (ISRaD_extra); and (3) report problems, questions, or other issues.
The Soil Carbon Information Hub For students or non-experts interested in learning more about the science behind the data, we have developed the Soil Organic Carbon Information Hub (SOC-Hub). SOC-Hub (https://internationalsoil-radiocarbon-database. github. io/SOC-Hub/) is a set of articles in the form of blog posts providing background information on soils, radiocarbon, the terrestrial carbon cycle, and soil models. A large portion of the content for this site was created by students, and whenever possible uses non-technical language to describe topics pertinent to ISRaD. Technical editing of the SOC-Hub is facilitated through the ISRaD GitHub repository. Users are welcome and encouraged to contribute to or improve the content in SOC-Hub.
Accessing data entries Individual data entries (i. e. , completed templates, or templates output from ingested compilations) that have passed QA/QC and the expert review process are hosted in the "ISRaD_data_files" folder of the GitHub repository. Users may download these entries in order to add new data or to make corrections to existing data if problems are discovered. Corrected files can be resubmitted to ISRaD once they pass QA/QC by emailing the updated template and a text file of the QA/QC report to the ISRaD editor (info. israd@gmail. com), and will be reingested after passing the expert review process. This process of user-initiated revision of existing data entries is particularly useful when large data compilations are ingested into ISRaD from previously published syntheses (e. g.