dataesr/scientific-paragraphs-categorization huggingface dataset:
Collections and Containers. RDF containers represent open sets of RDF terms, ordered (rdf:Sequence) or unordered (rdf:Bag, rdf:Alt). Their member terms are denoted with the rdf: n properties 1. RDF collections refer solely to type rdf:List that represents a closed-ordered list of RDF terms. An RDF list is built using cons-pairs; the first cons-pair of a list refers to an element of that list with the rdf:first property, and the rdf:rest to the remainder list. All list elements should be traversed via rdf:rest until the empty list rdf:nil. Generating RDF collections and containers in R2RML, while possible, results in a cumbersome and limited task. A container's properties rdf: n are typically generated only when a key in the form of a positive integer is yielded from the data source. By contrast, there is no elegant way to model a list's cons-pairs with R2RML if the list is of arbitrary length.
Due to the need for RDF containers and collections in several projects  [75] , e. g. , both the Metadata Authority Description Schema  [15]  and W3C's XHTML Vocabulary  [7]  use RDF containers, and both OWL [102] and SHACL  [68]  use RDF collections. The xR2RML  [76]  vocabulary supported the generation of nested collections and containers within the same data source iteration (e. g. , within one result among the results returned by the MongoDB database). Its vocabulary also allowed to change the iterator within a term map and yield nested collections and containers. By contrast,  [45]  provided terms for creating (nested) collections and containers from within an iteration (same row) and across iterations (across rows) and provided a property for retaining empty collections and containers.
RML-Core: Schema Transformations The RML-Core is the main module of the RML ontology, which generalizes and refines the R2RML ontology; all the other modules build on top of it. The RML-Core ontology consists of the same concepts as the R2RML ontology (rml:TriplesMap, rml:TermMap, rml:SubjectMap, rml:PredicateMap, rml:ObjectMap, rml:PredicateObjectMap, and rml:ReferencingObjectMap), but redefines them to distinguish them from the R2RML counterparts. RML-Core refines the R2RML ontology by introducing the concept of Expression Map rml:ExpressionMap (Listing 4, lines 6 & 9). An Expression Map is a mapping construct that can be evaluated on a data source to generate values during the mapping process, the so-called expression values. The R2RML specification allowed such mapping constructs (template-based, column-based or constant-based) which can only be applied to subject, predicate, object and named graph terms.
The residual nonabsorbed power of the beams will be attenuated in the beam dump located in the EP-17. Fig. 2. Left: deposition access of the EL and ULs across the plasma cross section and categorized based on driving counter (cnt) ECCD (shaded red), co-ECCD (shaded green) or pure heating (shaded blue), considering 1MW gyrotrons. Right: radial coverage of EC system when steering the poloidal angle for each mirror of the EL and ULs, as simulated with the TORBEAM wave code  [3].
The Integrated Modelling & Analysis Suite The ITER Integrated Modelling and Analysis Suite IMAS is the collection of physics software that will be used to support ITER operation and research as defined in the ITER Integrated Modeling Programme  [6]. It uses standard Interface Data Structures (IDS) to represent experimental and simulated data. IDSs are used to get/put data from/to storage, they are applicable to any fusion device, and they are passed between IMAS physics models to build up integrated modelling workflows. The global set of IDSs represent the IMAS Data Dictionary. IMAS will be capable of high physics fidelity predictive simulations of ITER plasmas and will be used for ITER data processing and analysis. IMAS is only used for off-line analysis so it will not be used as part of the Plasma Control The use of a standard data model such as IMAS offers a great level of modularity and flexibility, ensuring the use of identical input data when changing model, making it ideal for code benchmarking: for example, excellent agreement was recently found in between TORBEAM  [3]  and GRAY  [7]  in IMAS  [6].
Input and output data for EC modelling In IMAS, EC wave codes always receive a minimal set of input IDS data, which are:  equilibrium to describe the magnetic configuration of a given scenario  core_profiles which provides the kinetic profiles (densities, temperature, etc. ) for a given scenario  ec_launchers which provides the geometry of the EC system together with the configured waveforms, i. e. the scheduled time evolution of the applied power, polarization and steering angles. The results of EC codes in IMAS involve specific output IDSs. The evaluation of ECRH and ECCD is often performed using a wave code only. However, for more accurate results, wave codes can be associated to a Fokker-Planck calculation to simulate the evolution of the distribution of EC-accelerated electrons inside the plasma.
These two types of code provide their results using the following IDSs:  waves from EC wave propagation codes  distributions from EC Fokker-Planck codes As an illustration of EC wave modelling, Fig. 6  shows the ray tracing generated by the TORBEAM code  [3]  when taking its input from an ITER DT baseline 15MA / 5. 3T scenario of the IMAS database (130012/3/public/ITER) and the EC launcher geometry from the Machine Description database (120000/2/public/ITER_MD), applying power on all mirrors of the EL and all mirrors of one of the ULs. Fig. 6. EC rays read from the waves IDS generated by the TORBEAM code  [3] , for an ITER DT baseline 15MA/5. 3T scenario; the cold resonance layer is displayed in red.
The EC waveforms, as mentioned earlier, are part of the ec_launchers IDS, which contains both the static data (geometry of the system) and dynamic data (time evolution of the power, polarization, steering angles, etc. ) configured for a given scenario. For the time being, this dynamic data is configured in the ec_launchers IDS via a waveform editor, but it will ultimately be read from the pulse_schedule IDS, including the system latency time along with some operational variations, as illustrated in Fig. 8. In its current version, the geometry of the EC launchers stored in the MD database is described at the level of the steering mirrors. However, to model the whole flexibility and capabilities of the EC system, each of the 56 beamlines of the five launchers will soon be defined in the MD database instead.
Experimental results We provide proof-of-concept implementations of our algorithms in SageMath. 6 Our implmentations include operation-counting code to verify the counts claimed in this article. We provide the number of operations for a given ℓ-isogeny and the extension field k. Table  3  displays the costs for our algorithm, highlighted in light gray, compared with the basic Costello-Hisil algorithm (Algorithms 1 and 3). As depicted in Table  3 , our approach consistently employs fewer operations across all values of ℓ and extension fields. For k of this size, it is reasonable to use the approximation F ≈ M (see §5. 1). Finally, Table  4  shows our success rate (over all primes ℓ < 10 4 ) at finding optimal MDACs for k ≤ 12. These rates are computed by choosing the minimal representative of each Galois orbit to be in S 0 , and checking whether the set S 0 can be computed without any intermediary additions (that would not be otherwise used).
This work was funded in part by a  FRIA  grant by the  National Fund for Scientific Research  (F. N. R. S. ) of  Belgium , by the  French Agence Nationale de la Recherche  through  ANR   CIAO  ( ANR-19-CE48-0008 ), and by a  Plan France 2030  grant managed by the  Agence Nationale de la Recherche  ( ANR-22-PETQ-0008 ). Date of this document:  2023-06-27.
, 2022 , Gonzalez Alba et al. , 2019 , Vavassori et al. , 2022). In order to develop accurate transportation and environmental models, however it is necessary to document the current state of the territory. For this reason, digitization and update of road network databases represents a crucial topic for a good management of critical infrastructures by public administrations  (Moscovici et al. , 2022). Since 2001, Italian road-owning agencies have been required by the Ministry of Infrastructure and Transport to build and maintain a road cadastre, i. e. , a mapping inventory of their road networks. Such architecture should include georeferenced information about streets as well as all ancillary elements regulated by road regulations, ranging from safety and protection assets to traffic signs  (Barrile et al.
METHODOLOGY The proposed methodology of mobile mapping solutions is built based on the existing software architecture for the management of the Road Cadastre inventory of Piacenza (Figure  1 ). Indeed, in agreement with the official national requirements, in 2019 the Province of Piacenza adopted and implemented a digital cadastre with GIS and WebGIS functionalities built on top of free and open-source software. In particular, on the server side, PostgreSQL is used as database management system together with the PostGIS extension for enabling the manipulation of geographical data. and QGIS for the manipulation of geodata. QGIS Server is used for the publication of web geographic services, while Liz Map PHP application is used for the dynamic generation of a web map application (Figure  2 ), with its user interface configuration.
Public administrators can access the geodatabase through QGIS Desktop, manipulating, updating, and styling vector and raster data. Before defining the required steps of mobile mapping, a preliminary phase was dedicated to understanding of how traffic signs are modelled inside the adopted DB model. Such elements are indeed implemented through a one-to-many relationship between an entity representing the sign holder (parent table with a point geometry) and another one for the signs themselves (child table ). In this way, it is possible to collect and manage individually information about each sign (main ones and supplementary ones as well) always linked to their support pole (Figure  3 ). Then, together with the road cadastre responsible, a requirement analysis was conducted to understand the specific needs for the application.
For this purpose, a series of test sites was chosen, identifying roads to be surveyed with different features or conditions. A diverse sample of test users was involved in the data collection activity, ranging from people with no previous experience in geospatial technologies to GIS technicians. Finally, the data collected with both applications were reviewed in QGIS environment in a validation phase aimed at identifying differences between the dataset, their completeness, their position accuracy and their coherence with a ground truth represented by photos of corresponding traffic signs taken on field with mobile devices. First, the validation consisted in checking if the mapped elements were located within buffers calculated along the surveyed streets and then evaluating the coherence between the street code inserted in the element field and the one of the roads in whose buffer such sign is included.
Hence, a similar approach was adopted for comparing the value of municipality associated to the single traffic sign to the administrative boundaries within which it falls. A semantic validation on the traffic sign type documented with the mobile mapping was conducted by comparing values with what was depicted in photos taken on field. The entire validation routine process was automatized as much as possible with Python scripts using the PyQGIS library. All the validation scripts together with sample dataset are included in a GitHub repository in order to make them openly reusable and adaptable to other specific project needs. An analysis on the synchronization process of the collected data on the original main database was evaluated too, marking different approaches involving plugins or automatic scripts.
The configuration files served as starting point for the definition of the graphical aspect of the graphic user interfaces of two applications. Then, first a training with the operators on the field was conducted, highlighting in details the differences of procedures in Qfield and ODK Collect: the first one takes advantage of a map-based view for the project, simply resizing in a small portion of the screen the data form to be filled (Figure  4 ), while the other one is built entirely on the form architecture, showing the map object when it is required to associate a position to the point that will represent the traffic sign holder (Figure  5 ). Both applications were adopted in an offline data collection approach, meaning that features or errors collected with the form are not directly synchronized with the main Road Cadastre database, but they are temporarily stored in the mobile device local memory and later processed with a validation procedure in order to filter out of the dataset gross errors and inconsistencies.
The surveyed roads consisted in a total length of 14 kilometres. After the data collection phase, the operators were supported in the data transfer from the mobile device to the desktop station, facing the different approaches for the two applications. While Qfield enables the possibility to directly query and visualise collected data (stored as geopackage) in a QGIS project, ODK Collect requires a pre-processing step in which the instances of the original form are interpreted and transformed with ODK Briefcase into tabular data (comma separated values format) readable in a GIS environment. Once pre-processed, both collected dataset is prepared for the validation phase for data quality assessment through predefined Python scripts. Eventually, operators previously engaged in the data collection are then engaged again in the synchronization of the data that satisfied the validation requirements with the traffic signs layers stored in the PostgreSQL database on the server, updating the existent documentation of this entities.
RESULTS The data collected on field with the chosen mobile applications were subjected to a validation process and compared with a subset of data previously collected with the traditional methods of field papers and reports. Hence, this step of the study is devoted to the data quality analysis aimed at quantifying spatial and thematic accuracy, as suggested by ISO 19157, through significant indexes and statistics to be compared within the different approaches of data collection. A first data analysis was conducted on the position associated to each traffic sign holder. Each entity is checked to ensure that its location is within the buffer defined around the road geometry stored in the Road Cadastre and modelled as lines corresponding to the street axis. To this end, a Python script that makes use of PyQGIS and Pandas libraries and loops through all the features contained in the sign holder dataset was developed.
In this case, an error of 8% linked to data collected with the old methods was reduced to 3% in the case of ODK Collect and cleared with Qfield. The same evaluation methodology was applied to the case of the municipality within which the signs are located, compared with the information contained in the "location" attribute of the data. Similar results were obtained: from 19% of the old method to 11% of ODK Collect and 0% with Qfield. This latter evidence can be associated to the use of base map in the main interface view, supporting the users with a direct reference when inserting the correct road code. Hence, a data completeness analysis has been conducted on two typologies of attributes: mandatory and null ones. The fields considered for the evaluation are "image" (not null), containing the photo of the signal, and "roadside_distance" (null), referring to the distance in centimetres of the sign holder from the roadside.
The validation analysis workflow was automatised through the procedural execution of scripts in QGIS, also supporting the validator user with cartographical output able to make more evident positioning accuracies and highlighting as well through selection on the attribute table commission errors and data incompleteness (Figures  8  and 9 ). Finally, an important consideration on the data post-processing and validation needs to be done when analysing the data synchronising in the QGIS project environment. While Qfield take advantage of the functionalities of an official plugin, ODK Collect data need to be converted from tabular format to a vector one, taking care of unicity of features identifiers (IDs). Moreover, when aligning IDs of collected data with the one already existing in the Road Cadastre DB, it is important to preserve the correspondence between primary and secondary keys of parent and children features of the holder-traffic sign(s) relationship.
CONCLUSIONS The insights resulting from the validation step and the user feedback suggested that FOSS solutions for mobile mapping could play a relevant role in public administration routine process. Procedural guided geo-referenced forms like the ones implemented in Qfield and ODK Collect reduce the presence of gross error in the data and involve actively even non-expert users in the digital documentation process. Moreover, the possibility of adopting low-cost and less time-consuming approaches for adding new elements or updating existing information represents a critical benefit for public administrations that, having an up to date accurate documentation of their assets, could better manage their interventions of maintenance. Following the pilot testing, the Province of Piacenza decided to officially adopt both Qfield and ODK Collect for mobile data collected at different level, integrating them in an already FOSS4G architecture based on PostgreSQL, QGIS and LizMap.
An example of traffic sign data is also shared in order to understand the layers data structure. In this way, interested users could easily adapt the code and the methodology to their own data collection needs. The repository is available at: https://github. com/labmgf-polimi/road-cadastre-traffic-signs. Last, in order to better support the routine operations for the monitoring of the Road Cadastre entities, a plugin based on the validation scripts is currently under analysis for the automatic data quality assessment of collected data. Indeed, a user-friendly graphic interface that implement code in Python language could become another valuable tool to be embedded directly in QGIS, helping public administration agent to easily calculate statistics and store them in a printable operation report, representing quantitative e qualitative metadata of the entire procedure.
5V star HD40307 available in ESO archives. We calculated the radial velocity using the standard cross-correlation function (CCF) method and Gaussian fit of the CCF, with uncorrected spectra and the ESPRESSO standard stellar binary mask on one hand, and telluric-corrected spectra and an augmented binary mask with 696 additional lines on the other. Results. We find that the precision of radial velocity measurements is improved in the second case, with a reduction of the average formal error from 1. 04 m s -1 down to 0. 78 m s -1 in the case of these ESPRESSO data and this stellar type for the red arm. Using an estimator of the minimal error based on the photon noise limit applied to the full CCF, the error is reduced from 0. 89 m s -1 down to 0. 78 m s -1. This corresponds to a significant decrease (by about 35%) in the observing time required to reach the same precision in the red part.
Overview of telluric correction existing techniques One prominent technique is the division of each spectrum by the spectrum of a fast-rotating star (the so-called telluric standard) observed as close as possible in time and direction to the science target. This method has the disadvantage of requiring substantial additional observing time and the spectrum is affected by features present in the standard star. It is well adapted to multiobject spectrographs; in this case a number of fibers are devoted to the telluric target stars, but it is not well adapted to highprecision radial velocity measurements. A second, data-driven category of techniques builds on a series of auxiliary observations. Among these,  Artigau et al. (2014)  used a series of hot, fast-rotating stars to construct libraries of empirical telluric absorption spectra and performed a principal component analysis (PCA) of the dataset.
These authors showed that the simultaneous adjustment of the first five principal components of an observed star spectrum allows them to obtain a good correction, to extend the spectral domain for RV extraction, and to increase the RV accuracy. A third category of telluric decontamination relies on realistic atmospheric transmission spectra. Extremely detailed models of the global atmosphere and of time-and location-dependent atmospheric profiles are now available, the most detailed being the Global Data Assimilation System (GDAS) and the European Centre for Medium-Range Weather Forecasts (ECMWF). These give the altitude distribution of pressure, temperature, and H 2 O concentration. Several tools have been constructed over recent decades to compute the resulting transmission spectra based on these profiles and the HITRAN molecular database  (Rothman 2021; Gordon et al.
2017). The MolecFit facility developed by  Smette et al. (2015)  and the Telfit tool by  Gullikson et al. (2014)  make use of GDAS atmospheric profiles, while the TAPAS online service (see  Bertaux et al. 2014 ) is extracting vertical profiles from the ECMWF. Both MolecFit and TAPAS use the state-of-the-art Line-By-Line Radiative Transfer Model (LBLRTM) code and the HITRAN database to compute the atmospheric transmission. Telfit and MolecFit also include software allowing users to correct spectral observations based on fits of the atmospheric transmission to the data, by adjusting the wavelength solution, a polynomial continuum and molecule abundances. To do so, MolecFit automatically retrieves the atmospheric profile at the time and place of the observations from an ESO repository. The advantage of this third category is the lack of a requirement for additional measurements and the adaptability of the methods to any instrument or observatory.
Very recently,  Allart et al. (2022;  hereafter A22) presented a fourth type of method for correcting stellar spectra from telluric absorptions. Similarly to the previous techniques, A22 use the HITRAN spectral data base to compute the transmittance of H 2 O and O 2 ; however, instead of a worldwide time-variable grid of detailed atmospheric altitude profiles, the authors model the atmosphere as a single layer, characterized by a unique pressure p, unique temperature T , and a global H 2 O column. The line profiles are less accurate, because the resulting atmospheric transmission does not take into account the different widths that correspond to different altitudes, contrary to the realistic atmosphere, but the advantage of this technique is the absence of a dependence on a meteorological field.
A22 adjust p, T , and H 2 O abundance by piling up 20 H 2 O lines in a CCF. Our work enters into the third category. Here, for the model of the Earth's atmosphere and the simulated transmission spectra, we used the TAPAS facility  (Bertaux et al. 2014). TAPAS 2 is a free online web service that simulates with exquisite detail the atmospheric transmission spectra due to the main absorbing species as a function of date, observing site, and either zenith angle or target coordinates. TAPAS uses the ESPRI/AERIS ETHER (a French Atmospheric Chemistry Data Center) facility to obtain pressure, temperature, and constituent vertical profiles of the ECMWF, which are refreshed every 6 h. These are used 2 https://tapas. aeris-data. fr/en/home/ to compute the atmospheric transmittance from the top of the atmosphere down to the observatory in each of 137 altitude layers based on the HITRAN database and LBLRTM  (Clough & Iacono 1995; Clough et al.