Re: shapes-ISSUE-134 (knowing inverse): does SHACL syntax distinguish inverse property constraints [SHACL Spec]

That would be a modeling error, i.e. an invalid shapes graph. The rules 
state what the sh:defaultValueType is for sh:property and 
sh:inverseProperty. However, the "range" of sh:property is limited to 
sh:PropertyConstraint only, so it cannot have an 
sh:InversePropertyConstraint as values. If someone creates such a 
situation then it would evaluate both. This case can easily be checked 
using SHACL constraints at "compile time", reporting an error in the 
shapes graph. We could also make sh:PropertyConstraint and 
sh:InversePropertyConstraint disjoint...

Holger


On 11/03/2016 14:22, Peter F. Patel-Schneider wrote:
> Oops, I messed up the example.  Sorry for the confusion.
>
> Here is what I meant
>
> ex:s a sh:Shape ;
>      sh:property _:c ;
>      sh:property [ sh:predicate ex:q ;
>                    sh:valueShape [ sh:inverseProperty _:c ] ] .
>
>   _:c [ sh:predicate ex:p ;
>          sh:minCount 5 ] .
>
> peter
>
>
>
> On 03/10/2016 08:12 PM, Holger Knublauch wrote:
>> On 11/03/2016 13:38, Peter F. Patel-Schneider wrote:
>>> _:c will be both a sh:PropertyConstraint and sh:InversePropertyConstraint.
>>> Which SPARQL query will it pick?  Both?  In this case things might work out,
>> Yes both. I am glad we agree.
> We don't agree, even here.  Doing both works only because _:c was used in the
> same place.
>
>>> but what happens if the incoming links are from different places, as in
>>>
>>> ex:s a sh:Shape ;
>>>     sh:property _:c ;
>>>     sh:property [ sh:predicate ex:q ;
>>>                   sh:valueShape [ sh:property _:c ] ] .
>>>
>>> _:c [ sh:predicate ex:p ;
>>>         sh:minCount 5 ] .
>> I see no problem there. In both cases it's a sh:PropertyConstraint based on
>> the sh:defaultValueType of sh:property. They are not executed at the same
>> time, and on different focus nodes.
>>
>> Does this answer your ticket?
>>
>> Holger
>>
>>
>>> peter
>>>
>>>
>>>
>>> On 03/10/2016 04:43 PM, Holger Knublauch wrote:
>>>> In the current draft this is handled by sh:defaultValueType:
>>>>
>>>> ex:s a sh:Shape ;
>>>>     sh:property _:c ;
>>>>     sh:inverseProperty _:c .
>>>> _:c [ sh:predicate ex:p ;
>>>>         sh:minCount 5 ] .
>>>>
>>>>
>>>> The engine will "add" two type triples:
>>>>
>>>> _:c a sh:PropertyConstraint .
>>>> _:c a sh:InversePropertyConstraint .
>>>>
>>>> The engine can then pick the correct validator (SPARQL query) for each
>>>> rdf:type of that constraint.
>>>>
>>>> Holger
>>>>
>>>>
>>>> On 11/03/2016 7:15, RDF Data Shapes Working Group Issue Tracker wrote:
>>>>> shapes-ISSUE-134 (knowing inverse): does SHACL syntax distinguish inverse
>>>>> property constraints [SHACL Spec]
>>>>>
>>>>> http://www.w3.org/2014/data-shapes/track/issues/134
>>>>>
>>>>> Raised by: Peter Patel-Schneider
>>>>> On product: SHACL Spec
>>>>>
>>>>>> From
>>>>> https://lists.w3.org/Archives/Public/public-data-shapes-wg/2016Mar/0106.html
>>>>>
>>>>> Some constraint types require different SPARQL queries (or JavaScript or
>>>>> whatever) depending on the direction of a property (or even worse, for an
>>>>> arbitrary path). For example sh:minCount needs to count subjects versus
>>>>> objects.
>>>>>
>>>>> Is it possible to determine whether a sh:minCount constraint is an inverse
>>>>> or not?  Consider
>>>>>
>>>>> ex:s a sh:Shape ;
>>>>>      sh:property _:c ;
>>>>>      sh:inverseProperty _:c .
>>>>> _:c [ sh:predicate ex:p ;
>>>>>          sh:minCount 5 ] .
>>>>>
>>>>>
>>>>>
>>

Received on Friday, 11 March 2016 04:33:09 UTC