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

I like Adrian's suggestion of having a single property rather than separate
asWKT and asGML etc, as the datatype could provide that info, and for most
of the standard geo formats, specification of coordinate reference system
could be part of the literal contents.  You could have more than one value
of that property if you wanted to offer multiple formats or CRS.

The cases where you might want more than one geometry (as opposed to more
than one serialization) and hence need a separate geometry node might be to
support different levels of generalisation, or perhaps a 2D geometry vs a
3D geometry.

On Wed, 29 Jul 2020 at 13:53, Frans Knibbe <fjknibbe@gmail.com> wrote:

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