- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Fri, 25 Sep 2015 17:30:16 +0200
- To: public-data-shapes-wg@w3.org
On 9/25/15 3: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". Would the use of sh:ClosedShapeConstraint give the desired result? Also, what if you want an "Info" severity for properties in addition to the ones named explicitly in the constraint? Does that then require the use of a sh:ClosedShapeConstraint? kc > > >>> 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? > >> > >> > >> > >> > > >>> >>> >> > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 skype: kcoylenet/+1-510-984-3600
Received on Friday, 25 September 2015 15:30:50 UTC