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