Re: SHACL semantics - any alternatives to SPARQL?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/06/2015 03:50 PM, Holger Knublauch wrote:
> On 3/7/15 2:38 AM, Peter F. Patel-Schneider wrote:
>> I'm one of the members of the working group that have been voicing and 
>> writing disapprovals, but I'm certainly not the only one.
> 
> Yes and I believe I have addressed your recent comments. I have
> integrated the scope feature, clarified the wording around SPARQL and
> clearly marked TODO items and ISSUES where we disagree for now. But
> overall these disagreements appear rather minor to me and include things
> that can and will be discussed further.
> 
> Overall, I think this WG could use some input from other people than the 
> handful of very vocal members. I think feedback from the outside would
> help. We also need more real-time conversations within the group. I don't
> think we are all that far apart from each other, but these emails always
> focus on the differences rather than the commonalities.
> 
> Cheers, Holger


I still see the following differences:



Differences between my SHACL specification (now at
https://www.w3.org/2014/data-shapes/wiki/Shacl-sparql) and the specification
at http://w3c.github.io/data-shapes/shacl/


Significant Differences (as of 6 March)

My specification

- - has a single execution engine - SPARQL - instead of multiple exeuction
  engines

- - has a single semantics - translation to SPARQL - instead of potentially
  multiple semantics

- - is completely implementable by first translating to SPARQL and then
  running the SPARQL queries under the RDFS entailment regime, instead of
  requiring significant extensions to SPARQL that may not be well behaved

- - has constraints separate from classes

- - separates the constraint graph from the data graph

- - does not have a specialization relationship for constraints or shapes

- - has a control mechanism centered around constraints instead of being
  centered around classes and nodes

- - does not have (self-)recursion - shapes can include other shapes so long
  as no cycles result

- - does not have any OO features like private, or abstract, or final, or
  inheritance [As of 6 March most of these have been eliminated.]

- - has reporting based on SPARQL
  - There is nothing to prevent post-processing, though.

- - has no functions

- - has no contexts


Other Differences (as of 6 March)

My specification

- - has a scope mechanism instead of organizing constraints into local and
  global

- - has constraints containing shapes and shapes containing other shapes
  instead of having shapes containing constraints

- - does not heavily use the notion of property constraints

- - does not have a profile mechanism

- - has a somewhat different top-level control mechanism


Non-significant differences (as of 6 March)

My specification

- - does not include much of the high-level language vocabulary
  - filling in this could largely be a matter of copying

- - does not discuss a template mechanism
  - this could be largely copied over, removing any non-SPARQL stuff and
    having templates produce shapes (which are parts of a constraint)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJU+lylAAoJECjN6+QThfjz0SsH/1jVR1d4YPv8zFYiwcUf4pnr
sdYVRZ66E36L7aSdOZpiC+2lkjqqomXnZPYVxTWt3Db5ba3bljn1TV+XEUFqM1au
cNZtxSpFNyAlQRCHnud1Z8ccFfdOP0aPVYmMiia+D1GUduqOn1ZIK2z0ZytpeluR
9bnFrDNGkcQ4v39NVZHm+Z2Llz1AOhdJk5qMyF1aus8x4HRCsSkpMqlzLmd83Stn
Mn3eNgeBZ4QUhfxPZqHsIieweV/XI9mMtcS/4sTaQmRBGVjCdsGgEXD7/+f8GEMO
25kB8sTAhFGRGlJ1ahSzArklZ2RPW7+QYP2Ju0P1UMQs6VhLwD01sR+BT1L666Q=
=rA/3
-----END PGP SIGNATURE-----

Received on Saturday, 7 March 2015 02:04:55 UTC