- From: Holger Knublauch <holger@topquadrant.com>
- Date: Mon, 21 Sep 2015 09:18:20 +1000
- To: public-data-shapes-wg@w3.org
On 9/20/2015 16:34, Karen Coyle wrote: > Thanks, Holger. More below: > > On 9/20/15 1:39 AM, Holger Knublauch wrote: >> On 9/19/15 5:02 PM, Karen Coyle wrote: >>> 2) repeated properties >>> This is a real and not uncommon example: >>> >>> <bf_Person1> >>> bf:identifiedBy <http://id.loc.gov/authorities/names/n80103961#RWO> ; >>> #IRI from id.loc.gov, min 1, max 1 >>> bf:identifiedBy <https://viaf.org/viaf/268367832/#Knape,_Joachim> . >>> #IRI from viaf.org, min 1, max unlimited >> >> I agree it makes sense to talk about the requirements before requesting >> a change to the language. If I understand the intention correctly, then >> the above could be expressed with an incremental addition to the core >> library: >> >> ex:MyShape >> a sh:Shape ; >> sh:property [ >> sh:predicate bf:identifiedBy ; >> sh:qualifiedMinCount 1 ; >> sh:qualifiedMaxCount 1 ; >> sh:qualifiedValueShape [ >> sh:constraint [ >> a sh:URIPatternConstraint ; >> sh:uriPattern "^http://id.loc.gov" ; >> ] ; >> ] ; >> ] ; >> sh:property [ >> sh:predicate bf:identifiedBy ; >> sh:qualifiedMinCount 1 ; >> sh:qualifiedValueShape [ >> sh:constraint [ >> a sh:URIPatternConstraint ; >> sh:uriPattern "^http://viaf.org" ; >> ] ; >> ] ; >> ] . >> >> The new feature that would be needed would be sh:URIPatternConstraint - >> the current sh:pattern only applies to property values "one hop away" >> while here we would need something that talks about the IRI of the focus >> node itself. > > I'm not sure what this "one hop" is. When I look at sh:pattern: > > ex:PatternExampleShape > a sh:Shape ; > sh:property [ > sh:predicate ex:someProperty ; > sh:pattern "^Ali" ; > ] . > > ex:PatternShapeExampleValidResource > ex:someProperty "Alice" . > > I see an instance example that looks very much like what I've offered, > although with an IRI object rather than a literal object, and min/max. > Can you explain what makes these two examples different? The main issue is that sh:valueShape and sh:qualifiedValueShape need to point at a sh:Shape, in particular the shape of a value of a property (ex:someProperty above). sh:Shapes describe the value itself, and we don't have a syntax for restricting the IRI of a given focus node itself. So checking sh:pattern currently only works when you start at a focus node, walk one property (one hop away) and then test that property value. Adding something like sh:IRIPatternConstraint would fix this problem, but there may be a more general solution with relative low cost for the underlying issue. I need to think more about it. > It also isn't clear to me why sh:pattern here isn't coded as a > constraint. It is a constraint - sh:property links a shape with a sh:PropertyConstraint about a given predicate. Holger > > Note that the IRI pattern matching has been in the use cases all this > time in use case 37 [1]. However, I was assuming that general > sh:pattern matching would work on this case and therefore a more > specific solution was not necessary. And there could be cases where > the pattern is "OR" -- there could be a set of valid patterns, where > each property could have a value from "one of" the IRI pattern list. I > haven't thought about whether that would coincide with min/max > constraints, though -- that latter case sounds overly complex to me. > > kc > [1] > http://w3c.github.io/data-shapes/data-shapes-ucr/#uc37-defining-allowed-required-values > > > We had a similar topic recently with regards to >> sh:allowedValues. It may make sense to generalize the validation >> function mechanism so that the same infrastructure can be reused, but in >> the end this is about syntactic sugar only. >> >> Holger >> >> >> >
Received on Sunday, 20 September 2015 23:18:54 UTC