Add node expression function for the empty list

[HolgerKnublauch]

In some cases it is useful to specify an empty list, for example as a dummy input to some other node expression.

Many people will expect to use () for the empty list. However, that is in fact the constant rdf:nil.

I think the "empty" blank node [] should be interpreted as the empty list.

[afs]

In some cases

Example of why () doesn't work? It works for list-argument functions.

() is syntax for rdf:nil and it is the empty list.

[ sparql:now () ] works.

A SHACL list in an RDF graph G is an IRI or a blank node that is either rdf:nil (provided that rdf:nil has no value for either rdf:first or rdf:rest),

[HolgerKnublauch]

In general, rdf:nil is a IRI Node Expression (constant).

With list-argument functions, the interpretation is that it first looks for the list so rdf:nil is an exception for that and hard-coded. But not for general node expressions.

[afs]

In general, rdf:nil is a IRI Node Expression (constant).

And it is still a list!
RDF "hard-coded" the meaning long ago.

This isn't special to node expressions - it's true for RDF data. When code looks for a list, it is zero or more cons cells terminated by rdf:nil so code is always looking for rdf:nil in every list.

In some cases

... example ...?

[HolgerKnublauch]

I don't think we are talking about the same issue here, Andy.

ex:SomeShape
    sh:targetNode () .

In SHACL 1.0 this means that rdf:nil itself is the target node. In SHACL 1.2 this is interpreted as a node expression, and we cannot break things therefore it needs to keep the same interpretation - as a constant and not the empty list.

In terms of examples, any function that uses list-based syntax where a value is optional and we just want to pass in nothing.

[afs]

In SHACL 1.0 this means that rdf:nil itself is the target node.

Yes (I thought we'd discussed this when sh:targetNodes was discussed)
Is this the only case?

In this one case, because sh:targetNode () as a node expression is a no-op, then make a special case for legacy reasons.

Whether the spec defines [ shnex:emptyList () ] or not doesn't change the fact that [ sparql:now () ] can be written.

any function that uses list-based syntax where a value is optional

This isn't the same situation - the function can and should define the interpretation of its arguments. The "don't care" value may be different for different functions (string expected vs URI expected) to pass implementation argument checking. No need to mandate behaviour.

[ my:print ( "abc" [ :returnsBlankNode() ] "def" ) ] and print skips non-strings can be written now.

[HolgerKnublauch]

Instead of adding exceptions to existing terms such as sh:targetNode, why not just handle rdf:nil differently for list-based functions in the Node Expression spec? This is a fresh concept that we are just about to introduce and there is no legacy code yet to consider. We just need to allow cases like sparql:now () to receive the empty list of arguments. I think this is already the plan anyway - if the value of a property like sparql:now is an RDF list then the engine should walk the list and evaluate the nested expressions, then use their first (and only) result node as argument for the function call.

[afs]

Might work. It least it does not break writing SPARQL based node expressions.
It s about the way of thinking about it - if theer are no oteh case, equally that the NX-extension of sh:targetNode has an exception.

The current node expression text works for evaluation.

where the object is a SHACL list.

[afs]

ex:SomeShape
    sh:targetNode () .

In SHACL 1.0 this means that rdf:nil itself is the target node. In SHACL 1.2 this is interpreted as a node expression,

The rdf:nil isn't a list-parameter or named-parameter expression. No blank node, no function predicate. It's the constant rdf:nil.

[] can be a "no value" mark. It isn't a node expression eiither. No function predicate.

---

Although this is a named-parameter expression

	sh:values [
		shnex:limit 2 ;
	] .

because the definition says

where the predicate can be used to uniquely identify the function,

which shnex:limit does. The text does not positively say that shnex:nodes is required.

[HolgerKnublauch]

I would introduce [] just like we have introduced the constants (URIs and literals) - as an exception that doesn't fit the other two forms.

IMHO shnex:nodes is required already, but it may be hidden in the text. The intro of section 4 states that properties in bold are required. But I will need to go over all this to clarify the syntax contracts.

[afs]

[ ], being a unique, fresh blank node, captures the idea of don't care (c.f. _ in prolog) quite well.