dataesr/scientific-paragraphs-categorization huggingface dataset:
depicts a pie chart of the number of IP addresses retained for different durations. Switzerland Canada India Netherlands Russia United Kingdom China France USA Germany 5. 04 3. 95 4. 52 5. 42 11. 59 19. 62 18. 39 21. 38 18. 93 36. 96 0 5 10 15 Retention Period (days) 20 25 30 35 40 Figure 6: Average retention period for the Top 10 contribut- ing countries. Countries ordered from highest number of IP ad- dresses in our dataset (top), to lowest (bottom).
Thus, a new current metric (I eq-IGCT ) has to be defined to compare efficiently IGCTs and IGBTs current capabilities. This new current metric should correspond to a generic MMC case (it is not specific to one MMC implementation in particular) and has of course to be based on data available in the IGCT datasheet. The goal is to build a current metric comparable to the dc-current quoted in IGBT datasheets I dc-igbt , considering the actual current waveforms in a MMC. The worst case for the IGCT -i. e. when the IGCT is subject to the maximum possible current -is when the submodule is inserted for an entire ac period. Considering the asymmetric operation of the MMC (because arm currents have DC and AC components), one of the IGCTs will be subject to more current than the other. These IGCTs currents have their waveforms drawn in figure  2 , assuming the current of the ac output of the MMC is perfectly sinusoidal.
Model Description As it can be seen in the literature (see Tab. III), IGCTs are always found to cause less losses than IGBTs. However, the estimated amount actually varies noticeably from one publication to another because it depends on many factors: MMC ratings, control methods, operating points, not all of which are disclosed in the corresponding publications. As a consequence, it is difficult to use published results to validate our FOMs. That is why a simple MMC model has been developed, focusing on the individual behaviour of each submodule (capacitor and semiconductors). This model is used to validate the FOM approach. The model is written as a Matlab script. The modelling assumptions are as follows: perfect sinusoidal current in the arm and perfect sinusoidal voltage across the arm for the ac components of current and voltage; arm inductor, line resistors and energy exchange between arms not modelled; only one arm considered.
Semantic technologies are at the core of Earth Observation (EO) data integration, by providing an infrastructure based on RDF representation and ontologies. Because many EO data come in raster files, this paper addresses the integration of data calculated from rasters as a way of qualifying geographic units through their spatio-temporal features. We propose (i) a modular ontology that contributes to the semantic and homogeneous description of spatio-temporal data to qualify predefined areas; (ii) a Semantic Extraction, Transformation, and Load (ETL) process, allowing us to extract data from rasters and to link them to the corresponding spatio-temporal units and features; and (iii) a resulting dataset that is published as an RDF triplestore, exposed through a SPARQL endpoint, and exploited by a semantic interface.
Introduction Earth Observation (EO) is a domain that has greatly evolved in the previous years thanks to large-scale Earth monitoring programs, such as the US Landsat Program (https://www. usgs. gov/landresources/nli/landsat) and the EU Copernicus Program (http://www. copernicus. eu/en). In particular, with the Copernicus program launched by the European Space Agency (ESA), data are collected by satellites and combined with observation data from sensor networks on the Earth's surface. Nowadays, two types of Sentinel satellites are in production, several others being expected by 2030. Since 2015, Sentinel-1 and Sentinel-2 deliver high-quality Earth images (estimated between 8 TB to 10 TB of data daily), providing users with free, reliable, and up-to-date Earth image data and metadata. The availability of these data sources opened opportunities to better support existing domain-oriented applications and to boost emerging new ones, from agriculture to forestry, environmental monitoring to urban planning, climate studies, and disaster monitoring.
However, rasters are not human-readable. The interpretation of their content, either by users of decision support software tools, requires higher-level descriptions, based on the representation of spatial and temporal features. In the EO field, one fundamental type of data is the Earth's surface coverage or land cover (e. g. , water, croplands, or urban). In many cases, land cover information is provided as a raster linked to a text file containing the naming convention of the land cover classes. Each pixel in the raster file is associated with one of these classes. These rasters may come in different formats. They are produced by different services as a result of massive time-series image processing under different resolutions  [2]. Examples of land cover classifications are the Global Land Cover Share (GLC-SHARE), the European Corine Land Cover (CLC), and the French CESBIO Land Cover (CESBIO-LC).
• A third contribution is the dataset resulting from the integration process of three different sources that we used for experimental validation: land cover data of a specific French winery geographic area, its administrative units, and their land registers. Stored and published as an RDF triplestore, it is exposed through a SPARQL endpoint and exploited by a semantic query interface. Given a period and a village name or a geographic area defined by its geometry, one can retrieve the land registers in this area and the evolution of their land cover during this period. These data serve as the basis for three scenarios: integration of time series observations; EO process guidance; and data cross-comparison. This work extends the work in  [6]  by (a) representing the metadata and provenance of the data sources using the DCAT and PROV-O vocabularies, and the data themselves by extending the SOSA vocabulary; (b) considering data extracted from rasters as observable properties, which makes the model generic enough for accommodating any kind of properties (e.
g. , land cover, change indicator, or vegetation index) as long as they are available in raster format. This work is carried out in the context of the CANDELA project (http://www. candela-h2020. eu/) that aims at providing building blocks and services allowing users to quickly use, manipulate, explore, and process Copernicus data together with large sets of open data. One of the motivations to build such a platform is that searching for images using only their original meta-data, mainly using the sensor type, the capture date, and the location is not sufficient to find relevant images for a specific purpose. Contextual information, coming from different heterogeneous data sources, such as rasters, may be useful as well as a semantic search module. The paper is organized as follows. Section 2 discusses the main related work.
In  [9] , QB has been used for publishing tabular time series data and for structuring it into slices to support multiple views on the data. In a way similar to a spatio-temporal data cube, the semantic EO data cube  [10]  contains EO data where for each observation at least one nominal (i. e. , categorical) interpretation is available. Closer to our work but with an ontology-based data access (OBDA) approach, the model used in  [11]  extends three ontologies, namely Data Cube, GeoSPARQL, and OWL-Time, to offer access to Copernicus services. Rather, we have chosen SOSA to represent observation collections but alignments (https: //www. w3. org/TR/vocab-ssn/) exist between SOSA and QB vocabularies to describe observations as multi-dimensional data according to a data cube model. While some approaches aim at producing open linked datasets, other ones focus on the methodological aspects of interlinking heterogeneous data, as for sensor data products, as discussed in  [12].
Several ontologies have been interlinked to create the satellite INSAT-3D vocabulary. In  [13] , data-intensive environmental services are proposed based on EO data and data from government databases, national and European agencies. Our approach here is close to these studies in the sense that we guide the integration process on the top of an ontology reusing existing standards. Another close proposal is the one from  [3] , which carries out an ETL process to integrate EO image and external data sources, such as CLC, Urban Atlas, and Geonames. The process relies on their SAR ontology. Another similar work in terms of datasets is from  [14] , where data is integrated and published as LOD based on an ontology, called proDataMarket. Three data sources, the Spanish land parcel identification system, Sentinel-2 satellite, and LiDAR flights, are integrated.
The raster must consequently be imported into a PostGIS database before processing. In this approach, converting the all raster pixels into RDF significantly increases the number of triples, which in the end might cause performance issues. The second approach consists of extracting entities from raster files and representing them as ontological features. These entities are sets of raster elements (i. e. , sets of pixels) that meet a certain context-dependent definition. A prototype is presented in  [19]  to integrate and process scientific vector and raster data from LOD repositories using vectorization and mathematical tools for geo-processing. First, bounding boxes from raster are used to query LOD endpoints for geofeatures. Next, the returned geofeatures are used to select raster pixels for supervised training based on content-based descriptors.
Finally, the results can be vectorized, transformed, and inserted into the triplestore. In  [3] , the approach proposes to restructure the images in patches with a fixed size, to which contextual information is linked. In the end, each patch is directly transformed into a feature based on their ontology. A similar solution is implemented in  [20]  where the ontological features are road segments. By mapping their bounding boxes (1 meter around the segment) to the raster data, the pixel value in this area is compared to a threshold and determines the value of a semantic property of the road segment. The authors also propose to extend the SPARQL query language so as to manage standard geometric functions on both raster files and vector files. To do so, they polygonize the desired region of the raster.
The most similar approach that makes use of vector input (containing geolocated features) is  [19]. However, this work is not completed and the model has not been published. In Table  2  we distinguish two ways of performing semantic data integration: either a mediator is built for virtual systems (on-demand mapping) or data materialization is accomplished for persistent systems (data materialization). These are important aspects of the ETL process. For the on-demand mapping, data remains located in their source, as a consequence, SPARQL queries must be rewritten at the query evaluation step. This approach is well-suited in the context of very large datasets that would hardly support centralization due to resource limitations. For data materialization, like in warehouse approaches, data sources are transformed into RDF graphs that are thereafter loaded into a triplestore and accessed through a SPARQL query engine.
Our proposal applies the materialization approach. The major advantage of this approach is to facilitate further processing, analysis, or reasoning on the materialized RDF data. More specifically, this choice is motivated by the following reasons: (i) it is not easy to run an on-demand mapping since the data sources we considered (presented below) are available in different formats (JSON/GeoJSON, GeoTIFF image, shapefile or even remote compressed files), which requires a pre-processing step of conversion; (ii) Geospatial triplestores can be considered as a warehouse to store semantic data so that data enrichment and linking could be performed; and (iii) different datasets may be offered by different endpoints requiring federation mechanisms, however, there is currently no query engine mature enough for answering GeoSPARQL queries over such a federation  [11].
As we send a single GeoSPARQL query to examine the geofeatures stored in different places, spatial comparisons on the fly are not possible. [3] stModel X stSPARQL X [11] GeoSPARQL OWL-Time Data Cube X X X GeoSPARQL [13] stModel X stSPARQL [14] GeoSPARQL Data Cube, DUL X X GeoSPARQL [15] GeoSPARQL DUL GeoSPARQL X [16] SSN, CCO BFO, ENVO X X X SPARQL [17] none X SciSPARQL X [18] GeoSPARQL GeoSPARQL X [19] GeoSPARQL GeoSPARQL X [20] GeoSPARQL X GeoSPARQL X Ours GeoSPARQL OWL-Time SOSA, PROV-O TSN X X X X GeoSPARQL X.
An observation can be seen as an activity producing a calculated property value of the areas. Before presenting the TUM and TUOM models (Section 3. 2), we describe the state-of-the-art vocabularies on which they rely (Section 3. 1), namely GeoSPARQL (for geospatial data), OWL-Time (for temporal features), DCAT (for data sources metadata), PROV-O (for data sources provenance) and SOSA (for the observations).
). It is used to describe the temporal properties of the data. DCAT vocabulary (https://www. w3. org/TR/vocab-dcat-2/): DCAT is a vocabulary designed to publish metadata catalogs on the web. In DCAT, a catalog (dcat:Catalog) is a dataset in which each item is a metadata record describing some resource; the scope of the catalog is collections of metadata about datasets or data services. A dataset (dcat:Dataset) is a collection of data, published or curated by a single agent. The vocabulary combines elements from other vocabularies such as Dublin Core Terms (dct prefix): dct:temporal and dct:spatial are used to describe the spatial and temporal coverage of the dataset. An instance of the dcat:Distribution class represents a concrete implementation of a dataset (e. g. , raster, shapefile, etc.
In the SOSA vocabulary, an observation (sosa:Observation) is considered as an activity providing an estimation of a property value using a given procedure. It allows us to describe the related feature of interest and the observed property as well. SOSA reuses OWL-Time to date observations (sosa:phenomenomTime). The sosa:ObservationCollection class is an extension proposed in a current working draft (https://www. w3. org/TR/2020/WD-vocab-ssn-ext-20200116/). It represents a collection of observations that share a common value for one or more of the observation properties (e. g. , same sensor, same scene). Such a representation avoids the duplication of triples, and as a consequence, it optimizes data storage and reduces query execution time.
Territorial Unit Model (TUM) To represent different kinds of territorial units, such as administrative units and parcels, throughout their life, we propose the Territorial Unit Model (TUM) ontology that extends the TSN ontology described above. Indeed, since administrative units and land registers datasets are updated regularly, it is possible to manage different versions of their content. TUM introduces two classes, tum:AdministrativeUnit and tum:Parcel. They extend the tsn:Unit to take into account different timeslices of these entities through time. We use the PROV-O vocabulary for the management of the integrated sources. A territorial unit nomenclature version is thus considered as a prov-o:Entity that was derived from an (open) dataset, i. e. , an another prov-o:Entity. This source (tum:NomenclatureSourceDataset) is also represented as a dcat:Dataset whose distribution is in most cases a vector file containing geofeatures.
2. Raster data sources: A raster data source provides a matrix of cells (or pixels) where each cell contains a value representing the phenomenon considered by the source. Each cell covers a portion of the Earth's surface; the size of the cells is defined by the spatial resolution of the raster. Higher spatial resolution involves more cells per unit area. When cells contain class values (e. g. , land cover class), the classification must be provided to decode these values. Raster is the standard format of interchange between tools developed in the project, including tools for change detection and land cover classification from Sentinel images. Other formats will be considered in the next development. Our RDF dataset provides data computed from land cover rasters. Land cover rasters: Each pixel of land cover rasters provides information about the physical coverage of the Earth's surface at this place.
Coverage may be over forests, grasslands or croplands for instance. Each type of cover is associated with a number according to the specific classification, and the pixel value is set to one of these numbers. There are different sources of land covers, with their classification In particular, CESBIO-LC is mainly based on Sentinel-2 images acquired all year long, whereas GLC-SHARE combines various EO sources. Moreover, while the GLC-SHARE has global coverage, with a spatial resolution of 1000 m 2 per pixel, CESBIO-LC only covers France with a spatial resolution of 10 m 2. We selected the CESBIO datasets and the corresponding land cover classification because of its high-quality.
Semantic ETL Process We defined a four-step semantic ETL process to build an RDF triplestore from heterogeneous data sources: 1. Data retrieval: At this step, the datasets of interest are identified according to spatial and temporal criteria and retrieved using dedicated search mechanisms. This step can be done in a semi-automatic way with the help of dedicated scripts. For example, the dataset containing information of a French village can be retrieved based on its INSEE code and the publication year. In the case of land cover rasters, a detailed description of the land cover classes used to code the raster must also be retrieved. Such a vocabulary is usually described by a text (CESBIO-LC) or PDF file (CLC or GLC-SHARE).
2. Data extraction: This step aims at extracting and structuring data from the data sources. Firstly, metadata (e. g. , issue date, format, CRS, or spatial extent) is extracted. The, entity geometry in vector files is matched to the WGS84 CRS, which is the default CRS of GeoSPARQL. Rasters are processed to qualify territorial units: either new properties (e. g. , mean values) are extracted through pixel aggregation or a spatial mask is used to eliminate undesired areas (i. e. , only the area inside the unit footprint is preserved). For example, the land cover of a parcel is computed from a raster in three steps: (a) Reproject the parcel and the land cover raster onto the same CRS. (b) Apply the parcel (the geometry of the parcel version at a given date) as a mask on the raster. (c) Calculate the percentage of each land cover class occupying the parcel.
System Architecture The system is developed through docker technology. There are two dockers as described in Figure  4 : the first one contains Python scripts for data retrieval, data processing, data transformation, and triplestore bulk load, the second one is used to deploy the geospatial triplestore that manages the knowledge base. Currently, several triplestores support storing and querying spatial data using GeoSPARQL or stSPARQL. Those free that offer a good support are Parliament (http://parliament. semwebcentral. org/)  [28] , Strabon (http://strabon. di. uoa. gr/) [29]  and GraphDB (http://graphdb. ontotext. com/). They explicitly adopt the existing geospatial geometry standard, although many triplestores now support spatial queries of different complexity  [30]. While we have not tested Parliament, we did for GraphDB that performed poorly for the queries involving spatial joins.
Results and Discussion The results are evaluated with regards to the contributions of the resulting dataset to three use cases: integration of time series observations; EO process guidance; and data comparison. The areas of interest were chosen to answer to data requirements in the CANDELA project supporting different kinds of analysis from change detection to land cover evolution. The resulting dataset allows for users to homogeneously query the data, helping their tasks of information retrieval. Serving different use cases corroborates the contribution of our proposal in terms of a modular ontology that can accommodate different kinds of EO properties extracted from rasters along their spatial and temporal dimensions. The resulting semantic data was stored in a database that can be accessed through a semantic search interface or via a SPARQL endpoint (http://melodi.
irit. fr/tu/). The triplestore contains information about the French villages and their 2017 and 2018 versions. Out of 1377, 58 villages which are inside the zone of study (French departments 24, 33 and 47), were associated with parcel versions. The whole set results in 224,000 parcels (instances of tum:ParcelVersion) in the database. The CESBIO-LC information (2017 and 2018) is being updated based on the use cases and the user's need for analysis. While query performance is not optimal in the current publicly available version of the RDF dataset, performance and scalability have to be addressed in the future. An extended version of the dataset (including parcels and administrative units from other French departments) will be deployed on the CANDELA project platform. We present in the following paragraphs a basic user interface that allows for querying the dataset via SPARQL queries and visualizing the results with the help of a map.
Integration of Time Series Observations The resulting dataset provides information about parcels and administrative units (villages) of the three French departments. It also contains the details of the processed rasters. Users can make use of the knowledge base to monitor the land cover change through time. This can be done by examining all observations made on all parcel versions or administrative units. An example of a query involving parcels and its results is illustrated in Figure  5. It is observable that the land cover of the parcel 332260000A0012 has slightly changed between 2017 and 2018: vineyard decreased from 76% to 62% while urban fabric increased from 15% to 26%. As we keep track of the data provenance and the source metadata, it is possible to retrieve the details of the origin of the raster that has been used to generate an observation.
EO Process Guidance The dataset can also be exploited in diverse EO analysis processes. On the one hand, one can apply a set of algorithms on the returned query results, that contain spatial and temporal information (the parcels or related Sentinel images; and the period, respectively). On the other hand, the returned results can guide and boost the performance of the algorithms by providing precise spatial and temporal parameters (from the results of a query, we know on which region and for which period a specific analysis has to be carried out). It is then possible to make a pipeline combining semantic query with other modules like change detection or NDVI computation. More concretely, the dataset serves to two use cases of the CANDELA project: • Change detection in vineyards : the use case aims to detect changes in vineyard vegetation due to natural hazards such as frost or hail.
Data Cross-Comparison Another scenarioof exploitation of this dataset is the cross-comparison of information from various sources, including the results provided by the project partners. For example, it is possible to compare the CESBIO-LC information to the land cover annotated by DLR, a project partner; or to explain a change detection from unsupervised machine learning results, as provided by Thalès (another project partner). For the former example, while the results from DLR have not been included yet in the dataset, a manual comparison has been made from what is stored in our dataset and the land cover map generated by DLR.