dataesr/scientific-paragraphs-categorization huggingface dataset:
VI. CONCLUSION In this paper, we have explained why we believe the GCM technology can be a perfect fit to support data stream autonomous analytics. Indeed, GCM features (1) native dynamic reconfiguration capabilities and hierarchical definition, that can be handled by the runtime GCM API and a declarative architecture description language, (2) clear still inter-operable functional and non-functional levels that can host predefined or user-designed control loop components. Consequently, this greatly improves the expressiveness compared to the existing approaches. From the performance viewpoint, particularly important for handling big data, it incorporates both distributed and multicore native support as it relies upon the multi-active parallel and distributed active object technology, and the ProActive platform for dynamic host acquisition.
In this paper we present a new paradigm for the identification of datasets extracted from the Virtual Atomic and Molecular Data Centre (VAMDC) e-science infrastructure. Such identification includes information on the origin and version of the datasets, references associated to individual data in the datasets, as well as timestamps linked to the extraction procedure. This paradigm is described through the modifications of the language used to exchange data within the VAMDC and through the services that will implement those modifications. This new paradigm should enforce traceability of datasets, favour reproducibility of datasets extraction, and facilitate the systematic citation of the authors having originally measured and/or calculated the extracted atomic and molecular data.
Introduction Atomic and Molecular Data Providers are often at the forefront in defining new paradigms for the dissemination of their data to the scientific community: Since the second half of 1990s, with the spread of the Internet, some historical databases such as VALD  [19] , HITRAN  [23] ,  [24] , the Submillimeter, millimeter and microwave spectral line catalog (so-called JPL Catalogue)  [18] , CDMS  [16] ,  [15] , GEISA  [13] ,  [12]  were precursor of a free online sharing of data, thus anticipating of some decades trends later generalised by gouvernements and institutions with the open data and open knowledge initiatives  [11] ,  [14] ,  [20]. During the last ten years, Atomic and Molecular resources were highly fragmented and available through a variety of interfaces. This situation negatively impacted the full exploitation of the scientific data and has been a major bottleneck between the data providers and the wide body of users.
From 2009 to 2014, the goal of the European FP7 projects VAMDC  [5]  and its successor SUP@VAMDC  [27]  was to provide the international community with a unique technical and collaborative framework for Atomic and Molecular data sharing: the VAMDC International Consortium  [8]. The VAMDC technical e-infrastructure federates, in an interoperable way, a wide range of heterogeneous databases containing data coming from different physical communities, provides a single entry-point both for discovering resources and for accessing the available data in a unified way (http://portal. vamdc. eu). For building and maintaining this e-infrastructure, VAMDC has developed specific procedures, protocols, data formats and query languages (http://standards. vamdc. eu). The Atomic and Molecular data providers community, organised around the VAMDC Consortium, has thus anticipated the identification and resolution of problems that are currently discussed in international groups belonging to the Research Data Alliance (RDA).
The goal of RDA is indeed to build the social and technical bridges that enable open sharing of data in the current highly fragmented global research data landscape. Using the VAMDC facilities, scientists can now easily discover the atomic and molecular resources, and can access in a unique and practical way their contained data. However, the adoption of VAMDC by a large community has revealed a new set of challenging issues. The VAMDC infrastructure data are dynamic. A database exposed through the VAMDC infrastructure may evolve over time: the most recent and precise version of given data may replace old ones as in VALD  [19, 25] , or new datasets may be added to the already existing ones as in BASECOL  [6, 4]. It may happen that some of these database evolutions are not systematically reported through new publications.
Assume then that a scientist extracts from VAMDC at a given time a "dataset", composed of an ensemble of "data", and wishes to use this "dataset" in order to produce some science that will be published into a scientific paper: how can he/she cite this "dataset" and the individual "data"? Since the database content may evolve, for the consistency of the scientific publication, the citation should refer to "datasets" well defined in space (where the "dataset" physically comes from) and time (at what time the "dataset" was produced and extracted). In addition the citations should contain pointers to the authors who originally measured, calculated and/or fitted the individual data. Moreover, for the reproducibility of the scientific process described into the paper referencing the "dataset", everybody wishing to verify step-by step the procedures described into the paper, should be able to easily recover the original "dataset" and replay the data-production workflow.
In spring 2014 we joined the RDA Data Citation Working Group in order to study these open questions. The goal of this Working Group  [22]  is to create the identification mechanisms that • allows us to identify and cite arbitrary views of a "dataset" in a precise, machine actionable manner; • allows us to cite and retrieve that "dataset" as it existed at a certain point in time, whenever the database is static or highly dynamic; • is stable across different technologies and technological changes. The very new model we will discuss through this paper is the mechanisms we may apply on the data coming from the VAMDC e-infrastructure in order to meet the recommendations of the RDA Working Group on Data Citation with the goal of obtaining • a rigorous and reproducible data citation model, • the reproducibility of data production (or data processing) workflows, and in order to facilitate the citation of the original authors of the atomic and molecular data.
Example of data-citation need for scientific authors Surveys of interstellar regions requires the use of spectroscopic information within the observed range of wavelengths/frequencies. As an example, the survey by  [10]  covers frequencies from 83302 MHz to 262404 MHz and detect emission from about 36 species. For that survey,  [10]  indicate that they used catalogues from two public databases  [18] ,  [15]  and one private database of J. Cernicharo (private communication). We note that there is no knowledge of the exact dataset used in the analysis, and therefore the analysis may not be reproductible if the database contents evolve over the years. Secondly, we note there is no citation of the authors who produced the spectroscopic data. Obviously for such large surveys with so many species there is a large contribution from many experimental/theoretical spectroscopic papers.
On the contrary, that for the non-local thermodynamical equilibrium analysis of spectra (that includes the use of collisional rate coefficients) about 12 publications related to collisional data are cited. This dichotomy of treatment could be first explained by the complexity of citing/finding many spectroscopy authors, while it is easy to cite a few collisional papers. Similarly, another survey  [2]  cites many spectroscopic databases without citing either the original authors or the version of data used in the survey's analysis. The study of Punanova et al. [21]  cites the authors of transitions that are not part of a database, such as the hyperfine transitions of N 2 H +  [17]  and such as the 1 → 0 transition of C 17 O  [9] , but they cite the splatalogue catalog (http://www. cv. nrao.
edu/php/splat/) for the 1 → 0 transition of C 17 O. Those examples confirm that the origin and versioning of spectroscopic data might be lost along the chain of usage as soon as spectroscopic data are taken from a database. Through the VAMDC e-infrastructure, the protocols presently allow to retrieve the references associated to the spectroscopic and collisional data in a straightforward and quick manner. For example, from the result page of the VAMDC portal (cf. figure  3 ) the "bibtex" visualisation processor allows one to get references attached to the data in a usable form for publication. This processor produces XSAMS output file (produced by the VAMDC infrastructure) by extracting the bibliographic information contained into the Sources field, which is embedded into each data entry (cf.
Introduction of the new schema elements for handling data versioning and origin The root element of a XSAMS file is the XSAMSData object (cf. figure  2 ), which is an instance of the XSAMSDataType class. The innovation compared with the current official version of the XSAMS format (version 12. 07) is the introduction of the Origin field, that contains the new mechanisms for handling the datasets citations. The Origin field is an instance of a class extending the AbstractOrigin-Type (cf. figure  5 ). This abstract type must contain: • a unique Timestamp. This field defines the exact time when the data have been extracted by the infrastructure;   • a Version field, instance of VersionType class (cf. paragraph 3. 1. 1); • a HomepageURL field, which is the link to the website describing the resource that produced the data; • a Name field, which is the name of the resource producing the data; • a Comments field, which (as its name indicates), contains the comments related with the resources producing the data.
Remark: It is important to underline the difference between the timestamp field contained into an Origin object and the timestamp contained into a Version object. The first corresponds to the time when the data were extracted by the user (i. e. the data when the file was created) while the second corresponds to the time when that specific version of data was made available to community by the resource providing the data. 4 Some examples of data extracted from VAMDC, formatted with the proposed schema In this paragraph we will provide examples of data extracted from the VAMDC infrastructure and formatted with the schema described in the previous section. For reason of clarity, we have lightened those examples, by manually selecting only a subset of the data really available into VAMDC. This will not affect the methods and the accuracy of the described approach.
The VAMDC internal convention is to use wavelength expressed in angstrom when querying radiative data from databases. This is imposed by the need of interoperability within VAMDC. Nevertheless from our portal (  [8] , http://portal. vamdc. eu) the users may query the radiative databases using whatever relevant quantities (frequency, energy, wavenumber, wavelength) associated to a choice of relevant units. No change in the original data is performed in the extracted output. For example B, line 108 shows that CDMS provides frequencies in MHz.
Example of an extraction from the BASECOL node Let us consider an elastic collisional process, where the target is CO and the collider is He. Let us try to find some data on this collision into the VAMDC infrastructure. The associated query (generated by the portal from the Graphical User Interface and passed to all the VAMDC nodes) is: select * where ((target. MoleculeStoichiometricFormula = 'CO')) AND ((collider. AtomSymbol = 'he')) The file reported in its entirety in A is the output that the BASECOL node  [4]  generates when answering the previous query (with the reservations made at the beginning of paragraph 4). Let us browse the content of this file and focus on the Origin element: The first line indicates that the resource producing the file is a VAMDC node and the second line indicates when the extraction has been performed (this time also corresponds to the creation of the file).
On lines 3 to line 12 we find the information about the versioning of the contained data: it is specified that 1 <Origin xsi:type="VamdcNodeOriginType"> 2 • the species referenced by the identifiers XBAS2, XBAS52 (defined respectively at lines 56 and 89 of A); • the states referenced by the identifiers SBASET54-1, SBASET52-1, SBASET52-2 (defined respectively at lines 58, 119 and 134 of A); • the processes referenced by the identifier PBASC50t2T1c1C1 (defined at line 154 of A) • the sources referenced by the identifiers BBAS0, BBAS849 (defined respectively at line 194 and 207 of A. belong to the version VER001 of the database. This version was made available on the date 2015-09-01T08:10:12+01:00. Starting from line 13 we have the information about the database that produced the data: the link to its homepage (line 13), its Name (line 14), the query used for generating extracting the data and generating the file (lines 15 to 16), the unique identifier of the resource as it appears into the VAMDC infrastructure registry (line 17).
Example of an extraction from the CDMS node Let us now try to extract from the VAMDC infrastructure some spectroscopic data for the carbon monoxyde in a range of wavelength between 2. 6006 10 7 Å and 2. 6008 10 7 Å. The associates query (typically generated by the portal from the Graphical User Web Interface and passed to all the VAMDC nodes) is select * where (RadTransWavelength >= 2. 6006E7 AND RadTransWavelength <= 2. 6008E7) AND ((MoleculeStoichiometricFormula = 'CO')) The file reported in its entirety in B is the output that the CDMS node  [15]  generates when answering the previous query (with the reservations made at the beginning of paragraph 4). Let us browse the content of this file and focus on the Origin element: As in the example from BASECOL, the first line indicates that the resource producing the file is a VAMDC node and the second line indicates when the file was generated.
From line 3 to 12 we find the information about the versioning of the contained data: it is specified that • the species referenced by the identifier XCDMS-83 (defined at line 24 of B); 1 <Origin xsi:type="VamdcNodeOriginType"> 2 <Timestamp>2015- • the states referenced by the identifiers SCDMS-83-1, SCDMS-83-2, SCDMS-origin-83 (respectively defined at lines 67, 83, 51 of B); • the process referenced by the identifier PCDMS-R15140649 (defined at line 105 of B) • the sources referenced by the identifier BCDMS0, BCDMS-1921, BCDMS-1681 (defined respectively at line 131, 150 and 170 of B) belong to the version VER1 of the database. This version was made available on the date 2000-10-01T12:00:00+01:00. Starting from line 13 we have the information about the database that produced the data: the link to its homepage (line 13), its name (line 14), the query used for extracting the data and generating the file (line 13), the unique identifier of the resource, as it appears into the VAMDC infrastructure registry (line 15).
Documenting data processing workflow: merging of two files with SpectCol We used the SpectCol tool  [3] ,  [7]  2 for cross-matching the data from the two files described into the previous subparagraphs. The SpectCol tool allows to create combined spectroscopic and collisional data files where the collisional rate coefficients come from a collisional database (BASECOL in this example) and the spectroscopic data (energy levels and Einstein coefficients) come from a spectroscopic database (CDMS in this example). This process requires to match the spectroscopic energy levels of CDMS with those of BASECOL on the basis of identical quantum numbers. We asked Spectcol to merge the two files by identifying the states of the Carbon Monoxyde characterised by the same quantum number values J: the state referenced by the identifier SBASET52-1 (J = 0, cf.
line 117 of A) has been identified and assimilated with CDMS-83-1 (cf. line 64 of B) while the state referenced by the identifier SBASET52-2 (J = 1, cf. line 132 of A) has been identified and assimilated with CDMS-83-1 (cf. line 80 of B). The resulting merged file is reported in C. Let us browse the content of this file and focus on the root Origin element: We see (line 1) that the file was not produced by a VAMDC node, but by the Spectcol tool (line 11 to 15). The current file has been produced on 2015-12-07T15:50:21+01:00 and results from the merging of data coming from BASECOL and from CDMS, where the states of CO characterised by the same values of the quantum number J are crossmatched (line 15). The data coming from BASECOL and CDMS are detailed into the two contained Origin sub-elements: 1 <Origin xsi:type="OtherOriginType"> 2 • the first one is defined from line 17 to line 31 and holds the data coming from the CDMS node.
This includes the species referenced by the identifier XCDMS-83, the states referenced by the identifier SCDMS-83-1, SCDMS-83-2, SCDMS-origin-83 (respectively defined at line 137, 151, 165 of C), the process referenced by the identifier PCDMS-R15140649 (defined at line 186 of C). The extraction of those data was performed on 2015-12-03T15:50:21+01:00 from the CDMS Node by submitting the query select * where (RadTransWavelength >= 2. 6006E7 AND RadTransWavelength <= 2. 6008E7) AND ((MoleculeStoichiometricFormula = 'CO')) The extracted data correspond to the version VERCDMS1 that was available to the community since 2000-10-01T12:00:00+01:00 • the second one is defined from line 31 to line 42 and holds the data coming from the BASECOL node. This includes the species referenced by the identifier XBAS2 (defined at line 75 of C) and the state referenced by the identifier SBASET54-1 (defined at line 77 of C).
The extraction of those data was performed on 2015-12-03T14:40:21+01:00 from the BASECOL node by submitting the query select * where ((target. MoleculeStoichiometricFormula = 'CO')) AND ((collider. AtomSymbol = 'he')) The extracted data correspond to the version VER001 of the database. This was available to the community since 2015-09-01T08:10:12+01:00. Let us focus again on the root Origin element: • As we can see from line 5 to 9, all the sources references from the merged files are now contained into the Version object of the root Origin. Indeed during the merging procedure, the sources from both the BASECOL and the CDMS files are compiled together into the root element since the data coming from all the sources are used. Moreover for data citation, it is very convenient to store at a same location all the references linked to the current file.
• The process referenced by PBASC50t2T1c1C1 belongs to the Version field of the root element (line 4). If we compare with A, line 154, we discover that this is a collisional process coming from BASECOL. It is important to understand why it is not contained into the second sub-origin element which, as we previously shown, contains the data coming from BASECOL: in its original extraction from BASECOL (cf. A, line 154) this process is a collision between CO (identified with the label XBAS52) and He (identified with the label XBAS2). During the collision, the CO pass from the state referenced by SBASET52-2 to the state referenced by SBASET52-1. All these identifiers and references have consistency in the BASECOL perimeter. Let us look at the same collisional process as it is described on the merged file (cf.
line 212 of C): the collision is between CO (now identified with the label XCDMS-83, since during the crossmatching procedure we have replaced the CO from BASECOL with the one coming from CDMS) and He. During the collision CO pass from the state referenced by SCDMS-83-2 to the state referenced by SCDMS-83-1 (indeed we remember that during the crossmatching we have identified the state SBASET52-2 from BASECOL with the state SCDMS-83-2 from CDMS and the states SBASET52-1 from BASECOL with the state SCDMS-83-1 from CDMS). Due to these changes, the collisional process refer now to data coming both from BASECOL and CDMS and the data is no more the original one freshly extracted from BASECOL (as it was the case in A, line 154). As a direct consequence BASECOL is no more the source origin of this data.
Practical use of the new XSAMS features In section 3 we introduced new changes and additions to the XSAMS format which allows one to identify unequivocally through time and location the datasets extracted from VAMDC: all the relevant metadata (the extraction query, the date when the query was submitted to the infrastructure, the responding node, the version of the responding node, etc. ) are automatically embedded into the output file. But from the practical point of view of the final user, how to use this information ? Our aim is to simplify the "data citation" landscape and not to complicate the actual one described in section 2. In this paragraph we are going to sketch the future VAMDC services that will allow a simple and fluid use of these new features: When a user queries data from the VAMDC e-infrastructure by submitting a given query, he/she will receive an output file formatted as described in section 3.
This file will be associated with a unique digital identifier. This identifier (as it is the case for the DOI), will be resolvable and the landing page 3  will summarize the information contained in the Origin field of the output file, the data-file itself (via query re-execution, if the node supports this feature)  4  , the bibtex references of all the papers used for compiling the output file. This sketched service is a part of a Query Store as it is understood in the Data Citation RDA context and described in  [22]. This query store may be used in collaboration with editors. We imagine the following data-citation workflow: when a scientist wishes to cite a dataset extracted from VAMDC, he/she has just to put into the references the unique identifier returned by the VAMDC infrastructure during the extraction procedure.
Concluding remarks Through this work we have discussed an evolution of the VAMDC standard output format which provides a mechanisms allowing to identify through time and location, in a sustainable and unique way, data sets extracted by users from the VAMDC e-infrastructure. With our proposed solution the information about the origin and version of data are embedded into (and indissoluble from) the file containing the atomic and molecular data. The same mechanisms define an unambiguous method for tracing and documenting the data processing workflows. The methods and technical solutions introduced in this paper are designed for scientist wishing to efficiently cite the datasets and the dataproducers of the Atomic and Molecular data extracted from the VAMDC infrastructure: let us consider an XSAMS data file containing N references (N >> 1) to the sources used for the data file compilation.
Before the introduction of the solution discussed into this paper, a scientist wishing to publish a work based on that data file would need to include the N publications in order to properly cite the data. With the introduction of the proposed solution, the scientist will only cite the Digital Unique Identifier (DUI) returned by the VAMDC infrastructure during the extraction procedure. This DUI is resolvable and the landing page will contain the original query used for the generation of the data file and the bibliographic references to the N publications.
The Seventh Framework Program. Call topic: INFRA-2008-1. 2. 2 and INFRA-2012 Scientific Data Infrastructure. Grant Agreement numbers: 239108 and 313284. We acknowledge support from Paris Astronomical Data Center. We thank Thomas Marquart, Guy Rixon and Mickail Doronin from the VAMDC Consortium for fruitful discussions. BCDMS0"> <Comments>This Source is a self-reference. It represents the database and the query that produced the xml document. The sourceID contains a timestamp. The full URL is given in the tag UniformResourceIdentifier but you need to unescape ampersands and angle brackets to re-use it.