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

Re: differences between github SHACL spec and my SPARQL-based spec

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Thu, 05 Mar 2015 16:49:21 -0800
Message-ID: <54F8F991.8060601@gmail.com>
To: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg@w3.org
Hash: SHA1

On 03/05/2015 04:42 PM, Holger Knublauch wrote:
> On 3/6/2015 10:19, Peter F. Patel-Schneider wrote:
>> It certainly was not evident in the previous versions of the document
>> that SPARQL was anything besides the default engine or had any sort of
>> precedence over other engines. Even now, the abstract says "SPARQL and
>> other third[-]party languages".
> Ok, I have taken that partial sentence out for now, as it may give the 
> non-SPARQL aspect too much visibility for an abstract.
>> The current document requires that every macro has a SPARQL expansion,
>> but doesn't say anything about the relationships between the different
>> expansions.
> Changed to
> "Each constraint needs to provide at least one executable body in SPARQL,
> *and any alternative bodies need to follow the same semantics as the
> SPARQL queries.*"
>> Each different execution engine would provide a different semantics
>> (and maybe the axiomatic semantics provides yet another). Maybe,
>> instead, the intent was that the axiomatic semantics was *the*
>> semantics and the SPARQL execution engine had to conform to that
>> semantics. However, this is very problematic as the axiomatic semantics
>> doesn't cover a lot of SPARQL constructs.
> Agreed. Plus the axiomatic semantics are unnecessary because the
> template mechanism with SPARQL queries is already self-contained.
>> As far as I can tell, implementing sh:valueShape is not possible.  I
>> don't think that there is even a good specification of just what it is
>> supposed to be doing.
> When I implemented sh:hasShape I noticed that I needed to add a hack
> that prevents infinite loops. If it encounters the same combination of
> arguments twice, it currently just assumes "true". Is this related to the
> problems that you see?

Yes, indeed, but just using "true" is not a full solution.  For example,
suppose the self-reference is inside a MINUS or other negative construct.

>> Section 7 shows how nodes and classes are the center of the spec. 
>> Properties hung off of classes and nodes are the way that constraint 
>> handling is initiated.
> But it seems that SHACL-SPARQL does the same thing, just using properties
> that go in the other direction. Is this what you are referring to?
> Also I believe Section 7 is coming fairly late, and I have already tried
> to find a compromise on the classes-vs-shape discussions. So I don't
> agree that nodes and classes at the center. The properties hang off
> sh:Shapes, and punning allows us to reuse the URIs of existing RDFS
> classes, because this will significantly improve useability of the
> language.
> Minor update at:
> https://github.com/w3c/data-shapes/commit/4077bc9cf4376011df4ae4e9c4a8b699ce793fbc
> Thanks, Holger
Version: GnuPG v1

Received on Friday, 6 March 2015 00:49:53 UTC

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