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

Francisco J. Lopez-Pellicer fjlopez at unizar.es
Tue Aug 2 06:20:21 EDT 2011


PART A


1. Evaluator:
name: Francisco J. Lopez-Pellicer
company: IAAA, University Zaragoza
address: Edif. Ada Byron, C/ Maria de Luna, 1, Zaragoza, 50018 Spain
e-mail: frans.knibbe at geodan.nl

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


PART B

1. Requirement: 1, 2, 3, 10, 13, 19
2. Implementation Specification Section number: General
3. Criticality: Major
4. Comments/justifications for changes: The requirements 1, 2, 3, 10, 13 
and 19 about the transitivity of rdfs:subClassOf are redundant. They can 
be replaced by a single requirement that states which is the entailment 
regime (e.g. RDFS entailment regime [1] ) that the implementation should 
support. This approach simplifies the specification. In addition, and 
thinking in future work (section 11), SPARQL 1.1 servers may operate 
with explicit entailment regimes [2]. Thus, a future version of this 
requirement should assert which are the entailment regimes that the 
implementation should at least support.

[1] http://www.w3.org/TR/rdf-mt/#rdfs_entailment
[2] http://www.w3.org/TR/sparql11-service-description/#sd-entailmentRegime

1. Requirement: 11
2. Implementation Specification Section number: General
3. Criticality: Major
4. Comments/justifications for changes: The requirement 11 is 
incomplete. geo:defaultGeometry is a subproperty of geo:hasGeometry. 
Therefore the requirement 11 should say that implementations shall 
support transitivity of rdfs:subPropertyOf so that all 
geo:defaultGeometries entails geo:hasGeometry. This issue is avoided 
with the specification as requirement of the entailment regime required 
in implementations.

1. Requirement: 11
2. Implementation Specification Section number: General
3. Criticality: Minor
4. Comments/justifications for changes: The requirement seems to be 11 
is incomplete. May a given feature have two geo:defaultGeometry with the 
same spatial reference system? If the answer is no, it is possible to 
add to the requirement: A Feature has no more than one value of 
geo:defaultGeometry per spatial reference system. A similar solution in 
a different domain can be found in the integrity constraints of the  
SKOS vocabulary [1].

[1] http://www.w3.org/TR/skos-reference/#labels

1. Requirement: 14, 15, 16, 17, 20 , 21, 22
2. Implementation Specification Section number: General
3. Criticality: Major
4. Comments/justifications for changes: The definition of new RDF 
Datatypes should be defined in terms of their value space, the valid 
lexical space (the set of valid Unicode [UNICODE] strings) and the rules 
of the lexical-to-value mappings (and viceversa) (normative in RDF 
[1,2]).  These concept must be explicitly included in the normative part 
of the standard. Often this implies just a copy&paste in the document. 
For example, instead of:

(normative in the conformance test) Req 14 "All RDFS Literals of type 
WKTLiteral shall consist of an optional URI
identifying the coordinate reference system followed by Simple Features 
Well Known
Text (WKT) describing a geometric value."
/req/geometryExtension/WKTLiteral

(Non normative) Valid WKTLiterals are formed by concatenating
a valid URI as defined in [W3C SPARQL], one or more spaces (Unicode 
U+0020 character)
as a separator, and a WKT string as defined in [ISO 19125-1]

Should be:.

(normative in the conformance test) Req 14 "All RDFS Literals of type 
WKTLiteral shall consist of an optional URI
identifying the coordinate reference system followed by Simple Features 
Well Known
Text (WKT) describing a geometric value. Valid WKTLiterals are formed by 
concatenating
a valid URI as defined in [W3C SPARQL], one or more spaces (Unicode 
U+0020 character)
as a separator, and a WKT string as defined in [ISO 19125-1]."
/req/geometryExtension/WKTLiteral

Example of description of RDF datatypes following the RDF guidelines can 
be found at [3,4].

[1] http://www.w3.org/TR/rdf-concepts/#section-Datatypes
[2] http://www.w3.org/TR/rdf-mt/#dtype_interp
[3] http://www.w3.org/TR/rdf-concepts/#section-XMLLiteral
[4] http://www.w3.org/TR/rdf-plain-literal/

1. Requirement: General
2. Implementation Specification Section number: 11
3. Criticality: Minor
4. Comments/justifications for changes: Future work does not include 
references to  SPARQL 1.1 [1]. Note that SPARQL 1.1 is transactional [1] 
and allows federate queries [2]. From my point of view, these 
characteristics make worthwhile to consider as future work the explicit 
support of SPARQL 1.1.

[1] http://www.w3.org/TR/sparql11-update/
[2] http://www.w3.org/TR/sparql11-federated-query/


Kind regards,
Francisco J.



-- 

Dr. Francisco J. Lopez-Pellicer
Advanced Information Systems Group (IAAA)
Computer Science and Systems Engineering Department
University of Zaragoza

Edif. Ada Byron D2.22
C/ María de Luna, 1
Zaragoza, 50018 Spain

Tel. +34 976762331
Fax. +34 976761914
http://iaaa.cps.unizar.es/showContent.do?cid=fjlopez&sid=curriculum-iaaa&nid=paginas_personales.EN






More information about the Requests mailing list