dataesr/scientific-paragraphs-categorization huggingface dataset:
e. , the key "things" in the Web Ontology Language (OWL) sense, that acts as interoperability pivot by linking one dataset to another. These interoperability pivots, shared between datasets, enable the construction of datalinks and must be unambiguously identified and curated in each data repository. Pivot identifiers must be shared among repositories to enable data interoperability and build a working information system federation. Indeed, phenotyping experiments can be carried out for a wide range of scientific objectives (e. g. , study of the impact of climate change, study of the genetic architecture of traits) with different types of underlying analyses that impact the nature of datasets. The consistency of the datasets is ensured through the integration of the data collected from the different experiments, which is achieved by building links between some clearly described and identified pivots.
A common example is the integration of genotyping and phenotyping datasets obtained with the same panel of individuals in distinct experiments in order to search for marker-trait associations. In this case, individuals of the panel in each dataset provide the pivot required to enable interdataset integration. Other examples of interoperability pivot are the Global Positioning System (GPS) localization of plants (e. g. , integration of climatic and phenotyping datasets) or the observation variables (e. g. , integration of several phenotyping datasets). When managing and therefore integrating research data in any Phenotype Information System, the objectives of the data services to be provided must be considered. For instance, the MaizeGDB  [18]  database gives access to phenotypic data in the context of functional genomics studies by offering very elaborated phenotype without experimentation environment data.
Genomes To Fields (https://www. genomes2fields. org [19] ) and the Triticeae Toolbox  [20]  offer more trial centric portals for, respectively, the US maize and the US Triticeae communities. All these repositories allow sharing and publishing curated datasets but neither data discovery nor multitrial data integration. There are also a number of trial-centric databases whose objectives are to capture all the steps of the data production of platforms, like PhenopsisDB  [21] , the Integrated Breeding Platform (IBP, https://www. integratedbreeding. net), Phenomics Ontology Driven Database (PODD)  [22] , or the Phenomic Hybrid Information System of the Phenome-Emphasis (https://www. phenome-emphasis. fr/) infrastructure (PHIS, http://www. phis. inra. fr) [23]. This latter database, PHIS, is specifically designed for addressing the challenges of data acquisition in high throughput phenotyping platforms.
GnpIS  [24]  (http://urgi. versailles. inra. fr/gnpis) is an international information system that links phenomic, genetic, and genomic data (see examples in  [25, 26] ) for plant and their pathogens. It is the French National Institute for Agricultural Research (INRA) phenotyping archive which has been designed to publish and integrate standardized data from phenotyping trials carried out in natural sites, field, or controlled environments, with observations at different physical scales like groups of plants, single plants, single organs, or tissues. It gives access to standardized data and enables the development of federations of repositories.
Material and Methods The GnpIS software component dedicated to phenotyping, named GnpIS-Ephesis, is based on a four layers' architecture, Plant Phenomics 3 described in the result section: storage, data discovery, query, and web interface. The storage layer of GnpIS-Ephesis is implemented in PostgreSQL 9. 6 running in a 2-core 4 Gb Virtual Machine plus file-system access through simple HTTP GET requests for direct file download. The query layer is based on Elasticsearch 2. 3 running on Java 7 in two 8-core 16Gb RAM Virtual Machines. It allows precise, field-by-field, data querying and processing. Its native Representational State Transfer (REST) API is hidden behind a service business layer for security and ease of querying. Its API is queried either by Google Web Toolkit Remote Procedure Call (GWT RPC) or by a REST Web Service API.
This Web service layer is written in Java/JEE using Jersey 1. 18+ and Spring 2. 5. The Extract Transform Load (ETL) tools allowing for feeding the query layer from the storage layer are written in scripted PostgreSQL specific JSON-SQL queries orchestrated by a Shell tool suite. The data integration and insertion toolbox is developed with the Talend Open Studio (http://www. talend. com/) Extract Transform Load (ETL) tool version 6, plus some Shell and Python scripts. The ontology repository is based on a public Gitlab project running on the INRA forge (https://forgemia. inra. fr/ urgi-is/ontologies) which allows versioning of the ontologies plus a graphical widget giving access to their last versions. The Ontology Widget (https://github. com/gnpis/trait-ontologywidget) is written in JavaScript and uses the JQuery (https:// jquery.
com/) and JStree (https://www. jstree. com/) libraries. The Web interfaces are running on a Tomcat 7 instance using Java 7 in a dedicated Virtual Machine with 2 cores and 16Gb of RAM. They are developed in Java 7 using the GWT framework. The geographic map overview is powered by Leaflet (https://leafletjs. com/) with OpenStreetMap (https://www. openstreetmap. org/) as map backend. The web user interfaces are open source under BSD3 license and available upon request. The database model of the storage layer is under a proprietary license and is protected by deposits in at the European program deposit agency (Agence de Protection des Programmes).
Results GnpIS is a repository for phenotyping experiments, i. e. , Trials, at various physical and temporal scales. It has been developed within the GnpIS-Ephesis project which gave its name to the software modules of GnpIS dedicated to phenotyping. The experimental data may be associated with measurement time, hence creating time series. Data can be raw or computed, organized in textual data matrices of physical measures possibly derived from sensors, phenological observations, or concentrations for a few dozens of biochemical components. Those data matrices are inserted in the storage database together with additional information like factors, cofactors, timing, location, and other trial parameters description. In some cases, such as dense time series with up to hundreds of measures, multispectral images, or Near Infrared Spectrometry (NIRS) spectra, the data can be stored as files (with a size limit of few Gb by Trial) or can be cross-referenced to specialized platform information systems.
It is designed to allow data access either by full experiment or by aggregating data across several experiments. It also allows the linking of phenotypic data with genetic and genomic data for Quantitative Trait Loci (QTLs), Genome Wide Association Studies (GWAS), and gene annotations published in GnpIS. GnpIS currently stores data for the French National Institute for Agricultural Research (INRA) and its national and international partners. It is the official repository of the International Wheat Genome Sequencing Consortium  [25]  and it is included in emerging international federations of information systems in the frame of the Elixir plant community (https://www. elixir-europe. org/ communities/plant-sciences), the French node of the Emphasis European infrastructure for plant phenotyping (https:// www.
GnpIS Phenotyping Data Model. Phenotyping data is handled in GnpIS through the GnpIS-Ephesis conceptual data model (Figure  1 ). It has been designed in close collaboration with field scientists, experts in plant phenomics, geneticists, and breeders, many of them being particularly interested in deciphering genotype by environment interactions. It has been designed for flexibility, to allow both the retrieval of individual datasets and the combination of different subsets for meta-analysis. It relies on three main components: (i) the main dataset containing the description of the trial and the observation units (Figure  1 ) as well as the observation values, (ii) the observation variables, and (iii) the identification of plant material assayed. Those three components act as independent but linked subdatasets.
Trial, Trial Set, Observation Unit, and Observation. Figure  2  shows a typical phenotyping dataset and how it is integrated in GnpIS through four main concepts: Trial Set, Trial, Observation Unit, and Observation. The Trial and Trial Set handle most of the experiment metadata. A trial is an experiment under field or controlled conditions (greenhouse, culture chamber. ), in a single location and possibly on multiple years. This allows for handling series of yearly observations for perennial plants, possibly over several decades. Note that, in this case, the plant material list is stable from one year to another. The Observation Unit in GnpIS and MIAPPE v1. 1 is the object, i. e. , the scale or level, on which the measurements or observations are done (Figure  1 ; example in Figure  2(B) ).
Plant Material. The phenotyped plant material, or germplasm, is the main interoperability pivot in GnpIS. Its correct identification varies depending on the context, but this problem has been discussed for several decades now and is addressed by an internationally recognized data standard, the Multi Crop Passport Descriptors (MCPD)  [31]. Its importance and possible related issues are described in the study by Adam-Blondon et al. [13]. GnpIS is MCPD compliant and slightly extends it to fit the needs of its communities of users. In particular, our system handles experimental material that is not conserved in Genbanks as well as the concept of Lot which is a group of seeds or plant derived from a single accession. The identification of accessions in the MCPD relies on a triplet of information: the accession number, the holding institution, and the genus plus optional species.
The Accession Number is the actual identifier of the plant material and must be unique in the holding institution and genus namespace. This triplet is now completed in GnpIS by a permanent unique identifier through a DOI or an URI (Unified Resource Identifier), as recommended by the FAO (International Treaty on Plant Genetic Resources citation). Those permanent unique identifiers are unique at the scale of the World Wide Web. This allows for storing a comprehensive description of the plant material at different levels: identification of the accession of a germplasm collection and of a derived seed lot used in an experiment and the corresponding variety name. For instance, in a Zea maize trial, the variety B73 would have been provided by the INRA maize collection under the accession identifier B73 inra and the B73 inra SMH08 seed lot was experimented.
Software Architecture. An overview of the software architecture of GnpIS-Ephesis is given in Figure  3. Its originality is to isolate the long-term storage of the data from the query Plant Phenomics layer, which is specific to the current web services and user interfaces. Furthermore, the user interface and the query layer are connected through web services and inspired by the microservice architecture. The storage layer consists of (i) a relational database which implements the conceptual data model and stores the two-dimensional data matrices and (ii) a file repository that stores data files such as images, global description of cultural practices, soil characteristics, NIRS results, and ontologies. The storage layer uncouples components of the phenotyping datasets to ease data curation and update.
This is fully implemented for observation variables where datasets are stored in the database and ontologies in the file repository as seen in Figure  3. This allows for updating the ontologies without interfering with the Trials storage. The storage layer relational model is almost fully normalized (in the third normal form) which makes it efficient for storing consistent data on the long term but difficult to optimize for fast querying. Indeed, filtering the data or rebuilding the data matrix for export involves SQL joins between the Observation Unit table (more than 360 000 rows in 2018) and the Phenotype table (near 4 million rows in 2018), plus most of the other tables of the model. This join is costly even with fine-tuned indices such as composite indices or programmatic optimizations, i.
e. , using several light queries rather than one expensive query. To address this problem, we have explored data denormalization with a pure SQL approach. This proved to be efficient for the expected volumes but was not flexible enough to handle heterogeneous phenotyping data, in particular with respect to the varying width of the data matrices. Furthermore, NoSQL systems allow much easier horizontal scaling to cope with data volume increases. The phenotype query layer was therefore introduced as a document-oriented NoSQL system based on Elasticsearch. Trial and Observation Unit documents are aggregating all the data necessary for querying, filtering, displaying, and exporting whole datasets. This document structure is based on the denormalization of the first normal form  [33]  by aggregating several objects in a single document.
Web User Interface. GnpIS provides phenotyping data discovery capabilities and data aggregation among several datasets. The dedicated query form, available in the phenotyping section of GnpIS (https://urgi. versailles. inra. fr/ gnpis/), is based on three tabs: (i) "Genotype" for filtering the plant material by species, genetic panel, and collections, (ii) "Observation variables" that allows variables selection using a Breeding API compliant open source widget (https://github. com/gnpis/trait-ontology-widget), and (iii) "Trial" that contains filters for general metadata like the Phenotyping Campaign, i. e. , Year, the location, the datasets list, or project filtering. The trait-ontology-widget (Figure  3 ) provides a biologist friendly tree navigation and keyword search in the ontologies and displays the full details of each variable.
Data Management. GnpIS data publication and integration process includes both a data review step by data managers and an automated validation step to ensure a good balance between data submission ease and data quality. It starts by filling a tabular exchange format available through the web application. This format is the result of several years of collaboration with biology experts including geneticists, agronomists, genotype by environment specialists, researchers, and experimentation managers all working on annual or perennial plant, including forest trees. This exchange format has been designed to be both human and machine readable. This allows data validation and curation by data producers as well as efficient and reliable parsing before database insertion. When submitting a dataset, the users must first consolidate their interoperability pivots.
Discussion The phenotyping data life cycle main steps are data collection, quality control including curation and cleaning, analysis, publication, sharing, and finally reuse. GnpIS mainly supports the three last steps while, for instance, the recently published PHIS  [23]  supports mainly the first three. Experimentation datasets usually include three types of data: (i) raw untransformed data (images, multispectral images, NIRS, frequencies, etc. ) which are transformed into (ii) raw transformed data (in International System units, including dates) and finally (iii) elaborated or derived data (stress resistance, biomass, leaf area index, etc. ). Depending on the needs, data of the second and third types can be directly managed in GnpIS whose data model has been designed to handle both field and greenhouse experimental data.
How FAIR Is GnpIS? Currently, phenotyping data in GnpIS implements mainly the "FAIR for the human" as described in the study by Wilkinson et al. [36]. It is well advanced and allows a good traceability of the data acquisition methods, of its transformation, and experimentation factors. But that information still needs to be expressed with more advanced formalisms to enable FAIR machine readability and to improve the quality of the metadata. Indeed, enabling FAIRness for machines would in particular imply the use of semantic formats, i. e. , Resource Description Framework (RDF) and JSON-LD. It is a complex objective that is not only technical but would require an evaluation of the FAIRness of each of the datasets integrated in GnpIS, which is not yet done. In addition, the linked data principles  [17]  state that every resource must be correctly identified with an HTTP URI, described in RDF, and linked to other resources.
This has been partially implemented in GnpIS: the interoperability pivots (Variables, Accessions, and Datasets) are linked to other resources with permanent unique IDs but only the accessions and some datasets have DOIs or URIs. Nonetheless, with the right namespace, GnpIS IDs are unique at the scale of the World Wide Web and therefore provide a strong basis for future full enabling of linked data in GnpIS. The interoperability of GnpIS with other databases is ensured by REST Open APIs, and especially the increasingly adopted Breeding API. REST is well integrated with the current web application development ecosystem. As a consequence, RDF is not planned to be used directly as the main medium for linked data in GnpIS, which will rather be enabled through extension of those APIs using the JSON-LD semantic format, hence enabling the conversion to RDF.
A proof of concept has been realized with a Wheat dataset available in a dedicated triple store and as a downloadable RDF file (see link to data in the DOI of  [37] ). Findability of the datasets by users is enabled through indexing rich metadata and fast querying mechanisms. Accessibility is guaranteed by long-term storage associated with open technologies (HTTP REST) and format (CSV, JSON, and ISATab). The license is by default Creative Commons (CC-BY 4) and can be modified through a DOI associated with specific datasets. Interoperability in GnpIS also relies on data curation and integration aiming at the unambiguous identification of the pivot data and the use of standard formats for metadata descriptions and vocabularies, which is a costly effort  [38]. In our experience, the most difficult points are the correct identification of the plant material and the development of the appropriate Crop Ontology variable list when it does not exist yet.
This curation process is greatly eased by the uncoupling of the datasets and the ontologies which allow seamless updates of the variable ontologies. Indeed, upgrading an ontology version, or switching back to a previous version in case of problems, can be done in less than an hour by a data manager. The Crop Ontology community is also working on easing the process of building and enriching ontologies from information systems like Cassavabase  [39]  which provides a web form for creating or requesting new variables. The use of the CO approach and trait dictionary format to submit Observation Variables in GnpIS has two objectives. The first one is to guide and capture agreements within a research network on measurement methods which allows consistent data collection and analysis. The originality of the Crop Ontology approach  [40]  is to build a set of species specific, or clade-specific, variable ontologies, rather than building a global variable ontology, which would be difficult if not irrelevant.
Therefore, the second objective is to focus on a better standardized list of traits and to let communities freely create methods and variables adapted to their research. This work has begun within the Planteome initiative, and could be extended by publishing common Trait lists. To ease this process, we are considering maintaining two sets of ontologies for some species, one to address the specific needs of GnpIS communities and to act as a clearing house for variable curation and validation and the other which is much broader and therefore published on references portals. With this pragmatic approach, the FAIRness of the datasets is ensured either by annotating with existing ontologies, published in Crop Ontology, or by creating ad hoc ontologies following the proven CO model. Particular Observation Variables use cases needed some adaptations of the recommendations of the Crop Ontology while keeping semantic interoperability.
2 and Canker length. 1). This example can be found with the Trial Code "POP2-Orleans-chancre". This way, any variable necessary for a given experiment can be freely created as long as it is linked to a variable existing in a crop ontology. In the future, those specific variables could be simple text description annotated with IDs taken from several reference ontologies (e. g. , Plant Environmental Condition Ontology for the treatment part, Plant Ontology for the growth stage part,. ). Curation of the plant material identifiers is more difficult to achieve. Indeed, while the MCPD standard provides identification principles, their application is community-based and cannot be automated for the moment. Currently, the plant material ID curation is a prerequisite for each dataset integration and publication in collaboration with the data providers.
Once achieved, GnpIS associates with each accession a DOI generated by INRA to ensure a good traceability of the plant material and an unambiguous identification across any federation of information systems. This curation process, however, can introduce a delay in data publication. Reusability in GnpIS varies from one phenotype dataset to the other. Data is generally available in easily parsable standard open formats: OpenAPI (BrAPI), JSON, and MIAPPE compliant Isa Tab or csv. They are currently being improved to better handle traceability of environment parameters and field practices. This type of data can currently be handled in GnpIS through variables like lodging or hail storm dates, comments on each variable or files describing field practices attached to the Trial. There is, however, no clear standard way yet proposed in GnpIS for this type of data.
Since they are very important on the long term for meta-analysis, their submission should be facilitated in the future through a full upgrade of GnpIS to MIAPPE v1. 1. Finally, the documentation of the provenance of the dataset, including measurement methods and data processing, is only partial and varies too much. The use of dedicated systems like the Phenotyping Hybrid Information System (PHIS) by the data producers would certainly facilitate the capture of all the metadata and their MIAPPE compliant publication in GnpIS.
The importance of the implication of end users is well demonstrated in the collaboration with the Crop Ontology. Indeed, the biologist friendly framework built within this initiative and based on the CGIAR experience has been easily adopted by GnpIS and Elixir Plant communities. This greatly helped to improve the quality of our datasets and in turn will open collaborations with large initiatives in the domain of plant ontologies like Planteome or Agroportal. The implementation of these standards in GnpIS together with data curation efforts in collaboration with the data producers have been instrumental to ensure GnpIS interoperability at a larger scale. Indeed, GnpIS is included in international data repositories federations including Elixir plant community, Emphasis (https://emphasis. plantphenotyping.