feat: #407 add support for sh:TripleTerm to sh:nodeKind and allow lists

[bergos]

Closes #407

• See this document rendered online here

[HolgerKnublauch]

It is good to have sh:TripleTerm added, but I really don't think we should support rdf:Lists here as values. The common combinations are already covered with sh:BlankNodeOrIRI etc, and the use case for a combination of TripleTerm with others is very very rare. And in those corner cases, people can already use sh:or. But introducing list syntax here is yet another option that then needs to be supported by editing tools and any algorithm that walks shape structures, for example to determine whether a property is literal-typed. There is a lot of flow-on cost from such seemingly little tweaks to the spec.

[afs]

Symmetry suggests that sh:BlankNodeOrIRIOrLiteral is now needed.

I think the use of a list makes sense and sh:x_Or_y can be redefined as equivalent to a list form so that tools need only support one form with a small amount of compatibility code when reading "sh:nodeKind".

[bergos]

I also see pros and cons:

Cons:

• Adds complexity

Pros:

• Consistency and the lack of symmetry if we stick to the old structure
• Lists are easier to handle in node expressions

I favor making this change mainly because of the last point about node expressions.

[HolgerKnublauch]

I am not blocking this but I think at we should deprecate the OR variations when the lists get allowed.

Best to be put on the agenda for the next meeting.

[afs]

• Lists are easier to handle in node expressions

Could you explain that please?