Re: propose to make repeated-properties additive

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? It also isn't 
clear to me why sh:pattern here isn't coded as a constraint.

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

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600

Received on Sunday, 20 September 2015 06:34:36 UTC