dataesr/scientific-paragraphs-categorization huggingface dataset:
While big data capabilities can offer analytics to power digital advisories and facilitate innovation in agricultural research, and agility and impact in the solutions space for farmers and other stakeholders, they rely on standardized, machine-interpretable agronomic data. An exemplar of the power of open, interoperable data is the  COVID-19 Open Research Dataset (Semantic Scholar, 2021)  with the use of widely accepted standards such as mature biomedical ontologies  (Bodenreider et al. , 2005)  enabling such advances. The collaborative application of massive computing power to this shared data and standards enabled researchers to model and identify promising compounds for treatment in just under two days-a result that would otherwise have taken years  (Quitzau, 2021). This is a powerful demonstration of in silico analysis over vast data pools enhancing the speed and scale of scientific innovation, and a similar model could be just as ground-breaking for millions of agricultural practitioners.
This necessitates mining pools of agriculture-related publications, data, and data products that are fully open, interoperable and reusable, adhering to the FAIR Data Principles  (Wilkinson et al. , 2016). With the exception of the genomic/genetic disciplines, the agricultural domain in general has lagged in this regard. Most agronomic datasets are collected as activities under individual projects, following project recommendations at best, resulting in bespoke data terminologies and annotations, uneven or nonexistent metadata, and other issues that make it difficult to share, reuse, or aggregate such data. CGIAR 2  is a large network of global agricultural research for development centers working globally with partners and farmers in several of the poorest nations. CGIAR's Platform for Big Data in Agriculture 3  has developed many open-source tools and solutions to help agricultural researchers anywhere generate open and FAIR outputs easily and quickly, and to create high-value data products drawing on these outputs.
Its GARDIAN data ecosystem 4  includes a toolkit with a FAIR data workflow, for instance, that helps make legacy data assets FAIR. In these endeavors data interoperability tends to be the more difficult aspect to address, and it has become clear that it is most efficient to generate data that is interoperable "at birth" and also as findable as possible. The CGIAR Platform for Big Data in Agriculture developed the Agronomy Field Information Management System or AgroFIMS 5  in response, to enable the collection of agronomic data that is highly interoperable and findable, helping users with some of the more challenging aspects of FAIR data. AgroFIMS is a web-based, open-source tool that allows users to create fieldbooks which can be exported to several free digital collection Android apps, including KDSmart 6  , Open Data Kit 7   (Hartung et al.
, 2010) , and Fieldbook 8   (Rife and Poland, 2014). The fieldbooks include metadata already tied to a standard [the CG Core Metadata Schema, 9  aligned with the industry standard Dublin Core  (Apps, 2005) ], and data variables that are linked to concepts in semantic standards like the Agronomy Ontology 10  (AgrO). Users do not need to know details about standards such as ontologies, as the terms they choose are part of their normal scientific and agronomic domain vocabulary. By employing these data standards toward annotation a priori, AgroFIMS helps to create a semantic pool of data for easy aggregation and leveraging by machine learning and other technologies. AgroFIMS also generates rich metadata that largely adheres to semantic standards and controlled vocabularies, facilitating compliance with growing institutional, founder and publisher mandates for FAIR data through this focus on interoperability and findability.
Although users are encouraged to use the least restrictive licensing possible, the tool itself does not force licensing choices on users. In-development efforts will make it easier for users to choose appropriate standard licenses for access and data reuse. To further encourage more accessible and reusable data, by the end of 2021 AgroFIMS will call on aspects of the GARDIAN FAIRscribe to provide a score indicating how FAIR data is, allowing the user to address lowscoring dimensions.
METHOD AgroFIMS Framework AgroFIMS allows users to easily design and create fieldbooks to collect agronomic data already tied to a metadata standard, the CG Core Metadata Schema, and calling on ontologies to populate metadata fields. The tool was first developed in 2018, but its features and user interface have undergone iterative improvements based on testing and feedback by agronomists, crop modelers and developers. It now offers an intuitive platform to guide users through different screens following the schema of a typical agronomic experiment. AgroFIMS then aggregates this information in an easily usable data collection form or fieldbook. The general workflow for an AgroFIMS user starts with fieldbook creation and ends with data publication in one of many repository platforms (Figure  1 ).
The first step of this workflow, the design of a fieldbook, is done online on the AgroFIMS website (Figure  2 ), and involves filling the Metadata module that allows users to specify where the agronomic trial will be conducted by defining one or more sites via the Sites tab. The tab allows users to specify and manage trial locations, with site metadata (including latitude, longitude, elevation, administration level names etc. ) introduced in a web form that displays and zooms a map. To add a new site, users enter administrative division names, the GPS coordinates or pinpoint the site on this map (Figure  3 ). GADM Maps and Data 11 is used to define administrative levels (countries and their sub-divisions). The newly created site is then saved in AgroFIMS and can be connected to experiments.
A site is the entry point for any fieldbook in AgroFIMS. The next step of the Metadata module involves defining an agronomic experiment or trial with experiment details, representing trial metadata (Figure  4 ). The experiments are assigned unique identifiers by the system and are accessible only to the person who designed them, they are not shared across AgroFIMS users. To create an experiment, users give it a name and add details about the project and its objectives, grant information, funding agency, management entity and/or lead. A tab dedicated to personnel working on the experiment auto-loads the user's information and allows registration of different team members and their roles in the trial. A new fieldbook can now be added to the experiment. One or more fieldbooks may be included in the same experiment as part of a project, allowing multisite and multiyear experiments.
A special pop-up module facilitates the calculation of fertilizer quantity to apply, along with implements to be used, timing of application/s and more. This feature is described in the Results section (Figure  7 ). AgroFIMS supports either spreadsheet or mobile-based data collection, and once a fieldbook is completed it can be downloaded in different formats:. xlsx,. kdx,. csv,. trt and. xml. The mobile format is tailored for three freely available Android applications: KDSmart, 12  Fieldbook 13   (Rife and Poland, 2014) , and ODK Collect 14   (Hartung et al. , 2010). Excel displays the metadata added in the AgroFIMS website as the first tab, with other tabs based on field protocols, crop, soil, and weather measurements, and traits specified. Digital data collection eliminates the need to transcribe from paper to digital format and reduces errors thanks to the validity range applied to each measurement.
Collected data can be uploaded every day making it possible to assure and course-correct to ensure that an experiment follows the planned trajectory. Once data is collected, files can be exported in a Google spreadsheet from ODK, and as a zip file from Fieldbook. Users of KDSmart can export collected data back to AgroFIMS for analysis using a statistical analysis module compatible with the application (Figure  1 ). File outputs from KDSmart are uploaded to AgroFIMS to generate a statistical report in a Word format and based on R scripts. Datasets can then be saved in institutional repositories (Figure  1 ). This step is currently done manually, but direct upload from AgroFIMS to repositories through an Application Program Interface (API) will soon be available. A help  page 15 has been designed to support the use of AgroFIMS  (Aubert et al.
Technical Specifications The AgroFIMS platform initially began as an interactive analytics platform for breeding trials, developed in the R statistical language. It was expanded to be a more complex data collection tool that is developed on top of Angular 11. 0, a single web-based page application framework maintained by Google and compatible with multiple browsers  (Google, 2020). The application source code is maintained on GitHub, 16  where all commits, changes, and enhancements in the source code are tracked. The single web-based page application permits building data-driven and form-intensive applications such as AgroFIMS. The AgroFIMS frontend comprises one to multiple complex forms and auto-save forms functionality, everything based on Angular. The frontend communicates with the backend, which is developed in PHP and TypeScript (NodeJS), via web services establishing a connection to the database.
The backend contains the queries that bring the required data from the database. This data is presented in the user interface through AgrAPI. APIs are configured to carry the information through URLs in JSON. The database uses MySQL as the database engine to manage data through tables, using a relational model. The database stores information from the auto-save functionality to restore sessions, and agronomic data dictionaries. The web architecture of AgroFIMS follows REST (REpresentational State Transfer) specifications, widely supported by modern web services  (Fielding and Taylor, 2002 ). An API is defined over this for data exchange between users and services to handle agronomic data in the platform. This REST API called AgrAPI addresses the problem of accessing large and complex datasets, enabling access, integration and exchange of FAIR agronomic data across systems and applications  (Leonelli et al.
, 2013). AgrAPI calls have been organized to mirror the operational structure of AgroFIMS via categories such as experiment details, site details, crop, design, fertilizer, management practices, field measurements and environmental variables (Table  1 ). AgrAPI calls are implemented through an R-package called ragrapi 17 This package is aimed at accessing all the relevant data defined in AgrAPI, retrieving information about an experiment, getting field layouts, searching for fertilizer data, and accessing the different variables of the agronomic experiment.
While ontologies offer powerful capabilities, they are not easy to leverage. AgroFIMS makes it easy for agronomists to use these and metadata standards without necessarily knowing the particulars of the standards themselves, as described below. AgroFIMS relies on the Agronomy Ontology 18 (AgrO) to enable standardization of data variables and parameters, and thus, interoperability across multiple datasets. AgrO includes approximately 2270 terms depicting the agronomy domain (as of June 2021). These are semantically organized and can facilitate the collection, management, understanding, sharing and use of agronomic data, enabling easy interpretation and reuse of the data by humans and machines alike. AgrO follows OBO Foundry principles, 19 and therefore builds on existing standards. It relies on traits and parameters identified by agronomists and avoids replication of concepts already in other ontologies and vocabularies by including them with their native URIs.
Some indicative standards that AgrO draws from include the ICASA Data Dictionary  (White et al. , 2013) , and other existing ontologies such as the Environment Ontology  (Buttigieg et al. , 2016) , the Unit Ontology, 20 the Trait Ontology  (Cooper et al. , 2020)  and the Crop Ontologies  (Shrestha et al. , 2012) , as illustrated in Figure  6 , which shows a small part of AgrO. Like many other ontologies, AgrO is enriched through knowledge provided by scientists working in the agronomy domain, allowing it to realistically describe and model agronomic experiments including agricultural practices and implements, and variables that are typically measured 17 https://github. com/AGROFIMS/ragapi. 18 https://bigdata. cgiar. org/resources/agronomy-ontology/ 19 http://www. obofoundry. org/principles/fp-000-summary.
AgrO is maintained using the OBO Foundry suite of tools [Ontology Development Kit 21  and ROBOT 22   (Jackson et al. , 2019) ] for the release process and with the Protégé tool  (Noy and Mcguinness, 2001)  for adding new terms. The ontology is openly maintained on GitHub, 23  allowing anyone to contribute. It is open source and available through several ontology registries including EBI-Ontology Lookup Service,  24 AgroPortal, 25  and Ontobee. 26 Although AgroFIMS was the first use case of the Agronomy Ontology, its continued growth and maintenance ensures wider relevance (e. g. , to the agroforestry sector), and greater interoperability with existing standards in the life sciences. Annotations can be used to guide data entry in a database or when publishing to a data repository. As already mentioned, reliance on ontologies means that humans and machines understand the meaning behind data produced during an experiment designed using AgroFIMS.
" This means that users keying in "fertilizer" in a search engine will find this dataset even if it does not reference the term "fertilizer" because the ontology relationships specify that "urea" belongs to a class of things called "fertilizer. " That is, the machine is able to infer through the ontology that urea is a fertilizer, rendering that dataset more easily findable and interoperable. Regarding the access and reuse concerns of FAIR, AgroFIMS recommends that data authors make their datasets as open as possible. However, the tool does not manage the accessibility of data or mandate licenses. This entirely depends on data authors and the particular policies or regulations they are governed by, but AgroFIMS is being developed to make it easier for data authors to choose appropriate open licenses and check FAIR assets against actionable FAIR metrics, as already mentioned.
Apart from the value addition of born-FAIRer data recognized by the agronomist, crop modeler, and developer participants of user testing workshops at different phases of development, feedback has been positive concerning the user interface and navigation, and features including the provision of statistical scripts and analysis reports, direct upload from the AgroFIMS database to a variety of repositories, and plans to provide users with authoritative picklists (e. g. , institution names from the Research Organization Repository or ROR 27 database). Some illustrative examples of efforts to enhance usability of AgroFIMS follow: Crop measurements. Crop measurements listed in AgroFIMS are displayed depending on the crop selected earlier in the workflow. Thus, parameters such as "marketable yield" will be available as measurement choices for root and tuber crops, but not for cereals.
g. , 2 applications each of 20 kg/ha and 30 kg/ha for the treatments specified in Figure  7 ). The timing, technique, and method of application can also be indicated, and the amount of nutrient calculated via an R script initiated via the "calculate" button (Figure  7 ). If nutrient is selected rather than product, users indicate the nutrient amount they want to apply (e. g. , 40 kg/ha N; 20 kg/ha P; 10kg/ha K etc. ) and select the fertilizer products. The tool then calculates the quantity of fertilizer to needed to deliver the desired nutrient amount. Statistical analysis. Once data has been collected, those using the KDSmart application have the option to export their data and download them to the statistical analysis module of AgroFIMS. The module provides a statistical report of the data through R scripts to assess such measures as the analysis of variances (ANOVA), Least Significant Difference (LSD) and Tukey tests.
These engines will enable links to proposed ontology terms and URIs that a human can verify. That is, for the question: "Has cassava been grown in the past in this field as a monocrop?" the tool will recognize the standardizable terms of the question (the words in italics), and link these to the correct ontology terms. Through these direct links to data standards, the generated ODK forms and fieldbook will therefore begin to enable standardization of datasets. The goal for the next version of AgroFIMS is to overcome such current limitations and offer a solution that more fully supports data management. The vision for this improved tool includes data collection that can handle data collection from different agronomic trial types; pipelines to the FAIR workflow currently in alpha version to strengthen user ability to easily address aspects of data accessibilty and reuse, a database integrated with CGIAR's collaborative analytical CG Labs 31  environment built on Jupyter notebooks for teams to work together on data processing; access rights and roles at project level; and the possibility to push data to repositories and the GARDIAN discovery portal once project teams are ready to do so.
Team members and enumerators will access data collection forms via CG Labs or other sharing platforms, with the goal of ultimately providing access through a single database. Once data is collected by enumerators, they will be able to upload the forms back to CG Labs or any ODK-compliant platform that offers an API for data to be pulled/synced into CG Labs (e. g. , ONA 32  ). CG Labs provides easy access to Git repositories, R libraries, crop model pipelines (e. g. , WOFOST, Ecocrop, DSSAT), and a large number of data services, including very large (7-10 TB) datasets. This environment therefore makes it easy to clean, process, and analyze data with other team members, interoperating at the same time with other datasets of relevance. An infrastructure is therefore envisaged by 2022 that allows researchers to design survey forms and fieldbooks, share these with enumerators, and frequently upload and assess the data collected.
ACKNOWLEDGMENTS We gratefully acknowledge  Pieter Pypers  and  Meklit Chernet  (IITA),  Myriam Adam  (CIRAD),  Cheryl Porter  and  Christopher Villalobos  ( University of Florida ),  Richard Ostler  and  Aislinn Pearson  ( Rothamsted Research ),  Peter Craufurd ,  Balwinder Singh , and  Anurag Ajay  (CIMMYT),  Robert Hijmans  ( University of Davis ),  Elizabeth Arnaud  ( Alliance Bioversity-CIAT ),  Abhishek Rathore ,  Anil Kumar ,  Sravani Mana  and  Praveen Reddy (ICRISAT) ,  Sylvain Delerce (CIAT) , and  Brian Lowe (Ontocale). They provided insight and expertise that greatly assisted the development of the tool. We also thank  Brian Pearce  ( Diversity Arrays Technology ) and the  Diversity Arrays Technology team  for making the KDSmart application compliant with our tool. We are also indebted to our colleagues from  CIP :  Henry Juarez ,  Elisa Salas ,  Raul Eyzaguirre ,  Vilma Hualla ,  Peter Juro , and  Jazmin Molano  who offered their time and support in building the tool.
This work is organised as follows. In Sec. 2 we present Lagrangian formulations for the considered simplified models that all feature a different class of new top-philic bosons, we construct the minimal set of four-top operators needed to match these models to an EFT framework and discuss four-top production at the LHC. In Sec. 3 we describe the experimental search used to constrain new physics-induced four-top production at the LHC, as well as our calculation and simulation setup. Finally, Sec. 4 is dedicated to the presentation of our results. We show limits derived from CMS four-top data and therefore obtain the most up-to-date constraints on the considered topphilic simplified model scenarios. Prospects at the future high-luminosity LHC (HL-LHC) run are also estimated. We summarise our work and conclude in Sec.
Therefore, the selection ensures the presence of a large number of isolated jets and leptons. Furthermore, given the large number of required b-tagged jets, a precise description of the CMS b-tagging performance is crucial to obtain an accurate modelling of the search. This represents the major change implemented in the Delphes 3 card dedicated to this search (that is now shipped with the Public Analysis Database of MadAnalysis 5), relative to the default CMS parametrisation in Delphes 3. This tuned card allows one to reproduce the efficiencies of the deep neural network b-tagging algorithm of CMS (DeepCSV)  [78] , whose medium working point configuration is used in the search under consideration. For the validation of our implementation, we have mimicked the simulation setup used in the CMS-TOP-18-003 four-top analysis, and hence generated SM four-top events at NLO in QCD when all EW contributions are neglected.
Numerical procedure In this subsection, we detail the numerical procedure that we follow to obtain limits on the simplified models presented in Sec. 2. 1. We use the chain of high-energy physics tools introduced at the beginning of Sec. 3 to simulate 200,000 events for a variety of configurations in each model. We High -Simp. Mod. High -EFT SR8 -Simp. Mod. SR8 -EFT Table  4 : Maximum number of events populating the most relevant signal regions of the CMS-TOP-18-003 analysis and the high-H T additional region proposed in this work. We show the observed limits from LHC run 2 data at 95% C. L. , together with the expected projections at the HL-LHC assuming a linear scaling of the number of events and their errors with the luminosity. consider scenarios with a coupling value set to either 0. 1, 0.
3. 2 (dotted lines). We consider (a) g 1L = g 1R as a function of M V1 for a vector singlet simplified model, and (b) g 8L = g 8R as a function of M V8 for a vector octet model. We include results extracted from LHC run 2 data and our projections for the HL-LHC, the regions above the curves being excluded in both cases. The K-factor is fixed at 1. The grey exclusions represent the parameter space regions in which the width of the top-philic particle is too large, making our approach unreliable. that leads to a very large cross section for masses smaller than about 1 TeV. Our results improve those derived in the earlier analysis of ref. [32] , which was based on the reinterpretation of the results of the LHC for a smaller dataset, including only a luminosity of 35. 9 fb -1. Moreover, in this particular pair-production-driven regime, one can confidently consider that the aggressive limit obtained when using a K-factor of K = 2 is valid, as explained and computed in ref.
B Some technical details on event generation We generate all required four-top samples using the MadGraph5 aMC@NLO framework. The UFO model files for each simplified models have been made available in the FeynRules model database (https://feynrules. irmp. ucl. ac. be/wiki/ModelDatabaseMainPage). We generate events by including all interference terms with the EW contributions to SM four-top production by typing in the MadGraph5 aMC@NLO interpreter g e n e r a t e p p > t t∼ t t∼ NPˆ2>0 QCD=4 QED=2 Once the process folder has been created, we implement our choice of renormalisation and factorisation scales as a user-defined dynamical scale directly in the file setscales. f. We use r s c a l e=d s q r t (max( 0 d0 , 2 d0 * dot (P ( 0 , 1 ) , P ( 0 , 2 ) ) ) ) / 2 The CMS-TOP-18-003 analysis that we have recast is available from the MadAnalysis 5 Public Analysis Database at https://madanalysis.
Acknowledgments We are thankful to  Eleni Vryonidou  and  Gauthier Durieux  for comments on the manuscript and many enlightening discussions. LD and FM are supported by the  INFN "Iniziativa Specifica" Theoretical Astroparticle Physics (TAsP-LNF ) and QFT@Colliders, respectively. FM acknowledges the support of the  F. R. S. -FNRS  under the  Excellence of Science EOS  be. h project n. 30820817.