Shall the work on Inferencing start earlier?

[HolgerKnublauch]

The plan outlined in the first WG meeting was to first bring the Core and SPARQL specs to conclusion before starting the other documents.

However, arguably there is no strong reason to not at least start the work on Inferencing, perhaps through a dedicated Task force, assuming this does not block or hinder the deliverables from the first round.

First, there seems to be a LOT of interest in this topic, so I assume there will be volunteers.

But more importantly, I believe there is a huge potential in expanding the expressiveness of SHACL Core if the Inferencing work leads to the standardization of SHACL-AF Node Expressions: https://w3c.github.io/shacl/shacl-af/#node-expressions

In a nutshell, Node Expressions start at a focus node and then compute a stream of value nodes. There are various kinds of such node expressions but it's essentially an extension point of its own.

IF Node Expressions would become a deliverable alongside the Core Spec (maybe even as a chapter in core) the following new use cases would become possible:

1. Dynamically computed targets, see also add targetShape #213 (split from consider Extra SHACL features #199 (comment))

ex:SomeShape
    a sh:NodeShape ;
    sh:targetExpression [
        sh:if [ ... ] ;
        sh:then [ ... ] ;
        sh:else [ ... ] ;
    ]

(This would also remove the need to add SPARQL-based targets to SHACL-SPARQL because sh:select is one of the standard node expression types).

2. Dynamically computed constraint parameters, see https://datashapes.org/dynamic.html#example-state

3. Generalizing property path expressions as a subset of node expressions. This is possible because path expressions also just start at a focus node and then produce a stream of value nodes. This would mean that the sh:path of a property shape may make much richer computations.

So depending on the output of the inferencing work, SHACL Core and SHACL SPARQL may look quite different.

[VladimirAlexiev]

Hi @HolgerKnublauch! If you give a more prominent status to node expressions, that would mean less emphasis on SPARQL, right?
Maybe even the reference implementation of Constraint Components would be based more on expressions and less on SPARQL?

To my mind, the more machinery is based on declarative RDF notations, the better.

• So far all implementations have taken SPARQL as opaque: parameterize it and run it, but don't try to figure out what's going on inside.
• Whereas with declarative RDF, implementations can more easily pick it apart and implement it in a more optimized way.

[HolgerKnublauch]

Yes, that declarative model is exactly one of the advantages. And for the difficult cases, there is a Node Expression type that allows sh:select SPARQL. Likewise, other languages such as JS could be added in the future if we define Node Expressions as an extension point.

And as indicated elsewhere, there will be a role for SHACL profiles to still have the traditional "Core" language without node expressions.

[VladimirAlexiev]

Posted #216 about "SHACL (Own) Profiles"

[afs]

Shall the work on Inferencing start earlier?

Yes (within reason! - we must get phase 1 done).

The inferencing theme would benefit in some work to bring the WG as a group to a common understanding.

Asking for use cases would be a start.

[ajnelson-nist]

Shall the work on Inferencing start earlier?

Yes (within reason! - we must get phase 1 done).

The inferencing theme would benefit in some work to bring the WG as a group to a common understanding.

Asking for use cases would be a start.

A use case:

SHACL inferencing alone should be able to implement RDFS entailment as described in RDF 1.1 Semantics, Section 9.2.1, both in full, and in selected application of the expansion rules.

The motivation for selected application of rules is that some of the rules lead to statements like "example" a rdfs:Resource . which is true under full RDF semantics but a problem for data stores or concrete syntaxes that expect literals to not appear in the subject position.

An analogous use case exists for OWL expansion, but I keep misplacing my bookmark to the OWL document that provides similar entailment tables.

[ajnelson-nist]

An analogous use case exists for OWL expansion, but I keep misplacing my bookmark to the OWL document that provides similar entailment tables.

Found it: here, via the RDFLib OWL-RL README.

[HolgerKnublauch]

Thinking more about it, the changes to the Core spec to support this type of inference-based validation are quite manageable:

1. Introduce the concept of Node Expression as an algorithm that takes one or more input parameters plus an implicit focus node and produces a stream of output value nodes. Define Property Expression as a kind of Node Expression where the only difference is the interpretation of constant URIs, like in the property at sh:path. Change the definitions of sh:inversePath etc slightly to be Property Expressions.

(The library of other supported Node Expressions can then be left to a separate document, esp the Inferences spec and therefore would not steal any WG resources. Core delivery would NOT be delayed.)

2. Generalize sh:path to allow any Property Expression.

3. Generalize sh:targetNode to allow any Node Expression. (We don't need sh:targetExpression that I mentioned above).

4. For most constraint parameters, allow any Node Expression that evaluates to a given datatype or IRI. For example, sh:minCount currently takes an xsd:integer, and it would need to be generalized to allow any Node Expression that produces an xsd:integer. An example use case here would be to have sh:minCount 1 only if some other property values are also present, otherwise 0.

Optionally, Node Expressions could be allowed in other places such as sh:deactivated (we do this already in TopBraid). Once SHACL engines have implemented support for Node Expressions these become low-hanging fruits to implement across the board.

Result will be a very significant gain in expressiveness for SHACL, as well as future-proofing because the library of Node Expressions can be extended through separate specs. Vendors can also introduce their own Node Expression types for their specific needs, like our dash:js to support inline JavaScript.

@PapoutsoglouE if there time in the next meeting, I could briefly explain some background here.