Re: SHACL semantics - any alternatives to SPARQL?

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

On 03/08/2015 04:49 PM, Holger Knublauch wrote:
> Hi Peter,
> 
> the goal of "my" version of the SHACL spec is to serve as a possible 
> compromise between the "SPARQL camp" and the "ShEx camp".

I'm unaware of the compromises that you have made between the "SPARQL camp"
and the "ShEx camp".  As far as I can see
http://w3c.github.io/data-shapes/shacl/ of 5 March 2015 is based on SPARQL,
except for Section 2, which does not appear to be related to anything in the
rest of the document.

> While you may find your proposal more consistent, I doubt that it will 
> help the group come closer together. So while I have tried to address 
> some of your ideas (many as TODO items and ISSUES) I do not believe your
>  proposal is going in the right direction. Furthermore it is very 
> incomplete. You cannot on the one hand side point at possible problems in
> the details of the ShEx specifications while at the same time glance over
> important gaps of your own "spec".

As far as I know there was only one significant gap in my spec as of 6
March.  I did not have an expansion for embedded in shapes.  This has now
been filled in.  I do still only have expansions for a few kinds of shapes
but the remaining ones can easily be filled in.

There are some things that my spec does not address at all, such as nice
reporting of violations and profiles.  These are largely indpendent of the
underlying spec.

What I pointed out in the some of the ShEx proposals were problems in the
semantics.  As far as I can tell, both the semantics partly based on Z and
the axiomatic semantics have problems with recursive shapes when negation is
involved.

> More comments in-line.
> 
> On 3/7/2015 12:04, Peter F. Patel-Schneider wrote:
>> 
>> 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 engines
> 
> As soon as a high-level vocabulary is defined, anyone is free to 
> implement non-SPARQL execution languages even with your own proposal. The
> SHACL spec is in the same spirit: it only defines the SPARQL-based 
> operations as normative, yet it makes clear that certain profiles do not
>  require a full SPARQL processor to make sense of a model.

http://w3c.github.io/data-shapes/shacl/ as of 5 March has the notion of
different executable bodies.  I view this as a very significant difference
between the two proposals.

>> - - has a single semantics - translation to SPARQL - instead of 
>> potentially multiple semantics
> 
> If you are referring to section 2 then I agree, and I mentioned before 
> that this requires consolidation.

Section 2 and the notion of different executable bodies.  Each different
kind of executable body induces a new semantics.  There is now wording that
alternative bodies have to produce the same result as the SPARQL body.  But
then why bother to have different execution bodies.  As you say above anyone
is free to implement in other ways so there is no need to have difference
execution bodies after all.

>> - - 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
> 
> You seem to refer to your recurrent theme of recursive shape definitions
>  via sh:valueShape, because I see no other "significant extensions to 
> SPARQL" in the SHACL spec. And even for that I have already clarified 
> that there is an alternative implementation that can live without the 
> sh:hasShape function, so I am not sure why you keep repeating this aspect
> here. It's already addressed.

If you don't have the sh:hasShape function then how can you implement
recursive shapes?

> Your own spec does not even introduce sh:valueShape, and you do not 
> explain how your translation would work. You would need to provide an 
> alternative algorithm.

This missing piece is now in place, showing how non-recursive shape
inclusion can be handled.


>> - - has constraints separate from classes
> 
> The SHACL spec also has constraints separate from classes. They can be 
> global or be attached to shapes.

In Section 7.1 of http://w3c.github.io/data-shapes/shacl/ as of 5 March
shape selection based on type requires that classes also be shapes.  In my
proposal control nodes can have scopes that are types.

> In your own proposal, constraints are linked to classes with triples
> that point from a constraint to the URI (literal) of a class, e.g.
> 
> ex:Constraint sh:classScope "http://example.org/Person"^^xsd:anyURI ;
> 
> This is not fundamentally different from the SHACL mechanism of having
> 
> ex:Person sh:constraint ex:Constraint .
> 
> only that your proposal to use xsd:anyURI would create a still-born 
> technology.

Having individuals whose type is a shape (that is also a class) is different
from having constraints whose scope is a class and individuals whose type is
that class.

>> - - separates the constraint graph from the data graph
> 
> So does the SHACL spec, although I had to take out the sections on Graph 
> management because we had not reached this topic in the WG yet and you 
> suggested I take them out for now. Furthermore you have objected to a 
> requirement to clarify how the separation of constraints from data
> graphs work:
> 
> 
https://www.w3.org/2014/data-shapes/wiki/Requirements#Including_Named_Graphs_for_Query_Evaluation
> 
> Overall I see this as future work which will be resolved in due course.

I was objecting to the notion of importing as part of SHACL, not in
separating the constraint graph from the data graph.

>> - - does not have a specialization relationship for constraints or 
>> shapes
> 
> I have already addressed this by adding ISSUEs to the spec. The ShEx 
> people also wanted a sh:extends relationship between shapes, so whether 
> RDFS entailment will answer all this is unclear.

Agreed.

>> - - 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
> 
> As mentioned above this is not specified anywhere in your spec.

The section on SHACL Simple Shape Language says:
  A SHACL Shape Node must not refer to itself, either directly or
  indirectly.

>> - - has reporting based on SPARQL - There is nothing to prevent 
>> post-processing, though.
>> 
>> - - has no functions
>> 
>> - - has no contexts
> 
> Contexts have already been removed from the SHACL spec.

I see.

>> Other Differences (as of 6 March)
>> 
>> My specification
>> 
>> - - has a scope mechanism instead of organizing constraints into local
>>  and global
> 
> The SHACL spec now also has sh:scope. I don't think having scoping based
>  on SPARQL SELECT queries (your sh:sparqlScope) is a good idea. It would
>  exclude other implementations for too little gain (people can already do
>  this in the WHERE clauses of global SHACL constraints).

All the high-level and macro and template stuff can be done by directly
using SPARQL, so, yes, all the scoping can be done in other ways.  Shall we
then get rid of it all then?

>> - - 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
> 
> Profiles are an approved requirement:
> 
> https://www.w3.org/2014/data-shapes/wiki/Requirements#Profiles

Agreed.  My spec does not cover profiles.

> The uncommented differences seem largely a matter of taste.
> 
> Holger

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

iQEcBAEBAgAGBQJU/fdEAAoJECjN6+QThfjzwdAH/Ru5LaIr7ShddY/h/r8jAjLI
ZEQQ0dPBS2lWYcJEEeyudCo+Q7nYaa4TY/Spe3IrbAiUYW/GRYFpo072+AomXj+K
nqRUBtoWe8PJdxAWPSlDQ8fKsApx8UZycFTNnpa1TYazjnJTgglCsuPXw3Jd2VC/
p4m4fpNBFrh6womGUo0ncBKP+t39xEHhEsXGOrScOfVEZ0Wt6bsxXGS+EeyDCljk
TxKUdDuA08PFDnJG8JQznWxO91LPRh/ImsdK4b1YKThNT7w/P+H1dM9my6VS3yIX
5PeuXmfY0NsYyYORw4a4L6Fzcxl9FoEns6wBzI5FGQMVfZn7RhYKlU6ELfOaULs=
=rhdT
-----END PGP SIGNATURE-----

Received on Monday, 9 March 2015 19:41:24 UTC