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

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?

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

Received on Friday, 6 March 2015 00:43:29 UTC