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

Tschirner at bafg.de Tschirner at bafg.de
Fri Jul 15 14:12:58 EDT 2011



PART A

1. Evaluator:
Sven Tschirner
Federal Institute of Hydrology
Am Mainzer Tor 1
56068 Koblenz
Germany

Direct line: +49 261 1306 5243
Switchboard: +49 261 1306 0
mailto:tschirner at bafg.de
www.bafg.de

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


PART B

I)
  1. Requirement: -
  2. Implementation Specification Section number: General, most likely:
chapter 2
  3. Criticality: Major correction
  4. It seems that the terms 'Core' and 'Extension' hints at mandatory
and optional parts for GeoSPARQL-interface realization. But no
GeoSPARQL-interface will be useful without at least one particular
parametrized conformance class for Geometry Extension and maybe one for
Geometry Topology Extension. So the specification lacks declaring at
least the minimal configuration for a GeoSPARQL-implementation.

II)  
  1. Requirement: 4/6/8
  2. Implementation Specification Section number: 7.2/7.3/7.4 
  3. Criticality: Minor correction
  4. It's not clear enough in which way these requirements differ from
the usual SPARQL-result expectations (the dependency to SPARQL is
already declared in Requirement 1). The GeoSPARQL topology vocabulary
introduces these statically stored predicates but the assessment via a
SPARQL-query is like with any other RDF predicates.   
  
III) 
  1. Requirement: 5/7/9 
  2. Implementation Specification Section number: 7.2/7.3/7.4
  3. Criticality: Editorial correction
  4. Typing error in the requirement texts, should be "rdf:Property"
instead of "rdf:Propery"
  
IV)
  1. Requirement: - 
  2. Implementation Specification Section number: 8.4
  3. Criticality: Addition of feature
  4. Proposal for another standard property for geo:Geometry which is
called 'geo:captureResolution'. This property could
  transport a minimal information about geometrical data quality, could
be used for appropriate visualization resolutions or help an (external)
user interpret the data accuracy before data (re)usage.  
  
V)
  1. Requirement: 12
  2. Implementation Specification Section number: 8.4.4
  3. Criticality: Minor correction
  4. The predicate 'geo:isEmpty' is rather useless in the SemanticWeb
context. For relational geodatabases this information is captured due to
the fact that empty field values could be expressed this way. In the
SemanticWeb the predicates are usually not set then. Furthermore a
GeoSPARQL-conformant dataset with a Feature-instance relating to a
Geometry-instance attributed with my:geometry geo:isEmpty
'true'^^xsd:boolean does not make sense.
  
VI)
  1. Requirement: 12
  2. Implementation Specification Section number: 8.4.6
  3. Criticality: Minor correction
  4. The information of predicate geo:is3D is contained within predicate
geo:coordinateDimension so geo:is3D could be omitted.
  
VII)
  1. Requirement: -
  2. Implementation Specification Section number: General, most likely:
chapter 8
  3. Criticality: Addition of feature
  4. For the reason of backward compability to well-known geographical
information in SemanticWeb databases, a simple storage form is proposed
according to CRS WGS84 (the least common denominator). Besides, the most
important geometry types are points (for social tagging/labeling) and
bounding boxes/envelopes. Every geo:Geometry instance could comprise
therefore semantically unique predicates, for a reference location
stored as a point: 'geo:refLocation_min', 'geo:refLocation_max' and for
bbox-coordinates with: 'geo:bbox_minLat', 'geo:bbox_minLong',
'geo:bbox_maxLat', 'geo:bbox_maxLong'. These separated coordinates (not
tuples or sequences of tuples as in WKTLiteral or GMLLiteral) could be
derived out of the individual GeomLiteral and be easily compared with
any conventionally encoded geographical information from LinkedGeoData,
DBPedia, GeoNames etc. using W3C Basic Geo or other vocabularies. The
main reason for this proposal is that GeoSPARQL vocabulary conformant
datasets are then prepared for comparisons with plain old SPARQL
functions and so are not dependent only to GeoSPARQL processing which
leads to no gap between different domains in the meanwhile
(GeoSPARQL-support or not). Overloading of GeoSPARQL-funtions with
xsd:decimal types for individual coordinates would enable
GeoSPARQL-funtions be capable to handle both, the new complex geometry
literals and also the conventionally stored coordinate predicates.

