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: Fri, 8 Apr 2016 10:59:27 +1000
To: public-data-shapes-wg <public-data-shapes-wg@w3.org>
Message-ID: <5707026F.1090501@topquadrant.com>
I believe this email thread has morphed into

https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Apr/0021.html

and can now be closed?

Holger


On 7/04/2016 10:58, Peter F. Patel-Schneider wrote:
>
> 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 Friday, 8 April 2016 01:00:01 UTC

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