Remove some SRL functions

[afs]

After today's (2026-01-26) WG meeting, I took a look at the list of functions to see what can be removed:

Function	Reason
COALESCE	Failure to find an valid argument expression causes an error
BOUND	Well-formedness means this is does not happen
MD5, SHA*	Nowadays, there are other important hash functions
RAND	Not a well-behaved function (calling twice gives different values)
BNODE()	Zero-args form - not a well-behaved function

[liviorobaldo]

Hello!

Are you proposing to remove these functions from the SHACL rules grammar?

I am actually quite in favor of keeping BNODE. I use it frequently in my use cases. If BNODE were removed, the only way to create new RDF resources would be by entailing blank nodes ([...]) in the heads of rules, which seems less readable and more cumbersome. For this reason, it might be preferable to keep BNODE and instead adjust the grammar so as to prevent the creation of blank nodes directly in rule heads.

I also do not understand the rationale you provided, what do you mean by "not a well-behaved function"?

Regarding BOUND, I cannot find it in the SHACL rules grammar (§6).

[afs]

There are two forms of BNODE - which do you use?

[afs]

Regarding BOUND, I cannot find it in the SHACL rules grammar (§6).

It was in the Dec 9 version which is the current /TR/, it has been removed in a general update because it is particularly troublesome.

For this reason, it might be preferable to keep BNODE and instead adjust the grammar so as to prevent the creation of blank nodes directly in rule heads.

How would that work?

I also do not understand the rationale you provided, what do you mean by "not a well-behaved function"?

A function should return the same answer when it is called with the same arguments and the arguments are evaluated before passing to the function.

Just because something has a surface syntax of a function does not mean it is a function. It is a "functional form". (Different communities have different terminology.)

Evaluation of rules can cause the body to be evaluated multiple times but it has to be deterministic.

Consider

RULE { :s :p :o } WHERE { FILTER (RAND() < 0.5) }

[liviorobaldo]

I use it inside BIND to create new individuals via SHACL-AF rules. For example:

CONSTRUCT{?es rdf:type :M-Obligatory...}WHERE{... BIND(BNode() AS ?es) ...}

As I mentioned, I find this approach much cleaner and more readable than:

CONSTRUCT{[rdf:type :M-Obligatory...]}WHERE{...}

To the best of my knowledge, this is the only other option for creating anonymous individuals. But the option with BNode is better.

[liviorobaldo]

A function should return the same answer when it is called with the same arguments ...
Evaluation of rules can cause the body to be evaluated multiple times but it has to be deterministic.

So, the issue with BNode is that it creates a new anonymous individual every time it is called? The same rationale applies to the [...] in the heads, I would say: this also generates a new anonymous individual each time the rule is triggered.

For this reason, it might be preferable to keep BNODE and instead adjust the grammar so as to prevent the creation of blank nodes directly in rule heads.
How would that work?

After a quick look at the grammar, I think it would be sufficient to remove this production rule:

[56] BlankNodePropertyListPath ::= '[' PropertyListPathNotEmpty ']'

However, we should keep BNode if we want SHACL Rules to be able to create new RDF resources (and I hope we agree that they should be capable of doing so).

[afs]

RDF resources

See https://www.w3.org/TR/rdf12-concepts/#resources-and-statements

For example:

CONSTRUCT{?es rdf:type :M-Obligatory...}WHERE{... BIND(BNode() AS ?es) ...}`

I find this approach much cleaner and more readable than:

CONSTRUCT{[rdf:type :M-Obligatory...]}WHERE{...}

I think a lot of people will disagree with that!

At technical level, BIND/BNODE is unstable.

I can see how RULE { :s :temperature [ :value 10; :unit si-unit:degreeCelsius ] } might be made to work.

[liviorobaldo]

At technical level, BIND/BNODE is unstable.

Ok, if BNode is unstable, not well-behaved, or has any other issues (which I still find hard to pinpoint... or at least I struggle to see why they wouldn't apply to [...] as well), let's remove it from the grammar. I will use [...], although I find it less visually appealing (but that's only my preference, as you said).

On a separate note, I just noticed that the grammar does not include the GRAPH operator:

https://www.w3.org/TR/rdf-sparql-query/#queryDataset

Does this mean that SHACL rules cannot operate on subgraphs? Am I understanding this correctly, can you confirm? That could make things quite challenging for another use case I'm working on 😅

[afs]

I struggle to see why they wouldn't apply to [...] as well),

Because BIND/BNODE is in the body where as [...] is in the head.
(Not that we have a way to handle it in the head yet - but at least it there is apossiblity.)

[...] in the body has a different meaning.

Does this mean that SHACL rules cannot operate on subgraphs?

The input is a graph.The spec does not say where that graph comes from - that's a toolkit issue.

[liviorobaldo]

The input is a graph.The spec does not say where that graph comes from - that's a toolkit issue.

Ok, but is it possible to create, via SHACL rules, a new subgraph? Something like:

CONSTRUCT 
{
  # Create new subgraph (duplicate) and add a different triple
  :a :p ?newGraph .
  GRAPH ?newGraph {
    ?s ?p ?o .
    :z :w :y .
  }
}
WHERE {
  # Find the graph associated with :a containing the key triple
  :a :p ?graph .
  GRAPH ?graph {:d :r :e}

  # Copy all triples from the old graph
  GRAPH ?graph {?s ?p ?o}

  # Create a new graph as a blank node
  BIND(BNODE() AS ?newGraph)
}

Not sure how I could use [...] in place of BNode above, especially since ?newGraph is used in two triples in the head.

Anyway, this issue is not about subgraphs, so perhaps we should discuss it in a separate issue.

[afs]

Off topic.

The example creates a dateset, not a graph.

GRAPH in the construct template isn't legal in SPARQL.

Are you using a Jena based system? That has GRAPH in CONSTRUCT as an extension.

# Copy all triples from the old graph

As written, each triple goes into a separate named graph, which is not what the comment suggests.
(Move the BIND(BNODE() AS ?newGraph) to earlier in the query, before the GRAPH ?graph {?s ?p ?o}. It not clear what is intended is :a :p ?graph . matches more than once.