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

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.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - 
IBM Software Group


> Holger
> 
> 
> [1] https://lists.w3.org/Archives/Public/public-data-shapes-wg/
> 2015Sep/0128.html

> 
> 
> > 
> > Holger
> > 
> > 
> > >
> > >
> > > peter
> > >
> > >
> > >
> > >
> > >
> > > On 09/24/2015 07:53 AM, RDF Data Shapes Working Group Issue Tracker 
wrote:
> > >> shapes-ISSUE-92 (additive repeated properties): Should repeated
> properties be interpreted as additive or conjunctive? [SHACL Spec]
> > >>
> > >> http://www.w3.org/2014/data-shapes/track/issues/92> >>
> > >> Raised by: Eric Prud'hommeaux
> > >> On product: SHACL Spec
> > >>
> > >> Dublin Core experience suggests that users expect multiple 
> constraints on the same property to be "additive". For example
> > >>
> > >> <BFPersonInterface1> sh:property
> > >>    [ sh:predicate bf:identifiedBy ; sh:pattern 
"^http://id.loc.gov/" ] ,
> > >>    [ sh:predicate bf:identifiedBy ; sh:pattern "^http://viaf.org/" 
] .
> > >>
> > >> would be interpreted as requiring one bf:identifiedBy arc starting
> > >> with "http://id.loc.gov/" and another starting with
> > >> "http://viaf.org/".
> > >>
> > >> The current SHACL behavior is that multiple property constraints on
> > >> the same predicate are "conjunctive", meaning that any triple with
> > >> that predicate is expected to match all of property constraints. 
Are
> > >> there use cases for this?
> > >>
> > >>
> > >>
> > >>
> > 
> > 
>