- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Wed, 6 Apr 2016 17:58:02 -0700
- To: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg <public-data-shapes-wg@w3.org>
On 04/06/2016 05:16 PM, Holger Knublauch wrote: > 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. Would it? SHACL instance is defined without regards to default value types. >> _: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. I don't see that anywhere in the current document. >> _: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. Again, I don't see this requirement spelled out in the document. As well, RDFS processors may add rdf:type links to rdfs:Resource. However, _:c1 and _:c6 appear to be invalid for different reasons. This seems to go against the discussion about the relationship between SHACL and RDFS inferencing. >> _: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). Why is this different from _:c5? They both have a single rdf:type link to sh:Constraint. >> 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. I had thought that the document had a viable design for templates, and that the metamodel discussion was about improving this design. >> 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. > 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. The problem is that in many cases I don't know what should be valid or invalid. All I can do is look at the document and find places where it is unclear on this point. > 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. I think that this would be a horrible idea. The whole idea of having a standard is to define what is supposed to happen, particularly in the corner cases. The document should define a set of RDF graphs that are valid SHACL shape graphs and for these graphs define what happens when they are used to validate data graphs. > How did for example the OWL WG solve the situation of > invalid class declarations? OWL defines which graphs are valid OWL ontologies for the various levels of OWL. As far as I know an RDF graph is either an OWL (DL) ontology or not. There are no grey areas (except, I suppose, for the handling of owl:imports). > Thanks, > Holger peter
Received on Thursday, 7 April 2016 00:58:31 UTC