Re: Looking at the current proposals for SHACL

On Fri, Mar 20, 2015 at 1:03 AM, Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> There was some spirited discussion at the WG teleconference today, and then
> some spirited IRC chat afterwards.  This all prompted me to take another
> look at what proposals for SHACL that are being put forward in the WG at
> this point in time.
>
> I see four relevant documents.


> 1/ http://w3c.github.io/data-shapes/semantics/
>
> This document contains an informal description of a core for SHACL
>
> Significant Features:
> - - It does not contain a formal specification.
> - - It presents only a core of SHACL.
> - - The core contains potentially recursive shapes, but not closed shapes
> or
>   global constraints.
> - - The description of recursive shapes appears to be ill-founded.
> - - It does not discuss violation reporting.
> - - It only has a few methods for controlling evaluation of shapes.
> - - It does not describe an API.
>

That document identifies a basic set of constructs for that language. The
constructs are defined in natural language so it will be possible to define
their semantics by other means. It will also be possible to add more
language constructs to that language.

I like that approach because it can be the basis for the SHACL language
from which other documents like the SPARQL based implementations of the
formal semantics can be defined.

>From my point of view, that document should replace or be merged with the
language constructs defined in sections 2-6 of Holger's spec, so there
could be a common set of language constructs that can be used.

>
> 2/ http://w3c.github.io/data-shapes/semantics/Axiomatic
>
> This document contains an axiomatic semantics for the core in 1/ above.
>
> Significant Features:
> - - It provides a formal specification for a core of SHACL in terms of an
>   axiomatization.
> - - The core contains potentially recursive shapes, but not closed shapes
> or
>   global constraints.
> - - Some of the low-level portions are under-specified.
> - - It has errors.
> - - It is incomplete.
> - - It does not match the description in 1/ above.
>

That document is work-in-progress and I would appreciate any feedback to
improve it instead of just saying it "has errors" or "is incomplete".
Having said that, the main point of that document is to signal that it is
possible to define the formal semantics of the SHACL language in an way
that does not depend on SPARQL and that can motivate the appearance of
independent implementations.

The axiomatization approach was inspired by the RelaxNG specification and
is very similar to the approach used to define type systems of programming
languages. If the target audience for the document is future developers,
that approach is more amenable to that audience.

Another benefit of it, is that it is a simple (and relatively short)
self-contained document that doesn't depend on SPARQL so future
implementers can find it less scary.

Apart from that, that document doesn't limit the appearance of other
formalization attempts like some model-based semantics or Z. The main point
is to identify which are the language constructs that can be used by SHACL
users in a compatible way between different implementations.

3/ http://w3c.github.io/data-shapes/shacl/
>
> This document contains a formal specification of SHACL based on SPARQL with
> extra functionality.
>
> Significant Features:
> - - It provides a formal specification for SHACL in terms of an extended
>   version of SPARQL.
> - - It presents a full SHACL (modulo some of the non-validation portions).
> - - Its version of SHACL has all the expressive power of SPARQL.
> - - Its version of SHACL permits global constraints and recursive shapes
> but
>   not closed shapes.
> - - It provides a macro-expansion language.
> - - It provides violation reporting.
> - - The specification of recursive shapes appears to be ill-founded.
> - - It does not define a core, but the high-level constructs can act as
> such.
> - - The core does not need to be implemented using a SPARQL engine.
> - - It defines several methods for controlling evaluation of shapes.
> - - It defines a limited API.
>

That document should be separated in two sections. One for the SHACL
language (sections 2-6) whose constructs should be merged with
http://w3c.github.io/data-shapes/semantics/ and if the intention is that it
can be implemented without SPARQL then it should avoid references to
SPARQL.

Sections 7, 8 and 12 (constraint, templates and functions) can probably be
defined in terms of language constructs.

The other parts about the semantics based on SPARQL should be part of a
different document.

That document can contain a mapping from the language constructs to the
SPARQL definitions. As an example in this section:

http://w3c.github.io/data-shapes/semantics/Axiomatic#SimplifiedAbstractSyntax

which contains a table from the language constructs to the different
axiomatic definitions.

4/ https://www.w3.org/2014/data-shapes/wiki/Shacl-sparql
>
> This document contains a formal specification of SHACL directly based on
> SPARQL.
>
> Significant Features:
> - - It provides a formal specification for SHACL in terms of SPARQL.
> - - It presents a full SHACL (modulo some of the minor features and some of
>   the non-validation portions).
> - - Its version of SHACL has all the expressive power of SPARQL.
> - - Its version of SHACL permits global constraints but not recursive
> shapes
>   or closed shapes.
> - - It provides violation reporting.
> - - It does not define a core, but the high-level constructs can act as
> such.
> - - The core does not need to be implemented using a SPARQL engine.
> - - It defines several methods for controlling evaluation of shapes.
> - - It defines a flexible API.
>

The problem here is SPARQL dependency and the lack of the definition of
what a core or high-level constructs are.

You say: "It does not define a core, but the high-level constructs can act
as such." but the document doesn't define which are those high-level
constructs.

You also say: "The core does not need to be implemented using a SPARQL
engine." but there is no definition of what the core is.

I think there are 2 parts of that document that can be very useful:

- The definitions in terms of SPARQL look quite simple and easy to
understand...maybe, those definitions could be combined with the SPARQL
definitions in the other document.

- I found interesting the latest table (collected vocabulary
<https://www.w3.org/2014/data-shapes/wiki/Shacl-sparql#Collected_Vocabulary_and_analogue_in_http:.2F.2Fw3c.github.io.2Fdata-shapes.2Fshacl.2F>)
which contains mappings between different terms. I think the WG should
precisely concentrate its efforts in defining those common language
constructs so we can have a list of all the possible design choices
available.

Best regards, Jose Labra

>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVC2PAAAoJECjN6+QThfjzeEMIAMfI18HI7JP6vh7GF5gXD1z9
> tq7hRe7GiCpslvxYcKdA8PNkyjOerY+xMMSrUjiMU+zUkqQR36VBJkFfwDLhyBpN
> 7gAHL8fB0HGfcxeBAlHddhKXs07YiRnhKuG4/7p01vMMmY9SEMFJjFogf2BgplDF
> RZ2ZZfMmQDk4/V9Jhy7dhNkQWd/NDTWhRquZgbSIZTXV0TWX7IIYnZ2Jiyz6rtSh
> us6xGK5psFxeWDCkzSVSfM7eGp57I/kGAUWpIpWR8ZiL8zqWr8A3L4M5RRLTukwb
> IIzMK4oFBHau4luXfHu5mJwVsF/fDENXnPTHeQYXJqQJOjqVUVtCNSUBmImKuCg=
> =kUVd
> -----END PGP SIGNATURE-----
>
>


-- 
-- Jose Labra