Does Jena support GeoSPARQL 1.1?

[VladimirAlexiev]

Version

6

Question

@Aklakan, @SimonBIM, @LorenzBuehmann, @galbiston, @afs

Does Jena support GeoSPARQL 1.1?
I've looked at docs and javadocs (but not the source!) and they suggest it supports 1.0 but not 1.1:

• https://jena.apache.org/documentation/geosparql "An RDF/XML schema has been published for the GeoSPARQL v1.0 standard"
• https://jena.apache.org/documentation/javadoc/geosparql/org.apache.jena.geosparql/module-summary.html shows 1.0 terms (eg WKT, KML) but not 1.1 terms (eg KML).
• It shows GeoJSON (which is 1.1) but that is listed in https://jena.apache.org/documentation/geosparql/#future-work
• https://jena.apache.org/documentation/javadoc/geosparql/org.apache.jena.geosparql/org/apache/jena/geosparql/geof/nontopological/filter_functions/package-summary.html doesn't show the standard functions, eg area (1.0), metricArea (1.1). But search eg for "distance", there are many non-standard functions
• https://jena.apache.org/documentation/geosparql/#units-uri is good documentation (the OGC spec didn't even list what . But 1.1 added "metric" functions (where the unit is fixed to meters, and are guaranteed to work for metric CRS @MathiasVDA ) and I think this section should mention them

I also looked at existing issues:

• jena-geosparql changes for Jena6 #3593 doesn't mention that
• GeoSPARQL Docs update request #3717 is not it

Even if Jena has partial support for 1.1, it'd be extremely valuable to document exactly which .1 features it supports

• it seems to me that https://jena.apache.org/documentation/geosparql needs to be updated.
• this can also be stated in RDF, let me know and I'll dig out the OGC conformance turtles

---

@situx what is the status of https://github.com/i3mainz/jena-geo?

• It's 6y old, does it implement GeoSPARQL 1.1?
• Are there plans to merge it into Jena?

Thanks for any info!

[situx]

Hi @VladimirAlexiev ,

https://github.com/i3mainz/jena-geo and https://github.com/i3mainz/rdf4j-geo have been prototypical implementations to port POSTGIS functions to Apache Jena and RDF4J, respectively.
Most of these functions rely on the Java Topology Suite (JTS) in the background.

I can confirm, though, that these implementations do not support GeoSPARQL 1.1 because it did not exist at the time.
There is an overlap in the implementations of functions, but not 100%.

There are no further plans for these implementations, and admittedly, as you said, they are now 6 years old.
However, I think if there is interest, I could work on adding some or all of these functions as a pull request to Apache Jena mainstream.
We would need to agree on a namespace for non-GeoSPARQL geo functions and then I could begin adding these functions to what is currently in Apache Jena.

I can not do that immediately, though, since I am currently focusing on:

• GeoSPARQL 1.1 (and more) for rdflib here: https://github.com/situx/rdflib-geosparql (https://situx.github.io/rdflib-geosparql/) based on shapely
• GeoSPARQL 1.1 (and more) for comunica here: https://github.com/situx/comunica-geosparql/tree/geosparql (https://situx.github.io/comunica-geosparql/) based on turf.js

I could start once these implementations are at a more advanced stage.

[Aklakan]

We would need to agree on a namespace for non-GeoSPARQL geo functions.

There are these existing non-GeoSPARQL geo namespaces in https://jena.apache.org/documentation/geosparql/

PREFIX spatialF: <http://jena.apache.org/function/spatial#> # F → Filter Functions
PREFIX spatial: <http://jena.apache.org/spatial#> # Namespace for property functions

We'd also be interested in contributing extensions if they are considered useful and not already covered by GeoSPARQL 1.1 or @situx 's work (It's been a while and we'd also need to check).

If I understand correctly, one central change in GeoSPARQL 1.1 is, that different unit ontologies can be mixed. So perhaps some kind of UnitRegistry would be needed. GeoSPARQL 1.1 also introduces unit-less metric properties (i.e. the value is an xsd:double assumed to be in meters) such as: https://docs.ogc.org/is/22-047r1/22-047r1.html#_property_geohasmetriclength

Relevant namespaces:

# GeoSPARQL 1.0 used uom:
PREFIX uom: <http://www.opengis.net/def/uom/OGC/1.0/>

# Afaik GeoSPARQL 1.1 should in addition support qudt units:
PREFIX qudt: <http://qudt.org/schema/qudt/>

@LorenzBuehmann and I were thinking that actually this would probably something that a coding agent should be able to get right to a high degree with high coverage (at least for the functions part): check which functions are in geosparql 1.1, compare to what's in jena and set up the TODO list. then familiarize with existing implementation style in jena. finally go through each function, upgrade/add it and then test it.
But so far we also didn't get around to try that out and since @situx already did so much work there, he might want to give it a try first :)

[nicholascar]

Hi all, in the GeoSPARQL meeting we just had, @situx, I and others agreed to establish a GeoSPARQL Extensions namespace (GeoSPARQL Issue 672) for things not yet in GeoSPARQL 1.1 but being tested for later versions.

If I understand correctly, one central change in GeoSPARQL 1.1 is, that different unit ontologies can be mixed. So perhaps some kind of UnitRegistry would be needed. GeoSPARQL 1.1 also introduces unit-less metric properties (i.e. the value is an xsd:double assumed to be in meters)

Correct.

We can easily add a unit registry to OGC Definitions Server (https://defs.opengis.net/prez/). In the best case, this would just be a collection of units already defined by QUDT.

I have previously linked subsets of QUDT's units to the QUDT Homepage, such as the Loop3d Profile, so if we create such vocabs, we could indicate them there too.

Here is a geology domain subset of units: http://linked.data.gov.au/def/geou. We could make a spatial or perhaps semantic spatial one (and replace the OGC's various bad ones).

[VladimirAlexiev]

So there is no full GeoSPARQL 1.1 implementation in Java? We at Graphwise are setting out to make one.
Most likely, we'll start from this one, extend it to cover all of 1.1, and also port it to rdf4j