W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2015

Re: SHACL semantics - any alternatives to SPARQL?

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Fri, 06 Mar 2015 18:04:21 -0800
Message-ID: <54FA5CA5.7030809@gmail.com>
To: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg@w3.org
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

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

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

Version: GnuPG v1

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:17 UTC