RE: Don't you use GeoSPARQL? [ was: Do you use GeoSPARQL?]

Hi all,

I like to add a bit more detailed explanation of my comment (@mathib) mentioned by Simon. 

As a researcher applying geometry in a LD-context for the construction domain, I worked together with Anna Wagner (TU Darmstadt) to develop a uniform description and linking method for geometry which differs on some points from GeoSPARQL 1.0. This work eventually resulted in three modular ontologies: OMG (https://w3id.org/omg#), FOG (https://w3id.org/fog#) and GOM (https://w3id.org/gom#). 
The goal was to support geometry of any existing geometry format (2D/3D, binary/text-based) and to allow it to be (1) described entirely as an RDF graph using a dedicated ontology (needs dedicated converters), (2) embed the entire content of an existing geometry file "as-is" in the RDF graph (similar to embedding the entire content of images in an HTML img tag) or (3) store a URL referring to a geometry file outside the RDF graph (similar to referencing an image in an HTML img tag). Note that GeoSPARQL 1.0 only supports GML and WKT geometry formats following approach 2 (embedding the content of such files inside RDF literals).

In our research we decided to do the following:
* use datatype properties to indicate the actual geometry format used (similar to GeoSPARQL but allowing any existing geometry formats, incl. GeoJSON and PLY binary (little endian) for example)
* use datatypes to differentiate between approach 2 and 3. In case of approach 2 for a binary geometry format, the datatype indicates the type of binary-to-text encoding (this is different from GeoSPARQL 1.0 where the datatype just repeats the info that was described via the datatype property, i.e. the geometry format used)
* in most cases, the geometry should have metadata describing the coordinate system it is defined in, but not all geometry formats support this natively inside the geometry description. We did this in RDF by first allowing a node between the "thing described by geometry" and the actual geometry description (similar to GeoSPARQL 1.0) and linking that node to a coordinate system URI (different from GeoSPARQL 1.0, where the coordinate system is added to the content of the RDF literal value)

Some example triples in turtle to describe the differences:
 @prefix geo: <http://www.opengis.net/ont/geosparql#> .
 @prefix omg: <https://w3id.org/omg#> .
 @prefix fog: <https://w3id.org/fog#> .
 @prefix gom: <https://w3id.org/gom#> .
 @prefix epsg: <http://www.opengis.net/def/crs/EPSG/0/> .
 @prefix inst: <http://example.org/data/> .
 
 ## GeoSPARQL 1.0 example of WKT geometry:
 inst:building1 geo:hasGeometry inst:building1-geometryA .
 inst:building1-geometryA a geo:Geometry ;
       geo:asWKT "<http://www.opengis.net/def/crs/OGC/1.3/CRS84> POINT( -40 20 )"^^geo:wktLiteral . 

 ## OMG/FOG/GOM example of GeoJSON and PLY binary (little endian) geometry embedded in an RDF literal:
 inst:building1 omg:hasGeometry inst:building1-geometryB , inst:building1-geometryC .
 inst:building1-geometryB a omg:Geometry ;
  fog:asGeojson_v2016 """{"type": "Point", "coordinates": [-40, 20]}"""^^xsd:string ;
  gom:hasCoordinateSystem <http://www.opengis.net/def/crs/OGC/1.3/CRS84> .
 inst:building1-geometryC a omg:Geometry ;
  fog:asPly_v1.0-binaryLE "DkR5dm..."^^xsd:base64Binary ; # shortened for readability
  gom:hasCoordinateSystem epsg:6190 .

 ## OMG/FOG/GOM example of GeoJSON and PLY binary (little endian) geometry referenced via its URL stored in an RDF literal
 inst:building1 omg:hasGeometry inst:building1-geometryD , inst:building1-geometryE .
 inst:building1-geometryD a omg:Geometry ;
  fog:asGeojson_v2016 "http://mydomain.org/myfile1.json"^^xsd:anyURI .
 inst:building1-geometryE a omg:Geometry ;
  fog:asPly_v1.0-binaryLE "../geometryFiles/myfile2.ply"^^xsd:anyURI . # also relative URLs are possible in this way

Note that it is also possible to shorten the pattern, if you don't care much for explicit coordinate systems (or other geometry metadata) in the RDF graph (unless using methods such as RDF reification, RDF* or named graphs to add such metadata):
 inst:building1 fog:asPly_v1.0-binaryLE "../geometryFiles/myfile2.ply"^^xsd:anyURI , "DkR5dm..."^^xsd:base64Binary ;
  fog:asGeojson_v2016 "http://mydomain.org/myfile1.json"^^xsd:anyURI .

So in short: it feels like GeoSPARQL 1.0 is a little bit redundant (repeating the geometry format in the property and the datatype) and we decided to replace the GeoSPARQL datatype with existing datatypes from XSD (custom datatypes are also possible for more exotic binary-to-text encodings). This design touches maybe on issues related in the parallel thread on bland nodes and datatypes.

Kind regards,


Mathias Bonduel
Doctoral researcher
Faculty of Engineering Technology
Technology Campus Ghent
Gebroeders De Smetstraat 1
9000 GENT
https://www.researchgate.net/profile/Mathias_Bonduel 


-----Original Message-----
From: Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au> 
Sent: woensdag 29 juli 2020 0:57
To: Adrian Gschwend <ml-ktk@netlabs.org>; semantic-web@w3.org
Subject: RE: Don't you use GeoSPARQL? [ was: Do you use GeoSPARQL?]

All new OGC specs are HTML. 
Earlier they used a modified template from ISO, because of a close relationship with ISO/TC 211. 
Thankfully that expectation is now broken. 
New OGC work is all hosted in GitHub using .adoc

Your comment about testcases/unit-tests is on point. 

Regarding JSON/GeoJSON - see https://github.com/opengeospatial/geosemantics-dwg/issues/99

@mathib also comments on the doubling-up of predicate and datatype, but also describes a requirement - if the datatype is relatively generic (like `rdf:JSON`) then the predicate can indicate a flavour or schema (`geo:asGeoJSON`). Discussion needed. 

Simon Cox

> -----Original Message-----
> From: Adrian Gschwend <ml-ktk@netlabs.org>
> Sent: Wednesday, 29 July, 2020 06:33
> To: semantic-web@w3.org
> Subject: Re: Don't you use GeoSPARQL? [ was: Do you use GeoSPARQL?]
> 
> On 28.07.20 22:06, Frans Knibbe wrote:
> 
> Hi Frans,
> 
> >   * Have you ever used GeoSPARQL? If so, any problems?
> 
> yes, love it. But it also sucks due to bad spec. Off the top of my head:
> 
> - spec is unreadable in its current PDF form. I tried to make a HTML 
> version myself once but gave up as the PDF is really utterly broken. 
> So please make this a proper HTML spec like SPARQL & co.
> 
> - I'm not sure if it's due to the bad spec, missing testcases for 
> developers (?) or lack of sample queries that clearly show how to use 
> it, but it was really hard for me to understand how I am supposed to 
> write a proper query that did what I wanted to do.
> 
> I'm good in SPARQL but I really did not dig GeoSPARQL for a long time.
> For a while I also had the impression that every implementation 
> (Fuseki vs Stardog vs Virtuoso) behaved differently or was broken. It 
> got better now but it's not a good sign if those who implement it 
> can't agree on it. Might be also related to:
> 
> - the fact that the geometry is on its own node does not make it easy. 
> I see the point in some use-cases (hasGeometry vs defaultGeometry for 
> example), but maybe there could be a simpler representation for 
> default use-cases
> 
> - why there is a asWKT property beats me. I mean we have datatypes and 
> we use them so why would one name the property according to the 
> datatype used in the literal? IMO there should be a neutral property 
> and based on the datatype of the literal the store figures out what 
> serialization it is. Also not sure what is hip in the JSON world today 
> but maybe it's time for some GeoJSON like support as well. Or whatever 
> is used in the web stack nowadays.
> 
> >   * Domains like geography, astronomy, biology, computer graphics, web
> >     graphics, building information modelling (BIM) and computer aided
> >     design (CAD) all use spatial data. Have you ever tried to somehow
> >     combine different types of spatial data or spatial knowledge? If so,
> >     how was that experience?
> 
> the functions that everyone implements are rather basic and the rest 
> is often not straight forward to add so I had limited success with 
> anything besides default functions.
> 
> regards
> 
> Adrian

Received on Wednesday, 29 July 2020 11:47:35 UTC