Allow geo predicates to operate on literals

[VladimirAlexiev]

Use case: the user draws a polygon on the map and wants to find all features within.

• The most natural way to do this is with a query where the polygon is given inline (rather than written to some temporary graph).
• but you cannot specify or make triples in WHERE. You can only test triple patterns for existence
• (You can make triples in CONSTRUCT, but only with "material" you already found with WHERE)
• So the only way to test GeoSPARQL data against geometries specified inline, is to use geof functions but not geo predicates.
  • https://graphdb.ontotext.com/documentation/10.8/geosparql-support.html#geosparql-support-example-2 gives an example with a function and the same with a predicate
  • https://opengeospatial.github.io/ogc-geosparql/geosparql11/document.html#C.2.2.2 gives example only with function
• The problem is that functions are much slower: they can only test but cannot generate candidate solutions
• So you have to fetch all geometries, then compare them against the inline polygon
• in contrast, predicates can use the spatial index to quickly find only matching ontologies

GraphDB has such a non-standard extension but a customer challenged it, and asked instead "to allow functions to use the spatial index". But I don't see how this can be done: functions cannot take unbound arguments, and cannot generate candidate solutions.

---

To implement this in the ontology:

• declare abstract Datatype ogc:geomLiteral as superclass of wktLiteral, gmlLiteral etc and subclass of rdf:Literal
  • I think but am not sure that literals can form class hierarchies
• declare SpatialObjectOrGeometryLiteral as union of SpatialObject and ogc:geomLiteral
• downgrade geo predicates from ObjectProperty to Property
• redeclare their range to be SpatialObjectOrGeometryLiteral
  • let's leave the domain as is because this is not valid in RDF (it's only valid in "generalised RDF" but that's a hypothetical beast):

# invalid
"literal" geo:sfWithin "literal"
 
# valid
<geometry> geo:sfWithin "literal"

More important than the ontology: give examples! (and conformance tests)

[VladimirAlexiev]

If this:

• Predicates should work on Geometry not SpatialObject #642

Is accepted, then the above proposal should change to use geo:GeometryOrLiteral rather than SpatialObjectOrGeometryLiteral.
Some turtle follows:

# is `ogc` same as `geo`??
ogc:geomLiteral a rdfs:Datatype; rdfs:subClassOf rdf:Literal.
geo:wktLiteral a rdfs:Datatype; rdfs:subClassOf ogc:geomLiteral.
geo:gmlLiteral a rdfs:Datatype; rdfs:subClassOf ogc:geomLiteral.
...
geo:hasSerialization rdfs:range ogc:geomLiteral.

geo:GeometryOrLiteral a owl:Class; owl:unionOf (geo:Geometry ogc:geomLiteral). # new
geo:sfWithin a rdf:Property; rdfs:domain geo:Geometry; rdfs:range geo:GeometryOrLiteral.
...

[mperry455]

Hi @VladimirAlexiev

The problem is that functions are much slower: they can only test but cannot generate candidate solutions

This looks like an implementation issue to me.

PREFIX my: <http://example.org/ApplicationSchema#>
PREFIX geo: <http://www.opengis.net/ont/geosparql#>
PREFIX geof: <http://www.opengis.net/def/function/geosparql/>

SELECT ?f
WHERE {
    ?f my:hasPointGeometry ?fGeom .
    ?fGeom geo:asWKT ?fWKT .
    FILTER (geof:sfWithin(?fWKT, '''
        <http://www.opengis.net/def/crs/OGC/1.3/CRS84>
            Polygon ((-83.4 34.0, -83.1 34.0,
                      -83.1 34.2, -83.4 34.2,
                      -83.4 34.0))
        '''^^geo:wktLiteral))
}

Can't you find candidate bindings for ?fWKT from the spatial index and then drive the triple pattern evaluations from there? Relational databases have used such techniques for decades.

[VladimirAlexiev]

@mperry455 You cannot because it will contradict SPARQL Algebra: a filter cannot generate candidates.
Trivial filters like filter(?x=<...>) can be converted to values ?x {<...>}, but filters on functions cannot be converted to a VALUES clause.