- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Mon, 28 Nov 2016 18:39:36 -0800
- To: public-data-shapes-wg@w3.org
On August 7, in section 2, some uses of "shape" were changed to "focus node constraint".[1] It may have originally come in on this earlier edit.[2] I couldn't find an issue or a resolution that specifically mentioned this. Now it is proposed to change this back to "shape". At this point, it seems like terms are being added and removed at a rather dizzying pace, and everything seems to be both a shape and a constraint. Maybe a discussion of what we are modeling, after all of this, would be warranted. I'm pretty sure that the group could benefit from this. kc [1] https://github.com/w3c/data-shapes/commit/a18ef517e1df8d8304947d1b264479e71e2ecd3c [2] https://github.com/w3c/data-shapes/commit/9a4ccdc40bf71444afb945ec29373535fe06b4a4 On 11/28/16 3:59 PM, Holger Knublauch wrote: > I believe the metamodel itself is fine, but we may have a terminology > issue. The term "focus node constraint" is equivalent to "shape", and > since it will be hard to drop the term "shape" from a language called > SHACL I suggest to drop "focus node constraint" - it's also too long. I > skimmed through the document and believe it's quite easy (and > beneficial) to make this replacement. I have updated the proposal > accordingly: > > > https://www.w3.org/2014/data-shapes/wiki/Proposals#ISSUE-212:_Property_constraints > > Making more fundamental changes such as merging shapes and property > constraints (and SPARQL constraints) is a clear -1 from my side. It > would result in even more chaos (e.g. ex:MyShape sh:property [ > sh:datatype xsd:string ] would be legal, but what would it mean?). > > I also don't think that making the classes disjoint is beneficial. If we > say that "a node that is both a shape and a property constraint results > in a failure" then we would need to perform schema validation before > every data validation, and this is quite expensive because there are > quite a number of triples to check to determine whether a node is a > shape or a property constraint. In the current solution, no such > checking is needed, and the engine just looks at the incoming > sh:property link. That single sentence that I had added to clarify what > happens in the case of overlaps covers this IMHO. > > Holger > > > On 28/11/2016 23:45, Dimitris Kontokostas wrote: >> 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 >> <https://www.w3.org/2016/07/28-shapes-minutes.html#resolution04> >> [2] https://en.wikipedia.org/wiki/Mixin >> <https://en.wikipedia.org/wiki/Mixin> >> >> On Mon, Nov 28, 2016 at 3:06 PM, Holger Knublauch >> <holger@topquadrant.com <mailto: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 >> <mailto: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 <mailto: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 <mailto: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 >>>> <mailto: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 >>>>> <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 >>>>> <mailto: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 >>>>> <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_-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 <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 >>>>>> <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 >>>>> <http://aksw.org/DimitrisKontokostas> >>>>> Research Group: AKSW/KILT http://aksw.org/Groups/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 >>>> <http://aksw.org/DimitrisKontokostas> >>>> Research Group: AKSW/KILT http://aksw.org/Groups/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 >>> <http://aksw.org/DimitrisKontokostas> >>> Research Group: AKSW/KILT http://aksw.org/Groups/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 -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Tuesday, 29 November 2016 02:40:14 UTC