RE: Update and opportunities with SHACL

I'm responding to all mails in this thread in a single response. So don't be confused by the various mail headers :-)

On Tuesday, August 11, 2015 12:13 AM, Arnaud Le Hors wrote:
> Hi Markus,
> Thank you for your feedback.

I wish I would be able to participate more actively.. but it is a start I guess :-)


> We've now heard from several people that to address their needs SHACL
> must provide a decent amount of built-in constraints. That's what we
> refer to as "the core". These are constraints one can use without
> having to write any SPARQL or using some other extension mechanism.

Great.


> Of course, the difficulty is to determine what "a decent amount of
> built-in constraints" is but, it's becoming clear that what we
> currently have is not enough.
>
> I think we need to look at our use cases and determine how much is
> covered by the core vs how much requires using the extension
> mechanism.

Looking at popular frameworks and data validation libraries should also provide a good idea of what is commonly needed.


On 11 Aug 2015 at 00:53, Holger Knublauch 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.

Since we just talked about Symfony on a different thread (on public-hydra) I had something like this in mind:

  http://symfony.com/doc/current/book/validation.html#supported-constraints

There are heaps of data validation libraries out there. I think learning from them would be a good idea.

Some of these things are already supported by SHACL, some can be worked around or approximated. But just looking at a very basic example like email validation already shows how complex this can become in practice.


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

Why?


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

Right. But this a different beast. You don't use your "programming language" (SHACL) to create those "libraries" (new constraints) but a completely different language (SPARQL).


> I anticipate that most deployed server-side SHACL systems will
> have full support for the SPARQL extension point.

This is the point I'm not so sure about. If that would indeed be the case, why not simplify it to something like Tom mentioned in his email:

On Tuesday, August 11, 2015 1:36 AM, Tom Johnson wrote:
> 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`?


> This means that it
> will become quite safe to rely on SPARQL-based extensions, if your data
> is stored in an RDF database.

These are a lot of "ifs" if you ask me.


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

... which makes interoperable implementations even harder and way more complex. Now they don't only need to include a full-fledged SPARQL engine but also a JavaScript engine. The statement in your other mail unfortunately leaves the impression that you don't find this to be a problem:

On Tuesday, August 11, 2015 2:04 AM, Holger Knublauch wrote:
> 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.

In that same email you made an interesting statement that I don't fully understand:

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

What exactly do you mean by "the spirit of the web" in this context?


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 11 August 2015 20:40:29 UTC