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

It is good to know that a revised specification will be available in HTML.
That could also increase the ease of use of conformance tests, which often
refer to external documents. Hyperlinks can come to the rescue. Along the
same line, having the ontology available in JSON-LD could also increase
ease of use (this is on the wish-list already).

Regarding conformance tests and sample queries, they are now covered in
appendices A and B of the GeoSPARQL specification
<https://portal.opengeospatial.org/files/?artifact_id=47664>. I will gladly
believe that there is room for improvement there. An issue about that has
not yet been reported. Such an issue report would be strengthened by good
examples of why the current example queries or conformance test fall short.
Any suggestions? If it can be demonstrated that the conformance definitions
leave room for software implementations behaving differently from each
other that would be a strong reason to push a fix.

I'm not sure I follow Adrian's remark about geometry being on its own node.
Does it mean that for really simple use cases it should be possible to
relate a spatial feature to a geometry that describes it using a single
triple? In which case there should be something like a geometry datatype?
That would be an interesting suggestion. In its present state, I think
GeoSPARQL is already cramming too much information in the literals that
contain coordinate lists. So it seems there are varying demands for
complexity of expressions of geometry. I guess it won't hurt to ask for a
simple geometry datatype for ease of use. That would make it similar to
expression of time: you can use the XML datatype or more complex
expressions using OWL Time <https://www.w3.org/TR/owl-time/>.

About limited success combining spatial data from different sources: I was
specifically asking about that because one of the ideas for upgrading
GeoSPARQL is to turn it into a specification/ontology for *all* spatial
data, not just geographical data. It could do a world of good, see
https://github.com/w3c/sdw/issues/1095 for more information. So I really
wonder if people in this group think it is a good or a bad idea.

Regards,
Frans

Op wo 29 jul. 2020 om 01:04 schreef Cox, Simon (L&W, Clayton)
<Simon.Cox@csiro.au>:

> 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
>
>