Re: CRS specification

Hello,

> What happens though if you merge the following graphs:
>
> ex1:myGeometry ex2:asWKT "POLYGON((97372 487152,97372 580407,149636
> 580407,149636 487152,97372 487152))"^^ex2:wktLiteral ;
>                            ex2:CRS
> <http://www.opengis.net/def/crs/EPSG/0/28992>
> <http://www.opengis.net/def/crs/EPSG/0/28992> .
>
> ex1:myGeometry ex2:asWKT " POLYGON((4.54103559631648
> 52.369221013436,4.52469206625503 53.2071950151372,5.30692041653441
> 53.210266927542,5.30843905756704 52.3722183594399,4.54103559631648
> 52.369221013436))"^^ex2:wktLiteral ;
>                            ex2:CRS
> <http://www.opengis.net/def/crs/EPSG/0/4326> .

Well clearly, one would need a compound object that embeds the WKT and 
the CRS information, this can be a blank node.

>      1. It should be possible to specify the CRS at the level of a data
>         set or a collection of geometries.
>
> Anyhow, WKT and GML provides geometry collections like MULTIPOINT,
> MULTILINESTRING, MULTIPOLYGON etc. so you have specify a single CRS for
> a geometry collection.

Well, but a MULTIPOLYGON is not the same thing than a collection of 
POLYGON !

>      1. It should be possible to easily select data based on CRS in
>         SPARQL queries.
>
>   GeoSPARQL and stSPARQL already provide a function for doing so.

What about plain SPARQL endpoints?

>      1. It should be possible to select only the CRS or only the
>         coordinates (for specific use cases).
>
> 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.

> 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.
Best regards.

   Raphaël

-- 
Raphaël Troncy
EURECOM, Campus SophiaTech
Multimedia Communications Department
450 route des Chappes, 06410 Biot, France.
e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~troncy/

Received on Friday, 3 January 2014 17:43:20 UTC