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

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

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


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

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

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

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

Received on Thursday, 5 March 2015 23:23:39 UTC