Re: shapes-ISSUE-212 (Property constraints): Property constraints and focus node constraints [SHACL Spec]

We could just declare the constraint classes to be disjoint and achieve the same without revisiting the whole design. These are just artificial corner cases anyway - who would ever do this in practice?

Sent from my iPad

> On 28 Nov. 2016, at 20:09, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> wrote:
> 
> I think this problem stems from merging  node constraints with shapes.
> Before, focus node constraints were declared with sh:constraint and not directly into the shape and  were disjoint with property constraints so this problem could not occur.
> 
> The proposed solution fixes this problem, but adding exceptions to definitions is not a good approach. 
> I would prefer to reconsider our resolution
> https://www.w3.org/2016/07/28-shapes-minutes.html#resolution04
> 
>> On Thu, Nov 24, 2016 at 6:17 AM, Holger Knublauch <holger@topquadrant.com> wrote:
>> The email thread quoted below went back and forth, because the original SHACL examples that Peter had given were syntactically incorrect. From what I can see, the last unanswered email on this topic was
>> 
>> https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Nov/0012.html
>> 
>> In the last sentence there, Peter claims that
>> sh:pc2 is also a property constraint so the
>> constraint component is also checked with focus node ex:i1 and value node
>> ex:i2, which produces a validation report.  Therefore se:s2 produces a
>> validation report.
>> However this case has been excluded through the addition of a sentence to the Validation Definition in section 3:
>> 
>> Note that validation against a shape processes the shape as a focus node constraint only, even if the shape may have rdf:type triples or an expected type that would also make them property constraints.
>> 
>> As a result of this, I believe we can close this issue as resolved.
>> 
>> Holger
>> 
>> 
>> 
>>> On 23/11/2016 8:46, RDF Data Shapes Working Group Issue Tracker wrote:
>>> shapes-ISSUE-212 (Property constraints): Property constraints and focus node constraints [SHACL Spec]
>>> 
>>> http://www.w3.org/2014/data-shapes/track/issues/212
>>> 
>>> Raised by: Karen Coyle
>>> On product: SHACL Spec
>>> 
>>> Peter's email: https://lists.w3.org/Archives/Public/public-rdf-shapes/2016Nov/0005.html
>>> 
>>> Data Graph D:
>>> 
>>> ex:i1 rdf:type ex:c ;
>>>  ex:p1 ex:i2 .
>>> 
>>> 1/ property constraints and focus node constraints
>>> 
>>> Shapes Graph S1:
>>> 
>>> se:s1 rdf:type sh:Shape ;
>>>   sh:targetClass ex:c ;
>>>   sh:property [ sh:predicate ex:p2 ;
>>>                 sh:property se:s2 ] ;
>>>   sh:shape se:s2 .
>>> se:s2 sh:predicate ex:p1 ;
>>>   sh:class ex:c .
>>> 
>>> Validating D against S1 produces the following validation report
>>> 
>>> [ rdf:type sh:ValidationResult ;
>>>   sh:severity sh:Violation ;
>>>   sh:focusNode ex:i1 ;
>>>   sh:sourceConstraintComponent sh:ShapeConstraintComponent ;
>>>   sh:sourceShape se:s1 ] .
>>> 
>>> It is actually a tiny bit unclear what makes a property constraint.  There
>>> is wording that values of sh:property have sh:PropertyConstraint as expected
>>> type, but there is no actual explicit connection between nodes with expected
>>> type sh:PropertyConstraint.  However, se:s2 is definitely a property
>>> constraint as it is the value of sh:property in a shape.
>>> 
>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Dimitris Kontokostas
> Department of Computer Science, University of Leipzig & DBpedia Association
> Projects: http://dbpedia.org, http://rdfunit.aksw.org, http://aligned-project.eu
> Homepage: http://aksw.org/DimitrisKontokostas
> Research Group: AKSW/KILT http://aksw.org/Groups/KILT
>