[Requests] Comments to candidate OGC GeoSPARQL Standard

Michael Lutz michael.lutz at jrc.ec.europa.eu
Fri Aug 5 12:36:11 EDT 2011


Dear GeoSPARQL SWG,

please find some (mainly editorial) comments on the candidate OGC 
GeoSPARQL Standard below.

Best regards,
Michael & Sven

----------------
1. Requirement: General

2. Implementation Specification Section number: Introduction

3. Criticality: Editorial

4. Comments/justifications for changes: Clarify and/or highlight which 
of the paragraph(s) following "From http://dbpedia.org/page/SPARQL: " 
are taken from DBpedia


1. Requirement: General

2. Implementation Specification Section number: Title

3. Criticality: Editorial

4. Comments/justifications for changes: Given that GeoSPARQL defines not 
just "an extension to the SPARQL query language for processing 
geospatial data", but also "a vocabulary for representing geospatial 
data in RDF" in general, shouldn't this be added to the title or the 
title kept more general?


1. Requirement: General

2. Implementation Specification Section number: General, 8.5

3. Criticality: Minor

4. Comments/justifications for changes: The document mentions the Simple 
Features Specification (ISO 19125). What exactly does this imply in 
relation to the ISO Spatial Schema and the ISO Temporal Schema? Are both 
fully supported or either ‘only’ in parts?


1. Requirement: 18, 23

2. Implementation Specification Section number: 8.5, 8.6

3. Criticality: Minor

4. Comments/justifications for changes: geo:asWKT and geo:asGML are 
practical solutions for referring to different representations, but the 
use of MIME types might be discussed, too.


1. Requirement: General

2. Implementation Specification Section number: 9

3. Criticality: Minor

4. Comments/justifications for changes: When it comes to topologic 
relations, issues of tolerances and implementing several topologic 
models based on the same geometry might be discussed. Different users 
might be interested in different models. Years ago, Radius Studio 
offered a similar solution for Oracle Spatial. This might be an item for 
future work. Might this be reflected in the current GeoSPARQL model?


1. Requirement: General

2. Implementation Specification Section number: 6.2.2

3. Criticality: Editorial

4. Comments/justifications for changes: Change documentation of 
"Feature" into something more meaningful than "The class Feature, 
superclass of everything feature."



1. Requirement: General

2. Implementation Specification Section number: General

3. Criticality: Editorial

4. Comments/justifications for changes: XML/RDF is hard to read. You may 
want to consider another (alternative) formalism, e.g. N3.


1. Requirement: General

2. Implementation Specification Section number: 7.4, Table 4

3. Criticality: Editorial

4. Comments/justifications for changes: Use the same names for RCC8 
relations as used in Table 3. Explain what "+" means.


1. Requirement: General

2. Implementation Specification Section number: 8.3.1.2

3. Criticality: Minor

4. Comments/justifications for changes: Does each feature have to have 
at least 1 geo:defaultGeometry or can there also be features without?


1. Requirement: 11, 5

2. Implementation Specification Section number: General

3. Criticality: Minor

4. Comments/justifications for changes: Why does req. 5 specify the 
range and domain of the properties explicitly, while there is no such 
requirement for the properties in req. 11 (here the range and domain are 
specified in the text)? Be consistent throughout the document.


1. Requirement: 14

2. Implementation Specification Section number: 8.5.1

3. Criticality: Minor

4. Comments/justifications for changes: Make the requirement consistent 
with the following paragraph. Clarify whether the URI is optional and 
that one or more spaces (Unicode U+0020 character) shall be included as 
a separator.


1. Requirement: 14

2. Implementation Specification Section number: 8.5.1

3. Criticality: Minor

4. Comments/justifications for changes: How are other CRS referred to? 
Make a reference to the URIs for CRS defined by OGC (similar to the 
paragraph on UoM URIs in 8.7).


1. Requirement: 15

2. Implementation Specification Section number: 8.5.1

3. Criticality: Minor

4. Comments/justifications for changes: The meaning of "used" is not 
clear. Do you mean that if no URI is specified, WGS84 (as identified by 
the URI <http://www.opengis.net/def/crs/OGC/1.3/CRS84>) is _assumed_ as 
the CRS?


1. Requirement: 13

2. Implementation Specification Section number: 8.5.1

3. Criticality: Minor

4. Comments/justifications for changes: Are mappings defined between the 
geometry types in different versions of Simple Features, e.g. between  
http://www.opengis.net/def/geometryType/OGC-SF/1.0/Polygon and 
http://www.opengis.net/def/geometryType/OGC-SF/1.1/Polygon? Explain why 
the version is needed in the first place.


1. Requirement: General

2. Implementation Specification Section number: 8.7.x

3. Criticality: Minor

4. Comments/justifications for changes: Are the short descriptions 
enough to unambiguously define the semantics of these operations? Maybe 
a reference should be included to another normative standard, e.g. ISO 
19107?



-- 
Michael Lutz
European Commission - Joint Research Centre
Institute for Environment and Sustainability
Spatial Data Infrastructure Unit
T.P. 262, I-21027 Ispra (VA), Italy

Tel: +39 0332 78 6759
Fax: +39 0332 78 6325
e-mail: michael.lutz at jrc.ec.europa.eu
WWW: http://ies.jrc.ec.europa.eu/SDI.html



More information about the Requests mailing list