W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > April 2016

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

From: Holger Knublauch <holger@topquadrant.com>
Date: Thu, 7 Apr 2016 10:16:15 +1000
To: public-data-shapes-wg <public-data-shapes-wg@w3.org>
Message-ID: <5705A6CF.5070208@topquadrant.com>
On 7/04/2016 5:39, Peter F. Patel-Schneider wrote:
> Before this issue is closed, it should be possible to state what syntax errors
> there are in the following document and what a SHACL engine should do when
> encountering these errors, justifying each error and behaviour by pointing to
> unambiguous  and well-defined sections of the SHACL document.  We are not
> nearly at this point.
>
> peter
>
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
> @prefix sh: <http://www.w3.org/ns/shacl#> .
> @prefix ex: <http://ex.com/> .
>
> ex:s1 a sh:Shape ;
>   sh:property _:c1 ;
>   sh:property _:c2 ;
>   sh:property _:c3 ;
>   sh:property _:c4 ;
>   sh:property _:c5 ;
>   sh:property _:c6 ;
>   sh:property _:c7 ;
>   sh:property _:c8 ;
>   sh:property _:c9 ;
>   sh:property _:c10 ;
>   sh:property _:c11 .
>
> ex:s2 a sh:Shape ;
>   sh:inverseProperty _:c1 ;
>   sh:inverseProperty _:c2 ;
>   sh:inverseProperty _:c3 ;
>   sh:inverseProperty _:c4 ;
>   sh:inverseProperty _:c5 ;
>   sh:inverseProperty _:c6 ;
>   sh:inverseProperty _:c7 ;
>   sh:inverseProperty _:c8 ;
>   sh:inverseProperty _:c9 ;
>   sh:inverseProperty _:c10 ;
>   sh:inverseProperty _:c11 .
>
> ex:s3 a sh:Shape ;
>   sh:constraint _:c1 ;
>   sh:constraint _:c2 ;
>   sh:constraint _:c3 ;
>   sh:constraint _:c4 ;
>   sh:constraint _:c5 ;
>   sh:constraint _:c6 ;
>   sh:constraint _:c7 ;
>   sh:constraint _:c8 ;
>   sh:constraint _:c9 ;
>   sh:constraint _:c10 ;
>   sh:constraint _:c11 .
>
> _:c1 sh:predicate ex:p ;
>       sh:nodeKind sh:IRI .

The default value types of sh:property and sh:inverseProperty would make 
_:c1 invalid because it would be an instance of both 
sh:PropertyConstraint and sh:InversePropertyConstraint.

>
> _:c2 a sh:PropertyConstraint ;
>       sh:predicate ex:q ;
>       sh:nodeKind sh:IRI .

This would be invalid because values of sh:inverseProperty must be 
instances of sh:InversePropertyConstraint.

>
> _:c3 a sh:InversePropertyConstraint ;
>       sh:predicate ex:r ;
>       sh:nodeKind sh:IRI .
>
> _:c4 a sh:NodeConstraint ;
>       sh:predicate ex:s ;
>       sh:nodeKind sh:IRI .
>
> _:c5 a sh:Constraint ;
>       sh:predicate ex:s ;
>       sh:nodeKind sh:IRI .
>
> _:c6 a rdfs:Resource ;
>       sh:predicate ex:st ;
>       sh:nodeKind sh:IRI .

Similar, incorrect rdf:type of these constraints.

>
> _:c7 a sh:Constraint ;
>       sh:sparql "SELECT...." .

That case is syntactically valid but doesn't do anything. I am not sure 
what the engine should do (e.g. warning?). It would need to be a 
sh:SPARQLConstraint (in the new design).

>
> ex:LanguageConstraint a sh:ConstraintTemplate ;
>       rdfs:subClassOf sh:TemplateConstraint ;
>       sh:argument [ sh:predicate sh:predicate ; ] ;
>       sh:argument [ sh:predicate ex:lang ; ] ;
>       sh:sparql "SELECT ..." .
>
> _:c8 a ex:LanguageConstraint ;
>       sh:predicate ex:englishLabel ;
>       ex:lang "en" .
>
> ex:LanguagePropertyConstraint a sh:ConstraintTemplate ;
>       rdfs:subClassOf sh:PropertyConstraint ;
>       sh:argument [ sh:predicate sh:predicate ; ] ;
>       sh:argument [ sh:predicate ex:lang ; ] ;
>       sh:sparql "SELECT ..." .
>
> _:c9 a ex:LanguagePropertyConstraint ;
>       sh:predicate ex:englishLabel ;
>       ex:lang "en" .
>
> ex:LanguageInversePropertyConstraint a sh:ConstraintTemplate ;
>       rdfs:subClassOf sh:InversePropertyConstraint ;
>       sh:argument [ sh:predicate ex:lang ; ] ;
>       sh:sparql "SELECT ..." .
>
> _:c10 a ex:LanguageInversePropertyConstraint ;
>       sh:predicate ex:englishLabel ;
>       ex:lang "en" .

It is IMHO not worth spending more time on the above syntax using 
templates. Both open metamodel proposal use a different approach.

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

In that we can add further paragraphs on other cases that we deem 
invalid, and how to handle them. If you have specific input, I'd be 
happy to fold that in. I believe this section could become quite large, 
e.g. what to do with invalid parameters (e.g. sh:minCount "hello"), so I 
hope we can come up with more generic statements.

Another approach would be to leave this a grey area, where each 
implementation may decide what to do. How did for example the OWL WG 
solve the situation of invalid class declarations?

Thanks,
Holger
Received on Thursday, 7 April 2016 00:16:50 UTC

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