Re: Update and opportunities with SHACL

On 8/12/2015 6:39, Markus Lanthaler wrote:

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

It is possible to use existing SHACL shapes to define new shapes, by 
combining them with AND, OR, NOT, sh:valueShape, via subclassing 
relationships or even via the sh:hasShape callback. These new shapes get 
a new URI and can be published as a library.

But I do understand your point of layering SHACL on top of another 
language or two, and a similar issue was raised by Jose in the past. At 
the beginning of the SHACL WG we were collecting use cases and quickly 
found that if we want to stay entirely within a high-level language, 
then this high-level language would have to be equivalent to SPARQL to 
achieve the required expressivity. So basically we'd need an object 
model consisting of nodes for all kinds of expressions (=, >, !=, 
variables etc) plus joining of values similar to Basic Graph Patterns, 
and other features. For those familiar with SPIN, this was exactly the 
approach taken by the SPIN RDF Vocabulary (http://spinrdf.org/sp.html).

But this would lead to a massively bigger core language with all its 
consequences. Furthermore, if this language is so close to SPARQL, why 
not use SPARQL directly and systems that wish to operate on objects can 
parse the strings. Finally, this model could not express things that 
JavaScript could, i.e. we'd need to extend this high-level vocabulary 
with typical imperative constructs such as if and while. This is just 
not realistic.

>
>
>> 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 is indeed a subset of SHACL, basically if you only use 
sh:constraint and sh:sparql, e.g.

ex:MyShape
     a sh:Shape ;
     sh:constraint [
         sh:sparql "..." ;
     ] .

But this doesn't fulfill the design goal of SHACL to serve as a language 
to communicate the structure of data in a high-level language, e.g. to 
populate input forms. What we created was a compromise between those two 
worlds.

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

If someone is willing to help with the JavaScript execution language 
(see my original post) then all popular templates including the Core 
vocabulary will likely have a JavaScript executable too. This removes 
most of the ifs above, because people can then run them client-side 
against normal JSON objects.

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

I personally want SHACL to be a language that I can use to get work 
done. If our design goal is to have 100% compatibility between all 
implementations then SHACL will likely be a very limited language, or 
(as I said above) a reinvention of SPARQL. In many environments 
(especially enterprise software) people will be perfectly happy to use 
SHACL with their own extensions - uploading a model to the public web is 
not relevant there.

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

Languages like OWL were designed by committee and include exactly the 
features that certain people found relevant at a given point in time. 
There is no extension mechanism in OWL. Nobody is able to publish a new 
keyword such as owl:IrreflexiveProperty themselves. If someone wants to 
express that the values of skos:prefLabel must all have different 
language tags, they cannot do that. See [1].

With SHACL, the committee just publishes a Core starter kit plus a 
web-based extension mechanism. We do not know yet what people will do 
with these building blocks in the next few years. Anyone can publish 
their own lego bricks (shapes, templates, functions) for others to reuse 
by pointing at their URIs. So in addition to publishing ontologies and 
data, people can publish domain-specific language libraries. These 
libraries include instructions on how they should be executed - in 
SPARQL, JavaScript or whatever. Complete SHACL engines would not 
hard-code anything - just the generic code to take those macro 
definitions and execute them. Even the Core language (sh:minCount etc) 
is soft-coded in SPARQL, and could easily have other implementations for 
various JavaScript set-ups. And if Google invents a successor scripting 
language to replace JavaScript then the SHACL spec would not need to be 
changed - it would be just another execution language plugin.

HTH
Holger

[1] 
http://composing-the-semantic-web.blogspot.com.au/2010/04/where-owl-fails.html

Received on Wednesday, 12 August 2015 05:53:52 UTC