- 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