Alternative property for computed values

[bergos]

As discussed in the definition of node expressions PR, the sh:path property could be misleading for the use case of creating intermediate values for validations. One may expect that sh:path keeps the functionality of traversing the path given as the object value. In the case of a node expression, the result of the node expression should be used for traversing. A new property could be defined that skips the traversing part and only sets the value to the computed value of the node expression.

Below are two property shapes and how they could be translated into SPARQL:

ex:propertyShape1 a sh:PropertyShape;
  sh:path [
    shn:iri [
      shn:concat ("http://example.org/" "property")
    ]
  ].

ex:propertyShape2 a sh:PropertyShape;
  sh:computed [
    shn:iri [
      shn:concat ("http://example.org/" "property")
    ]
  ].

# for ex:propertyShape1
SELECT * WHERE {
  $this IRI(CONCAT("http://example.org/", "property")) $value
}

# for ex:propertyShape2
SELECT * WHERE {
  BIND(IRI(CONCAT("http://example.org/", "property")) AS $value)  
}

There were multiple proposals in the PR for the name of the property. derived sounds good, but I would prefer computed. As shown in the example, it's not required to derive the value from any existing data. Maybe also combine it with value, like computedValue. computedNode may give the impression that only blank node and named node results are expected from the node expressions, but literals would also be allowed.

I took the term value from the SPARQL definitions of the constraint components as I think we don't have a defined term for the result of the traversing step from focus node over path.

[afs]

Is it really a sh:NodeShape? or even a new "ValuesShape"?

Informally, property shapes specify constraints that need to be met with respect to nodes that can be reached from the focus node

[HolgerKnublauch]

I don't think the use of node expressions where we previously already allowed complex SPARQL paths is fundamentally different. In the future, people may naturally switch between the node expression features and paths. It is probably just for the transition period that this confusion will happen.

What are the use cases to only compute the predicate, and not its values directly?

However, it is potentially worthwhile to introduce a distinct property for node expressions only, so that a property shape EITHER has sh:path or sh:expression, where sh:expression would be excluded from SHACL Core engines and always point to node expressions.

[tpluscode]

I stand by the explanation of @HolgerKnublauch's original proposal

the intent is for node expressions to behave like property path expressions, namely to compute some value nodes starting at the focus node. For example, sh:zeroOrMorePath also doesn't compute a property but produces the value nodes that can be reached by transitive traversal.

I think it's good that we move away from SPARQL analogies. This should make it easier to shift to a more functional nature of Node Expressions (and Property Paths). In both cases, you'd view the value of sh:path as definition of a function which returns value nodes. Be it by path traversal or evaluating a Node Expression.

The only question if how we treat sh:path.

However, it is potentially worthwhile to introduce a distinct property for node expressions only, so that a property shape EITHER has sh:path or sh:expression, where sh:expression would be excluded from SHACL Core engines and always point to node expressions.

What do you think about my proposal in this comment to introduce a new property and keep sh:path for backward-compatibility?

It might as well be called sh:expression, if we can afford to rebrand Property Paths a expressions. But I would not add it for expressions only.

[afs]

However, it is potentially worthwhile to introduce a distinct property for node expressions only, so that a property shape EITHER has sh:path or sh:expression, where sh:expression would be excluded from SHACL Core engines and always point to node expressions.

Yes.

sh:path(generalized), triple rule sh:object, sh:targetNode etc are all uses of node expressions for a purpose (i.e. they are contextual).

[HolgerKnublauch]

D'oh, I think I just had an epiphany, almost trivial in retrospect:

If we introduce a new property for node expressions such as sh:expression, we should just call it sh:values and have a pretty good solution to the open questions:

1. sh:values would be the same property that is already used in SHACL-AF, with pretty much the same meaning. It defines the expressions that compute the value nodes of a property shape.
2. If sh:values is present, then these are the value nodes.
3. If sh:values is present, then sh:path must be IRI. This IRI will become the predicate to use when the actual inferences are executed and the triples are materialized. (Maybe we can also support sh:inversePath IRI for the inverse asserted direction, but that's another ticket already.)
4. Once the triples have been materialized, the sh:values no longer have to be computed and instead the property shape can be used just like any "normal" property shape, with sh:path pointing at the value nodes.
5. The name sh:values also fits quite nicely with sh:defaultValue, which should be used as derived value when no other values exist.

I'll see if I can make a PR tomorrow on these refinements.

[tpluscode]

Is this almost exactly SHACL-AF?

[HolgerKnublauch]

Is this almost exactly SHACL-AF?

Yes. I think it was useful to evaluate the alternatives yet it would be perfect if we can confirm the original syntax. Much less disruption.

[afs]

@HolgerKnublauch

This (#301) is described in the agenda as "Node expression syntax in CfC" -- isn't that #222?

[HolgerKnublauch]

#222 is already merged into main, so I am not sure what else was there to discuss. But ok, for process reasons I have reverted the agenda and moved the new topic (this) to the second part of the agenda.

[afs]

I think the main agenda point is whether to incorporate NE in the FPWD which is issue #222 (which can be reopened). The original CfC didn't explicitly cover that.