Re: propose to make repeated-properties additive

Karen,

Is this requirement about the ability to say Œorš as in:

Œthe value of this property cold be either an integer or a dateš

Or is it about the ability to do qualified cardinality constraints as in:

Œat least one value must be an integer and at least one value must be a
dateš


Irene Polikoff






On 9/20/15, 10:19 PM, "Karen Coyle" <kcoyle@kcoyle.net> wrote:

>
>
>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 21:07:12 UTC