On the inevitability of SPARQL/SPIN for SHAQL

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

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

What features are not currently handled by SPIN?  As far as I can tell, the
mssing features are shape recognition and coverage of edges of the graph.
Both of these appear impossible in a SPARQL-based solution, the former
because it would require a significant extension to SPARQL, which SPARQL
engines may not support, and the latter because there is no reasonable
definition of edge coverage that is computed by SPARQL engines.

What then should the working group be doing?  It should fix up various bits
of SPIN, such as basing class membership on RDFS reasoning.  It should
remove the parts of SPIN that are not needed.  It should determine the
relationship between shapes and classes.  It should clarify the top-level
control of shapes and how shapes documents are to be handled and how
violations are reported.


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.


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

Received on Saturday, 28 February 2015 00:54:45 UTC