On 29/03/2021 7:05 pm, Tomasz Pluskiewicz wrote:
> 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:FirstNameShape
a sh:NodeShape ;
sh:property [ sh:path ex:firstName ; sh:minCount 1 ]
.
ex:GivenNameShape
a 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:PropertyShape
a 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:OrConstraintExampleShape
a 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/bedd1acd-4fd9-4a78-8465-dd37ca02bef2n%40googlegroups.com
<https://groups.google.com/d/msgid/topbraid-users/bedd1acd-4fd9-4a78-8465-dd37ca02bef2n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/933c4358-50ea-40fc-b0da-410fe4b34c1an%40googlegroups.com
<https://groups.google.com/d/msgid/topbraid-users/933c4358-50ea-40fc-b0da-410fe4b34c1an%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/cad0dba9-64e2-3f34-c620-117d38e32d34%40topquadrant.com.
