Logical constraints
Tomasz Pluskiewicz
Holger Knublauch
The spec only states that the list members of sh:or must be (any) *shapes*. This means they may be node shapes OR property shapes, as in the example of the spec. Both syntaxes here would/should have the same semantics unless I am missing something. To reiterate, property shapes have the same status as node shapes in SHACL, and may also appear stand-alone.
Holger
--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/bedd1acd-4fd9-4a78-8465-dd37ca02bef2n%40googlegroups.com.
Tomasz Pluskiewicz
ex:FirstNameShape
ex:GivenNameShape
Holger Knublauch
> The spec only states that the list members of sh:or must be (any) *shapes*
This is understandable but I would expect them to actually match the subject. So sh:or used with Node Shape would logically "require" Node Shape members and same for Property Shape.
The leap that the example takes (and it works in the playground too) is the surprising part.
To explain my thinking: We have the ex:OrConstraintExampleShape, which allows ex:firstName "or" ex:givenName. My understanding was that the logical alternative could be separated to create two shapes, one of which would be valid
ex:FirstNameShapea sh:NodeShape ;sh:property [ sh:path ex:firstName ; sh:minCount 1 ].
ex:GivenNameShapea sh:NodeShape ;sh:property [ sh:path ex:givenName ; sh:minCount 1 ].
Thus, the members of sh:or would be interpreted as if their properties were merged with the subject of the list. This is where I drew the conclusion that their Shape types should match.
To give an example of the opposite, how would you interpret a Property Shape which has a logical constraint with a Node Shape member?
ex:PersonShape sh:targetClass ex:Person ; sh:property ex:PropertyShape .
ex:PropertyShapea sh:PropertyShape ;sh:not [sh:property [ sh:path ex:firstName ] ;] ;.
I cannot even begin.
Yeah this is not very intuitive and I was against allowing too much flexibility here during the WG, but got overruled. Unless I miss something, the interpretation above would be that each value node (i.e. the values of the sh:path of the property shape (which you forgot to specify) must not have a first name.
Holger
--poniedziałek, 29 marca 2021 o 10:50:13 UTC+2 Holger Knublauch napisał(a):
The spec only states that the list members of sh:or must be (any) *shapes*. This means they may be node shapes OR property shapes, as in the example of the spec. Both syntaxes here would/should have the same semantics unless I am missing something. To reiterate, property shapes have the same status as node shapes in SHACL, and may also appear stand-alone.
Holger
On 28/03/2021 11:23 pm, Tomasz Pluskiewicz wrote:
I'm a little confused by the example of sh:or presented in the spec.
Why are the sh:path and sh:minCount directly attached to the shape in the list? Wouldn't sh:property be necessary?
ex:OrConstraintExampleShapea sh:NodeShape ;sh:or ([ sh:property [ sh:path ex:firstName ; sh:minCount 1 ; ][ sh:property [ sh:path ex:givenName ; sh:minCount 1 ; ]
).--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/bedd1acd-4fd9-4a78-8465-dd37ca02bef2n%40googlegroups.com.
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/933c4358-50ea-40fc-b0da-410fe4b34c1an%40googlegroups.com.