opengeospatial/ogc-geosparql

SD should describe `sd:extensionFunction, extensionAggregate, propertyFeature`

Closed this issue · 4 comments

VladimirAlexiev commented

servicedescription_conformanceclasses.ttl and servicedescription_extensions.ttl
include SPARQL Service Description props sd:feature, sd:resultFormat, sd:supportedLanguage.

The semantics of this is not very clear to me: such claims should be made by a particular SPARQL endpoint.
These OGC resources are not such, and they make a white lie about it:

<http://www.opengis.net/def/geosparql/servicedescconformanceclasses/1.1> a sd:Service 
<http://www.opengis.net/def/geosparql/servicedescextensions/1.1> a sd:Service

But I'm not arguing to remove this since it establishes URLs for these features, and is an excellent example for people to make GeoSPARQL-related SDs for their own endpoints.

I'd like to argue to extend this to use the following SD props:

  • sd:extensionFunction: Relates an instance of sd:Service to a function that may be used in a SPARQL SELECT expression or a FILTER, HAVING, GROUP BY, ORDER BY, or BIND clause.
    Should list all non-aggregation functions (funcs:sf, eh, rcc, nonTopo), eg geof:sfEquals
  • sd:extensionAggregate: Relates an instance of sd:Service to an aggregate that may be used in a SPARQL aggregate query (for instance in a HAVING clause or SELECT expression) besides the standard list of supported aggregates COUNT, SUM, MIN, MAX, AVG, GROUP_CONCAT, and SAMPLE
    Should list all aggregation functions (funcs:sa), eg geof:aggBoundingBox
  • sd:propertyFeature: Relates an instance of sd:Service to a resource representing an implemented feature that extends the SPARQL Query or Update language and that is accessed by using the named property
    Should list all "magic predicates", eg geo:sfEquals

In addition, it would be great to relate the described sd:feature to the above 3 lists. Eg conf/topology-vocab-extension can be also defined as a skos:Collection of all the "magic predicates" listed in sd:propertyFeature.

situx commented

Thank you very much for the suggestions.

The semantics of this is not very clear to me: such claims should be made by a particular SPARQL endpoint.
These OGC resources are not such, and they make a white lie about it:

Correct, there are no SPARQL endpoints or services resolving from these URIs, but we wanted to showcase what a service description might look like.
Indeed, the service descriptions were meant precisely this way: As templates for implementers to expose the parts of the standard they implemented, so I will be happy to extend/correct them if needed.

  • sd:extensionFunction: We listed all these functions in the example file "servicedescription_all_functions.ttl" to show that implementers may choose to implement and communicate only a part of the functions
  • sd:extensionAggregate: Also listed as an example in "servicedescription_all_functions.ttl"
  • sd:propertyFeature: This is a good idea, and we should add it to one of the examples.

Rationale for the two files you pointed out:

  • The example in servicedescription_extensions.ttl shows that implementers may choose only to expose the supported GeoSPARQL extensions
  • The example in servicedescription_conformanceclasses.ttl shows that implementers may choose to expose only the supported conformance classes, but not necessarily the functions implemented
VladimirAlexiev commented

Thanks! I missed servicedescription_all_functions.ttl because it's a broken link in https://opengeospatial.github.io/ogc-geosparql/

  • <http://www.opengis.net/def/geosparql/servicedescallfunctions> should be sd:Service but not skos:ConceptScheme since it doesn't use any SKOS properties
  • sd:extensionAggregate is missing geof:aggBoundingBox
  • This should be referenced in the spec. Currently the only mention of SD is

A. 0. Overview
This Annex lists tests for the Conformance Classes defined in the main body sections of this Specification with links to their Requirements and test purpose method and type. Conformance classes may be used to signify the compatibility of a given implementation to parts of the GeoSPARQL standard. They may be stated as part of a SPARQL 1.1 Service Description

jabhay commented

Hi @VladimirAlexiev,
Whilst @situx is addressing other parts of this issue, I just wanted to tackle the question of whether the specification needs to refer to the service description document. The service description is a component of the SPARQL framework to enable discoverability of a SPARQL endpoint's capabilities. It's not really relevant to the GeoSPARQL specification as such, and so we're not inclined to make reference to it in the specification. Hope that makes sense :)
Jo

VladimirAlexiev commented

Hi @jabhay !
servicedescription_conformanceclasses.ttl and servicedescription_extensions.ttl are excellent examples for people to make GeoSPARQL-related SDs for their own endpoints.

  • The spec can only win if it points to the valuable developer resources that you have created.
  • You already have the sentence "They may be stated as part of a SPARQL 1.1 Service Description": all I'm suggesting is to add a link to those files.

Cheers!