- From: Carlos Buil Aranda <cbuil@fi.upm.es>
- Date: Tue, 29 Mar 2011 14:04:07 +0200
- To: SPARQL Working Group <public-rdf-dawg@w3.org>
- Message-ID: <4D91CAB7.3000805@fi.upm.es>
some more comments, these are about what it was discussed in GeoVocamp a week ago. There people say that geoSPARQL defines geometry using a literal (with GML or WKT) but people in GeoVoCamp think that is is important to make geometry explicit in RDF allowing access to different representations via content negotation (http://vocamp.org/wiki/Geometry-vocab and http://code.google.com/p/neogeovocab/ ) Carlos -------- Original Message -------- Subject: review of the GeoSPARQl specification Resent-Date: Tue, 29 Mar 2011 10:59:29 +0000 Resent-From: public-rdf-dawg@w3.org Date: Tue, 29 Mar 2011 12:57:40 +0200 From: Carlos Buil Aranda <cbuil@fi.upm.es> To: SPARQL Working Group <public-rdf-dawg@w3.org> Dear all, here come my comments about the GeoSPARQL specification. There is a typo in item 1.2.4.3 which described LineString class, there is the name Curve instead of LineString in the URI identifying the resource In t he SimpleFeature object from OGC we came up with the following questions: to what is referring the ArcString class, is the same class than SimpleFeature in OGC? Wht there is no class LinearRing in the model? Why compose relations such TIN which is composed by triangles or MultiPoint are not taken into account? Why envelope and boundary attributes are taken into account as filter function and not as class properties? In general this model is widely used, Virtuoso and other implementations (like geometry2rdf) in general follow the same approach than the one described in the specification. Cheers, Carlos
Received on Tuesday, 29 March 2011 12:04:35 UTC