Re: shapes-ISSUE-103 (Syntax simplifications): Can we further simplify the syntax of some constraint types? [SHACL Spec]

>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.

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:19:04 UTC