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

Gerjon de Vries g.devries at opensahara.com
Thu Aug 4 07:15:50 EDT 2011


PART A

1. Evaluator:
G. de Vries
g.devries at opensahara.com

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

PART B

I)
1. Requirement: General
2. Implementation Specification Section number: General but summarized
in Section 2 - Conformance
3. Criticality: Major
4. Comments/justifications for changes:
The proposal introduces a 'Core' part (which seems to imply mandatory),
and several 'Extensions' (which seems to imply optional). The Core part
defines an RDFS ontology (Feature and SpatialObject) but no means to
store geometry information about those. Additionally, the wording of the
geometry serialisation classes seems to imply that conformance to one of
those classes (e.g. WKTLiteral) implies that a geometry literal should
always be wrapped in at least a SpatialObject. The proposal should make
conformance to a Geometry Serialisation class 'Core' functionality
(including a minimal set of functions to relate geometry literals), and
make the introduced ontologies (including the inferred properties on
those ontologies) an 'Extension' for the following reasons:
- Serialisation of geometries to Literals (e.g. WKT Serialisation) and
query function on those Literals are useful even without the RDFS
ontology, while the reverse is not true: a SpatialObject/Geometry
ontology is only useful if at least one of the serialisation conformance
classes is implemented.
- By defining RDFS classes as core, RDFS based reasoning is a
prerequisite for any implementation of the proposal. Geospatial queries
though are also useful in applications were (e.g. because of practical
or scalability issues) RDFS is out of the question.
- Geometry literals and the filter functions that operate on them are
useful, even without inferred properties on instances of Geometry
classes, and their use should not be limited to use them as members of
such instances only.
- Why force the use of a specific ontology? None of the other Literal
datatypes in RDF or RDFS require that they be used as properties of a
specific ontology. It would be rather awkward if an xsd:dataTime must
not be used outside instances of some kind of DateBearingFeature class
for instance. An RDFS SpatialObject ontology definitely has its use, but
not as core requirement for a GeoSPARQL standard.

II)
1. Requirement: 29
2. Implementation Specification Section number: 10
3. Criticality: Major
4. Comments/justifications for changes:
The query rewrite extension will, according to the textual description,
work only for instances of RDFS SpatialObject and its subclasses. The
rewrite rule template pattern though, on page 28, also allows rewrites
if the predicates geo:defaultGeometry and/or ogc:asGeomLiteral are used
outside of SpatialObject instances. Either the rewrite rule should be
changed to explicitly limit the rewrite rules to instances of the
specific classes, or the description should specify that using these
predicates outside the SpatialObject ontology will result in the same
rewrite rules being applied.

III)
1. Requirement: 13
2. Implementation Specification Section number: 8.5.1
3. Criticality: Major
4. Comments/justifications for changes:
The specification forces redundancy in data definition by duplicating
the logical hierarchy of geometry instances inside a Geometry class
hierarchy. E.g. when serialising a POLYGON, one is required to define
that it is a polygon on both the Geometry (Polygon) class instance, and
inside the literal embedded in that instance. Forcing redundancy in a
standard aimed at end-users doesn't seem right, in this case the
standard also fails to address cases in which erroneous conflicting
information is stored. It should also be noted that all the reasoning
capabilities that are introduced in this standard would have been
possible without the proposed redundancy, and that if type information
about the geometry is deemed necessary as linked data, this could have
been achieved by using a functional property that exposes the type of
geometry (just like geo:is3D, geo:isSimple, etc.).

IV)
1. Requirement: General, 12, 24
2. Implementation Specification Section number: General, 8.4, 8.7
3. Criticality: Major
4. Comments/justifications for changes:
The specification uses both functional properties and filter functions
to relate geometry literals and/or SpatialThings or compute their
properties. Many of the proposed functional properties are not available
as filter functions, and therefore only accessible for implementations
that implement the standard properties for geo:Geometry. Those function
properties would also be useful as filter functions on the literals, so
that they can be used in applications that don't support or use the
functional properties. Since an implementation needs to extract this
information from the literal anyway, it only makes sense to add filter
function that compute those properties directly from geometry literals
in addition to the functional properties that are defined.

V)
1. Requirement: 14
2. Implementation Specification Section number: 8.5.2
3. Criticality: Minor
4. Comments/justifications for changes:
The spatial reference system of a WKTLiteral is supposed to be defined
by an URI that precedes the geometry description.
- The proposal fails to define where and how these URI's are defined. If
there is a standard somewhere that links URI's to spatial reference
systems this should have been mentioned in a requirement.
- XML serialisation of Literals that contain characters from URI's is
verbose. This will make serialisation of WKT literals hard to read,
since characters such as < and > that are part of the reference system
URI need to be encoded in many serialisation formats (e.g. XML-RDF), or
require the use of CDATA sections.
- There are a well-known, and universally applied numbering schemes for
spatial reference systems, such as the EPSG SRID. Using such a numbering
scheme instead of URI's would result in less verbosity and easier to
read XML-RDF data.

VI)
1. Requirement: 12
2. Implementation Specification Section number: 8.4
3. Criticality: Major
4. Comments/justifications for changes:
The proposal fails to address how SPARQL queries should respond when
unbound predicates are used. E.g. it is unclear if a query like:
SELECT * WHERE { ?subject ?predicate ?object }
should return results for the functional predicates defined on
SpatialObjects, such as geo:is3D.

VII)
1. Requirement 2, 3, 10, 13
2. Implementation Specification Section number: General
3. Criticality: Minor
4. Comments/justifications for changes:
The proposal explicitly makes rdfs:subClassOf transitivity a
requirement. By doing so it is suggested that this is the only
requirement from RDFS, and e.g. rdf:type inference is not a requirement.
If only rdfs:subClassOf transitivity is a requirement, the proposal
should explicitly exclude other RDFS inference rules. If more inference
rules from RDFS are a requirement, the proposal should drop the
requirements for rdfs:subClassOf and instead refer to the appropriate
parts of RDFS in its requirements.

VIII)
1. Requirement 26, 27
2. Implementation Specification Section number: 9
3. Criticality: Minor
4. Comments/justifications for changes:
Function names for the various conformance classes are prefixed by
letter codes for their conformance class, e.g.: sf-disjoint vs.
eh-disjoint. Queries would be easier to read if these prefixes were part
of the namespace so that one could write e.g. sf:disjoint or eh:disjoint
in a query.

IX)
1. Requirement: General
2. Implementation Specification Section number: General
3. Criticality: Major
4. Comments/justifications for changes:
The proposal fails to address under what conditions geometry literals
are deemed equal. It is unclear if, when the following data is added to
an RDF database that implements this proposal, this should result in one
or two triples in the database:
  <uri:mygeometry> <geo:asWKT> "POINT(0 0)"^^ogc:WKTLiteral
  <uri:mygeometry> <geo:asWKT> "POINT       (0      0) 
  "^^ogc:WKTLiteral
Likewise it is unclear if the following filter expression in a GeoSPARQL
query should return true or false:
  ("POINT(0 0)"^^ogc:WKTLiteral != "POINT       (0      0) 
  "^^ogc:WKTLiteral)
This should be addressed, and probably boils down to defining the
"lexical form" of a geometry literal in each of the serialisation
conformance classes. See
http://www.w3.org/TR/rdf-concepts/#dfn-lexical-form.

Best regards,

G. De Vries


More information about the Requests mailing list