Make list optional for list-parameter node expressions that take only one parameter

[HolgerKnublauch]

For example, sparql:abs currently would need to be written as

[
    sparql:abs ( [ shnex:path ex:property ] )
]

If this was a named-parameter node expression, it would be written as

[
    sparql:abs [ shnex:path ex:property ]
]

Many users will not know the difference and when to use which notation. Many users will not really be aware that the distinction between list and named parameters even exists.

I think any list parameter functions that take only one argument should support the second syntax without a list. So this would also be legal:

[
    sparql:abs -42
]

[afs]

Reading is at least as important writing. For reading, one form has its advantages.

UIs will automate much of the writing and forms such as [ shnex:expr "SPARQL syntax" ] can be introduced to aid writing.

I don't think we can know whether it is a good idea at this stage. Node expressions is still under development.

If there are convenience forms, then other expectations may appear:

Named parameter functions return lists but that is a different "list" to arguments. ¹
[ sparql:plus [ shnex:path ex:property ] ] -- is that sum all elements? (users: why not? especially if shnex:sum is removed as per the current spec note)

Another expectation might be around use of comma's [ sparql:plus 1 , 2] or more complicated expressions:

[ sparql:plus [ shnex:path ex:property1] , [ shnex:path ex:property2 ] ]

but [ sparql:subtract 1 , 2] is never going to work.

Or maybe it means applying a single argument functions to each element of the list and returning a new list (add shnex:apply -- #484).

[ sparql:abs [ sh:order [ shnex:path ex:property ] ] -- is that apply abs to all elements?

It makes the engine a bit more difficult in knowing the difference between list and named argument functions and for the users, too, similar syntax can make for easy errors.

Footnotes

1. A section title of "List Operator Expressions" in the TOC is confusing when there is "List-parameter functions". ↩

[HolgerKnublauch]

After many years of SHACL-AF in TopBraid, we still did not have time and resources to build a proper UI editor for node expressions. I guess it would need to be something graphical with draggable edges and nodes, as any other editor is just as good as Turtle. In the absence of a suitable Compact Syntax, and even after that, it needs to be easy to edit from TTL. Ideally, a SHACL-SHACL could help define the valid patterns.

Yes, we don't know if this is a good idea but my own preference is to make this change now, because it gives more options for users to enter the right syntax.

[afs]

a suitable Compact Syntax

1. Let's see what SHACL-C come up with.
2. The rules grammar has expression syntax. If we define "parsing" SRL as "generate RDF", then there is a converted there (its mainly a big map of keyword to URI).