W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > March 2016

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

From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
Date: Thu, 10 Mar 2016 21:16:17 -0800
To: Holger Knublauch <holger@topquadrant.com>, public-data-shapes-wg@w3.org
Message-ID: <56E254A1.5060803@gmail.com>
There isn't anything that currently says that the object of a sh:property
triple can't be a sh:InversePropertyConstraint, i.e., this is a valid shapes
graph currently.  It thus appears that this example would pass all inspections
and then work incorrectly.

As you say, making this syntactically illegal will solve this particular
problem.  I do wonder if there are any other cases like this.  I just happened
to notice this because of what you said about different code being needed for
the different cases.

peter


On 03/10/2016 08:32 PM, Holger Knublauch wrote:
> 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 05:16:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:30 UTC