Sequence processing

[afs]

The definition of node expressions with lists is based on sequences of nodes.

The naming of operations, however, is set-style.

If the processing model is to be list based, then naming might reflect that:

• sh:union => sh:sequenceOf or sh:concat or sh:join
• sh:minus => sh:remove

A natural step is then whether the usual operations on sequences sh:flatmap, sh:findFirst, sh:matchAll are needed.

[HolgerKnublauch]

Makes sense, esp on the missing sequence operations.

If we rename sh:union and sh:minus we'll have to remove the terms from the TTL file, something which I thought was difficult due to W3C policies. But if that's easy to do, then I would prefer sh:join. With sh:minus maybe sh:removeAll would be better.

[HolgerKnublauch]

Related to this, and I'll raise the topic here although it may become its own ticket:

Maybe we use this opportunity to modularize the namespace. We have already made a start by introducing the sparql: prefix. I think it would be good to, now, move all other built-in node expressions into their own namespace and prefix, to signal that these are SHACL Node Expressions and not constraints.

I suggest we move them into a new document with prefix shnex (which rolls off the tongue quite nicely in German) or expr, and leave the legacy terms marked as deprecated in the main TTL file. Implementations that supported the sh: old node expressions could continue to support them as aliases, but migration is quite simple.

It would look like this:

ex:Person-maleChildren
	sh:values [
		shnex:nodes [
			shnex:path ex:child ;
		] ;
		shnex:filterShape [
			sh:property [
				sh:path ex:gender ;
				sh:hasValue "male" ;
			]
		] ;
	] .

or

ex:Person-maleChildren
	sh:values [
		expr:nodes [
			expr:path ex:child ;
		] ;
		expr:filterShape [
			sh:property [
				sh:path ex:gender ;
				sh:hasValue "male" ;
			]
		] ;
	] .

It would more clearly separate sh:path from shnex:path among others. And it will make it easier to add many more node expression types as we move forward. Adding them is actually quite simple because most algorithms are trivial, once the generic infrastructure is in place.

[afs]

Maybe we use this opportunity to modularize the namespace. We have already made a start by introducing the sparql: prefix. I think it would be good to, now, move all other built-in node expressions into their own namespace and prefix, to signal that these are SHACL Node Expressions and not constraints.

Good idea.

Node Expressions may have uses beyond SHACL. e.g. custom function in SPARQL engines.

The rules RDF-format would be another candidate for a separate namespace.

[TallTed]

I wonder whether sparql: shouldn't be shsparql:? (I've not looked to see what namespace URI is being targeted.)

[afs]

sparql: refers to (what will be) http://www.w3.org/ns/sparql#

current draft:
https://github.com/w3c/sparql-query/blob/main/sparql-ns.ttl

[VladimirAlexiev]

@HolgerKnublauch

• is it imperative for shnex:path ex:child and sh:path ex:gender to use different predicates?
• I'm worried some users may confuse them (of course, the spec and examples will alleviate this)
• @jeswr I'm also worried what sort of SHACL-C syntax can be devised: keywords for sh: constructs, but shnex: URIs for shnex: constructs?
• I understand the former generates and the latter checks/restricts, but do both of them take a SHACL prop path as argument?
• If so, perhaps engines can disambiguate two uses of the same predicate sh:path?

@afs

Node Expressions may have uses beyond SHACL. e.g. custom function in SPARQL engines.

Which of the above can play such role?

• Do they need to match the [function (args)] pattern as you showed for SPARQL functions?

[afs]

Node Expressions may have uses beyond SHACL. e.g. custom function in SPARQL engines.

Which of the above can play such role?

Domain-specific functions would be candidates - why have to write things twice, once for SHACL and once for SPARQL?

[HolgerKnublauch]

@VladimirAlexiev the two cases of sh:path and shnex:path are different in that not only is shnex:path a node expression, but it can also be combined with shnex:nodes to specify different focus nodes. So we need to keep them apart and make sure that all examples are clear enough to get this point across.

We can also rename shnex:path to shnex:pathValues or similar if that helps.

[simonstey]

@HolgerKnublauch

We can also rename shnex:path to shnex:pathValues or similar if that helps.

+1 as people will confuse the two.. I would also appreciate a sentence or two in https://w3c.github.io/data-shapes/shacl12-node-expr/#PathExpression explaining the difference between sh:path and shnex:pathValues.