- From: Holger Knublauch <holger@topquadrant.com>
- Date: Fri, 11 Mar 2016 15:57:11 +1000
- To: public-data-shapes-wg@w3.org
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. 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 ] . >>>>>>>>> >>>>>>>>> >>>>>>>>> >>
Received on Friday, 11 March 2016 05:57:47 UTC