Rename shnex:path to shnex:pathValues and change its shnex:nodes to shnex:focusNode

[HolgerKnublauch]

Discussed here #484 (comment)

The first suggestion is to rename shnex:path to shnex:pathValues.

The second is to replace shnex:nodes with shnex:focusNode. This is to modify the focus node, which defaults to the currently active one. The current design allows multiple nodes and I guess few people will understand what that means and use cases are likely rather light. It also raises questions such as how are these values concatenated into a single list. It would make the language more predictable if there is always just one focus node.

[HolgerKnublauch]

How do people feel about this? shnex:path will be used A LOT so a shorter name would be better than shnex:pathValues? Any better names?

[bergos]

shnex:valuesOf could be a slightly shorter alternative, but shnex:pathValues is more self-describing, that's why I would favor the last one.

[robert-david]

+1 for 'shnex:pathValues'

[robert-david]

+1 for 'shnex:focusNodes', because 'shnex:nodes' is a bit ambiguous with 'sh:values'.

[HolgerKnublauch]

@robert-david I am wondering whether we really need the plural. Do you have a use case?

Note that we'll likely have something like flatMap later (details unclear though).

[TallTed]

shnex:focusNode (singular) because each object/value will appear once, even if there are several values to be considered overall.

Likewise, shnex:pathValue (singular).

[HolgerKnublauch]

@TallTed pathValue singular doesn't sound right to me. The value here isn't the path itself, but the (list of) value nodes of the path/predicate at the focus node. These are in general zero or more.

[robert-david]

@HolgerKnublauch is is my understanding that there could be multiple focus nodes returned (i.e. a node expression producing the focus nodes) and then for each of these nodes the path will be followed to the value nodes. Finally, the union of these value nodes (for all focus nodes) will be returned.
Am I mistaken here?

E.g a node expression to collect all skos:prefLabel literals of skos:Concept nodes:

sh:values [
	shnex:pathValues skos:prefLabel ;
	shnex:focusNodes [ shnex:instanceOf skos:Concept ]
]

[HolgerKnublauch]

Yes, this is the current definition. But do we need this use case, or can it be simplified to be just for one focusNode at a time.

[robert-david]

A use case would be to check if a skos:prefLabel is already used in the graph for another skos:Concept.

[HolgerKnublauch]

Iterating over all values and check them one by one would be a very inefficient solution, when it should just be a direct triple look-up.

[TallTed]

@HolgerKnublauch — You seem to be arguing with yourself. About shnex:pathValues and/or shnex:focusNodes, you wrote:

I am wondering whether we really need the plural. Do you have a use case?

and then you wrote:

pathValue singular doesn't sound right to me. The value here isn't the path itself, but the (list of) value nodes of the path/predicate at the focus node. These are in general zero or more.

My thinking is that while each of these predicates might have zero or more values, these are typically found in the form of one triple per value in the graph. No value itself is plural, though sugar in some syntaxes (primarily Turtle) may make it look so, whether by writing a comma-delimited list (which can be burst into one triple per value, by, for instance, converting from Turtle to N-Triples) or by putting a blank node (singular!) that contains multiple values, thereby creating a complex value (singular!)....

[HolgerKnublauch]

This argument would make sense if this was about individual triples. But the result of this node expression is a list of nodes. (Not an rdf:List but a data structure list, or iterator, or stream).