Re: On the inevitability of SPARQL/SPIN for SHAQL

On Sat, Feb 28, 2015 at 1:54 AM, Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I think that it is about time to accept the fact that SHAQL is going to be
> based on SPARQL and look a lot like SPIN.  This is not my preferred outcome
> from the working group, but I can live with it in the absence of anything
> better.
>

In my opinion, what we should do, is to clarify what are the roles of
SPARQL here and the relationship between SPARQL and SHACL.

Why do I say that SPARQL/SPIN is inevitable for SHAQL?  There is no other
> proposal that will satisfy the bulk of the members of the working group.  I
> myself would prefer something based on OWL Constraints, but there are many
> working group members who feel a need for features that are not part of the
> RDF model theory.


I think we should not throw in the towel now. In this email:

https://lists.w3.org/Archives/Public/public-data-shapes-wg/2015Feb/0266.html

You proposed a model-based semantics based on a simple language that can be
used as a first step towards a core language. I was reviewing it and I
think it is compatible with the axiomatic semantics of the same subset of
language features.

There are the various versions of Shape Expressions, but
> each of them has fatal problems.  The W3C Submission has a broken semantics
> and there ia no obvious way to fix it.  The algebraic version of Shape
> Expressions is too different from the other proposals and doesn't even work
> on RDF graphs.  The Resource Shape 2.0 W3C submission is only words.
>

It was said in another thread and during the meeting that most of the
people behind Shape Expressions and Resource Shapes are part of the WG and
I think we are all committed to define the new SHACL formalism. I still
think that we should keep working on to find the common features that
underlies all the proposals.

This doesn't mean that I think that the SHACL Specification is going in the
> right direction.  I think that there are two choices for the SHACL
> Specification.  Either it starts with the SPARQL stuff and later introduces
> the high-level language as a shorthad or it starts with the high-level
> language (without any mention of SPARQL) and only later brings out how the
> high-level language can be implemented as mappings to SPARQL.  Right now
> the specification is much too scatter-shot, with no clear notion of what
> SHAQL is supposed to be.
>

I agree with you that the current spec needs a lot of work to accommodate
the different proposals but I really think it can be done if everybody
tries to work in the same direction.

>From my point of view, there are different roles that SPARQL can play with
regards to SHACL:

1.- SPARQL as an implementation language. SPARQl can be used to define most
of the structural constraints. It needs some extra layer to be able to
handle recursion, but in principle it can be a good candidate to express
how to implement the main features of Shacl. The advantage is that people
who know SPARQL will find familiar the Shacl constructs. I don't oppose to
have mappings from the core Shacl language to SPARQL.

2.- SPARQL as an extension mechanism. SPARQL (and other languages like
javascript) can be invoked by the Shacl processors to obtaing greater
expressivity. In this way, users can define some complex constraints using
those languages. The advantage is that we don't limit expressiveness to the
core language. I think this mechanism is very useful and I agree to have it
in the language. However, I think this extensibility mechanism should be in
a controlled part of the language so users know that if they employ these
extra features they are compromising compatibility, i.e. their shapes that
use SPARQL features will not work with a SHACL processor that doesn't
support SPARQL.

3.- Define new macros using SPARQL. This is for me the most controversial
point. I may agree to have some mechanism to define macros in the language,
but i would not impose those macros to be defined only in SPARQL. If we
want macros with parameters and so, we can add some language construct to
define macros. Defining those macros directly in SPARQL is a language
mistake. It means that the high level language (Shacl) allows users to
define functions in the low level language (SPARQL). It would be as if Java
programmers could define their methods using bytecodes.

4.- Use SPARQL to construct error messahes. I think this is not needed and
we can just define some vocabulary of error messages or some
Post-Schema-Validation data structure with information about the errors.

Best regards, Jose Labra

>
>
> Peter F. Patel-Schneider
> Nuance Commmunications
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJU8RG2AAoJECjN6+QThfjzeg8IAKzDVXgFsXJWvdLRiYExTLGj
> 3rVUpUqnogsH/sOIZthu+v2tIi8VZ/nAKfZcpaZYwNQ+QEL4ahy+q/7Lbb+m3fRh
> Vyzhh4n32PEuL21SHzyU5181murvXVfktpVl+6d2iU2HNkTq028YROtSSOzh5cjU
> lR1+Ys5Brfed3/v3Uu+CNua4K9B3PWlcAPXuS78c1c0llYslOJ0uSKt/Cfz1j7wU
> VX2nPq4tKS+wZbPvJ1R1/oT06O8l9b+20vJ4bpkUmiZhR817Kkhz632syi6ESOsi
> ErqUcm7Nc3mrngmBd6oT0e31D00EJq0GSyS6jOrkNhK45/WEfwOzkgESy/beDMc=
> =r1P5
> -----END PGP SIGNATURE-----
>
>


-- 
-- Jose Labra