- From: Holger Knublauch <holger@topquadrant.com>
- Date: Tue, 29 Nov 2016 09:59:20 +1000
- To: public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <4b1da89e-1584-6cc1-d2f8-a26d00a0c549@topquadrant.com>
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 afocus 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 >>>> anexpected type >>>> <#m_-4227046068154925177_m_8263554335808019572_m_6642620271588933798_m_5129570904457041819_dfn-expected-type>that >>>> would also make themproperty 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
Received on Tuesday, 29 November 2016 00:00:03 UTC