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

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



On 03/05/2015 03:22 PM, Holger Knublauch wrote:
> Hi Peter,
> 
> thanks for enumerating these differences. Please allow me to try to
> address your issues with updates to "my" version of the spec, to see if
> we can evolve this into more common ground. I hate to call it "my" spec,
> so I'll use "SHACL spec" to refer to "my" version, and "SHACL-SPARQL" to
> "your" version.
> 
> On 3/6/2015 7:56, Peter F. Patel-Schneider wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> Significant 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/
> 
> (BTW I have just made minor edits to your table at the end, please verify
> if these make sense).
> 
>> My specification
>> 
>> - - has a single execution engine - SPARQL - instead of multiple
>> exeuction engines
> 
> The SHACL spec also only has a single execution engine built-in. It is 
> described through a combination of the section on Operations and the
> section on sh:sparql. I have tried to make this clearer. For example, the
> abstract now states
> 
> "Additional constraints can either be stated globally or be associated
> with shapes using SPARQL and other third party languages which extend
> SHACL."
> 
> I hope this makes clear that no other language than SPARQL is part of
> the standard, but being in an open RDF world I see no reason to disallow
> other people from adding other triples such as my:javaScript to their
> template declarations.
> 
> My proposal remains that 1) All well-formed SHACL files must have SPARQL
> queries for the templates and native constraints 2) Other languages such
> as JavaScript can be used assuming that also a SPARQL query is provided.
> 
> I believe this addresses the concerns by some WG members, but we ran out
> of time today to cover this topic and I did not get email responses, so I
> can only speculate at this stage.
> 
> I have made several edits across the spec to clarify this (see link to
> history below).

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".  The current document requires that every macro
has a SPARQL expansion, but doesn't say anything about the relationships
between the different expansions.

>> - - has a single semantics - translation to SPARQL - instead of
>> potentially multiple semantics
> 
> Where do I allow multiple semantics in the SHACL spec? This was not the 
> intention. Please help me improve the wording.
> 
> If you are referring to section 2, this is clearly marked as an open
> ISSUE. It has been added by Eric and I am in no position to remove that
> section, and we ran out of time to discuss this today, so I hope it
> doesn't take another couple of weeks to clarify what to do with it...

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.


>> - - 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
> 
> Which significant extensions to SPARQL are required in your opinion? I
> can only think of sh:valueShape. As I indicated elsewhere, it would be
> perfectly possible to change the implementation of sh:valueShape so that
> it is not backed by a SPARQL query with sh:hasShape, but instead does the
> recursion in a hard-coded fashion. I had already added a red TODO block
> under the SPARQL query to explain this. If this (TODO) is not strong
> enough, shall I swap the order and make the sh:hasShape function optional
> instead?
> 
> Note that sh:hasShape is also used in sh:OrConstraint, but this can
> similarly (easily) be hard-coded into the engine instead of being backed
> by a SPARQL query.
> 
> If this would bring our languages closer together, I'd be happy to make
> these changes. OTOH I believe the sh:hasShape function will be generally
> useful outside of these two scenarios, and it is quite elegant to be able
> to stay soft-coded within SPARQL for these templates (e.g. assume someone
> would want to implement an Xor).

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.

>> - - is centered around constraints and shapes instead of being centered
>> around classes and nodes
> 
> This may be a matter of wording in the SHACL Spec, but I believe both
> are centered around constraints and shapes. Do you have specific
> paragraphs that you object to (other than the OO features you mention
> below)? Classes are de-emphasized already in favor of sh:Shape.

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.

>> - - does not have (self-)recursion
> 
> SHACL-SPARQL does not talk about sh:valueShape much, so it is unclear
> what support it would have. I guess the ShEx people will not be happy to
> just drop that feature.

Well if the Shape Expressions people want to have recursion they need to
produce an acceptable specification for it.

>> - - does not have any OO features like private, or abstract, or final,
>> or inheritance, or extends
> 
> I have removed private, abstract and final from the spec for now.
> Inheritance is clearly marked to be affected by ISSUE 4. It is quite
> possible that we make RDFS semantics mandatory (automated) but this has
> not been decided yet, so I'd at least want to enumerate the two proposals
> in the spec.



>> - - has reporting based on SPARQL - There is nothing to prevent
>> post-processing, though.
>> 
>> - - has no functions
> 
> I will fight very hard to keep the idea of SPIN functions in the spec.
> They are an incredibly useful feature for most people who have worked
> with them, although I can understand that they may seem unnecessary from
> the point of view of producing a minimum viable spec, and for someone who
> has not yet worked with SPIN. In fact Functions significantly reduce the
> complexity of writing SPARQL queries to average users, if they have
> higher-level building blocks to work with. So it's not about creating a
> minimal spec for me, but a spec that actually will be user-friendly.


> 
>> 
>> - - has no contexts
> 
> I had deleted the sh:Contexts yesterday, among with other clean up.
> 
> You can see a diff of my changes here:
> 
> https://github.com/w3c/data-shapes/commit/8c2c707c9bd5b259a386cb0789490e3dd3ab56d7
>
> 
> 
> Thanks, Holger

peter

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

iQEcBAEBAgAGBQJU+PKmAAoJECjN6+QThfjzAm0H+wYPV4y8RR3KTYpATEZn61Hw
TspD/t9qavqMPgDvZ1qyuu96lOhFCE5wKlV0DJu0ZfRpphEvzt1SKOrAB10SH6V4
SRwyniNkcetQf4qQK5s0GAVNmDQZRD7aqy3tMIecwLRfpQ/hXm5PKZ6aN3Oq18WS
FDB0EOeAsD9OhQDIwn6xXqQBV9q7whscC5LVhWuiJsaBiWiVTozLE8GJVrWu2IOZ
MJZSlYYgTfb1oMcStRFM33NU/U89iSHP769n/uZaXhZH1Ozp0xgwrFYjvl9sQOL8
66K9ciopUo615dB0Po0niKt8St40BCY45eXCfgKAdQqSZF9xk3zfTrgNuZDU350=
=KtSN
-----END PGP SIGNATURE-----

Received on Friday, 6 March 2015 00:20:22 UTC