Re: propose to make repeated-properties additive

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

In fact, the question was less about the URI pattern than about the 
ability to have different values for the same property, and to constrain 
them separately. So we should pick some other value constraints to use 
that SHACL already handles -- perhaps that the first instance is an IRI 
and the second is a literal. Looking at the above, I think both would 
fail when the "other" value is evaluated.

Wouldn't this be a case that could use sh:filterShape? That is, there 
would be a separate sh:filterShape for the two different cases. By using 
the filter, only one value type would be included in the graph being 
evaluated.

If that works, then I have a follow-up question.

Thanks,
kc

>
> 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 20:20:17 UTC