VIII)
  1. Requirement: -
  2. Implementation Specification Section number: 8 and 9
(topolical/non-topological functions)
  3. Criticality: Functional modification of feature
  4. The specification should clarify if an implementation with support
for two serializations (e.g. GML 3.2.1 and WKT 1.0)
     and for Geometry Topology Extension must accept different
serialized geometry literals in one topolical/non-topological
function-call. Section 8.7 indicates possible errors but why should the
user be constraint to apply a function only for one serialization type?
In case of integration tasks (two or more datasets each with different
serialization types) there would be a real hurdle otherwise.
  
IX)
  1. Requirement: -
  2. Implementation Specification Section number: 9
  3. Criticality: Major correction
  4. The redundancy between many topological functions (specially
between Egenhofer and their SimpleFeatures adoption with some new names)
seems to be too sophisticated for this specification; consider
SemanticWeb users so far not affected by OGC specifications or
geographical concerns. A handful of functions as provided by Simple
Features with the ability to express every topological situation with
function 'geo:relate' should work as well. If done so there is no need
for the 'relation_family' parameter and the function names could be
shorter without strange prefixes rcc8 or sf. 

X)
  1. Requirement: -
  2. Implementation Specification Section number: 10
  3. Criticality: Minor correction
  4. The conformance class 'Query Rewrite Extension' has three
parameters 'relation_family', 'serialization', 'version'. The last two
of them are not relevant for the rewriting functionality, temporary
evaluations of serialization matters during run-time are not worthful
for any query rewriting process. Parametrizing the 'Query Rewrite
Extension' with 'serialization' and 'version' will overload/complicate
the implementation documentation without any positive effect. The
extension should be self-contained and optional and only support the
parameter 'relation_family'.   
  
XI)
  1. Requirement: -
  2. Implementation Specification Section number: General
  3. Criticality: General consideration about conformance classes for
serializations
  4. The possibly numerous conformance classes due to many different
serialization types and versions could
  emerge as a big disadvantage of GeoSPARQL. For example the usage of
predicates geo:asGML, geo:asWKT is not really convenient (the user will
certainly expect something like a unique 'geo:geomLiteral') and their
introduction are a major concession for future implementations which
will not support so many geometry serializations. But then there must be
a geo:asGML321, geo:asGML300, geo:asGML210 and so on, because the
differentiation is used by the GeoSPARQL-functions.   
  Besides WKT and GML, which other serializations are really promising?
KML and GeoRSS with its geometry types deeply related to GML; GeoJSON is
characterized like WKT as a plain text form, maybe a better encoded than
WKT, but with a subset of WKT geometry types. So WKT and GML are the
only two promising serializations, why not constrain GeoSPARQL to these
two and facilitate software products to get most features or all
conformance classes implemented.   
  
XII)
  1. Requirement: - 
  2. Implementation Specification Section number: General
  3. Criticality: Addition of feature 
  4. Besides directly stored topological predicates between
geo:SpatialObject instances (with Topology Vocabulary Extension) also
two inverse functional predicates are proposed between geo:Geometry
instances: 'geo:generalizes' and 'geo:generalizedBy' for generalization
hints. Another predicate could be derived from geo:hasGeometry and is
called e.g. 'geo:hasOriginalGeometry' to indicate the primary geometry
which is just captured, corrected and therefore with the highest
resolution under all geo:Geometry instances for one geo:Feature
instance.





best regards
Sven Tschirner

__________________________________

Sven Tschirner
Federal Institute of Hydrology
Am Mainzer Tor 1
56068 Koblenz
Germany

Direct line: +49 261 1306 5243
Switchboard: +49 261 1306 0
mailto:tschirner at bafg.de
www.bafg.de
__________________________________ 


More information about the Requests mailing list