[Requests] Comments on candidate GeoSPARQL standard (OGC 11-052r3)

Frans Knibbe frans.knibbe at geodan.nl
Tue Jul 26 07:03:52 EDT 2011


PART A

1. Evaluator:
name: Frans Knibbe
company: Geodan
address: President Kennedylaan 1, 1079MB Amsterdam, The Netherlands
e-mail: frans.knibbe at geodan.nl


2. Submission:
OGC GeoSPARQL - A Geographic Query Language for RDF Data (11-052r3)


PART B

I.
1. Requirement: 14
2. Implementation Specification Section number: General
3. Criticality: Major
4. Comments/justifications for changes:
I would like to see the possiblity of defining a  'level of detail' or 
'spatial resolution' for geometry. The Level of Detail (LoD) is a way of 
indicating how geometric data can be used. Being able to have this 
available as a selection criterion will be extremely important in the 
web of data, where its likely that many geometric representations of the 
same geographical feature will exist. For visualisation or analysis of 
geographical data in most cases only a certain interval of LoD will be 
appropriate. So it is important that data providers are able to indicate 
that geometries are meant to be used at a certain scale, and consumers 
are able to select the most appropriately scaled geometries.
The class MD_Resolution as defined in ISO:19115 might be used for 
indicating the LoD.

II.
1. Requirement: General
2. Implementation Specification Section number: 4
3. Criticality: Major
4. Comments/justifications for changes:
The document could do with a glossary of terms where the reader can find 
definitions. I would especially value a clear definition of the term 
'geometry'. In ISO:19107 there is no definition of this term, just 
'geometric object' and  'geometeric primitive'.

III.
1. Requirement: General
2. Implementation Specification Section number: General
3. Criticality: Major
4. Comments/justifications for changes:
It would be a good for the uptake of this standard to be able to view it 
as an extension of the Basic Geo vocabulary from the W3C 
(http://www.w3.org/2003/01/geo/). Although the Basic Geo vocabulary is 
not a standard, it is widely used at the moment, and easy to use for 
people lacking a background in GIS. Being able to make a smooth 
transition between using both vocabularies would be of great value to 
both the Geospatial and the Linked Data communities.

IV.
1. Requirement: General
2. Implementation Specification Section number: 2
3. Criticality: Major
4. Comments/justifications for changes:
Is it really necessary to have to support the Core conformance class if 
one just wants to serialize geometry? If an implementation that is only 
used for serialization needs to support the Core requirements (which 
seems unnecessary), it will be harder to make such an implementation.
Note: I am not really sure what the extra burden of having to support 
the Core requirements would be. I guess that if in practice there are no 
complications the issue is of minor criticality.

V.
1. Requirement: General
2. Implementation Specification Section number: 2
3. Criticality: Major
4. Comments/justifications for changes:
WKT and GML serialization are bundled together in one conformance class. 
I take this to mean that an implementation of this standard, if it 
states that it has the Geometry Extension, should always support both 
serializations. And if the standard is extended with more serialization 
formats (the desire for doing this is expressed in section 11), the 
extra formats will probably also be part of the Geometry Extension 
conformance class. The requirement of having to support all 
serialization formats will be an obstacle for this standard being used. 
A suggestion: define separate conformance classes for each serialization 
format.

VI.
1. Requirement: 14
2. Implementation Specification Section number: 8.5.2.
3. Criticality: Major
4. Comments/justifications for changes:
It seems strange to concatenate CRS and the WKT string. It seems more 
logical and useful to keep them separate. It should be possible to use 
the CRS as a selection criterion in queries on the web of data (for 
instance, in the case of displaying data on a map, only data with the 
same CRS as the map are desirable). It seems this will be impossible or 
harder if the CRS data are concatenated with the WKT. Also, if WKT or 
CRS data need to be used, the data first have to be pulled from the 
combined text string. This will cause unwanted processing overhead.

In ISO:19125, the SRS and the coordinate string are modelled as to 
separate properties of a geometry. Why merge them in GeoSPARQL for the 
WKT serialization?

VII.
1. Requirement: General
2. Implementation Specification Section number: 5
3. Criticality: Editorial
4. Comments/justifications for changes:
The abbreviations OOPL  (I assume Object Oriented Programming Language) 
and URI are used in the text, but are not explained in paragraph 5.1.

VIII.
1. Requirement: General
2. Implementation Specification Section number: 2
3. Criticality: Major
4. Comments/justifications for changes:
WKT and GML serialization are bundled together in one conformance class. 
I take this to mean that an implementation of this standard - if it 
states that it has the Geometry Extension - should always support both 
serializations. And if the standard is extended with more serialization 
formats (the desire for doing this is expressed in section 11), the 
extra formats will probably also be part of the Geometry Extension 
conformance class. The requirement of having to support all 
serialization formats will be an obstacle for this standard being used. 
A suggestion: define separate conformance classes for each serialization 
format.

Kind regards,
Frans




More information about the Requests mailing list