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

On 11/03/2016 15:57, Holger Knublauch wrote:
> Ok, we can leave this ticket open here as a reminder that this needs 
> to be clarified. Like the other unwritten details about sh:property vs 
> sh:inverseProperty vs sh:constraint, this will be cleaned up once we 
> have resolved the general metamodel discussion.

I believe this ISSUE-134 can be closed now: Section 2.3 now includes a 
paragraph:

The classes|sh:PropertyConstraint|and|sh:InversePropertyConstraint|are 
disjoint, i.e. it is illegal to have shape definitions that use nodes 
that are instances of both classes - either explicitly stated 
via|rdf:type|or implicitly via theirdefault value type.

Holger


>
> My plan is to not have 3.1, 3.2 or 3.3 anymore, but to handle them all 
> uniformly. Basically, each constraint type (or we could call them 
> "constraint component" if you like) would have a URI, information 
> about their context (sh:property, sh:inverseProperty and/or 
> sh:constraint) and then the other details including the SPARQL logic. 
> Many reuse the same SPARQL logic in all three cases. Others need 
> variations depending on the direction of the triple traversal. And 
> then suitable example(s), and "tips and tricks".
>
> I am keen to clean this up, so please forgive my impatience towards a 
> metamodel resolution...
>
> Holger
>
>
> On 11/03/2016 15:35, Peter F. Patel-Schneider wrote:
>> 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 ] .
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>
>