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

They are the same thing to me, just another word in the spec. The term shape is more relevant, we could delete its alias.

Holger


Sent from my iPad

> On 28 Nov. 2016, at 22:20, Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de> wrote:
> 
> since shapes and focus node constraints have different definitions in the spec they should be distinguishable from each other, otherwise we should remove one of them
> this will also make more clear where sh:target* and sh:property properties are attached / specified: on the shape or the focus node constraint
> 
>> On Mon, Nov 28, 2016 at 1:38 PM, Holger Knublauch <holger@topquadrant.com> wrote:
>> 
>> 
>>> On 28/11/2016 21:06, Dimitris Kontokostas wrote:
>>> I think this is not possible with the current class hierarchy but could work if we adjust it
>>> 
>>> Currently sh:Constraint is the class of all constraints and focus node constraints are instances of sh:Constraint
>>> sh:PropertyConstraint is a subclass of sh:Constraint so disjointness would not work
>>> if we create another class for focus node constraint this could be possible
>> 
>> Focus node constraints are instances of sh:Shape, which is a subclass of sh:Constraint, which is just an "abstract" superclass. Why couldn't we make sh:Shape, sh:PropertyConstraint and sh:SPARQLConstraint pairwise disjoint?
>> 
>> Holger
>> 
>> 
>> 
>>> 
>>> On Mon, Nov 28, 2016 at 12:40 PM, Holger Knublauch <holger@topquadrant.com> wrote:
>>>> 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
>>> 
>>> --
>>> 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
> 
> 
> 
> -- 
> 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
>