Re: Update and opportunities with SHACL

On 8/11/2015 9:35, Tom Johnson wrote:
> Thanks Arnaud and Holger,
>
> I see something of a disconnect between what Markus is saying and what 
> I'm hearing from the Shapes WG on this (forgive me if I'm 
> misrepresenting, you, Markus). On the one hand, we have desire for 
> SHACL to be, in some meaningful sense, a complete language. On the 
> other hand, there is the view that SHACL should provide "a decent 
> amount of built-in constraints" on top of SPARQL.
>
> It doesn't seem enough to say that there are n "built-in" 
> constraints--and that you have recourse to extensions for expressions 
> that are not covered by those.

One problem that we need to address is to avoid the term "extensions". 
That term sounds like something alien, outside of the "real" language. 
This is not the goal. SPARQL is not an extension language but a genuine 
part of SHACL.

> What is needed is a fully featured language that allows its users to 
> write expressions in, as Holger puts it, a truly extensible fashion. 
> The expressivity I would look for would allow for, e.g., composition 
> of constraints.

You can define new (named) shapes that combine other shapes, e.g. using 
sh:OrConstraint. This is a simple macro mechanism. Do you have examples 
of what you believe is missing?

> Leaning on the SPARQL grammar to do this strikes me as very weak. If 
> this is required, why not jettison the idea of a language and simply 
> use SPARQL and focus the Shapes WG output on a lightweight API for 
> `f(Graph, SPARQL Expression) -> Violations`? In short... such a 
> language seems like "a tough sell".
>
> To be clear: I *do* want a stand-alone constraint language, and I'm 
> glad that you've chosen to use SPARQL for the base semantics. This 
> seems like a massive savings both in language design and opportunity 
> cost for SHACL users of any sophistication. My concern is that there 
> is a reliance on not just the semantics of SPARQL, but the actual 
> grammar; or, as I've seen it put several times, an "engine". The 
> latter strikes me as massively limiting from an implementation 
> standpoint. For the user, it seems to tip the opportunity cost toward 
> ignoring SHACL, as a language, and just using SPARQL + a SHACL-like 
> violations API.

What I hope will emerge is that any popular SHACL macro gets implemented 
in a cross-platform fashion, e.g.

ex:MyTemplate
     a sh:ConstraintTemplate ;
     sh:sparql "..." ;
     sh:jsExpression "..." ;
...

i.e. it would have executable bodies in SPARQL, JavaScript and whatever 
other languages will emerge. Templates as the above would be shared as 
linked data, just like people publish programming APIs. This leads to a 
separation of roles in which only few people need the skills to prepare 
these "APIs" while the majority of users just need to plug in the 
features and use a high-level language "ex:MyTemplate" with arguments.

To be clear though: it will be perfectly fine to declare macros that do 
not have a SPARQL body, because they can only be implemented in, say, 
JavaScript. It only means that SPARQL-based engines will not be able to 
make sense of them.

>
> As I've thought more about implementing, it has become less clear to 
> me which of these things SHACL aims to be. I'd really like to hear 
> from the group a strong commitment to developing a fully featured 
> constraints DSL; alternatively, a backing off of "language" 
> terminology, and a focus on developing a violations API may be 
> appropriate.

We are trying our best to cover the most relevant use cases out of the 
box, with the Core vocabulary. But it would be a wasted opportunity to 
not rely on the spirit of the web here. We want things to evolve even 
after the WG has ended. Few Java developers are content to use just the 
Java Standard Library. Few JavaScript developers would be content 
without something like jQuery. There will be plenty of domain-specific 
SHACL macro libraries in the future.

Holger