Re: Property paths in property pair constraint components

Hello Irene,

Much appreciated! I will have a go at that.I did think of using inferred triples, but that approach seemed not as ideal for two reasons:

- managing the predicates introduced for these inferred triples;
- the overhead of the inferred model which will then be inspected.

It seems that SPARQL Constraints are more efficient.

With my best regards,

Christophe Debruyne


> On Feb 20, 2020, at 23:20, Irene Polikoff <irene@topquadrant.com> wrote:
> 
> Hi Christophe,
> 
> I would create a new property e.g., foo:endDate and dynamically infer its values using use property value rules (sh:values), see https://w3c.github.io/shacl/shacl-af/#PropertyValueRule <https://w3c.github.io/shacl/shacl-af/#PropertyValueRule>.
> 
> Then, I could do:
> 
> <#foo:DOB>
>  a sh:NodeShape ;
>  sh:targetClass foo:Person ; 
>  sh:property [
>       sh:path foo:endDate;
>       sh:values [
>             sh:path foo:with ;
>            sh:nodes [
>               sh:path foo:end ;
>                 ] ;
>           ] ;
>  ] ;
>  sh:property [
>   sh:path ( foo:start foo:with ) ;
>   sh:lessThan foo:endDate ;
>  ] ;
> 
> As to why paths are not supported as values of sh:lessThan, I do not recall the reason. It is possible that there was no strong reason. Towards the end of the standardization process there was a strong push to simplify the spec in order to get it accepted and approved.
> 
> Regards,
> 
> Irene
> 
>> On Feb 20, 2020, at 4:55 PM, Christophe D. <christophe.debruyne@gmail.com <mailto:christophe.debruyne@gmail.com>> wrote:
>> 
>> Dear all,
>> 
>> I’m currently working with a fairly complex graph. Long story short, the standard adopted in this project has classes for tons of attributes (birthdates, names, etc.). The following works swell:
>> 
>> <#foo:DOB>
>>  a sh:NodeShape ;
>>  sh:targetClass foo:Person ; 
>>  sh:property [
>>   sh:path ( foo:start foo:with ) ;
>>   sh:lessThan foo:end ;
>>  ] ;
>> .
>> 
>> <#x>
>>  a foo:Person ;
>>  foo:start [ foo:with "2002-05-29"^^xsd:date ] ;
>>  foo:end "2002-05-30"^^xsd:date ;
>> .
>> 
>> <#y>
>>  a foo:Person ;
>>  foo:start [ foo:with "2002-05-30"^^xsd:date ] ;
>>  foo:end "2002-05-30"^^xsd:date ;
>> .
>> 
>> The problem is that the data is more complex and rather looks as follows:
>> 
>> <#x>
>>  a foo:Person ;
>>  foo:start [ foo:with "2002-05-29"^^xsd:date ] ;
>>  foo:end [ foo:with "2002-05-30"^^xsd:date ] ;
>> .
>> 
>> <#y>
>>  a foo:Person ;
>>  foo:start [ foo:with "2002-05-30"^^xsd:date ] ;
>>  foo:end [ foo:with "2002-05-30"^^xsd:date ] ;
>> .
>> 
>> This cannot be solved by providing a property path ( foo:end foo:with ) for sh:lessThan. 
>> 
>> <#foo:DOB>
>>  a sh:NodeShape ;
>>  sh:targetClass foo:Person ; 
>>  sh:property [
>>   sh:path ( foo:start foo:with ) ;
>>   sh:lessThan ( foo:end foo:with ) ;
>>  ] ;
>> .
>> 
>> The specification limits the values of property pair constraints to IRIs. Yes, I could probably achieve the desired result by creating property shapes from the date of birth (for instance), but that does not seem as intuitive as approaching it from the perspective of people.
>> 
>> Was there a particular reason property paths are not allowed for sh:lessThan? Or am I overlooking something and is it feasible?
>> I currently solve this problem with a SPARQLConstraint, which I am not entirely happy with.
>> 
>> With my best regards,
>> 
>> Christophe
>