Relax Node Expression definitions to avoid BNode requirement

[gtfierro]

Apologies if this is not the right place to raise this issue (and I'm happy to document this elsewhere if necessary!), but I was curious about the possibility of removing the BNode requirement for Node Expressions: https://www.w3.org/TR/shacl-af/#node-expressions

Specifically, requiring that the expression starts with a BNode makes it impossible to use skolemization on the shapes graph as part of processing. Skolemization replaces the blank nodes with named nodes, and therefore won't trigger evaluation of the Node Expression as intended. We ran into this issue at open223/docs.open223.info#49 (with @steveraysteveray). The TopQuadrant SHACL implementation doesn't seem to care about the node expressions being BNodes, but the PySHACL implementation does.

My ask is that the definition of Node Expressions be relaxed to use either named nodes or blank nodes. Let me know if I can provide more details, draft spec language, or anything else!

[steveraysteveray]

+1

[HolgerKnublauch]

I believe that's too difficult and not worth doing for this specific scenario of skolemization. Also, there is already at least one other place (sh:paths) where SHACL Core relied on using blank nodes. Those would need to change too, making every processing of SHACL files slower and more complex. It will be much harder to read SHACL files as it's unclear whether a node is an expression of a constant, without looking into all imported graphs etc.

[TallTed]

I believe that's too difficult and not worth doing for this specific scenario of skolemization.

It seems to me this should be raised to the broader community, as it appears to have been easy enough to do in PySHACL (or do I misunderstand @gtfierro's comment that "The TopQuadrant SHACL implementation doesn't seem to care about the node expressions being BNodes, but the PySHACL implementation does." Does that mean it was easy enough to do in TopQuadrant's implementation, but not in PySHACL?)...

In any case — I strongly advise raising the question of implementation feasibility on the mailing list (and possibly elsewhere as well) to get the broadest possible audience and response. This should not be decided by fiat.

[afs]

My ask is that the definition of Node Expressions be relaxed to use either named nodes or blank nodes. Let me know if I can provide more details, draft spec language, or anything else!

The link trail in the description is quite long and in the context of open223.info. Something concise and standalone would be useful.

[ashleysommer]

I agree with @HolgerKnublauch, and as the developer of PySHACL, relaxing this spec would make it much harder for the implementation to discern whether an IRI in the expression is to be treated as a Constant Term IRI, or as a skolemized BNode.

[gtfierro]

"The TopQuadrant SHACL implementation doesn't seem to care about the node expressions being BNodes, but the PySHACL implementation does." Does that mean it was easy enough to do in TopQuadrant's implementation, but not in PySHACL?)...

I should have been more specific, sorry! What I meant is that TopQuadrant's SHACL implementation seems to support both IRIs and BNodes for Node Expressions. PySHACL follows the SHACL specification more strictly -- if it sees an IRI as the value of sh:object in the TripleRule, it will just treat that as an IRI instead of a Node Expression.

[gtfierro]

I agree with @HolgerKnublauch, and as the developer of PySHACL, relaxing this spec would make it much harder for the implementation to discern whether an IRI in the expression is to be treated as a Constant Term IRI, or as a skolemized BNode.

Thanks for the reply! I just sent an email to the mailing list to solicit some additional thoughts on this. I think we can work around the lack of skolemization as long as we can keep the shape graph and (expanded) data graph separate across different SHACL implementations.

[HolgerKnublauch]

On the TopQuadrant implementation, I cannot confirm this. In the open source version, see

https://github.com/TopQuadrant/shacl/blob/master/src/main/java/org/topbraid/shacl/expr/NodeExpressionFactory.java#L247

where it will return a ConstantTermExpression for IRIs or Literals before even checking blank nodes. So whatever you saw would have been a bug elsewhere.

[ashleysommer]

@HolgerKnublauch I agree, I checked that code too after reading this thread, and saw the same behavior.

[steveraysteveray]

Just to clarify the symptoms, the results of the simple toy example using PySHACL are shown here: and the results using TopBraid are shown here:

[gtfierro]

I think a conflating factor is that TopBraid can emit only the inferred triples (which can then be added directly to the original data graph) but pySHACL unions the data and shapes graphs (we needed to do this to get inference to work correctly) and they need to be separated after the fact. An example of the script which demonstrates this behavior is at open223/docs.open223.info#49 (comment) . I'll try to put together a more easily usable reproducing example later today