Closed VladimirAlexiev closed 4 months ago
Considering the structure of the specification in requirements and conformance classes, I believe we are bound to the OGC modular specification in which a requirement, grouped in requirement classes should always have a corresponding conformance test, grouped in conformance classes. So conformance classes are collections of tests and not requirements as per the structure of OGC standards. @jabhay might prove me wrong here, but I think this is a given.
In the GeoSPARQL spec we only define abstract tests and the only compliance benchmark that I believe exists (https://www.mdpi.com/2220-9964/10/7/487) has been developed out of scope of the GeoSPARQL work, but with the abstract test suite as a template of what to test.
As I understand it, tests in OGC are usually done using the OGC TEAM Engine (https://cite.opengeospatial.org/teamengine/) with the goal to certify that an implementation complies to certain specifications. Right now, there is not GeoSPARQL validation test in the TEAM engine. We have talked about possibly adding or adapting the GeoSPARQL compliance benchmark for this, but it has not happened yet. It could be an idea to model it with EARL though. https://www.w3.org/TR/EARL10-Schema/
@situx I saw "requirement classes" in the spec. But I don't see them in reqs.ttl
?
The requirement classes were indeed missing and you are right. These are the better fits for the service descriptions.
Complementing #490:
https://github.com/opengeospatial/ogc-geosparql/blob/master/spec/ontology/requirements/reqs.ttl
On the conceptual level, there are 2 considerations that are probably too drastic to be accepted, but I'll still raise them:
spec:testPurpose "check conformance with this requirement"@en
). So I think it would be better to make collections of requirements in addition to (or instead of) collections of tests.