Re: SHACL syntax and metamodel complexity

I am aware of the process and the trade-offs you mention. My intent is 
not to close the door. I am trying to understand the details of what 
Peter is proposing and if there are good things to harvest then I'd be 
happy to integrate them.

But in order to put all this back on the drawing board, there need to be 
good reasons. I have not seen those reasons yet, other than degrees of 
personal taste and relative beauty of the metamodel. I am very aware 
from practical experience that having moving targets will discourage 
implementers, early adopters and limit feedback, thus create problems on 
their own.

So please accept that I will also use the process in the sense that it 
has been designed, and apply my judgement to -1 certain proposals.

Also, instead of coming up with yet another proposal, I don't think 
Proposal 3 has been adequately discussed yet.

Holger


On 4/03/2016 10:47, Arnaud Le Hors wrote:
> 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
> >
> >
>