For SHACL Rules (1.2) does sh:targetGraph exist?

[kurtcagle]

I was thinking about this in terms of generated output. You can control the target graph in a sh:sparql rule in your constructor, but does a similar capability exist to be able to specify in a rule the targetGraph(s) (via sh:targetGraph or something similar) of created content?

[HolgerKnublauch]

(A name sh:targetGraph would be unfortunate because the sh:targetXY properties are about declaring the target nodes of a shape, i.e. the nodes that will be targeted for validation. Here I think this is about where to copy the inferences, which is a different task and should get a different name.)

[afs]

One clarification - I think this is referring to sh:construct

But it could be about the constraints use of sh:sparql and wanting to look in another graph.

The experience from the rules section on SHACL 1.0 Advanced Features has shown there is user demand for rules. The work in SHACL 1.2 Rules does not change SHACL-AF in anyway; it leaves it alone and the RDF vocabulary for SHACL 1.2 Rules is separate.

The focus on SHACL 1.2 Rules is finding what can be inferred from a set of rules and a data graph, including rules from different sources and rules that depend on other rules, with a predictable output.

The output of rules evaluation is an RDF graph of triples not found in the data graph.

It does not say what happens to the output. The triples may be put back in the data graph - that's left as a choice by the users/application. There are other reasonable choices - keep along side the data graph to be clear which triples are in the base data and which are not; wait of changes to be reviewed and approved; etc.

Executing a rule set can be used as one step in wider process. Another step may be removing triples using SPARQL Update. Maybe one rule set is run, then some other service runs, then a second rule set is run. Users can be very creative!

[kurtcagle]

Hi, Andy, Holger! The question concerns the output of triples from a rule in SHACL 1.2, either when the output is generated through SRL or via node expressions in a sh:ruleset. My assumption had been that there was only one target for generation that was specified externally, but I was doing some experimentation and found that you might have a workflow process that generated one output (such as reports) to one named graph, generated triples to a second name graph, and possibly required a sink from a third named group (the last is more dubious, but possible). This should be doable with SRL using named graph notation as per SPARQL, but I would expect their to be a corresponding equivalency within the Turtle node expression library. . *Kurt Cagle* Editor in Chief The Cagle Report ***@***.*** 443-837-8725 <http://voice.google.com/calls?a=nc,%2B14438378725>

…

On Mon, Jan 26, 2026 at 1:25 PM Andy Seaborne ***@***.***> wrote: *afs* left a comment (w3c/data-shapes#732) <#732 (comment)> One clarification - I think this is referring to sh:construct <https://w3c.github.io/shacl/shacl-af/index.html#SPARQLRule> But it could be about the constraints use of sh:sparql <https://www.w3.org/TR/shacl12-sparql/#sparql-constraints> and wanting to look in another graph. The experience from the rules section on SHACL 1.0 Advanced Features has shown there is user demand for rules. The work in SHACL 1.2 Rules does not change SHACL-AF in anyway; it leaves it alone and the RDF vocabulary for SHACL 1.2 Rules is separate. The focus on SHACL 1.2 Rules is finding what can be inferred from a set of rules and a data graph, including rules from different sources and rules that depend on other rules, with a predictable output. The output of rules evaluation is an RDF graph of triples not found in the data graph. It does not say what happens to the output. The triples may be put back in the data graph - that's left as a choice by the users/application. There are other reasonable choices - keep along side the data graph to be clear which triples are in the base data and which are not; wait of changes to be reviewed and approved; etc. Executing a rule set can be used as one step in wider process. Another step may be removing triples using SPARQL Update. Maybe one rule set is run, then some other service runs, then a second rule set is run. Users can be very creative! — Reply to this email directly, view it on GitHub <#732 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAHOAQKLVWA35N22CPA6634I2A27AVCNFSM6AAAAACSX3KJI6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTQMBRHAZDSNJQGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[afs]

Hi @kurtcagle ,

Yes - it can be specified externally. Neither SRL or RDF forms indicate where the inferred triples go. Like your examples - too many choices. A toolkit API might allow the users/application to provide a destination but that's outside the scope of SHACL 1.2 Rules spec.

If you want 3 different sections to go to 3 different places, then it sounds like having 3 rule sets. Rule sets will be able to have "IMPORTS" so they can share rules.

The RDF and SRL forms are intended to be equivalent -- they both generate abstract syntax and execution is defined by operating on the abstract syntax.