Implementation complexity of relaxing Node Expression definitions to avoid BNode requirement

Hi everyone:

We have been using SHACL and SHACL-AF to implement ASHRAE standard 223 using validation shapes and SHACL-AF rules. This has raised a question of SHACL-AF specification and implementation feasibility regarding Node Expressions, and I was encouraged to raise this issue with this mailing list. I'll put the SHACL-specific ask up front and provide some context at the end of the email.

I am curious about the possibility of removing the BNode requirement for Node Expressions https://www.w3.org/TR/shacl-af/#node-expressions (and also for `sh:path`s in the SHACL core). 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. A possible fix to support skolemization would be to allow Node Expressions to be defined using either an IRI or a BNode. However, as has been raised on https://github.com/w3c/data-shapes/issues/371, this will complicate SHACL implementations.

My ask to the community is provide your thoughts on the complexity of relaxing Node Expression definitions in SHACL implementations. How much of an impact would this change have on your implementations? Is it a change worth making? Or is there another way to work around this? Does SHACL Core or AF have a stance on whether skolemization should be used? Finally -- am I missing anything?


This is my first post on the forum so I hope I'm following your norms. Please let me know if I can provide any further information or clarification on the issue at hand! I have put some additional context at the end of this email after my signature.

Best,
Gabe

--
Dr. Gabe Fierro | https://home.gtf.fyi<https://home.gtf.fyi/>
Assistant Professor of Computer Science | Colorado School of Mines
Joint Appointment | National Renewable Energy Laboratory

---

"Why do you need skolemization in this case?"

You can find some discussion of ASHRAE standard 223 ("223P") at https://github.com/w3c/data-shapes/issues/343 and additional unofficial information on the proposed standard at https://open223.info.

One of the use cases of 223P is using SHACL-AF rules to add additional information to a knowledge graph of a building. This makes it easier to express our connectivity model (see https://docs.open223.info/explanation/223_overview.html#topology : the modeler just adds the `s223:cnx` edges and the inference rules handle adding the rest of the edges). We want to access the post-inference model to serve queries and build other applications. We also want to keep the building knowledge graph separate from the 223P graph. One way to accomplish this is to skolemize the 223P graph, run SHACL inference on the union of the knowledge graph and 223P graph, and then subtract the skolemized 223P graph from the expanded model. This specific workflow raised the original issue that inspired the email you’re reading: https://github.com/open223/docs.open223.info/issues/49 . The comment where I discover the issue is here: https://github.com/open223/docs.open223.info/issues/49#issuecomment-2821601146