Contents of SHACL-AF

[afs]

I am unclear why shacl-af and shacl-js were edited here too, as those documents are from the previous WG and will not be moved forward.

Originally posted by @HolgerKnublauch in #167 (comment)

[afs]

Is this where some of the section from SHACL-AF will go?

• SPARQL Custom Targets
  This moves to SHACL-SPARQL (if not subsumed by targetNode +node expressions)

• Annotation Properties
  This moves to SHACL-SPARQL?

• SHACL Functions (Node Expressions)
  Part of node expressions

[HolgerKnublauch]

@afs please double-check the title of this issue, doesn't look right.

• Yes I believe custom SPARQL targets will be solved with the sh:select node expression and sh:targetNode. Custom target types do not have an equivalent unless we introduce a higher-level template language for node expressions.

• I have no strong opinion on whether the Annotation Properties need to be upgraded as I have never seen them used.

• User-defined SHACL functions are a general extension point that I believe makes sense in SHACL-SPARQL 1.2 but may be out of scope due their implementation complexity.

• The use of functions as node expressions would become a node expression in SHACL-SPARQL if we elect to limit them to SPARQL functions, otherwise no clue. For example, we also support JS-based custom functions.

[afs]

@afs please double-check the title of this issue, doesn't look right.

Done! (Side effect of GH "create new issue" on the original comment - lesson learnt)

[afs]

The two sections "Node Expressions" and "SHACL Rules" could be two documents, depending on how big the node expressions document is likely to become. The machinery for node expressions needs to be in core.

The node expressions proposal is suggesting "Eventually, the library of Node Expressions could cover all of SPARQL"

That's not small, even if SHACL taps into "Functions and Operators" directly.

[simonstey]

The two sections "Node Expressions" and "SHACL Rules" could be two documents, depending on how big the node expressions document is likely to become. The machinery for node expressions needs to be in core.

+1, the benefit then would certainly be that the "collection" of NExp could be extended and worked on independently from the core spec. (a bit like ODRL's Vocab for example)

[HolgerKnublauch]

Yes I like that suggestion, @afs . It would also protect the existence of Node Expressions in case there are significant objections against the graph-level rule inferencing by someone, or they need much longer than the NE spec.

In terms of the core NE machinery, I looked at the SPARQL definition of variables and solution mapping sequences, which could be the foundation of input and output of each expression. Basically they would take a sequence of variables (including, usually, focusNode) as input and then produce a new output variables sequence, including a dedicated default variable such as "outputNodes" that serves as input for other expressions that currently take sh:nodes as parameter. This would allow chaining them together in a modular way while potentially covering all of SPARQL in the future? The algorithms behind each would then be just a description of how the input sequences map to the output sequences, e.g. sh:count would return a single xsd:integer counting the input sequence.

Does this make sense?

[afs]

Does this make sense?

I think I see what your getting at - SPARQL functions themselves don't work on solution mappings except when evaluating a variable.

A "function" is something that already-evaluated arguments. There are few things that look like functions, but aren't (||, for example).

#227
We don't want to use SPARQL Node Expressions, for the reasons mentioned in the wiki page above and in #215

#222 is probably the place for discussing the way evaluation happens. I put some examples in - more from other people would be great.

Rules of more than one triple with NE conditions will need named variables in some form (warning current thinking), c.f. CONSTRUCT templates, because of being able to restrict values and then use in generated triples - one expression, two locations.