ISSUE-92: Should repeated properties be interpreted as additive or conjunctive?

At the January 11th meeting we have attempted to close this issue by removing sh:partition, but have not reached a conclusion because attendees wanted to get more details on the issue. Since we are likely to look at this issue again during the next meeting, I thought it would be useful to summarize the details.

A typical use case that motivated the issue is as follows:

Dublin Core experience suggests that users expect multiple constraints on the same property to be "additive". For example

ex:BibframeShape 
sh:property
[ sh:predicate bf:identifiedBy ; sh:pattern "^http://id.loc.gov/ <http://id.loc.gov/>" ] ,
[ sh:predicate bf:identifiedBy ; sh:pattern "^http://viaf.org/ <http://viaf.org/>" ] .

would be interpreted as requiring one bf:identifiedBy value starting
with "http://id.loc.gov/ <http://id.loc.gov/>" and another starting with
"http://viaf.org/ <http://viaf.org/>“ and no other values.


The issue was first created in September 2015. At the time, there was a proposal on the table to have multiple constraints on the same predicate to be additive as outlined above. it was decided that the basic combination of constraints would not work in this way and be conjunctive. Thus, no data could ever satisfy the shape as written above since it will be interpreted as requiring every value of bf:identifiedBy to start with both, http://id.loc.gov/ <http://id.loc.gov/> and http://viaf.org/ <http://viaf.org/> . 

Since there are logical operators, one could instead say:

ex:BibframeShape
sh:property [

                        sh:predicate bf:identifiedBy ;

           sh:minCount 2;

          sh:maxCount 2;

                        sh:or (

                                    [ sh:pattern "^http://id.loc.gov/”;]


                                    [sh:pattern "^http://viaf.org/”; ]

                                     )

 ] .



This shape, however, doesn’t require one of each values. It simply says that the values must have either one of the pattern. With this, if we had one value  http://id.loc.gov/ <http://id.loc.gov/>value1 <http://id.loc.gov/value1> and another http://id.loc.gov/value2 <http://id.loc.gov/value2> , there would be no error.

To enforce one of each, we can use qualified value shapes as follows:

ex:BibframeShape

sh:property [

        sh:predicate bf:identifiedBy ;

        sh:minCount 2;

        sh:maxCount 2;

    ] ;

sh:property [

        sh:predicate bf:identifiedBy ;

        sh:qualifiedValueShape [sh:pattern "^http://id.loc.gov/” ] ;

        sh:qualifiedMinCount 1 ;

        sh:qualifiedMaxCount 1 ;

    ] ;

sh:property [

        sh:predicate bf:identifiedBy ;

        sh:qualifiedValueShape [sh:pattern "^ http://viaf.org/” ] ;

        sh:qualifiedMinCount 1 ;

        sh:qualifiedMaxCount 1 ;

    ] ;


This satisfies the use case, but it is verbose.

sh;partition offers a simpler syntax in support of this use case:

ex:BibframeShape

            sh:property [

                        sh:predicate bf:identifiedBy ;

                        sh:partition (

                                    [sh:minCount 1; sh:maxCount 1; sh:pattern "^http://id.loc.gov/"]

                                    [sh:minCount 1; sh:maxCount 1; sh:pattern "^https://viaf.org/"]


                        )

] .


However, sh:partition uses lists and the order of resources within the list is significant. In general, if the members of the list are reordered, then different value node sets will be matched and different violation results will be reported. It was also seen as an overly complex feature to implement and likely to be poorly performing. With this, WG members had concerns about requiring that implementers must support it to comply with SHACL CORE. When this proposal was voted on, no one but Arthur Ryman, who proposed it, casted a positive vote. In addition to the majority of negative votes, proposal for sh:partition was also blocked by a -1 vote from Peter Patel-Schneider.

Since then, several people volunteered to work on improving the proposal including Arthur himself and, more recently, Eric Prud’hommeaux. They have not produced results in a form of an alternative, improved proposal.

sh:partition is included in the spec, but it has been marked as a feature at risk in all editor drafts. 

The current proposal is to close the issue 92 ( https://www.w3.org/2014/data-shapes/wiki/index.php?title=Proposals#ISSUE-92:_additive_repeated_properties <https://www.w3.org/2014/data-shapes/wiki/index.php?title=Proposals#ISSUE-92:_additive_repeated_properties>) by removing sh:partition.  The use case is supported, although using a verbose syntax. It is not perfect, but the WG has no resources to solve the issues with sh:partition. So, unless there is someone in the WG or in the broader community who feels strongly about sh:partition and will volunteer to dedicate time on resolving the issues with it, I see no other option but to remove it.

Irene