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

I don't see where meta-shapes has any play here.

This is currently a *valid* shapes graph.

The spec doesn't say what the result should be because 3.2 is still unwritten.
 I had assumed that 3.2 was just a reiteration of big chunks of 3.1, but this
is apparently not the case.  Thus the spec has a large hole in it.

peter


On 03/10/2016 09:18 PM, Holger Knublauch wrote:
> Yes, we did not really investigate meta-shapes yet, and what the patterns of
> invalid shapes graphs are. This should be future work...
> 
> Holger
> 
> 
> On 11/03/2016 15:16, Peter F. Patel-Schneider wrote:
>> 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:35:47 UTC