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

* Holger Knublauch <holger@topquadrant.com> [2015-09-25 10:32+1000]
> On 9/25/2015 10:17, Arnaud Le Hors wrote:
> >
> >> From: "Holger Knublauch" <holger@topquadrant.com
> ><mailto: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/" ;
>             ]
>         ] ;
>     ] .

ex:BFPersonInterface1 a sh:Shape ;
    sh:property [
        sh:predicate bf:identifiedBy ; sh:minCount 1 ; sh:maxCount 1 ;
        sh:valueShape [ sh:constraint [ sh:pattern "^http://id.loc.gov/" ; ] ]
    ] .

requires exactly one bf:identifiedBy arc, and that arc must start
with "id.loc.gov". The shape you propose permits any number of
bf:identifiedBy arcs not matching "id.loc.gov" or "viaf.org".


> >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.
> 
> 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? > >> > >> > >> > >> > >
> >
> >
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Friday, 25 September 2015 13:01:09 UTC