- From: Holger Knublauch <holger@topquadrant.com>
- Date: Mon, 28 Nov 2016 21:38:14 +1000
- To: public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <f3d6c272-8c0e-d33e-93c0-5c9dda5d59f0@topquadrant.com>
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_6642620271588933798_m_5129570904457041819_dfn-focus-node-constraints>only, >> even if the shape may have|rdf:type|triples or anexpected >> type >> <#m_6642620271588933798_m_5129570904457041819_dfn-expected-type>that >> would also make themproperty constraints >> <#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 > Research Group: AKSW/KILT http://aksw.org/Groups/KILT
Received on Monday, 28 November 2016 11:38:54 UTC