{'fraction_non_alphanumeric': 0.029479830526578134, 'fraction_numerical': 0.01570121408480792, 'mean_word_length': 4.81411716000828, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 8, 'https://': 0, 'lorem ipsum': 0, 'www.': 3, 'xml': 3}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
New model for datasets citation and extraction reproducibility in VAMDC

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. 2 Existing VAMDC solution for data citation All the output of the VAMDC infrastructure are built upon an abstract object model: each specific output is an instance of this model. For historical reasons, without loss of generality, the model has been fixed into an XML format, the XSAMS XSD schema 1 .

Graphical convention for representing XML elements
The graphical diagrams displayed in this document are a simple rendering of every XML element contained in the XSAMS, and they are obtained following the graphical conventions of Fig. 1. In this graphical representation (see Fig. 2 for example) every complex element is linked with segments to the contained sub-elements. A bold segment indicates that the sub-element is required and a thin segment indicates that the sub-element is optional. Moreover, the cardinality of the contained sub-elements can be expressed on the segments. The detailed explanation of the XSAMS components can be found in the official VAMDC XSAMS documentation at http://www.vamdc.org/standards.

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. figure 2 and 4). Thus, the use of the current version of VAMDC allows full citation of any data and such citation relies on the good will of the users. Even so, the citation process may become cumbersome when the extracted datasets come from many sources. This latter issue and the former issue of reproducibility of the extraction process are addressed in the new paradigm of datasets citation that we describe below.

Introducing the evolutions of the XSAMS format
In this paragraph we discuss new mechanisms allowing one to identify through time and location, in a sustainable and unique way, the data sets extracted by users from the VAMDC e-infrastructure. The proposed mechanisms comes with an evolution of the XSAMS standard. The practical usage of the described features is presented in section 5

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.
The VamdcNodeOriginType (cf. figure 6), as its name indicates, is used when the resource producing the data is a VAMDC node. It extends the AbstractOriginType by mandatorily adding: • a Query field, which is a text string defining the query used for extracting the data from the described node.
• an OriginIdentifier field, which is the identifier of the node into the VAMDC infrastructure, as it appears into the VAMDC registry. The VamdcProcessorOriginType (cf. figure 7), as its name indicates, is used when the resource producing the data is a VAMDC processor. It extends the AbstractOriginType by mandatorily adding: • an OriginIdentifier field, which is the identifier of the processor into the VAMDC infrastructure, as it appears into the VAMDC registry.
• the list (which must contain at least one element) of the Origins that produced the data used as inputs by the current processor. The OtherOriginType (cf. figure 8), as its name indicates, is used when the resource producing the data is not a VAMDC node and neither a VAMDC processor. It extends the AbstractOriginType by adding: • an OriginIdentifier field, which is the identifier of the resource into the VAMDC infrastructure, as it appears in the VAMDC registry.
• the list of the Origins that produced the data used as inputs by the current resource.  These three classes make sure that the users know what is the latest treatment of the data, and what are the original sources of the data, thus making possible to trace the original public exposure of the data.

The Version element
With the VersionType class the data contained in a XSAMS file are managed with fine grained granularity (cf. figure 9). This class contains three attributes: • a versionID which is the unique identifier of the current version instance; • a global boolean field. If global is true, then XSAMS file should consist of a unique instance of VersionType and all the data contained into the file will automatically belong to this Version. This implies that the attribute global equal to true is legal for XSAMS document with a unique Origin element (since Origin automatically contains a Version).
• a unique timestamp field which define the timestamp of the current version creation on the resources providing the data.
Moreover, this class contains three lists of elements: • a list of SpeciesRef objects of type SpeciesRefType. In other words, this list contains the references to all the species (defined elsewhere into the XSAMS file) which belong to the current Version; • a list of StateRef object of type StateRefType. This list contains the references to all the states (defined elsewhere into the XSAMS file) which belong to the current Version; • a list of ProcessRef object of type ProcessRefType. This list contains the references to all the process (defined elsewhere into the XSAMS file) which belong to the current Version.
• a list of SourceRef object of type SourceRefType. This list contains the references to all the bibliography sources (defined elsewhere into the XSAMS file) which belong to the current version.
If a given element is referenced into a specific Version object, it can not belong to another one.
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: 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 • 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).
We recall that the two bibliographic references BBAS0 and BBAS849 included into this VER001 version (cf. the last bullet of the previous item list) are respectively defined at line 194 of A: <Name>M.-L. Dubernet</Name> 8 </Author> 9 </Authors>

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 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 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).
We recall that the three bibliographic references BCDMS0, BCDMS-1921 and BCDMS-1681 (cf. the last bullet of the previous item list) are respectively defined at line 131 of B <Comments>This Source is a self-reference. 3 It represents the database and the query that produced the xml document. 4 The sourceID contains a timestamp. 5 The full URL is given in the tag UniformResourceIdentifier but you need 6 to unescape ampersands and angle brackets to re-use it. 7 Query was: select * where ((target.MoleculeStoichiometricFormula = 'CO')) AND ((collider.AtomSymbol = 'he'))</

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  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 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. This combined collision is created by SpectCol and it is natural that it appears into the root Origin element which holds the data produced by SpectCol during the crossmatching procedure.

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. Since this unique identifier is resolvable, the editors may resolve it and, by accessing the bibtex information of the landing page, give credits to all the listed authors. This automatic credit delegation method may also work with current systems (e.g. the SAO/NASA Astrophysics Data System 5 ). 3 The landing page will be human readable, but a machine actionable version may exist for automatic treatements 4 The evolved XSAMS standard described in section 3 allows a data provider to univocally tag version of their data. Even if we strongly suggest that the VAMDC nodes give access (through the VAMC infrastructure) to all the subsequent versions of their data, we cannot enforce the data policy on the federated nodes. A given node may delete an old version when a new one is available. In that case the metadata policy will always allow the unambiguous identification of the extracted data, but data extraction re-execution will not be possible 5 http://adswww.harvard.edu/

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.

133
It represents the database and the query that produced the xml document. 134 The sourceID contains a timestamp.

135
The full URL is given in the tag UniformResourceIdentifier but you need 136 to unescape ampersands and angle brackets to re-use it. <Comments>This Source is a self-reference. 292 It represents the database and the query that produced the xml document. 293 The sourceID contains a timestamp.

294
The full URL is given in the tag UniformResourceIdentifier but you need 295 to unescape ampersands and angle brackets to re-use it.