Re: SHACL syntax and metamodel complexity

Sorry Holger but you cannot stop people from making proposals they think 
would improve the spec. As I said before there is a good reason for which 
the status of document on all our drafts state that this is work in 
progress and can be changed at any time:

        "This is a draft document and may be updated, replaced or 
obsoleted by other documents at any time."

Until we reached Candidate Recommendation we can change anything.

Now, I agree with you that this shouldn't be done without proper 
consideration because it is likely to be disruptive and have a cost but 
you can't just close the door to such proposals. This will only make 
people be even more reluctant to agreeing to anything if they think there 
is no chance of changing it later.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - 
IBM Software Group


Holger Knublauch <holger@topquadrant.com> wrote on 03/03/2016 04:20:30 PM:

> From: Holger Knublauch <holger@topquadrant.com>
> To: public-data-shapes-wg@w3.org
> Date: 03/03/2016 04:21 PM
> Subject: Re: SHACL syntax and metamodel complexity
> 
> On 4/03/2016 10:10, Peter F. Patel-Schneider wrote:
> > On 03/03/2016 03:50 PM, Holger Knublauch wrote:
> >> On 4/03/2016 9:29, Peter F. Patel-Schneider wrote:
> >>> This wording is extremely confused.   It is possible to have 
multiple
> >>> constraint components on the same property in one component, such as 
a
> >>> minCount and a class.  The confusion comes from using "property" for 
two
> >>> different things.
> >> I have replaced the second use of "property" with "predicate" to make 
this
> >> clearer.
> >>
> >> In your approach, if you have multiple sh:class values, are they 
being
> >> interpreted as AND or OR?
> > These would be conjuctive, of course, just as a sh:class and an 
sh:minCount
> > would be conjunctive.
> 
> Well, then just use multiple sh:property constraints, e.g.
> 
> ex:MyShape
>      a sh:Shape ;
>      sh:property [
>          sh:predicate ex:myProperty ;
>          sh:class ex:Type1 ;
>      ] ;
>      sh:property [
>          sh:predicate ex:myProperty ;
>          sh:class ex:Type2 ;
>      ] ;
> 
> There is no need to overhaul everything just for the rare cases where 
> you need such intersections.
> 
> >
> >
> >> Note that in either case this multi-occurrence within the same 
property
> >> constraint causes a serious limitation by disallowing constraint 
types that
> >> have multiple parameters such as sh:pattern/sh:flags. I guess that's 
one
> >> reason why you (silently) dropped the extension mechanism, 
> because this would
> >> quickly expose this limitation as another show stopper.
> >>
> >> Holger
> > Not at all.
> >
> > First, constraint types that have multiple parameters are a horrible 
syntax.
> > It is too easy to have the two parameters separated.  It is too easy 
to
> > consider the parameter values in isolation.
> >
> > Instead, constructs that need more than a single item of information 
(like
> > sh:pattern) can take structured piece of information.  This can either 
be a
> > list or a node that itself has multiple properties.  So, patterns with 
flags
> > can be specified as
> >    sh:pattern ("a*b*" "i")
> 
> -1 from me on this. This will not lead to a user-friendly syntax. If 
> people want to group their parameters for clarification, they can 
> already do so by creating multiple property constraints.
> 
> >
> > The same approaches work for templates.
> 
> Your "metamodel" doesn't talk about extensions at all. If you want this 
> to be seriously considered, please work out the details, including 
> Turtle files etc. I spent a lot of time on coming up with a detailed 
> design based on the feedback that I got from the group. I believe 
> Proposal 3 addresses all concerns. Now, in March 2016 you come up with 
> radical changes all over again. This is very unhelpful. You should have 
> brought up these issues sometime last year. At some stage we need to 
> stabilize things, and expose them to tests.
> 
> Holger
> 
>