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

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
>>> <#m_8263554335808019572_m_6642620271588933798_m_5129570904457041819_dfn-focus-node-constraints>
>>>  only, even if the shape may have rdf:type triples or an expected type
>>> <#m_8263554335808019572_m_6642620271588933798_m_5129570904457041819_dfn-expected-type>
>>>  that would also make them property constraints
>>> <#m_8263554335808019572_m_6642620271588933798_m_5129570904457041819_dfn-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