dataesr/scientific-paragraphs-categorization huggingface dataset:
Fitting Coefficients Section The import script optionally processes the "Fitting Coefficients" section. This section corresponds to the object "Fitting Coefficients" of Appendix B, which is composed of a list of metadata given in Table  5  and of a numerical table. A template of a "Fitting Coefficients" section input is given in Table  A5. The transitions of the numerical fitting coefficients table must be organized identically to the transitions of the related rate coefficients table. indicate that the metadata are either mandatory or optional in the import file. In the column "Uniq. ", we indicate whether the metadata define the uniqueness of the object. In the column "Purpose", we indicate whether the information is meant for the BASECOL (B) public WebUI display and/or for VAMDC (V) interoperability.
Publications Section Finally, the import file imposes to process the "Publications" section. This section may include several "Publication" objects; each object is composed of a list of metadata given in Table  6  and follows the versioning defined in Appendix B. The "Publications" section input file must contain at least one "Publication" object, which is the reference to the paper where the collisional data set has been published. This main reference is indicated in the publication input file with $$mainArticle = yes; this reference appears in red in the "References" section of the public WebUI (cf. Section 4. 2). If the collisional dataset is obtained through several papers, additional references, identified with $$mainArticle = no, can be included. The BASECOL team strongly recommends to include the references to the potential energy surface used in the collisional calculations.
Additional references may be considered such as references linked to the collider and to the target energy levels, as well as to the method used in the calculations. We do not provide an input file for this entry as some minor format modifications are currently being made. In the case of old papers with no DOI, a random DOI is created with the string "tmp_doi" followed by a random unique identifier. This random internal DOI is not provided to VAMDC as DOI is not mandatory in VAMDC. In the import file, DOI is mandatory as we want to enforce the good practice of using unique identifiers. The references' entries of the BASECOL database are currently updated with their DOI. The keywords metadata are composed of a key metadata followed by its value. The key metadata are "Perturbing Element", "Target Element", "Possible systems", "Transitions", "Type of data", "Possible Method", and "Miscellaneous".
To each reference, a set of "key metadata:value" is attached that characterizes the content of the corresponding paper. These keywords allow the search by keywords in the "Articles" part of the BASECOL website (cf. Section 4). Table  6. List of properties/metadata for the object "Publications". The symbols [M] and [O] indicate that the metadata are either mandatory or optional in the import file. In the column "Uniq. ", we indicate whether the metadata define the uniqueness of the object. In the column "Purpose", we indicate whether the information is meant for the BASECOL (B) public WebUI display and/or for VAMDC (V) interoperability. It should be stressed that the publication part of the BASECOL database is extremely important because it ensures provenance of the data, and it ensures that BASECOL follows FAIR principles [7]  (cf.
Import Procedure The import script performs integrity and format checks on the import ASCII file. The importation process starts when the import file is valid. The import script is designed either to import a whole new "collisional data set" or to update an existing "collisional data set". In each "Data" section of the "collisional data set" (Section 3. 1), the import script checks the values of the metadata related to the uniqueness of an "object", and, in addition, for the "Energy Table ", "Energy Origin", "Rate Coefficients", and "Fitting Coefficients" sections, it checks the values of the numerical tables. If the value of a single item that we call "uniqueness item", metadata, or numerical value does not correspond to what is already in the database, the "collisional data set" is considered as a new collisional data set; if all the uniqueness items have the same value as in the database, the " collisional data set" is considered as an update of an existing "collisional data set".
When a new "collisional data set" is imported in the database, a collisional entry is created. In order to ensure data-traceability and reproducibility, a version number is attributed to the freshly created set and a comment describing the details of this creation operation is stored. Alternatively, when an existing "collisional data set" is updated, the metadata not linked to the uniqueness concept and affected by the change are modified, a new version number of the "collisional data set" is created, and a comment describing the type of change is stored. Detailed information on the versioning is provided in Appendix B. Once the import file has been processed, its scientific content, i. e. , the "collisional data set", is copied into the database of the BASECOL "ingestion instance". This "collisional data set" is visible on the website of the BASECOL "ingestion instance", and the administrator can check the imported data.
Once the information is checked, the administrator allows its visibility in the "production instance" of BASECOL. Indeed, by default, any new "collisional data set" status is "non visible" in the production database, thus protecting the "production instance" of the database from non checked information when the "ingestion" database is dumped into the "production" database. The visibility on the "production instance" website of BASECOL implies that VAMDC can access the "collisional data set". The processed import ASCII file is additionally copied into a git versioning system. The git versioning system allows traceability in case of a later update and allows restoration of the database in case of corruption and/or loss of the database. This process guarantees the data integrity.
Public Access to BASECOL via the Web User Interface (WebUI) at basecol. vamdc. org The public interface of BASECOL has been simplified, and we describe here its current features. The "Home" section is the landing page for the URL: https://basecol. vamdc. org; it provides the citation policies and the units. There are two ways to query the database: a guided query with the "Browse Collisions" (see Section 4. 1. 1) section that corresponds to a simplified version of BASECOL2012 collisional query browser and the "Search Collisions" (see Section 4. 1. 2) that provides queries by several free search criteria. The "Search articles" section (cf. Figure  3 ) provides a search on the bibliographic entries which are associated with numerical data. The "Tools" section gives access to information on the SPECTCOL tool [4] and on a scientific package for the water-H 2 collisions [19-24].
Browse Collisions The query part of the "Browse Collision" section is a four-step process: from a single page, the user successively chooses a target, its symmetry, then a collider and its symmetry. The interface provides an auto-completion for the species name and can suggest available colliders according to the selected target. The available datasets corresponding to the restrictions submitted by the user are listed immediately below the query section. Figure  4  shows an example for the request of CO colliding with ortho-H 2. In this example, we see that the data set of Yang et al. [25] has the flag recommended = "yes" as it is more complete and more recent than the previous sets [26,27] which have recommendation = "no".
Search Collisions The query part of the "Search Collision" section allows for freely querying the database with the year of publication and the authors of paper attached to the datasets, the target and collider species. Therefore, it is possible to see the complete content of the database when no criteria are chosen, it is possible to see all collisional sets with electrons as the collider, and so on. This is an extremely useful tool for both the users and the managers of the database. We provide an example in Figure  5.
General Display Once the user has selected a collisional data set, the user interface displays on the same single page the complete numerical and documentary information. Figure  6  shows the return page for the selection of Yang et al. [25] data set. From this page, one can access the rate coefficients, the fits to the rate coefficients, the energy tables with state labels that are used to identify states in the rate coefficient tables, the bibliographic references attached to the collisional data set (the main reference where the dataset is published is shown in red), and then a set of information that allows for rapidly characterizing the methodology used in the calculations. In BASECOL2012 [5] user interface, those items were split between several tabs. Figure  6. Return page containing the CO-ortho-H 2 data set when the reference of Yang et al.
History and Versioning In the "History" part of the return page, the different versions of the collisional datasets will be available. At the time of publication, none of the sets have been updated since the creation of the versioning system. Therefore, we show how it works in Figure  7. The versions correspond to major changes in the database (numerical data), and each version has a creation date and might have some minor modifications done at a later date. The currently displayed version is explicitly notified to the user by the "(this page)" tag after the corresponding version number. Clicking on any of the other versions will bring a similar return page (such as Figure  6 ) corresponding to the selected version. That history part reflects the complex versioning system described in this paper and is an important achievement as it allows full traceability and reproductibility of the data.
BASECOL Implementation of VAMDC Standards By implementing the node software  20  , the BASECOL database becomes a VAMDC-federated resource. BASECOL is currently the sole VAMDC connected database that implements the Java version of the node software  21. The node software is a wrapping between the internal BASECOL structure and the VAMDC standards: it implements a data access which is a variant of the TAP protocol from the IVOA  22  , deals with the query language  23  used in the VAMDC e-infrastructure, returns data in the XSAMS format  24  , and uses standardized field names described in a dictionary: the "Restrictables"  25  contain the list of field names that are used to filter the query to the database and the "Returnables"  26  refer to the type of data that the database returns to VAMDC.
The current BASECOL "Restrictables" and "Returnables" are reported in Tables  7  and 8. Finally, the database must be registered in the VAMDC registry  27. The VAMDC registry is a database of metadata describing the VAMDC nodes and web applications/services. These metadata are collected by querying directly the services' endpoints. The information stored into the registries allows humans and/or machines to find the address of a given node, in order to select nodes by the kinds of data they offer and to find out which query terms are supported at a node. The parameters of Tables  7  and 8  can be found in the registries description of BASECOL  28. Members of the VAMDC Consortium have a password allowing them to register a new database or a web application, once they have followed the quality procedures concerning the resource to be registered.
BASECOL and VAMDC Ecosystem Within the VAMDC ecosystem, BASECOL can be accessed from different VAMDC tools such as the VAMDC portal  29  and the SPECTCOL tool [4], and from any other software that has implemented the VAMDC protocols and standards. On the VAMDC portal, the BASECOL data may be displayed with the "Collisional XSAMS to HTML" display, and Figure  8  gives an example of output that corresponds to querying the CO molecule on the VAMDC portal without any selection of the collider. When the BASECOL data are queried through the VAMDC portal and the SPECTCOL tool, each query is stored in the VAMDC query store  30  and can be linked to a DOI. When this DOI is used in publication, the citations associated with the datasets are acknowledged, therefore increasing the impact factor of the data producers [28-30].
• Reusable: Trust in data is a crucial element for data reusability. With BASECOL, scientists are able to cite where data are coming from, with a fine-grained granularity that allows to achieve scientific reproducibility. Indeed data are both versioned and timestamped, and a user may refer to a specific version. All the "collisional data set" versions are stored in the BASECOL database and are available via the web interface. Another aspect that increases the trust in the BASECOL data is the direct link between a given collisional set and the refereed publication where the data set was published: the methods, hypothesis, and algorithms used for producing a given data set always come with the data.
Conclusions This paper provides a detailed analysis of the latest technical developments on the BASECOL database and its environment. The major upgrades concern its very careful versioning system linked to an ingestion system that verifies the imported data with respect to the content of the database, as well as the possibility for users to retrieve previous versions of the collisional data sets. Another major update is the dual system of a validation and of a production environment coupled to the storage of the collisional data sets ascii files in a github repository. BASECOL is now designed to be a database fully compliant with the VAMDC e-infrastructure, in particular through the import script that contains the parameters necessary for the VAMDC interoperability. Citing one referee: "The 2020 version is undoubtedly a major update compared to the 2012 version: simpler, clearer with excellent traceability and reproducibility.
The website is well designed and user friendly. " Nevertheless, some issues must still be solved, they concern a more friendly import management environment and, of course, the scientific update of the database. In the future, we might foresee partnerships with websites that provide the above cited RADEX files, and we might adopt a different business model for the sustainability of the database. Both the case and the quantum numbers are described in the case-by-case document (http://www. vamdc. eu/documents/cbc-1. 0/). In the second part of the table, all fields are mandatory. The logic of the numerical line is the same as in Table  A2. $$case = case (see caption) $$symmetry = none | A | E | meta | ortho | para (for atoms it is "none") $$quantumNumbers = Q1; Q2 # [M] 1 0. 0 value value [M] Table  A4  provides a template of a "Rate Coefficients" input; it includes the metadata of Table  4.
In the second part of this entry, the first four columns indicate the energy level's labels in the same way as as in the rate coefficient table (see Table  A4 ); this is followed by the values of fitting coefficients whose symbols are indicated in the parameter $$coefficients. [M] stands for mandatory. In the current template, the transition is between the third and the first energy levels of the target with the collider in its fundamental state, and the fitting functions have two coefficients. the BASECOL database, in order to modify and to add information, and then to create an import file in a flawless format that can be treated by the import script. This is particularly useful for the retrieval of metadata associated with species, for the discovery of the right format for quantum numbers, and in general for the retrieval of any information from the BASECOL database in order to create a new import file.
Under this framework, the required data can be obtained from different and diverse sources such as smart cards, GPS, sensors, video streams, images, social media and so on. The main purpose is to provide better services for both drivers and passengers and to globally improve the whole transportation system  [5]. In this article, we are investigating an ITS-related predictive approach, based on computer simulation and machine learning techniques. The proposed methods are applied over existing systems in an artificial environment (traffic simulator software) that can simulate real-life scenarios. The main goal is to develop prediction algorithms that can improve the efficiency of transportation over existing systems/infrastructures. More specifically, our objective is to improve the traffic flow management in public transportation with the help of both short and long-term prediction techniques, based on advanced machine learning algorithms.
In our work, we have adopted a microscopic traffic simulation approach, which is more appropriate for our experiments, since it is able to provide a detailed image (with location, time, speed, noise, pollution. ) of each vehicle in the system. Table  1  summarizes some of the most advanced microscopic platforms available today, with both open source and commercial solutions. Commercial software  [33]  sumo  [34]  quadstone paramics  [35]  matsim  [36]  vissim  [37]  repast  [38]  vissum  [39]  mainsim  [40]  aimsun  [41]  saturn In the right column of Table  1 , solely for information purposes, some commercial solutions are cited. We will not consider them further in our work, despite their advantages (real-life support, enhanced graphical user interfaces) since our purpose is to set up an open framework that can be exploited in the future by the research community.
In the left column of Table  1  are presented open source, free software packages that are usually adopted by the research community and individual developers. In our work, we have retained the SUMO  [42]  open source platform. SUMO (Simulation of Urban MObility) is a microscopic, multi-modal traffic simulator that is able to simulate different types of traffic data. SUMO allows simulating a given traffic demand which consists of individual vehicle moves through a given road network. The simulation permits addressing a large set of traffic management topics. It is purely microscopic: each vehicle is modeled explicitly, has an own route, and moves individually through the network. Simulations are deterministic by default but there are various options for introducing randomness. The SUMO package allowed us to develop our synthetic data further used for prediction purposes.
Concerning the neural networks, three deep learning architectures, including a stacked autoencoder, a recurrent neural network, and a LSTM have been retained. The obtained results show that the CNN-based approach manages to predict the traffic more accurately. In a less conventional manner, in  [56]  authors model the traffic flow as a diffusion process performed on a directed graph, with the help of the so-called DCRNN (Diffusion Convolutional Recurrent Neural Network) approach. The method incorporates both spatial and temporal dependencies of the traffic flow. The spatial dependencies are captured with the help of bidirectional random walks on the graph. The temporal dependency is taken into account by using the encoder-decoder architecture with scheduled sampling. The framework has been evaluated on two real-world datasets and shows significant improvement over the state of the art.
C. CONSUMER APPLICATIONS AND FRAMEWORKS Some mainstream, conventional commercial applications have also integrated real-time traffic conditions and provide prediction facilities for public transportation. Among the most popular solutions, let us cite Google Maps  [57] , Bing Maps  [58]  and Citymapper  [59] , which have been widely adopted by the general public. Among other applications, let us also mention some local applications for specific cities, like Transilien  [60]  for Paris, MVV  [61]  for Munich, or RTC  [62]  for Las Vegas. Even though such applications and software solutions are widely available and highly accepted, there is still a lot to be done (particularly for buses) in terms of accuracy for both long-and short-term prediction. The following section details the considered simulation scenario considered in our work.
The next step is of crucial importance for the learning stage. It involves the data split and the cross-validation, which were achieved as follows: • Total number of simulations 12000. • Training dataset -80 % (9600 simulations). • Test dataset -20 %, (2400 simulations), from which: 10 % (240) were used for validation, and 90 % (2160) for evaluation purposes. A data normalization procedure was included based on the following equation (1): 𝛾 𝑛𝑜𝑟𝑚𝑎𝑙𝑖𝑧𝑒𝑑 = 𝛾-𝜇 𝜎 (1) where: • ℽ: the data considered (denoting both the TDM matrix D and and the arrival time vector a), • µ: is the mean of (ℽ), • : is the standard deviation of (ℽ), The data normalization procedure has two benefits. On one hand, in many cases, it makes it possible to speed up the convergence rate of the training procedure. On the other hand, in the case of neural networks-based approaches, it allows increasing the number of neurons in the hidden layers.
A. OLS The first, basic machine learning technique that we have adopted and implemented is the Linear Regression  [43]  also known as OLS (Ordinary Least Squares). Here, we have used the implementation available in the Scikit-learn machine learning toolbox  [68]. The OLS approach fits a linear model to minimize the residual sum of squares between the observed targets in the considered dataset. Ordinary Least Squares (OLS) is the simplest machine learning technique retained.
Different kernel functions can be specified. In our case, we have adopted the SVR implementation available in the Scikit-learn library and used it for both operator (ODM) and client (CDM) data models. Two different SVR kernels have been considered: RBF (Radial Basis Function), and Polynomial (2 nd degreequadratic kernel). We have not considered the SVR with a linear kernel since in this case, the results are equivalent to those achieved by the OLS technique.
The best computational performance cTIME is achieved by OLS (with a high penalty of overall performance), with 818 seconds. The LSTM approach comes in the second position, with 1332 seconds. Let us also note that all the deep learning approaches considered are significantly more efficient in terms of computational effort (with cTIME values ranging in the [1332-1659 seconds] interval, than the SVR techniques (with cTIME values exceeding 12000 seconds). The EPOCH parameter presents the total number of times where the whole dataset was browsed during the learning stage. The smallest number of epochs to train successfully the model was CNN with 104 epochs in total, as illustrated in Figure  21. Here, the learning curves between different models and their performance are also presented. The training loss is presented with the red line and the validation loss is represented by the blue dotted line.
MAE = Mean Absolute Error (s), minMAE = Minimum MAE, maxMAE = Maximum MAE, MEDIAN = Separating higher from lower half in dataset, STD = Standard deviati cTIME = Computational Time in (s), EPOCHs = One whole dataset iteration, OLS = Ordinary Least Squares, SVR = Support Vector Regression, FNN = Feedforward Fully connected Neural Network, CNN = Convolutional Neural Network, RNN = Recurrent Neural Network, LSTM = Long-Short Term Memory.
2019a). It is in La Argentina Manuscrita that, among others, we find the first description of the Rio de la Plata region in Spanish. 4  The workflow demonstrated here includes technologies such as TEI-XML, the standard markup for text in the Humanities developed by the Text Encoding Initiative (TEI) Consortium 5  and Linked Open Data (LOD) 6  -but the good news is that you don't need to have any prior computing expertise related to these technologies to use Recogito. 7.