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?

[bergos]

@afs The OR values must be translated before they can be processed with a generic list or set function. The following example uses a generic ex:intersection function. That's why the second version will not work properbly, as the ex:intersection function doesn't know that sh:BlankNodeOrLiteral should be translated into two elements. A workaround could be the last option with a wrapper to translate the elements.

[
  sh:nodeKind [
    ex:intersection(ex:funcThatReturnsNodeKinds() (sh:BlankNode sh:Literal))
  ]
].

[
  sh:nodeKind [
    ex:intersection(ex:funcThatReturnsNodeKinds() (sh:BlankNodeOrLiteral))
  ]
].

[
  sh:nodeKind [
    ex:intersection(ex:funcThatReturnsNodeKinds() ([ex:nodeKindToList(sh:BlankNodeOrLiteral)]))
  ]
].

[HolgerKnublauch]

I remain worried about the complexity of having to support too many combinations of expressing the same thing.

Right now it is easy, for example, for an ontology editing UI to offer a drop-down list of the (6) options. What would happen if there are now different internal options for the same thing, how would the user chose between the URIs and an rdf:List.

Also, lists could then potentially be like ( sh:BlankNodeOrIRI sh:Literal ) which is redundant to ( sh:BlankNode sh:IRI sh:Literal ). These little things make static analysis of ontologies harder for downstream algorithms.

[bergos]

I can see the concerns regarding backward compatibility, especially lists mixed with single-value elements and multi-value elements. We can't eliminate the problem, but we can provide tools to simplify the usage with inconsistent value elements:

A node expression function could be defined as part of the SHACL specification that accepts an IRI or a list of node-kind elements, single-value and multi-value, as an argument. That function will return a list of single-value elements. One can expect that environments with SPARQL engines will expose node expression functions also as SPARQL functions. The function would also be available as a SPARQL function in that case.

Example:
The following function call...

[
  sh:toNodeKindList ( sh:BlankNodeOrIRI sh:Literal )
]

...would return the following list:

( sh:BlankNode sh:IRI sh:Literal )

[simonstey]

@bergos

A node expression function could be defined as part of the SHACL specification that accepts an IRI or a list of node-kind elements, single-value and multi-value, as an argument. That function will return a list of single-value elements. One can expect that environments with SPARQL engines will expose node expression functions also as SPARQL functions. The function would also be available as a SPARQL function in that case.

although I'm all for these small little "hacks", I think it is important to clearly differentiate between stuff that's left to/can/should be provided by implementations and the stuff that we specify in the specification. In the best case (and that's what we should strive for), SHACL 1.2 wouldn't require any of those NExp "hacks" at all. ;)

However, in SHACL 1.2 we could encourage users to use list+atomic concepts only, but potentially also suggest (non-normative) to e.g. use a NExp such as the one you outlined, to get to the list of single-value elements.

=> it's a slippery slope to not just slap a custom NExp on everything instead of making the specification usable in the first place:

[HolgerKnublauch]

If we decide to allow lists-as-nodeKinds, we could mandate that only the 4 primitive values are permitted, not the Or IRIs. Otherwise: malformed shapes graph.