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 Tuesday, 28 July 2020 22:57:09 UTC