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

Re: SHACL semantics - any alternatives to SPARQL?

From: Holger Knublauch <holger@topquadrant.com>
Date: Mon, 09 Mar 2015 09:49:20 +1000
Message-ID: <54FCE000.4060800@topquadrant.com>
To: public-data-shapes-wg@w3.org
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". 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".

More comments in-line.

On 3/7/2015 12:04, Peter F. Patel-Schneider wrote:
> Hash: SHA1
> 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.

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

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

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.

> - - has constraints separate from classes

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

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 

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


Overall I see this as future work which will be resolved in due course.

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

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

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

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

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


The uncommented differences seem largely a matter of taste.


> - - has a somewhat different top-level control mechanism
> Non-significant differences (as of 6 March)
> My specification
> - - does not include much of the high-level language vocabulary
>    - filling in this could largely be a matter of copying
> - - does not discuss a template mechanism
>    - this could be largely copied over, removing any non-SPARQL stuff and
>      having templates produce shapes (which are parts of a constraint)
Received on Sunday, 8 March 2015 23:50:21 UTC

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