- From: Holger Knublauch <holger@topquadrant.com>
- Date: Thu, 5 Nov 2015 09:24:04 +1000
- To: public-data-shapes-wg@w3.org
On 11/5/15 9:18 AM, Peter F. Patel-Schneider wrote: > From http://w3c.github.io/data-shapes/shacl/ > > 2.3 Constraints > - sh:constraint link a shape with constraints that do not involve just a > single dedicated property. > > The constraint illustrated would not involve just a single dedicated property, > and thus appears to be suitable for sh:constraint. > > 6. Native Constraints > The property sh:constraint provides the most general mechanism to associate a > constraint with a shape. > > If sh:constraint can't use certain kinds of constructs then how can it be the > most general mechanism? > > 6. Native constraints > Note that the property sh:property SHOULD be used instead of sh:constraint if > the constraint is a sh:PropertyConstraint. The property sh:inverseProperty > SHOULD be used instead of sh:constraint if the constraint is a > sh:InversePropertyConstraint. > > This strongly indicates that it is permissable to use sh:property constructs > in an sh:constraint, just that it should not be done. > > All these indicate that the difference between sh:constraint and sh:property > is just one of style. There do not appear to be any prohibitions against > using sh:property constructs in an sh:constraint value. This is correct, as long you add an rdf:type triple, which your example didn't. The following would be legal: sh:constraint [ a sh:PropertyConstraint ; sh:class ex:c ; sh:predicate ex:p ] However, even then sh:PropertyConstraint cannot have sh:not, which is limited to sh:NodeConstraint. Holger > > peter > > > > On 11/04/2015 03:00 PM, Holger Knublauch wrote: >> On 11/5/2015 1:19, Peter F. Patel-Schneider wrote: >>> As far as I can tell, this involves turning sh:not, etc., into the sort of >>> things that can be implicitly conjoined in a constraint. >>> >>> Can these be mixed with the kind of constraint bits that go in a sh:property >>> constraint? >>> >>> sh:constraint [ >>> sh:not [ ... ] ; >>> sh:valueClass ex:c ; >>> sh:predicate ex:p >>> ] >> In the above snippet, sh:valueClass and sh:predicate are already unsupported >> at sh:constraint. (sh:valueClass has also been renamed to sh:class). >> >>> Can these then be put into a sh:property constraint? >>> >>> sh:property [ >>> sh:predicate ex:foo ; >>> sh:minCount 1 ; >>> sh:not [ ... ] >>> ] >> In that snippet, sh:not can not appear at sh:property. sh:not would only be >> meaningful as part of sh:NodeConstraint, which is the value type of >> sh:constraint. >> >> If this answers your question, please consider updating your vote on the >> proposals page. >> >> Holger >> >> >>> peter >>> >>> >>> >>> On 10/18/2015 05:09 PM, RDF Data Shapes Working Group Issue Tracker wrote: >>>> shapes-ISSUE-103 (Syntax simplifications): Can we further simplify the >>>> syntax of some constraint types? [SHACL Spec] >>>> >>>> http://www.w3.org/2014/data-shapes/track/issues/103 >>>> >>>> Raised by: Holger Knublauch >>>> On product: SHACL Spec >>>> >>>> Now that we have a more consistent framework for node constraints, I >>>> noticed that we could further improve the syntax for various other >>>> constraint types: >>>> >>>> Currently: >>>> >>>> ex:NotExampleShape >>>> a sh:Shape ; >>>> sh:constraint [ >>>> a sh:NotConstraint ; >>>> sh:shape [ >>>> sh:property [ >>>> sh:predicate ex:property ; >>>> sh:minCount 1 ; >>>> ] ; >>>> ] >>>> ] . >>>> >>>> >>>> Suggested: >>>> >>>> ex:NotExampleShape >>>> a sh:Shape ; >>>> sh:constraint [ >>>> sh:not [ >>>> sh:property [ >>>> sh:predicate ex:property ; >>>> sh:minCount 1 ; >>>> ] ; >>>> ] >>>> ] . >>>> >>>> Similar for sh:and and sh:or. >>>> >>>> Closed constraints could become: >>>> >>>> ex:ClosedShapeExampleShape >>>> a sh:Shape ; >>>> sh:constraint [ >>>> sh:closed true ; >>>> sh:ignoredProperties (sh:nodeShape rdf:type) ; >>>> ] ; >>>> >>>> (which would also help with Karen's recent issue because she could say >>>> sh:closed=false explicitly). >>>> >>>> Which would only leave the 4 property pair constraints as ugly ducklings. >>>> We could decide to make them directional and then use sh:property, e.g. >>>> >>>> ex:EqualExampleShape >>>> a sh:Shape ; >>>> sh:property [ >>>> sh:predicate ex:firstName ; >>>> sh:equals ex:givenName ; >>>> ] >>>> ] . >>>> >>>> which would make perfect sense for sh:lessThan anyway. >>>> >>>> >>>> >>
Received on Wednesday, 4 November 2015 23:24:38 UTC