- From: Raphaël Troncy <raphael.troncy@eurecom.fr>
- Date: Fri, 03 Jan 2014 18:13:06 +0100
- To: Kostis Kyzirakos <Kostis.Kyzirakos@cwi.nl>
- CC: Frans Knibbe | Geodan <frans.knibbe@geodan.nl>, Clemens Portele <portele@interactive-instruments.de>, LocAdd W3C CG Public Mailing list <public-locadd@w3.org>
Hello Kostis, [snip] > If we want to ask for urban areas that contain Syntagma square we can > write the following GeoSPARQL/stSPARQL query: > > SELECT ?ua ?uageo > WHERE { > ex:SyntagmaSquare geo:hasGeometry ?sgeo . > ?sgeo geo:asWKT ?sgeometry . > > ?ua rdf:type ex:UrbanArea . > ?ua geo:hasGeometry ?uageo . > ?uageo geo:asWKT ?uageometry . > > FILTER (geof:sf-contains(?uageometry, ?sgeometry)) . > > } Yes, this would work ... but only on an endpoint that supports this GeoSPARQL/stSPARQL function, not on any SPARQL endpoint. Adding an extra triple with the CRS information will enable *any* SPARQL endpoints to filter by CRS. The only other alternative is to rely on a complex regex expression in the filter clause. 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? > In this case I do not see how one could define precise semantics for > functions like newgeo:sf-contains without incorporating the CRS to the > parameters. I think that this will just be a more complex version of the > GeoSPARQL functions. > For this reason, I have a strong opinion on that > the CRS has to be embeded to the spatial literal. Otherwise we will have > to define a new query language as well :) I'm not arguing for choosing one or the other form of representation, but to enable both, because use cases are diverse. It is obvious that some functionalities (such as Transform) should better rely on a function but the information of the CRS used could (also) be made explicit with a dedicated property. > Whether it is worth having an *extra* triple with the CRS is a different > question. My opinion is that there should not be such a triple, because > this information can be derived (similarly to properties geo:isEmpty, > geo:isSimple). Right, like many things can always be computed at runtime. But there is a cost: availability of such a function in the triple store, performance, etc. That's why we we use declarative knowledge. 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:13:35 UTC