Earth Observation (EO) data are becoming a ubiquitous and readily exploitable source of data for decision making. The openEO platform is a renowned solution to query EO data using webAPIs. Running integrated queries encompassing both EO data and data from diverse domains is achieved using Knowledge Graphs (KGs). However, the volume of EO data makes its materialization in a knowledge graph impractical. In this contribution we look at the integration of data from openEO with other data sources using the Virtual Knowledge Graph paradigm, providing the advantages of KGs while avoiding the need of creating copies of the data. Our approach enables answering cross-domain user queries over openEO federated with data coming from other sources.
perform cross-domain queries from EO data to other domains, and leverage the VKG approach to avoid storing any EO data locally.
The paper is organized as follows: Section 2 reviews related work, while Section 3 details the paradigm and outlines preliminary implementation details in Ontop. Finally, Section 4 ofers concluding remarks and discusses future research directions.
Software solutions are available to query raster data, including, e.g., relational database extensions such
as PostGIS3 in PostgreSQL, or multi-language solutions such as RasterFrames4 (using Python, Scala, and
SQL). However, the challenge of analyzing EO data and specifically their raster representation using
knowledge graphs has not yet garnered consensus. The Spatial Data on the Web Working Group [
Research has been conducted on extending the GeoSPARQL syntax for vector functions to raster data,
and respective prototype implementations have been built. GeoSPARQL+ [
Additional approaches [
The Plato data cube semantic [
OntoRaster [
Most of the research detailed earlier focuses on modelling EO classes and properties, as well as functions that extend the oficial GeoSPARQL standard, instead of considering comprehensive EO raster functions. Function calls that can execute raster or EO functions over remote endpoints have been discussed and implemented for Apache Jena and Virtuoso [15, 16], even including the definition of LDScript [17], a Linked Data script language on top of the SPARQL filter expression language. Descriptions of custom EO-related SPARQL functions, have been developed so that their signatures and expected output are independent of the development context, to facilitate interoperability [18].
A further contribution in this direction is the development of a module within the RDF Mapping Language (RML) called RML-FNML [19]. Rather than integrating a fixed set of functions, RML-FNML enhances RML with declarative function descriptions using the Function Ontology (FnO)7, providing a more flexible and extensible approach. Practitioners are realizing that built-in functions in RML systems are insuficient to handle the heterogeneity in input data and to address data processing tasks where more flexibility is needed [20]. User-defined functions can be therefore introduced and prototypes for RML with custom functions have been demonstrated.
We extend here the OntoRaster framework [
Several openEO cloud-based infrastructure providers exist which provide computing resources, storage capacity and the networking capabilities required to handle large scale data processing requirements. Two such platforms are Copernicus8, hosted by Copernicus Data and Information Access Services (DIAS), and the one hosted at the Institute for Earth Observation at EURAC Research9. Platforms such as the one managed by EURAC provide, in addition to Sentinel satellite data10, a better integration with regional datasets.
EO data is typically represented as raster data, structured as an n-dimensional data cube that encapsulates all collected dimensions. The data is retrieved primarily from satellites, e.g., Sentinel constellation. Datacubes are routinely filtered by domain experts based on spatial extent, temporal extent, and the light band of interest. In a datacube with dimensions , , , where is the longitude (east-west), the latitude (north-south) and the time, each spatio-temporal coordinate is associated with one or more values corresponding to the spectral bands dimension. For example, the satellite Sentinel-2 has 13 individual bands (including, e.g., B02, which captures visible blue light, useful for water body analysis and atmospheric studies).
We will conduct our analysis and demonstration using openEO data accessed through the Copernicus Data Space Ecosystem. Our study focuses specifically on cities within South Tyrol, utilizing municipal boundary shapefiles obtained from the regional geocatalogue 11 as our vector data.
8https://dataspace.copernicus.eu/analyse/openeo 9https://www.eurac.edu/en/institutes-centers/institute-for-earth-observation/projects/openeo 10https://sentinels.copernicus.eu/ 11https://geonetwork1.civis.bz.it/geonetwork/geonetwork/ita/catalog.search#/home
Queries over the openEO Web API are expressed as a JSON process graph12, a directed acyclic graph where nodes represent individual processes, and edges define the flow of data between them, and with exactly one sink node (returning the final result). A process in openEO is an operation that performs a specific task on a set of parameters and returns a result [ 21]. Processes are applied sequentially in the process graph, e.g., a first process can load a collection of data and a second process can take the result as input to filter that data. Individual processes can also be applied as subprocesses, e.g., statistical functions such as mean, maximum, or minimum applied over the temporal dimension. 3.3. Ontop As OBDA system, we use Ontop v5.2.0, providing query answering capabilities over VKGs. Ontop supports the RDF data model, the SPARQL13 query language, the OWL 2 QL14 profile of the OWL ontology language, and the R2RML15 mapping language. We have extended Ontop by implementing a set of SPARQL functions mapped to corresponding openEO functions. In our setting, a SPARQL query is able to emulate, through composition of SPARQL functions, a process graph which a user would specify either in the openEO python package or via web interfaces. Our implementation takes the SPARQL input and reformulates it into a corresponding process graph in JSON, which is then sent to the openEO endpoint for execution.
We illustrate our implementation with a query that uses the band S8 (thermal infrared) to approximate temperature (ignoring atmospheric efects). For this query, we defined the SPARQL function openeo:load_collection inside Ontop, and mapped it to the load_collection function of the openEO API. The function accepts the satellite name, start time, end time, spatial extent, and bands as arguments. These are then passed to a predefined PL/Python function, which in turn receives the process name (e.g., load_collection) along with the arguments.
PREFIX r d f s : < h t t p : / / www. w3 . org / 2 0 0 0 / 0 1 / r d f −schema #> PREFIX geo : < h t t p : / / www. o p e n g i s . n e t / ont / g e o s p a r q l #> PREFIX openeo : < h t t p : / / www. openeo − ontop . org #> SELECT ? a v g _ t e m p _ k e l v i n { ? g geo : asWKT ?geomWKT . ? g r d f s : l a b e l ?name .
FILTER (LANG( ? name ) = " i t " && ( STR ( ? name ) = " Bolzano " ) ) .
BIND ( "2 023 − 09 −0 1 T00 : 0 0 : 0 0 Z"^^ xsd : dateTime AS ? s t a r t _ t i m e ) .
BIND ( "2 023 − 09 −0 7 T00 : 0 0 : 0 0 Z"^^ xsd : dateTime AS ? end_time ) .
BIND ( " SENTINEL3_SLSTR " AS ? s a t e l l i t e ) .
BIND ( " S8 " AS ? band ) .
BIND ( openeo : l o a d _ c o l l e c t i o n ( ? s a t e l l i t e , ?geomWKT , ? s t a r t _ t i m e , ? end_time , ? band )
AS ? c o l l 1 ) . 12https://api.openeo.org/v/0.3.0/processgraphs/ 13https://www.w3.org/TR/sparql11-query/ 14https://www.w3.org/TR/owl2-profiles/#OWL_2_QL 15https://www.w3.org/TR/r2rml/
BIND ( openeo : r e d u c e _ d i m e n s i o n ( ? c o l l 1 , " t " , " mean " ) AS ? c o l l 2 ) .
BIND ( openeo : a g g r e g a t e _ s p a t i a l ( ? c o l l 2 , ?geomWkt , " mean " ) AS ? a v g _ t e m p _ k e l v i n ) . }
The vector data from the shapefiles is loaded directly into a geometry table in PostgreSQL 17 and its geometry extension PostGIS 3.5.0. Ontop already supports queries over relational databases with geospatial support such as PostGIS, but is limited to the Well-Known Text (WKT) RDF geometry serialization for GeoSPARQL functions.
PL/Python is a procedural language that exploits functions written in Python to return PostgreSQL query results with PostgreSQL datatypes. There is a well-maintained openEO Python client16 that can accept openEO process graphs as input. We use Python 3.11 with openEO 0.33.0 to connect to openEO cloud backends of choice, and shapely 2.0.2 to convert geometries expressed as WKT into a format that is compliant with openEO process graphs.
As part of the Python implementation, we create several templates for openEO processes, which can be completed with arguments coming from the SPARQL functions described above. The input retrieved from Ontop will replace each of the arguments named argi (see, e.g., the example below for load_collection). u n i q u e _ n o d e _ i d : { " p r o c e s s _ i d " : l o a d _ c o l l e c t i o n , " arguments " : { " i d " : arg1 , " s p a t i a l _ e x t e n t " : { a r g 2 } , " t e m p o r a l _ e x t e n t " : [ arg3 , a r g 4 ] , " bands " : [ a r g 5 ] }
}
We have shown how to query openEO Web API via SPARQL, using the Ontop VKG system and PostgreSQL as a federator with its PL/Python functions.
An area that we plan to further explore are User Defined Processes inside openEO, which would allow us to avoid the nesting of SPARQL functions and to use instead single functions calls over custom process graphs. We are currently working on a new mapping language in Ontop to further improve the mapping of geospatial concepts, rather than relying on SPARQL functions, as in our current proposal. E.g., incorporating notions from RML-FNML will allow the modelling of concepts at a higher level of abstraction, e.g., heatwaves and wildfires, again avoiding to use nesting of SPARQL function calls. This would also improve interoperability with other ontologies. A further question that arises is how to handle the important aspect of privacy in such a distributed, heterogeneous setting, which natural leads to the presence of data with diferent degrees of confidentiality. To address this, we are considering to incorporate into the new mapping language the facet of privacy-preservation, contingent upon the identity of the user running a query.
This work has been carried out while Albulen Pano was enrolled in the Italian National Doctorate on Artificial Intelligence run by Sapienza University of Rome in collaboration with Free University of Bozen-Bolzano. This work was supported by Agenzia per la cybersicurezza nazionale under the programme for promotion of XL cycle PhD research in cybersecurity – B83C24005640005. The views expressed are those of the authors and do not represent the funding institution.