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: 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>
Message-ID: <5705B09A.6050207@gmail.com>


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

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