dataesr/scientific-paragraphs-categorization huggingface dataset:
Biochemical analyses of scent composition in roses Volatile compounds were extracted from petals and stamens of the different rose genotypes with hexane, mainly as previously described28 (Supplementary Notes 9). Camphor was used as an internal standard to estimate compound quantities. Hexane sample fraction was analyzed with a gas chromatograph coupled to an electron ionization mass spectrometer detector (EI-MS; Agilent 6850) detector operated under an ion source temperature of 230°C, a trap emission current of 35 µA and a 70 eV ionization energy. All experiments were performed at least twice. Chromatograph data were analyzed using Agilent Data Analysis software and the volatile substances were identified by screening the WILEY 275, NIST 08 and CNRS libraries to compare MS spectra. The Kovats retention indexes (KI) of each substance were calculated using data of the injection of a homologous set of n-alkane (C 8 -C 20 ) according to the Kovats formula60.
Acknowledgements We thank  J. Thomas ,  T. Goujon  and  C. Bendahmane  for critical reading of the manuscript. We thank  Alain Meilland  for helpful discussion. We thank  Alexis Lacroix ,  Patrice Bolland  and  Justin Berger , the " Lyon Botanical Garden-France " and the  Rose Garden "O. Masquelier, La Bonne Maison, Lyon, France"  for providing plant material. We thank  Loïs Taulelle  and  Emmanuel Quemener  for computing resources. We thank the  Genotoul bioinformatics platform Toulouse Midi-Pyrenées  for providing help and computing resources. We gratefully acknowledge support from the  Pôle Scientifique de Modélisation Numérique of the ENS de Lyon  for the computing resources. We thank the epigenomic platform of the  IPS2-University Paris-Sud-Orsay France. We thank the platforms  AniRA-Cytometry  and 'Analyse génétiques et cellulaire' of the  IFR BioScience Lyon  ( UMS3444/US8 ) for HRM and FACS experiments.
PacBio sequencing was supported by the  GET-PACBIO program  ( Programme operationnel   FEDER-FSE MIDI-PYRENEES ET GARONNE 2014-2020 ). This work was supported by funds from the  French National Institute of Agronomic Research (INRA) , by the program  Fonds Recherche of Ecole Normale Supérieure-Lyon-France  to  M. Bend  and O. R. , by the Genoscope to P. W. , by  French National Research Agency programs DODO  ( ANR-16CE20-0024-03  to  M. Bend. and M. Va. ), and  AUXIFLO  ( ANR-12-BSV6-0005  to T. V), and by the  European Research Council  ( ERC-SEXYPARTH ) and by the  Labex Saclay Plant Sciences -SPS  ( ANR-10-LABX-0040-SPS)  to  A. Be.
We present a 3D orbit viewer application capable of displaying science data. 3DView, a web tool designed by the French Plasma Physics Data Center (CDPP) for the planetology and heliophysics community, has extended functionalities to render space physics data (observations and models alike) in their original 3D context. Time series, vectors, dynamic spectra, celestial body maps, magnetic field or flow lines, 2D cuts in simulation cubes, etc, are among the variety of data representation enabled by 3DView. The direct connection to several large databases, the use of VO standards and the possibility to upload user data makes 3DView a versatile tool able to cover a wide range of space physics contexts. The code is open source and the software is regularly used at Masters Degree level or summer school for pedagogical purposes.
3Dview offers the visualization of the trajectory of spacecraft and natural bodies and 3D functions like zoom, lighting of objects, instrument fields of view, and customization of external data (user imported objects). Orbit and attitude are handled through SPICE kernels and related files from ESA or NASA repositories, depending on the mission. It has been developed for several years by the GFI Company in collaboration with CDPP, the licence is owned by CNES (GPLv3) and the code is open source. The source code of 3Dview can be found at https://gitlab. irap. omp. eu/CDPP/3DVIEW. Historically, starting in 2005, the 3DView tool was developed for Rosetta mission to visualize its long and complex trajectory towards the 67/P comet (10 years of cruise, 4 planetary flybys and 2 asteroids flybys, the comet approach and escort phases).
At this stage the tool only dealt with trajectory and attitude information. In 2009, the generic tool was chosen by the CDPP to extend its capabilities in data analysis and to provide added value to its large database. This evolution was implemented in the frame of the FP7 IMPEx project which covered the year 2011-2015 (see Section 6). In 2015 the new version was fully operational and enabled displaying scientific models (analytical and simulation) together with data plotted along orbits. The IMPEx evolution and the ones that recently followed are jointly managed by CNES and IRAP. It now covers up to 60 missions with 75 probes. In 2014, a new 3DView Rosetta version helped scientists in the selection of the Philae probe landing site thanks to the accurate and regularly updated comet shape model and planned trajectories display.
3DView architecture The overall architecture of 3DView is depicted in Fig. 1. 3DView is made of two main components: the client, which is the only man/machine interface and is launched by the user (generally from a browser or a desktop icon), and the server which provides web-services for orbits, coordinate transformation and models, and procedures for data update. The client uses web-services to manipulate and plot data. It is developed in Java7 with Swing, JAX-WS, Java3D, JFreechart, JMF, NetCDF and XML and has been tested for Windows, MacOSX and Linux (32 or 64 bits). Although they were initially developed for the client, all web-services may be accessed by external applications. For instance the online coordinate transformation tool TREPS, described in a companion paper  (G enot et al.
, 2018) , uses the 3DView web-service for frame transformation. 3DView is a "Java Webstart application". Java Webstart is a technology which allows launching of applications remotely, using the Java Net Launching Protocol (JNLP). SWING, a GUI widget toolkit for Java, and Java3D, a scene graph based 3D application programming interface for the Java platform are used for the 3D display. Table  1  lists all the components used by 3DView. The choice of Java was settled more than 10 years ago. Java support on the long term has been questioned from time to time but it finally proved to be robust enough as maintenance quality (e. g. bug fixing velocity) improved regularly. Java2 Standard Edition provides a set of java classes allowing to display lists and graphical objects. It includes the SWING package which allows the display of graphical components like applets, frames and dialog boxes.
3DView was developed with the JDK (Java Developer Kit), but only needs the JRE (Java Runtime Environment). Java3D allows rendering and handling three-dimensional geometric objects: all items (including spacecraft, trajectories, simulation cuts, data and model representations, etc) are 3D objects (handled by the Java3D library) except maps which are cylindrically-projected textures. It is uploaded with Java Webstart when the 3D display is launched, if it was not uploaded upon the previous launch (package size is about 3 Mo). The Java Media Framework enables audio, video and other time-based media to be added to applications and applets built on Java technology. It is used by 3DView to create movies in QuickTime format, by concatenation of series of JPEG images. Java JFreeChart allows the display of several types of 2D graphs: curves, histograms, pie charts, etc.
Loader3DS, a Java loader for the 3DS file format, is used to load satellites and asteroids models in the main view. The NetCDF-Java Library is a Java interface to NetCDF format and many other types of scientific data formats. It was created and maintained by Unidata, and is used by 3DView to read files coming from AMDA (the Automated Multi Datasets Analysis tool of CDPP, see also Section 6). The 3DView server holds the database of SPICE kernels (see next section) and other associated files necessary to display spacecraft trajectories (satellite models for instance). Texture for planetary surfaces are also on the server side. Science data are stored and maintained externally, and accessed via interoperability means (see Section 6).
SPICE kernels for trajectories, attitudes and fields of view To display the trajectories and attitudes of different bodies, spacecraft or planets, it is necessary to know their positions. This information is given in data files, called SPICE kernels, provided by NASA/NAIF or ESA/ PSA, or defined internally by the tool developers (see below). SPICE (Spacecraft Planet Instrument C-matrix Events) which is the U. S Planetary Data System's standard for archiving ancillary data, provides ancillary data related to space missions, that help scientists determine where a spacecraft was located, how a spacecraft and its instruments were pointed, and what was the location, size, shape and orientation of the target body being observed. SPICE is used to organize these ancillary data in collections of stable file types (the kernels).
A direct connection to SSCWeb also allows creating and updating some orbit files related to Earth spacecraft. 3DView developers wrote the code to produce data (trajectories, attitudes, fields of view) from the kernels by using SPICE libraries. Users of 3DView can access Instrument Field of View (FOV) and spacecraft attitude from the 3DView server or upload them. Regarding orientation, instruments are simulated in three ways: by a cone, a straight line (java3D objects) or by simulation of the view: positioning of the scene view on the instrument branch: position þ viewing angle and angle of view. It is possible to create a view in a separate window. A new view is then created and positioned according to the attitude of the instrument. The target mode of an object leads a placement of the instrument on the main branch of the scene.
Analytic models for planetary boundaries and magnetic fields Analytical models for planetary boundary surfaces (bowshock, magnetopause) and magnetic field are available for a variety of bodies including the Sun. These are important representations which enhance the geometrical context into which data (observations or simulations) are analyzed. The boundary models included into 3DView are summarized in Table  2. Within the tool the bow shock and the magnetopause have editable properties that control their shape and appearance (see Fig. 3 ). Boundary crossings are marked as colored spheres along the spacecraft trajectories. At the solar/heliosphere scales 3DView also provides models related to the magnetic field: Parker spiral and field lines, and the Heliospheric Current Sheet (HCS). We shall see later that Carrington maps of magnetic data (Section 7.
The line is displayed in the 3D scene with an associated control box and will be animated when the targeted object moves. Several lines may be plotted simultaneously with the last two options. A "dynamic" capability is provided for several heliospheric spacecraft which have measured or still measure the solar wind velocity. Available spacecraft are those for which solar wind data are provided by the AMDA database (ACE, Wind, …). A last, still prototype functionality enables the user to upload his/her own field lines from a text file. Close to the Sun the magnetic field lines can really depart from Parker ones and more realistic configuration may be obtained from dedicated modelisation (PFSS, MHD). Modelled lines may also come from more global models like ENLIL or Euhforia. The Heliospheric Current Sheet (HCS) is the surface where the polarity of the Sun's magnetic field changes orientation.
g. Belenkaya et al. , 2013 and references therein). SINP team also provides interpolation of pre-calculated 3D-cubes (sets of three-dimensional arrays containing magnetic field vectors, calculated in points of a grid around planets) stored in a database. Both ways use the same PMM approach, which is intended for description of the magnetospheric dynamics, taking into account the intrinsic planetary magnetic field, the magnetopause current magnetic field, the tail current system magnetic field, the magnetodisc magnetic field, the ring current magnetic field, and the interplanetary magnetic field, penetrated from the solar wind. Such modular structure allows representing the magnetic field inside the magnetospheres of Mercury, Earth, Jupiter, and Saturn. 3DView can display three data products related to the magnetic field of those planets: time series (vector or scalar) along a chosen spacecraft trajectory, 2D cuts from the original 3D cube, and field lines.
The main setp-up window, through which 3D scenes are created, is the "Manage scene" dialog box (see Fig. 9 ). It allows the selection of the 3D scene attributes: time interval, coordinate system, time step, center body, spacecraft, natural bodies and time shift. Once created, a 3D scene may be modified at any time. For example, it is possible to add a spacecraft, several natural bodies, or modify the time interval. Selection of the Spacecraft tab displays the list of spacecraft for which orbit and attitude data are available. The Range column gives the time span for the corresponding spacecraft; details can be obtained on the coverage and time shift can be applied. Selection of the Natural bodies tab gives the full list of natural bodies (planets, satellites, main asteroids and comets) divided in two parts: Preferred available bodies gives the list of satellites of the body selected as center of the scene and Other available bodies gives all the other natural bodies of the solar system registered in 3DView.
Access to remote data One of the strengths of 3DView is its ability to access scientific data from various suppliers. These data may be derived from observations made by scientific instruments of many missions or from simulations using a variety of models. It is therefore possible to compare, in a single 3DView scene, observed and simulated data interpolated along the trajectory of spacecraft. This is made possible thanks to the presence in 3Dview of software layers managing the interface with many data providers of space physics and planetary sciences data. These layers are compliant with standards defined by several international bodies ensuring interoperability between data providers and software tools. Such facilities, IMPEx and VESPA, are described in the following paragraphs. Science data may also be accessed from the user's local disk, or using the SAMP protocol.
IMPEx (Integrated Medium for Planetary Exploration, 2011-2015) was a collaborative project of the "Exploitation of space science and exploration data" theme in the frame of the FP7 program of the European  Union. IMPEx aimed at the creation of an interactive framework where data from planetary missions are interconnected with numerical models providing the possibility of simulating planetary phenomena and interpreting space mission measurements, testing models versus experimental data, performing further improvements of models, filling gaps in the measurements by appropriate modelling runs, and performing preparation of specific mission operations. The main pillars of the IMPEx system are the IMPEx Protocol and the IMPEx Data Model which allow for the exchange of data between various nodes as captured in the IMPEx Configuration.
Enabling the connection between tools like 3DView and data providers was a challenging task, in particular when complex scientific data were involved. The approach of IMPEx is highly compatible with the vision of the International Virtual Observatory Alliance (IVOA) that calls for astronomical datasets and other resources to work as a seamless whole. The IVOA initiative, as does IMPEx, aims at connecting systems in order to be able to easily exchange science data and leverage functionalities of a rich set of tools. Thus, IMPEx uses several standards that originated out of the VO community that were defined by IVOA. Among them is the VOTable format that is heavily used in IMPEx, to exchange trajectories etc. SAMP (see below) is another IVOA standard that allows desktop applications as well as web-based tools to communicate with each other in a straightforward way (see for instance G enot et al.
, 2014). The overall architecture of IMPEx is depicted in Fig. 10. 3DView is a key component of the IMPEx infrastructure, giving access to scientific data coming from observations or simulations. During the IMPEx project, the capabilities of 3DView were extended, including the display of time series along the trajectory of spacecraft, 2D cuts in simulation cubes, spectrograms and field lines. From several simulation databases implementing the IMPEx protocol, users may fly "virtual" spacecraft, by calculating model parameters along the trajectory of a given spacecraft. A pop-up window gives access to IMPEx data represented as a tree. Data are classified by Data Provider Name (e. g. LAT-MOS), Object of the Solar System (e. g. Mars), Simulation Run, Product Type (e. g. Time Series), and physical parameter (e.
g. Magnetic field). The tree must be opened to access the different resources. As the tree expands by the addition of new resources this calls for a refined functionality (e. g. text search) which is under study. A set of filters allows shortening the list of data, according to the scene time range, the center body, or the spacecraft selected in the scene. After selection, data are displayed in the 3D scene. For example, scalar or vector time series are displayed along the trajectory of the previously selected spacecraft. Fig. 11  represents an example of IMPEx data selection. 3DView uses the IMPEx infrastructure to access 3D hybrid models for several planets (from the Finnish Meteorological Institute, FMI, and the Laboratoire Atmosph ere, Milieux, Observations Spatiales, LATMOS), MHD models for the Earth magnetosphere (from FMI), 3D Paraboloid Magnetospheric Model for several magnetospheres (from the Skobeltsyn Institute of Nuclear Physics, SINP), and observational data from many spacecraft via the AMDA, CLWeb, CDAWeb databases.
These three databases hold a wide variety of spacecraft in-situ observations in the ionospheric, magnetospheric, heliospheric and planetology domains. Finally a testbed to access simulation runs from CCMC was added for a few runs. Other simulation or observation databases are welcome to join the IMPEx infrastructure. They must only implement the IMPEx protocol and their holdings will become accessible through tools like 3DView. SAMP, the Simple Application Messaging Protocol, is a standard provided by the IVOA, for software tools to exchange control and data information, thus allowing users to treat separately developed applications as an integrated suite. The protocol has been designed within the context of the International Virtual Observatory Alliance (IVOA), but the design is not specific either to the Virtual Observatory (VO) or to Astronomy.
It is used in practice for both VO and non-VO work with astronomical tools, and is suitable for non-astronomical purposes as well. SAMP allows software tools to exchange messages. At the core of SAMP is the hub which is a service used to route messages between clients, making application discovery straightforward; the hub is intended to simplify the actions of clients, and each client only needs to locate the hub. SAMP is one of the ways used by 3DView to get data from external databases. 3DView "listens to" the Hub, waiting for time series data to be displayed along the trajectory of spacecraft. VESPA (Virtual European Solar and Planetary Access) is an VESPA provides access to a large pool of data providers covering science disciplines with a broader scope than planetary sciences and including heliophysics, plasmas physics, solid phase spectroscopy, atomic and molecular physics, exoplanets, etc.
These services primarily provide data derived from specific analyses, which complement the calibrated, non-interpreted datasets archived by space agencies or ground-based organisations whose main mission is the preservation of original data in the long run. These derived data are provided in standard formats to specialists of other fields (json, VOTable, CDF, JPEG, …). VESPA has defined a specific protocol, called EPN-TAP  (Erard et al. , 2014) , to handle the communication between clients and data providers (see also  Erard et al. , 2018). EPN-TAP is made of two components: the IVOA's Table Access Protocol, used to access data stored in tables, and EPNCore, a metadata model developed to describe planetary sciences data in a standard way. EPNCore inherits several attributes of the PDAP protocol provided by the IPDA, and the SPASE metadata model (PDAP is used to manage the search and exchange of planetary data between space agencies, while SPASE is used by the Heliophysics community).
EPNCore is composed of a set of mandatory parameters, common to all fields of planetary sciences, and several optional attributes. Using EPN-TAP, data are accessed in two steps. The first one consists in searching for available EPN-TAP services registered in the IVOA registries, while the second step consists in sending a query searching for data according to specific values of the parameters contained in a table, to filter the database contents. EPN-TAP queries are sent to services simply using HTTP GET or POST. The query is composed of a URL of the service, followed by a specific request expressed with the ADQL language. A Java library has been designed and developed (by the tool developing team, in the VESPA context) to manage the low level functions of the protocol. The two main functions of the library are: Search the IVOA registry to find relevant services providing data through EPN-TAP Send an EPN-TAP query to all these services.
Each event of a Time Table is characterized by a start time, an end time and a series of optional parameters. Created by scientists from statistical or data mining studies, they are provided to the community via     Karimabadi et al. , 2009). They may come from search tools based on orbit or conjunction criteria, on mathematical criteria applied on the content of databases (see AMDA), or on machine learning algorithms. 3DView allows the creation of Time Tables from a scene as well as the visualization of Time Tables coming from remote servers. The creation of Time Tables in 3DView is available from the animation bar. After positioning the animation cursor at START and STOP times, the user clicks on the Add Time button to save the corresponding time period. At the end of this iterative process, clicking on the Generate Time Table button saves the set of time intervals on the local hard disk.
Maps Central bodies in the 3D scene are displayed with a default map. The default map for the Earth shows its surface, with oceans and continents. Users may insert new maps on or above the central body. Maps may come from a set provided by the server of 3DView, and, as soon as simple longitude/latitude format is followed, they may be uploaded from the local disk or a remote URL. Tuning of transparency is provided through a dedicated control box. Fig. 17  shows a high resolution map loaded onto Enceladus surface. Carrington maps of the solar magnetic field may be added on the Sun (see Fig. 18 ). Datasets from GONG, SOHO, SDO, STEREO-A and STEREO-B are available in 3DView similarly to those available from the companion CDPP Propagation Tool (see also the companion papers by  Rouillard et al.