Re: shapes-ISSUE-134 (knowing inverse): does SHACL syntax distinguish inverse property constraints [SHACL Spec]

On 04/06/2016 10:44 PM, Dimitris Kontokostas wrote:
> 
> 
> On Thu, Apr 7, 2016 at 3:58 AM, Peter F. Patel-Schneider
> <pfpschneider@gmail.com <mailto:pfpschneider@gmail.com>> wrote:
> 
> 
> 
>     >> ex:myConstraint rdfs:subClassOf sh:PropertyConstraint .
>     >>
>     >> _:c11 a ex:myConstraint ;
>     >>       sh:predicate ex:q ;
>     >>       sh:nodeKind sh:IRI .
>     >
>     > We could handle that case either way. We could allow subclasses of the system
>     > constraint classes, or not. I have no strong opinion.
>     >
>     > In an attempt to resolve this (better) I have started a new section 4.1.1
>     > Invalid Shapes Graphs:
>     >
>     >     http://w3c.github.io/data-shapes/shacl/#shapes-graph-invalid
> 
>     Oh.  I was just looking at that section as if it had been around previously.
>     Even with that section there are holes.
> 
> 
> I suggest that we create a (normative) shapes document that can validate
> shapes graphs and in section 4.1 we reference that document.
> We say that shapes graphs that do not validate against our shapes document are
> considered invalid..

This would be a reasonable thing to do, if it is possible.

> What a SHACL engine does with an invalid shapes graph is up to the engine to
> decide. e.g. Virtuoso relaxes the sparql syntax on their endpoint interface to
> make it easier for the users.
> A SHACL engine could either reject the shapes graph or try to recover some
> errors with some heuristics.

I think that it would be better to require a strict mode where all documents
that are not serializations of valid SHACL shapes graphs are rejected by the
SHACL processor and no validation is done.

peter

Received on Thursday, 7 April 2016 12:46:44 UTC