- From: Holger Knublauch <holger@topquadrant.com>
- Date: Sat, 26 Sep 2015 09:00:14 +1000
- To: public-data-shapes-wg@w3.org
On 9/25/15 11:00 PM, Eric Prud'hommeaux wrote: > * 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". I assume we want to preserve the possibility to have QCRs with open shapes. So as written in my example, other values would still be permitted for that property. One would need to add sh:constraint sh:Closed . However, sh:ClosedShapeConstraint currently does not have the semantics that you intended. We would need to change it as follows: PROPOSAL: Change sh:ClosedShapeConstraint so that it also throws a violation for each value of a property involved in a QCR that does not fulfill any of the shapes enumerated via sh:qualifiedValueShape. I see no problems with such a change - sh:hasShape can be used - although the specification will become more complex. With this, I believe we have found an incremental evolutionary path to address the use case that you have brought forward. No need to make general changes to sh:property. For the record here would be the complete example: 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/" ; ] ] ; ] ; sh:constraint sh:Closed . Cheers, Holger
Received on Friday, 25 September 2015 23:00:47 UTC