Re: shapes-ISSUE-92 (additive repeated properties): Should repeated properties be interpreted as additive or conjunctive? [SHACL Spec]

On 9/25/15 3:02 PM, Arnaud Le Hors wrote:
> Holger Knublauch <holger@topquadrant.com> wrote on 09/24/2015 05:32:11 PM:
>
> > From: Holger Knublauch <holger@topquadrant.com>
> > To: public-data-shapes-wg@w3.org
> > Date: 09/24/2015 05:33 PM
> > Subject: Re: shapes-ISSUE-92 (additive repeated properties): Should
> > repeated  properties be interpreted as additive or conjunctive? 
> [SHACL Spec]
> >
> > > On 9/25/2015 10:17, Arnaud Le Hors wrote:
> > > > From: "Holger Knublauch" <holger@topquadrant.com>
> > > > ...
> > > >
> > > > I believe the requested use cases can already be covered by 
> qualified
> > > > value shape constraints and possibly sh:OrConstraint.
> > >
> > > Could you please show us what this would take with the current
> > > draft? On the call you said it was verbose but I think it's
> > > important that we have the actual solution to look at for people to
> > > be able to judge.
> >
> > Using the modifications that I had previously suggested [1] it would 
> be like
> >
> > ex:BFPersonInterface1
> >     a sh:Shape ;
> >     sh:property [
> >         sh:predicate bf:identifiedBy ;
> >         sh:qualifiedMinCount 1 ;
> >         sh:qualifiedMaxCount 1 ;
> >         sh:qualifiedValueShape [
> >             sh:constraint [
> > sh:pattern "^http://id.loc.gov/" ;
> >             ]
> >         ] ;
> >     ] ;
> >     sh:property [
> >         sh:predicate bf:identifiedBy ;
> >         sh:qualifiedMinCount 1 ;
> >         sh:qualifiedMaxCount 1 ;
> >         sh:qualifiedValueShape [
> >             sh:constraint [
> > sh:pattern "^http://viaf.org/" ;
> >             ]
> >         ] ;
> >     ] .
> >
>
> Thanks. It looks like changing the default of MinCount and MaxCount 
> would already make this a bit better. Something to consider in light 
> of ISSUE-91.
>
> > >
> > >
> > >  As I had written
> > > > before, QCRs are a niche feature in OWL. The core vocabulary 
> should do
> > > > its best job for the 80% most common scenarios, and not complicate
> > > > everything only to cater for some corner cases.
> > >
> > > I agree on principle but who's to say what is a corner case and what
> > > is not? I don't think there is much value in argue over this. What
> > > is a corner case to some isn't to others.
> > > So the only practical way forward is to accept that fact and when
> > > there is "enough" demand from the WG members for a given use case to
> > > support it.
> >
> > Every WG member can vote -1 on any proposal. If some members want to
> > enforce a certain design philosophy upon the whole language only
> > because of (what I consider) corner cases like QCRs and multi-
> > occurrance, then my vote will be a -1.
> >
>
> I have to admit not to understand how addressing this use case amounts 
> to enforcing a certain design philosophy upon the *whole* language. If 
> this were true I would expect those for whom what you consider the 
> common case to be the corner case and vice versa to feel that you're 
> currently imposing your own design philosophy upon the whole language 
> just the same.
>
> Again, I don't see how a discussion at that level can be productive.
>
> Yes, you can object to addressing such use cases but if you're about 
> the only one you will get overruled. I seriously doubt the Director 
> will have much sympathy for you if I have to tell him that you 
> objected to changing the spec to accommodate other people's use cases 
> because you didn't think they were worth bothering with.
>
> As I said before, many times, we cannot expect everyone to see the 
> world the same way and we have to recognize that not everybody cares 
> about the same use cases. Trying to judge their value is rather 
> futile. Instead, we should try and accommodate everyone's needs. This 
> is what standards are about: compromise.

Could you please clarify what you are talking about here at all? Eric 
has a use case. I have implemented a way to address this use case.

What is the problem?

Holger