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

I find this approach problematic as a foundation of SHACL and eliminating
shapes or focus node constraints will make SHACL very hard to understand.
Also, too many times we agreed that Shapes and constraints are different
things
My idea for that resolution [1] was thought more as a mix-in [2] and not a
concept merge but maybe others can also verify this

I believe we should make the distinction very clear or make
sh:PropertyConstraints also a shape (along the lines of Peter's recent
proposal)
We are currently right in the middle

[1] https://www.w3.org/2016/07/28-shapes-minutes.html#resolution04
[2] https://en.wikipedia.org/wiki/Mixin

On Mon, Nov 28, 2016 at 3:06 PM, Holger Knublauch <holger@topquadrant.com>
wrote:

> 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/2016N
>>>> ov/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_-4227046068154925177_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_-4227046068154925177_m_8263554335808019572_m_6642620271588933798_m_5129570904457041819_dfn-expected-type>
>>>>  that would also make them property constraints
>>>> <#m_-4227046068154925177_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
>
>


-- 
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

Received on Monday, 28 November 2016 13:46:41 UTC