dataesr/scientific-paragraphs-categorization huggingface dataset:
Automated verification of STA Figure  12  shows the number of transits processed by STA and their distribution as a function of G ext RVS. AVSTA (Fig. 2 ) verifies the quality of the single-transit radial velocities V t R (i. e. sV t R corrected for the barycentric velocity as in Eq. 13). For this purpose, a verification dataset is extracted from the ∼ 78 million of V t R obtained by the pipeline (Fig. 12 ), which contains only the stars belonging to the auxiliary radial velocity catalogues (Table  1 ) and covers the magnitude range of the DR2 data (Fig. 3 ). These stars are expected to be constant. The radial velocities obtained by the pipeline (V t R ) are compared with those in the catalogues (V ref R ).
Monitoring the quality of the upstream processing The verification of the radial velocities permits the indirect verification of the performance of the upstream processing, in particular, of the wavelength-calibration performance. For this check, the subset of the verification-dataset containing only the stars belonging to CU6GB-cal (Table  1 ) is used. The V ref R of the stars in CU6GB-cal are assumed to be perfectly determined (their uncertainties of < 0. 1 km s -1 are neglected), and being used to calibrate the wavelength-calibration zeropoint, should show no systematic shift with the RVS velocities. Any difference is then introduced by the processing, including the upstream AGIS pipeline on which the spectroscopic pipeline is dependent (Sect. 3). The precision of the single-transit radial velocities, indicative of random uncertainties, is quantified by the robust standard deviation of the residuals: σ(∆V t R ) (see Eq.
Dependence on the instrumental configuration The subset of the verification-dataset, containing only stars belonging to CU6GB-cal, is used to estimate the systematic differences in the V t R depending on the CCD row and on the FoV of the transit (the stars are observed in FoV1 and FoV2, the FoVs of the two telescopes, and in general, in a different CCD row at each transit). The mean, median, and robust standard deviations of the residuals ∆V t R were obtained over the entire period covered by DR2 for each configuration FoV-CCDrow. 3), the overall small systematic shift is ∼ -0. 01 km s -1 , showing that no zeropoint shift between the RVS V t R and the V ref R in CU6GB-cal is introduced by the processing overall; the temporal evolution of the shift for all configurations together is shown in Fig.
Comparison with the auxiliary catalogues The entire verification dataset is used (and not only the subset of CU6GB-cal stars) to estimate the performance of the V t R mea-surements. RAVE and APOGEE cover fainter magnitudes than CU6GB-cal (Fig. 3 ), and permit verifying the accuracy and precision of V t R up to G ext RVS ∼ 12. The accuracy and the precision of the V t R are quantified by Md(∆V t R ) and σ(∆V t R ), respectively, as described in Sect. 7. 8. 2. The results for the stars belonging to APOGEE are an overall accuracy of ∼ 0. 2 km s -1 , an overall precision of ∼ 1. 8 km s -1 , and for the stars belonging to RAVE, an overall accuracy of ∼ 0. 3 km s -1 and an overall precision of ∼ 1. 4 km s -1. The uncertainties on the APOGEE and RAVE V ref R are larger than those of CU6GB-cal and contribute to the estimation of the accuracy.
Radial velocity results Various diagnostics are implemented in the automated verification AVMTA (Fig. 2 ) to automatically verify the median radial velocity results produced by the MTA for each star from the total of its transits. In the same way as for the single-transit radial velocities, a verification dataset is defined that contains only stars for which we also have a ground-based radial velocity in the auxiliary external catalogues (Table  1 ). The verification dataset covers the magnitude range of the RVS data (Fig. 3 ), but does not contain early-type or late-M stars. Table  4  lists the measurements performed by AVMTA.
Overall accuracy The accuracy indicates the systematic uncertainty. It is estimated using the verification dataset by calculating the difference between the RVS and the external catalogue measurements. In Table  4 , Md(∆V R ) is the median value of the residuals, calculated over the entire period covered by DR2 for the stars belonging to each catalogue in the verification dataset. The residuals ∆V R =V R -V ref R are the differences between the median radial velocity obtained by the pipeline (Eq. 17) and those of the external catalogues (V ref R ) and contain both the catalogue and the RVS uncertainties. They are in good agreement with the median residuals Md(∆V t R ) obtained with the single-transit radial velocities V t R and indicate the overall shift between the RVS and the other catalogues.
Overall precision The precision indicates random uncertainties. In Table  4  the overall precision of the RVS V R measurements is quantified using the verification dataset with σ(∆V R ) and Md(σ MTA V R ) calculated over the 22 months covered by DR2. σ(∆V R ) is the robust dispersion (see Eq. 12) of the residuals for the stars belonging to the different catalogues of the verification dataset. When we assume negligible uncertainties in the external catalogues, it is an indicator of the overall precision of the RVS measurements and is called external precision (this includes the precision of the external catalogue measurements). Md(σ MTA V R ) is the overall internal precision, which is also shown in Table  4 , where σ MTA V R is estimated in the pipeline (Eq. 18). The internal precision is independent of the external catalogue uncertainty and depends on the dispersion of the RVS measurements.
It also depends on the magnitude of the stars: it is higher for CU6GB-cal and XHip, which are dominated by bright stars (see Fig. 3 ) and lower for RAVE and APOGEE, which contain fainter stars. The CU6GB-cal V ref R are more precise (σ < 0. 1; Table1) and are also expected to be more accurate than the other external catalogues. For these stars the agreement between the external P. Sartoretti et al. : Gaia Data Release 2 and the internal precision is reached by adding 0. 11 km s -1 in quadrature to the internal estimation. This shift is interpreted as a calibration floor. After the pipeline processing was completed, it was added quadratically to the MTA uncertainty (Eq. 19) to improve their estimation in a post-processing phase. Figure  17  shows the internal precision as a function of G ext RVS for the ∼ 10 million V R produced by the pipeline (not only those in the verification dataset: SB1 and variable stars are included).
Off-line validation When the processing of the data was completed and Automated Verification confirmed that the overall accuracy and precision of the V R met the requirements, a validation campaign started on the ∼ 10 million V R produced by the pipeline. Its purpose was to analyse the global properties of the dataset and identify the V R without sufficient quality to be published in DR2  (Katz et al. 2018). The exclusion criteria include those mentioned in previous sections, which are hot (T tpl eff ≥ 7000 K) and cool stars (T tpl eff ≤ 3500 K), see also Sec. 6. 5, suspected SB2 detected as double-lined in 90% of the transits, emission-line stars, and stars that are too faint (G int RVS > 14), stars for which the V t R has been detected as ambiguous (Sect. 7. 7) in all transits. Excluded from DR2 are also the V R for which σ V R ≥ 20 km s -1 , and ∼ 400 outliers V R ≥ 500 km s -1 that were obtained with poor-quality spectra.
Acknowledgements. We thank the referee,  Johannes Andersen , for his constructive comments. This work has made use of results from the  European Space Agency (ESA) space mission Gaia , the data from which were processed by the  Gaia Data Processing and Analysis Consortium (DPAC). Funding for the DPAC has been provided by national institutions, in particular the institutions participating in the Gaia Multilateral Agreement. The Gaia mission website is http://www. cosmos. esa. int/gaia. Most of the authors are current or past members of the  ESA Gaia mission team and of the Gaia DPAC  and their work has been supported by the  French Centre National de la Recherche Scientifique (CNRS) , the  Centre National d' Etudes Spatiales (CNES) , the  L'Agence Nationale de la Recherche , the  Région Aquitaine , the  Université de Bordeaux , the  Utinam Institute of the Université de Franche-Comté , and the  Institut des Sciences de l' Univers (INSU) ; the  Science and Technology Facilities Council  and the  United Kingdom Space Agency ; the  Belgian Federal Science Policy Office (BELSPO)  through various  Programme de Développement d'Expériences Scientifiques (PRODEX)  grants; the  German Aerospace Agency (Deutsches Zentrum fur Luft -und Raumfahrt e.
V. , DLR); the  Algerian Centre de Recherche en Astronomie, Astrophysique et Géophysique of Bouzareah Observatory ; the  Swiss State Secretariat for Education, Research, and Innovation  through the  ESA PRODEX programme , the  Mesures d'Accompagnement , the  Swiss Activités Nationales Complémentaires , and the  Swiss National Science Foundation ; the  Slovenian Research Agency  (research core funding No. P1-0188 ). This research has made use of the SIMBAD database (Wenger et al. 2000) developed and operated at  CDS, Strasbourg, France.
, 2015)  in 88% of random cases is largely higher than that introduced by the method reported in  (Gammoudi et al. , 2015). To show that the pack solution, proposed in  (Gammoudi et al. , 2015) , can be implemented in a real application, the work reported in  (Gammoudi et al. , 2016a)  proposes a new reconfigurable middleware, named Recon f -Middleware, that presents a plugin implemented in RTLinux and describes the transition from the pack theory to the implementation. An extension of the technique reported in  (Gammoudi et al. , 2015)  to homogeneous multi-core platforms is described in  (Gammoudi et al. , 2016b). The authors propose four solutions to schedule a real-time application composed of independent periodic tasks under energy constraints. Nevertheless, they do not consider the scheduling of dependent tasks onto heterogeneous platforms and they do not treat the influence of the task mapping on the communication and therefore on the energy consumption.
Introduction Agronomy, food, plant sciences, and biodiversity are complementary scientific disciplines that benefit from integrating the data they generate into meaningful information and interoperable knowledge. Undeniably, data integration and semantic interoperability enable new scientific discoveries through merging diverse datasets  (Goble and Stevens, 2008). A key aspect in addressing semantic interoperability is the use of ontologies as a common and shared means to describe data, make them interoperable, and annotate them to build structured and formalized knowledge. Biomedicine has always been a leading domain encouraging semantic interoperability  (Rubin et al. , 2008). The domain has seen success stories such as the Gene Ontology  (Ashburner et al. , 2000) , widely used to annotate genes and their products.
, 2012). Communities engaged in agronomic research often need to access specific sets of ontologies for data annotation and integration. For instance, plant genomics produces a large quantity of data (annotated genomes), and ontologies are used to build databases to facilitate cross-species comparisons  (Jaiswal, 2011). More recently, the focus of many scientific challenges in plant breeding has switched from genetics to phenotyping, and standard traits/phenotypes vocabularies have become necessary to facilitate breeders' data integration and comparison. In parallel with very specific crop dictionaries  (Shrestha et al. , 2010) , important organizations have produced large reference vocabularies such as Agrovoc (Food and Agriculture Organization)  (Sachit Rajbhandari, 2012) , the NAL Thesaurus (National Agricultural Library), and the CAB Thesaurus (Centre for Agricultural Bioscience International).
1 These thesauri are primarily used to index information resources and databases. As more vocabularies and ontologies 2 are produced in the domain, the greater the need to discover them, evaluate them, and manage their alignments  (d'Aquin and Noy, 2012). However, while great efforts have taken place in the biomedical domain to harmonize content (e. g. , the Unified Medical Language System (UMLS), mostly for medical terminologies)  (Bodenreider, 2004)  and ontology design principles (e. g. , the OBO Foundry, containing mostly biological and biomedical ontologies)  (Smith et al. , 2007) , ontologies in agriculture are spread out around the web (or even unshared), in many different formats and artifact types, and with different structures. Agronomy (and its related domains such as food, plant sciences, and biodiversity) needs an one-stop shop, allowing users to identify and select ontologies for specific tasks, as well as offering generic services to exploit them in search, annotation or other scientific data management processes.
The need is also for a community-oriented platform that will enable ontology developers and users to meet and discuss their respective opinions and wishes. This need was clearly expressed by stakeholders in various roles (developers, database maintainers, and researchers) across many community meetings, such as: 1st International Workshop for Semantics for Biodiversity in 2013 (http://semanticbiodiversity. mpl. ird. fr) (Larmande et al. , 2013) ; the "Improving Semantics in Agriculture" workshop in 2015  (Baker et al. , 2015) ; or several meetings of the Agricultural Data Interest Group (IGAD) of the Research Data Alliance. These motivations prompted us to build a vocabulary and ontology repository to address these needs. In this paper, we present the AgroPortal project, a community effort started by the Montpellier scientific community to build an ontology repository for the agronomy domain.
Our goal is to facilitate the adoption of metadata and semantics to facilitate open science in agronomy. By enabling straightforward use of agronomical ontologies, we let data managers and researchers focus on their tasks, without requiring them to deal with the complex engineering work needed for ontology management. AgroPortal offers a robust and reliable service to the community that provides ontology hosting, search, versioning, visualization, comment, and recommendation; enables semantic annotation; stores and exploits ontology alignments; and enables interoperation with the semantic web. Our vision is to facilitate the integrated use of all vocabularies and ontologies related to agriculture, regardless of their source, format, or content type. In order to capitalize on what is already available in other communities, we have reused the openly available NCBO BioPortal technology (http://bioportal.
, 2013). An important aspect is that NCBO technology  (Whetzel and Team, 2013 ) is domain-independent and open source. A BioPortal virtual appliance 9  is available as a server machine embedding the complete code and deployment environment, allowing anyone to set up a local ontology repository and customize it. It is important to note that the NCBO Virtual Appliance has been quite regularly reused by organizations which needed to use services like the NCBO Annotator but, for privacy reason, had to process the data in house. Via the Virtual Appliance, NCBO technology has already been adopted for different ontology repositories in related domains and was also chosen as foundational software of the Open Ontology Repository Initiative  (Baclawski and Schneider, 2009). The Marine Metadata Interoperability Ontology Registry and Repository  (Rueda et al.
A web Application Programming Interface (API) provides all necessary services to third party users like the Global Evaluation Trials Database, currently storing 35,000 trial records. Efforts have been made to structure and formalize the crop-specific ontologies following semantic web standards (using the Web Ontology Language (OWL)), as well as offering collaborative ontology enrichment and annotation features. The current Crop Ontology web application facilitates the ontology-engineering life cycle  (Noy et al. , 2010) , starting with collaborative construction, publishing, use and modification. However, it would require important improvements such as: versioning, community features, multilingual aspects, visualization, data annotation, and mapping services. For instance, it is important to support the alignment (or mapping) of terms within and across different ontologies both within the Crop Ontology itself (in different crop branch) and with other top level ontologies commonly used in plant biology, like the Plant Ontology, Plant Trait Ontology, Plant Environment Ontology, Plant Stress Ontology all maintained and extended within the Planteome project  (Jaiswal et al.
, 2016). The Planteome platform (www. planteome. org) is reusing the Gene Ontology project AmiGO technology  (Carbon et al. , 2009)  to build a database of searchable and browsable annotations for plant traits, phenotypes, diseases, genomes, gene expression data across a wide range of plant species. The project focuses on developing reference ontologies for plant and on integrating annotated data within the platform. Their objective is slightly different than AgroPortal's objective, and the scope is not as large as the one we envision for AgroPortal.
agrold. org) (Venkatesan et al. , 2015). Launched in May 2015, it serves as a platform to consolidate distributed information and facilitate formulation of research hypotheses. AgroLD offers information on genes, proteins, Gene Ontology Associations, homology predictions, metabolic pathways, plant traits, and germplasm, on the following species: rice, wheat, arabidopsis, sorghum and maize. We provide integrated agronomic data, as well as the infrastructure to aid domain experts answering relevant biological questions (for example, "identify wheat proteins that are involved in root development"). AgroLD relies on RDF and SPARQL technologies for information modelling and retrieval, and uses OpenLink Virtuoso (version 7. 1) triple store. Database contents were parsed and converted into RDF using a semi-automated pipeline implemented in Python (https://github.
com/SouthGreenPlatform/ AgroLD). The conceptual framework for knowledge in AgroLD is based on well-established ontologies in plant sciences such as Gene Ontology, Sequence Ontology, Plant Ontology, Crop Ontology and Plant Environment Ontology. AgroLD needs a dedicated application programming interface to these ontologies, as well as a means to annotate database fields (header and values) with ontology concepts. In addition, it requires a system to store mappings annotations between key entities in the AgroLD knowledge base and reference ontologies. In the longterm vision for AgroPortal and AgroLD, the former might be an entry point to the knowledge stored in AgroLD, enabling users to easily query and locate data annotated with ontologies. Wheat is a major source of calories and protein, especially for consumers in developing countries, and thus plays an important socioeconomical role.
This includes spreadsheet annotation tools such as OntoMaton  (Maguire et al. , 2013)  Weboulous  (Jupp et al. , 2015) , RightField  (Wolstencroft et al. , 2010)  and WebSmatch  (Coletta et al. , 2012; Castanier et al. , 2014) ; Zooma, a tool similar to the Annotator developed by the European Bioinformatics Institute (www. ebi. ac. uk/spot/zooma); the UIMA wrapper to use the Annotator web service in other NLP applications  (Roeder et al. , 2010) ; the ontology wrapper OntoCAT  (Adamusiak et al. , 2010) ; the Galaxy platform tools  (Miñarro-Giménez et al. , 2012) ; the visualization tool FlexViz  (Falconer et al. , 2009) ; and finally all the different API clients (Java, Ruby, Perl, etc. ) developed by the NCBO (https://github. com/ ncbo) or other organizations (e. g. REDCap or Protégé plugins).
New AgroPortal features developped since the beginning of the project While assuring community support, day-to-day maintenance and monitoring of the portal and keeping it up-to-date with the NCBO technology, we have worked on customizations and specific services. These services target the agronomic community, but that could in some cases be used for any domains. With the vision of collaborative development of BioPortal and AgroPortal, when relevant and possible, we push new features back to the main NCBO code branch where BioPortal users or the appliance itself can benefit. The AgroPortal open source code and documentation are accessible on GitHub: https:// github. com/agroportal.
g. , metrics, endpoints, links, examples). Ontology developers can manually update those extracted or calculated values if desired. In addition, we have entirely redesigned AgroPortal's ontology submission page to facilitate editing the metadata. Whenever possible, the user interface facilitates the selection of the metadata values, while in the backend those values are stored with standard URIs. For instance, the user interface will offer a pop-up menu to select the relevant license (CC, BSD, etc. ) while the corresponding URI will be taken from the RDFLicense dataset (http://rdflicense. appspot. com). Knowledge organization systems types are taken from the KOS Types Vocabulary from the Dublin Core initiative. 25 n example using the OntoBiotope ontology metadata page in AgroPortal is shown in Fig.
Agronomic Linked Data (AgroLD) The OWL versions of the ontologies available in AgroPortal were retrieved from that single repository. Although AgroPortal is not the main original location for these ontologies (they are accessible on the OBO Foundry and Cropontoloy. org) it was convenient to find them all in one place, and to use a unique and consistent API. Plus, we also used the AgroPortal Annotator web service to annotate more than 50 datasets and produced 22% additional triples, which were validated manually (Fig. 4 ). Building such an annotation service for all these ontologies was one of the driving needs for AgroPortal. Encoding the original data in RDF allowed us to establish an annotation for every appropriate case, using owl:sameAs relations, between the data element (e. g. , Protein in the SouthGreen database) defined with a new URI (http://www.
southgreen. fr/agrold/resource/Protein) and an ontology term (e. g. , the term 'polypeptide' in the Sequence Ontology (http://purl. obolibrary. org/obo/SO_0000104). Note that we have decided to use owl:sameAs in this case as the resources are logically equivalent and this is a common practice in linked open data to interlink datasets; similar annotations have been made for properties using owl:equivalentProperty or rdfs:subPropertyOf (when an equivalent property did not exist). Now that AgroPortal handles 'external mapping' as described in Section 4. 3, we have been able to upload all our annotations (to 23 classes and 21 properties) to fully connect the concepts from the different ontologies, and create annotations, directly within AgroPortal. 26 s a result, AgroLD has incorporated the data from various databases (Table and produced 37 million RDF triples  (Venkatesan et al.
, 2015). The data source selection followed the needs and priorities of the IBC project's work-package 5. It included important data sources such as GOA, Gramene, Oryza Tag Line, and Green-PhylDB. AgroLD can now gather genomic and phenotypic information to answer biological questions such as: "find proteins involved in plant disease resistance and high grain yield traits. " Such queries would be hard or impossible to resolve without the appropriate ontologies integrated to support the conclusion. The reader may refer to http://agrold. org/sparqleditor. jsp for more examples of queries in AgroLD.