Re: CRS specification

> Aside, I thought that geof functions were defined at
> http://www.opengis.net/def/queryLanguage/OGC-GeoSPARQL/1.0/function/ but
> this returns 404. Do you know where is the latest specification of the geof
> functions?
>

The functions defined by GeoSPARQL are defined at the pdf
https://portal.opengeospatial.org/files/?artifact_id=47664.

 GeoSPARQL and stSPARQL offers a function for selecting the CRS of a
>> geometry, and you can use a simple regex to get just the coordinates. As
>> you say, this is for specific use cases, so why reinventing the wheel
>> and not use existing standards?
>>
>
> The regex is not necessarily simple. This is a trade-off, as for many
> choices made when designing a language or when implementing a system. You
> could do many things with pure regex, but still we don't encode all the
> world knowledge in one massive literal. This is not reinventing the wheel,
> this is just designing a model that suits well some common use cases.
>
>  The most important aspect of having the CRS inside a spatial literal, is
>> that it relies on RDF and nothing more thus making it a good choice for
>> the linked open data world.
>>
>
> But I'm reversing this argument. By doing so, either you require to query
> with regex, or you require to have GeoSPARQL support and you're out of the
> current linked data world!
>

>  What you propose has to be encoded as an OWL 2 ontology with the
>> appropriate cardinality restrictions, and then the users are forced to
>> adopt this ontology.
>>
>
> Nobody is forcing anything. When you query a dataset that makes use of
> some vocab, then of course, you need to know this vocab to write queries.
> What you're enabling instead is a user to just use PLAIN SPARQL queries.
>

You are right about the distinction between a SPARQL search engine and a
GeoSPARQL/stSPARQL enabled one. I have been working on this for quite a
while so I was bit biased and did not get that essentially you were talking
about
staying compliant to standard SPARQL :)

In this context, I understand the need for using an extra triple for
representing
a CRS that is available for a geometry, in the sense that this information
is
metadata about the serialization of the geometry. So essentially, there is
the
need to export some geospatial functionality to standard RDF/SPARQL. To do
so, one must export properties of a geometry to plain RDF triples, but not
its
serialization. The problem is where to start and where to stop.

The OGC-Simple Features Access standard defines functions that request or
check properties of a geometry (e.g., isSimple, isEmpty, Dimension,
GeometryType, SRID), function that test test topological relations (e.g.,
contains),
and functions that construct new geometries from existing ones (e.g.,
buffer).
GeoSPARQL took most of the functions that check or return properties of
a geometry (all but SRID if I am not mistaken) and defined properties with
the
same name (e.g., the properties geo:isEmpty, geo:isSimple) so that one
would
be able to assert whether a geometry is empty etc. This is defined at the
Geometry Extension component of GeoSPARQL.

GeoSPARQL has six modules: the Core vocabulary, the Topology Vocabulary
extension, the Geometry extension, the Geometry Topology Extension, the
Query Rewrite extension, and the RDFS entailment extension (we have
some nice figures in
http://cgi.di.uoa.gr/~kkyzir/publications/tutorial-rw-2.pdf
, pages 39, 42).

I think that a good choice for representing metadata about geometries would
be to
adopt the vocabulary defined by the Geometry Extension component of
GeoSPARQL.
Note that this is just a vocabulary and nothing more (i.e., no geospatial
extensions are
needed for supporting this vocabulary). Standard SPARQL engines need no
GeoSPARQL extensions to support this vocabulary.


>  The linked data story so far (even though I do not
>> entirely agree with this :) ) has shown that the only way to achieve
>> adoption is by enforcing as few restrictions as possible.
>>
>
> Exactly ... thus not necessarily embark with a stack of technology (SPARQL
> + GeoSPARQL). I have nothing against GeoSPARQL, this is a great extension.
> But I'm pragmatic, and AFAIK, there are way many more SPARQL endpoints in
> the wild than GeoSPARQL ones.
>

This is true. However, we should be careful not re-designing yet-another-
SPARQL-version-of-GeoSPARQL and call it a new vocabulary :)
This is why I think that this vocabulary should not define a way to
represent
geometric information, but just provide the links to other standards
like W3C basic geo vocabulary, GeoSPARQL etc. that will deal with the
serialization of geometries.
The main conclusion that all geospatial RDF extensions have reached, is that
you cannot represent geometric information without extending RDF and SPARQL.
So, I think that this standard may represent all metadata that are
neccessary, but
delegate the representation of geometric information to other standards
(like W3C
basic geo vocabulary and GeoSPARQL).