Re: On the inevitability of SPARQL/SPIN for SHAQL

+1 for Jose's analysis. We did agree at the f2f that the first 
implementation examples would be shown in SPARQL, but not that the 
language would *depend* on SPARQL.

kc

On 2/28/15 1:51 AM, Jose Emilio Labra Gayo wrote:
> On Sat, Feb 28, 2015 at 1:54 AM, Peter F. Patel-Schneider
> <pfpschneider@gmail.com <mailto: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
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Sunday, 1 March 2015 15:45:50 UTC