Re: SHACL: A language for multiple platforms

On 6/20/15 6:35 AM, Dimitris Kontokostas wrote:
> From my point of view a W3C spec should strive for convergence and not 
> diversity.

As soon as we voted in favor of SPARQL it was clear that not every SHACL 
file will work on every platform. Most SPARQL processors have their own 
extension functions (e.g. afn:localname, GeoSPARQL or even magic 
properties), and people do use them. The situation has become even more 
hopeless after the vote on allowing other languages beside SPARQL. 
Instead of seeing this diversity as a problem, I think we should embrace 
it as a reality and an opportunity. SHACL should allow people to get 
their work done, and much of this work will be in controlled 
environments such as enterprise applications.

Our answer to the Linked Data vision of completely interoperable models 
is the Core Vocabulary. This will be the common ground that is supposed 
to work everywhere. Users venturing into extensions need to be aware 
that they are outside of convergence, and SHACL engines need to be built 
to fail gracefully on unsupported features.

> We already have core + sparql. Now we want to break sparql into two 
> modes and maybe javascript in another x modes in the future.

I don't want to break SPARQL into two modes at all. My preferred outcome 
would be to rely on

http://www.w3.org/2014/data-shapes/track/issues/71

only. Any other access to SPARQL endpoints should be a temporary 
solution only. Vendors with native SHACL support will have a business 
advantage, so we hopefully see adoption of such a protocol soon.

> I will certainly not block going into this direction but will not 
> endorse it either.
>
>     These are entirely different setups, for different user groups.
>     This is not a one-size-fits-all discussion. If the SPARQL endpoint
>     people don't need access to ?shapesGraph, SHACL functions,
>     recursion and blank nodes then fine for me, but they should not
>     block the dataset people from covering their use cases.
>
>
> Besides ?shapesGraph I never mentioned blank nodes or shacl functions 
> (which I am close to implementing). I already said I don't support 
> recursion it but it's a big way from not supporting to blocking.

This sounds good. I mentioned SHACL functions because SPARQL queries 
wouldn't be able to use them against SPARQL endpoints, unless you go 
through something like the protocol above.

BTW I noticed there is another complication if we dropped ?shapesGraph: 
template arguments can be rdf:Lists that are stored in the shapes graph. 
In order to walk these lists, ?shapesGraph access is needed. To get rid 
of this we would need to come up with a fairly sophisticated text 
insertion mechanism that generates various alternative SPARQL 
serializations for different use cases. And even then I don't see how we 
could implement order-preserving scenarios such as the tail recursion 
implemented by the sh:walkShapesList and lists of bnode shapes. An 
alternative again would be to disallow rdf:List arguments outside of the 
core, but I know from experience that SPIN users asked about 
multi-valued template arguments.

So what are your thoughts on ISSUE-71? Would this help with your dbpedia 
use cases?

Regards,
Holger