Re: Update and opportunities with SHACL

> This is not the goal. SPARQL is not an extension language but a genuine
part of SHACL.

I'm tempted to read this as "SPARQL is a subset of SHACL" (and I think it's
strictly true, on a current reading), but I suspect you might me something
different... under the current description, JavaScript is also a subset,
yes?

> 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?

Unfortunately, I've had to keep my comments to date at a high level, since
I haven't had enough time to try to do anything real. I understand that
there's a limited impact they can have unless and until I can provide some
concrete suggestions. For now, I think I have to stick to "my high level
concern is that SHACL is leaning too hard on SPARQL for too simple of
expressions".

>  We want things to evolve even after the WG has ended. Few Java
developers are content to use just the Java Standard Library.

At the risk of being too blunt, few Java developers would be excited about
writing their abstract classes in SPARQL, either.

- Tom

On Mon, Aug 10, 2015 at 5:03 PM, Holger Knublauch <holger@topquadrant.com>
wrote:

> 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
>
>