SHACL: A language for multiple platforms

I believe before we can decide on things like ?shapesGraph access, we 
need to clarify the spaces in which SHACL will be used. The platforms 
and use cases will be very heterogeneous.

a) Pure "core" engines that may not support any extension language
    - some may include hard-coded support for certain templates (OSLC?)

b) Engines that can operate against a SPARQL endpoint

c) Engines that can operate against datasets, accessed via an API like Jena
    - with inferencing support
    - without inferencing support

d) Engines that operate on a client in JavaScript, without SPARQL support

e) SPARQL-based engines that also support JavaScript, XML Schema etc.

...

Not every one of them will be able to handle all SHACL files, e.g. b) 
cannot handle recursion or blank nodes or ?shapesGraph. Some c) will not 
handle queries requiring RDFS or OWL inferencing. However, a c) can in 
principle handle SPARQL endpoints, by treating the endpoint as a graph, 
so there is nothing wrong with it in principle.

The situation is similar to OWL Lite/DL/Full. Being a consequence of 
Design-by-committee, it is natural that not everyone will be perfectly 
happy, and it leads to a certain level of mess by default.

A consequence of this situation is that my proposal uses the "Full" 
language as the basis of the spec, but includes error-handling for cases 
that certain engines may not handle. Most features can also be handled 
by engines that only cover subsets, e.g. sh:allowedValues can be 
converted into a FILTER NOT IN ... for SPARQL endpoints, and to whatever 
code the ShEx engine uses.

My proposal remains to write down the SPARQL endpoint support as a 
separate deliverable or chapter, similar to how ShEx people will write 
down how their implementation works. This way, everyone gets the 
features they need.

Holger

Received on Thursday, 18 June 2015 23:18:11 UTC