- From: Dimitris Kontokostas <kontokostas@informatik.uni-leipzig.de>
- Date: Tue, 19 Jul 2016 11:09:56 +0300
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: public-data-shapes-wg <public-data-shapes-wg@w3.org>
- Message-ID: <CA+u4+a0+X9c8Q1g4L-Bw1iO6uRD2u3Hs7v5=giXbYgBruq9mOQ@mail.gmail.com>
On Tue, Jul 19, 2016 at 9:41 AM, Holger Knublauch <holger@topquadrant.com> wrote: > > > On 19/07/2016 16:17, Dimitris Kontokostas wrote: > > > > On Tue, Jul 19, 2016 at 3:35 AM, Holger Knublauch <holger@topquadrant.com> > wrote: > >> On 18/07/2016 18:34, Dimitris Kontokostas wrote: >> >> In general I am in favor of syntax simplifications but I have some >> concerns on this one, mainly from the use perspective >> What might not be straightforward for the users with this proposal is >> that when they use sh:or in property constraints they will not be able to >> use components such as >> sh:hasValue, sh:equals, sh:disjoint, sh:min/maxCount, sh:uniqLang and in >> general all components with NC not checked in the table of section 4 >> e.g. when someone defines that a property ex:p must : >> - have sh:hasValue X or sh:hasValue Z >> - be sh:equals to ex:p1 or ex:p2 >> they will always get back failures or violations (depending on ISSUE-139) >> >> >> Let's try to get to the bottom of this. >> >> In the current syntax the above would be expressed as >> >> ex:MyShape >> a sh:Shape ; >> sh:constraint [ >> sh:or ( >> [ sh:property [ >> sh:predicate ex:p ; >> sh:hasValue X ; >> ] ] >> [ sh:property [ >> sh:predicate ex:p ; >> sh:hasValue Z ; >> ] ] >> ) ; >> ] ; >> sh:constraint [ >> sh:or ( >> [ sh:property [ >> sh:predicte ex:p ; >> sh:equals ex:p1 ; >> ] ] >> [ sh:property [ >> sh:predicte ex:p ; >> sh:equals ex:p2 ; >> ] ] >> ) ; >> ] . >> >> i.e. the sh:or must be placed on the outside. With the new syntax that >> situation does not change, only that the sh:constraint triples would be >> collapsed: >> >> ex:MyShape >> a sh:Shape ; >> sh:or ( >> [ sh:property [ >> sh:predicate ex:p ; >> sh:hasValue X ; >> ] ] >> [ sh:property [ >> sh:predicate ex:p ; >> sh:hasValue Z ; >> ] ] >> ) ; >> sh:or ( >> [ sh:property [ >> sh:predicte ex:p ; >> sh:equals ex:p1 ; >> ] ] >> [ sh:property [ >> sh:predicte ex:p ; >> sh:equals ex:p2 ; >> ] ] >> ) . >> >> Using sh:hasValue and the other operators inside of an sh:or at a >> property constraint would not have the desired effect, because sh:or >> iterates over all values of the property and then applies the constraint >> independently. And the members of the sh:or list are sh:Shapes, not >> sh:NodeConstraints. >> >> But this topic seems orthogonal to the question of merging >> sh:NodeConstraint with sh:Shape to me. Could you clarify where you see the >> connection? >> > > I agree that if you know how you want to do something the new syntax will > make it easier for you. > but if we merge sh:Shapes with with sh:NodeConstraints, we will make it > very natural for people to express shapes in a wrong way, i.e. write it like > > ex:MyShape > a sh:Shape ; > sh:property [ > sh:predicate ex:p ; > sh:or ( > [sh:hasValue X ;] > [sh:hasValue Y ;] > ) ; > sh:or ( > [sh:equals ex:p1 ;] > [sh:equals ex:p2 ;] > ) ; > ] ; > > and it will be harder for us to explain why the former is wrong while the > following is correct > > ex:MyShape > a sh:Shape ; > sh:property [ > sh:predicate ex:p ; > sh:or ( > [sh:datatype ex:d1 ;] > [sh:datatype ex:d2 ;] > ) ; > sh:or ( > [sh:class ex:c1 ;] > [sh:class ex:c2 ;] > ) ; > ] ; > > imho If we keep the sh:constraint (or sh:node) explicit in the definition > it will be easier to explain the difference > > > I agree with this aspect. Whether it's a strong enough argument is > unknown. > I know and that is why I stated from start that I stay neutral on this change -- 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, 19 July 2016 08:10:58 UTC