Re: Update and opportunities with SHACL

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

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.

- Tom



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

> On 8/11/15 6:06 AM, Markus Lanthaler wrote:
>
>> OK. What are the major missing parts? I tried to keep up with the
>> discussions on the mailing list but the volume of mails has been way too
>> high. I had a quick look at the current draft. I was kind of surprised by
>> the few constraints it defines. Is this something that still will be
>> addressed?
>>
>
> Do you have specific examples of features that are missing? This certainly
> still can be addressed. It is technically relatively little work to add new
> Core language elements, as long as they can be expressed in SPARQL.
>
> 1) SHACL should have a standard JSON-LD Context. While I do understand
>>> JSON-LD, I believe someone with more JSON-LD experience could do a much
>>> better job in defining a standard @context file to make shape
>>> definitions as readable as possible - before everyone invents their own
>>> variation of this.
>>>
>> I can certainly help with that.
>>
>
> Thanks a lot, we will likely re-raise this topic once the syntax becomes
> even more stable.
>
>
>> This is certainly nice but I think those extension points should be just
>> that.. extension points. In most cases users shouldn't need to use them but
>> just choose from a set of predefined constraints. If the set of predefined
>> constraints isn't compelling enough, I'd expect SHACL to be a quite tough
>> sell.
>>
>
> I would be surprised by this. My hope with SHACL is that we try to build a
> truly extensible language, not just wait for the W3C to prescribe whatever
> gets hard-coded into the language. Any programming language supports
> creating new functions and publishing them as libraries for re-use. I
> anticipate that most deployed server-side SHACL systems will have full
> support for the SPARQL extension point. This means that it will become
> quite safe to rely on SPARQL-based extensions, if your data is stored in an
> RDF database. I would like to be in a similar situation for other setups,
> esp for client-side SHACL systems. For this to work though, we need a
> proper JavaScript mapping from day one.
>
> Thanks,
> Holger
>
>
>