Re: SHACL semantics - any alternatives to SPARQL?

On 3/10/2015 5:40, Peter F. Patel-Schneider wrote:
> I'm unaware of the compromises that you have made between the "SPARQL 
> camp" and the "ShEx camp".

- Inclusion of sh:Shape, sh:nodeShape and sh:extends
- Allowing other executable bodies in addition to sh:sparql
- Profiles

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

As already explained, additional bodies such as shx:javaScript or 
shx:xpath could be used by engines that are not based on SPARQL. I 
believe leaving this backdoor open provides a natural mechanism for the 
language to evolve. In an open RDF vocabulary anyone should be allowed 
to add their own properties.

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

For example through another bullet item at

http://w3c.github.io/data-shapes/shacl/#operation-checkConstraint

which would "hard-code" sh:valueShape. It would recursively call 
checkNodeAgainstShape for all objects of the subject/predicate combination.

BTW my current prototype passes the test of your Polentoni example. 
There may be theoretical corner cases, but even for those the 
sh:hasShape function could simply return a sh:FatalError if infinite 
loops are encountered. But yes I would also be fine with simply making 
recursion illegal, like in your proposal. As mentioned elsewhere, I 
could well live without the whole sh:valueShape feature.


I think the rest of the email was already sufficiently discussed and I 
leave it to others to comment on your proposal if they are so inclined.

Regards,
Holger

Received on Monday, 9 March 2015 23:27:16 UTC