SHACL Rules / SRL / SHACL‑AF Rules in the W3C Data Shapes WG #1075
Replies: 11 comments 23 replies
|
@HolgerKnublauch @afs @nicholascar if this is not helpful, please ignore. but hopefully it is helpful and helps us to converge on a common ground. |
|
Fascinating how the agent has constructed all this from the various texts in the repo. Quite good. IMHO it doesn't have a true understanding of the options though and misses alternative solutions. Here is a strawman proposal:
Note that SRL would only need to declare syntactic dependency on SHACL-SPARQL. All its algorithms and even the grammar can be defined and evolve stand-alone. An engine that supports both can automatically switch to SRL algorithms if all sh:SPARQLRules fall into the SRL subset. Some ideas on the BIND vs SET conversion:
becomes If the bound doesn't exist and the expression MAY return unbound, mark the rule as ill-formed.
Can be made safe by |
|
The whole point about reusing CONSTRUCT is that the same rules can then also be used as SHACL SPARQL rules, i.e. with an engine that does the fixpoint iteration. And this is often no problem because the results of the brute-force fixpoint algorithm and the stratification algorithm are often (most of the time?) the same. We unfortunately have not collected enough use cases yet to give a qualified estimate on the percentage of real-world rule sets where the order really matters. For example, for the 69 OWL RL rules the order does not matter. And from anecdotal evidence I don't remember many cases where the order did matter to a SHACL-AF engine.
Yes, and that is correct, because it behaves exactly like SPARQL. The only difference is that additional constraints on SPARQL apply. And that is the same for the current SRL draft, where the user also needs to keep some well-formedness rules in mind that are outside of the syntax https://www.w3.org/TR/shacl12-rules/#wellformed Will some people mix things up and use CONSTRUCT incorrectly? Yes. Will some people mix things up and use BIND in RULE...WHERE? Yes. But in both cases the error will quickly be reported by the rule engine and can trivially be fixed by the rule editor. So I believe we are overstating something that will turn out to be a non-issue. And by doing so we are throwing out the possibility to deliver a unified rules framework instead of two disjoint and competing standards. |
Yes but then we are publishing two competing standards. And one of them currently has nothing to do with SHACL. |
3 ways to use within the SHACL Rules framework: |
|
None of these 3 proposed extensions to SRL incorporate SHACL. They just offer plugin mechanisms where other standards could interact with SHACL to produce focus nodes for the rules. And then there is hand-waving about how this would actually work without losing all the benefits of SRL. So, no. Current SRL has nothing to do with SHACL. |
I agree. Nobody has ever called me "the decidability hawk" before 😂 I'll try to read everything carefully asap, but now I want to pay attention to the meeting... |
|
Sadly, I am unable to locate where I was being the "Code‑of‑Conduct guardian" nor "where it turned personal (see §7.1 transcript)". Note that §7.1 does not include any "transcript". There is also a reference to "the material abridged in the transcript at §7.3" but again, §7.3 does not include any "transcript". It will take me some days to fully digest the LLM's "summary". I am now hesitant to take it at face value, and fear I will need to follow every link presented there, as I go, and that may take weeks rather than days. |
|
@afs not sure where else to continue the discussion from the meeting today, but I think you were wrong about eyeleng, see https://github.com/eyereasoner/eyeleng
|
|
There are a suite of reasoners on common techology. Another is: https://eyereasoner.github.io/eyeling/ Of note: Eyeleng supports "forward materialization with tabled backward proving". |
|
One of the goals of SRL is to have defined output. As well as #1075 (comment), there are other proposals how SHACL shapes work with rules in the SHACL Rules Framework, centered around the way how One way is as a property or a new rule type; the latter seem more popular. It can use the existing pre-binding mechanism directly. There is material on migration from AF-Rules
Another way is the proposal for parameterization syntax which directs pre-binding We also have the proposal As with the CONSTRUCT steps, SHACL Rules is still the outer controller, the choice of focusNodes is with the SHACL Rules Framework, and the interactions of between steps is the framework and user's responsibility. |
|
@robert-david wrote:
This is an interesting thought-experiment. What about we make CONSTRUCT interchangeable with another keyword but otherwise use SPARQL in the WHERE clause. Then people can use that different keyword to clarify they are writing a rule instead of a plain CONSTRUCT. I could live with that in SHACL-SPARQL if it helps us move forward. If this alternative to CONSTRUCT is introduced, I would prefer to call it INFER instead of RULE, see also #955
would be the same as Argh, which reminds me that the property name is sh:construct, which is another question then. Would we need sh:infer... Hmm. |
|
On syntax: My take is that "similar" isn't good enough for publishing when there is a way that puts it right at authoring time. The person writing rules may not be the person running them, so the idea of having the editor in the loop and fixing a run time error isn't so easy. Users will cut&paste text and then the context is lost. At scale, the errors may be subtle "wrong output" somewhere in a large output graph. (which SHACL AF Rules implementations check the syntax requirements on CONSTRUCT?) |
|
I hope we can agree that none of these arguments (both in favour of staying within SPARQL syntax or a new syntax) are black and white, but rather a matter of taste and speculation. There are pros and cons of both.
Well, this sounds like a very very weak argument. Who would seriously develop rules without testing them.
I don't think mine does so far. Things will be more motivating to clean up once this is a proper W3C standard. |
|
On syntax again, I just noticed that SHACL SPARQL global rules have no limitations on SPARQL whatsoever because they don't even use pre-binding. As SRL is only using global rules, it can define its own random subset of SPARQL that it wants to support. Likewise for any other subset of SPARQL-based rules, such as future versions of SRL. |
A team (designers) writes a set of rules, tests them, publishes them. Another team (data product) incorporates those rules in their workflows. The data changes. Even if the tests are also published, having guarantees of behavior has value. |
|
@HolgerKnublauch wrote:
Ok. So we have SPARQL CONSTRUCT queries, but with the keyword INFER instead. Exchanging INFER with CONSTRUCT makes them executable via SPARQL endpoint. Multiple INFERs form a rule set, which needs to conform to the 1.2 rule spec. This would retain the SPARQL aspect and also fit into the rules spec as it is now, with the exception of the limitations (SET, ...) that we introduced. One final note is that i would not put it into the 1.2 sparql spec, because INFER is not part of the SPARQL spec. I would prefer to leave it in the rules spec. We can have references between both. They are both part of the SHACL ecosystem. |
|
Basically, the .srl format can support RULE/INFER/whatever as long as it remains compatible to sh:SPARQLRule by simply exchanging the RULE/INFER keyword with CONSTRUCT. There is no need for a new RDF syntax in the SRL document. All SRL sh:SPARQLRules can be handled by a generic SHACL SPARQL engine. Best of both worlds, as Robert says. |
|
Ping @afs - Robert has asked you direct question above. I am also interested in your response. |
There is an assumption being made that each individual SRL rule is written and treated independently but that is not the case. It is now less of possibility because of new SHACL rules evaluation algorithm - to calculate that, needs all the rules given together to SRL. Also, it might be natural to have two or three rules together because that make sense together (e.g. enhanced "property paths"). I think designing so that there is a "good enough" translation to SHACL Rules using CONSTRUCT is better. In reality, it's "translations", not a fixed one rule to one CONSTRUCT e.g. choosing SHACL Rule run-once, not just on the SRL condition, but in combination with knowledge of the data. Another possibility is converting, by algorthm, not be hand, several rules to one (possible complex!) SPARQL query gives the SPARQL engine room to optimize. |
No such assumption is made. Where do you see this? The SHACL rules algorithm also gets a set of rules as input (via the shapes graph) and those don't change.
Yes, and what does this have to do with the syntactic differences between CONSTRUCT and RULE?
You are not giving any reasons why the translation approach is better. or In both cases the engine can compile the strings into exactly the same internal data structure and then run the stratification algorithm on that structure. Likewise, an engine can reshuffle such data structures to optimize them, e.g. combine multiple rules into one. All this works for either RULE or CONSTRUCT.
See above, this has nothing to do with the chosen surface syntax. |
|
@afs The SET vs BIND issue seems to be the main stumbling block in converting between SRL and SPARQL CONSTRUCTs. Also, having an error-safe variant of BIND may be of general interest for other SPARQL languages. In case the RDF 1.2 still has time, wouldn't it be ideal if something like SET is added to SPARQL 1.2 itself? It looks like a simple copy-and-paste addition, e.g. allow SET (expr AS ?var) as an alternative to BIND (expr AS ?var). Once we are there, what is the reason that you have preferred := over AS? That feels inconsistent and was pointed out by external feedback too. Finally, was the discussion about the SPARQL-RL name in the RDF WG recorded/scribed somewhere? I am curious what people said. |
I think it's here https://www.w3.org/2026/08/06-rdf-star-irc Vetos and formal objections are mentioned. The usual suspect. |
|
Why is it a stumbling block? (My system runs the SRL test suite with several different execution engines, including some translating to SPARQL.) The semantics of |
|
I see the only stumbling block in that we need to use two lines to map SET to BIND+FILTER, and there are multiple syntactic variations. For example, someone may use To work around this, I guess we can get away with saying that the expected pattern is where the FILTER follows immediately after the BIND. Anything else would not be recognized when translating from SPARQL CONSTRUCT to SPARQL-RL. On the AS syntax question, the point about unbound vars may be clear to you, but you are not exactly a normal end user. Even I as a very advanced SPARQL user didn't intuitively connect that AS is only used for cases with potentially unbound variables. I still think the := syntax is an unfortunate choice that is an unnecessary obstacle in the translation. For example, people working with SPARQL CONSTRUCTs to test queries and then wanting to convert them into SRL format will need to move more stuff around. Copy and Paste is just getting harder IMHO. |
Uh oh!
There was an error while loading. Please reload this page.
Note
This report and consolidation was done with the help of AI. [18th of July, 2026]
A comprehensive overview of the last month (≈ 11 June → 18 July 2026)
Table of contents
FOR ?v IN <shape>(#1074) the missing piece Holger wants?1. Executive summary
The SHACL 1.2 Working Group is running two parallel, competing rule tracks, and the last month is the period in which that competition became explicit, technical, and — briefly — personal.
Track A — SRL (the "Shape Rules Language"), championed by
afs(Andy Seaborne, Apache Jena). A brand‑new, standalone rule language with its own compact text grammar (RULE {…} WHERE {…}/IF {…} THEN {…}), its own RDF encoding, and a full formal semantics based on solution mappings + stratification that guarantees terminating, order‑independent, deterministic output. Lives in theshacl12-rulesdraft. Deliberately does not require a SHACL engine to run.Track B — SHACL‑SPARQL Rules, championed by
HolgerKnublauch(TopQuadrant, original SHACL‑AF author). The revival of the older SHACL‑AF rules: RDF‑encodedsh:rule→sh:SPARQLRule→sh:construct(a full SPARQLCONSTRUCTquery), attached to shapes, targeted via$this, ordered manually withsh:order. Merged into theshacl12-sparqldraft via PR #766: Added SHACL-AF rules to SHACL-SPARQL #984 on 2026‑07‑17.The flashpoint was naming and identity (issue #939, "Why SHACL rules?"). It culminated in Holger's framing issue #1073, "SPARQL‑Full vs SPARQL‑RL" (opened 17 July, still open) — the live head‑to‑head — while
afs's #1072 (sh:srlRuleSet) and #1074 (FOR ?v IN <shape>) are the concrete bridge proposals.The good news for common ground: the two are technically complementary, not mutually exclusive — one is an expressive/imperative SPARQL layer, the other a tractable/declarative layer — and there are already three concrete bridge mechanisms on the table (
FOR ?v IN <shape>in #1074,sh:srlRuleSetin #1072, and a CONSTRUCT→SRL translation in the earlier non‑normative PR #879). The disagreement is less "which one wins" than "do they live in one document or two, and does either have to embed the other."2. Technical grounding
Understanding the fight requires understanding that these are genuinely different artifacts, not two syntaxes for the same thing.
2.1 What SRL (Shape Rules Language) is
A standalone rule language with its own text grammar, its own RDF encoding (SRL/RDF), and its own formally defined declarative semantics. From
shacl12-rules/index.html: "SHACL Rules provides inferencing with the generation of new RDF data from a combination of a set of rules and a base data graph. Rules can be expressed as RDF or in the Shape Rules Language (SRL)." It defines two operations: infer (apply a rule set to a base graph, produce an inference graph) and query (determine whether a goal pattern is derivable).RULE iri? HeadTemplate 'WHERE' BodyPatternandIF BodyPattern 'THEN' HeadTemplate. A document (RuleSet) is a prologue (BASE,PREFIX,VERSION,IMPORTS) then a sequence of rules andDATA { … }blocks. Media type currently trending toapplication/sparql-rules(SRL Media Type registration root #921); file extension.srl.~reifier,{| … |}),FILTER,NOT { … }(negation‑as‑failure, restricted to triple patterns + FILTER, no nesting), andSET(?v := expr)(assignment; an eval error drops the solution, unlike SPARQLBIND).*/+), noOPTIONAL, noCOALESCE/BOUND/hashes/RAND;NOW()frozen for the whole evaluation.GI.(run‑once, general). Run‑once rules (those with aSETassignment or a blank node in the head) fire exactly once per layer, preventing unbounded/nondeterministic term creation. General rules iterate to fixpoint. Dependencies are labelled open (plain triple dependency) or closed (throughNOT, assignment, or a blank‑node head). Stratification condition: no dependency cycle may contain a closed edge. If violated, the outcome is undefined. This guarantees "the same inference graph is produced regardless of the order of rule execution."FOR … IN <shape>, "SRL+FOR", FOR ?v IN <shape> #1074) or a framework integration (Addsh:srlRuleSetto the SHACL Rules Framework #1072).2.2 What SHACL‑SPARQL Rules is
The RDF‑vocabulary rules framework ported from SHACL‑AF, with SPARQL
CONSTRUCTas the one concrete rule type. Not a new language; reuses SPARQL and the SHACL shape/target machinery. Fromshacl12-sparql/index.html(the section added by PR #984):sh:ruleon a shape; the shape's targets supply focus nodes;$thisis pre‑bound to each focus node.sh:condition(focus node must conform first),sh:order(manual ordering, default 0),sh:deactivated,sh:entailment sh:Rules(regime a shapes graph declares so a validator runs rules).MINUS, MUST NOT have aVALUESclause mentioning a pre‑bound variable, MUST NOT useAS ?varfor a pre‑bound variable, SHOULD NOT useSERVICE.2.3 Side‑by‑side
sh:rule/sh:SPARQLRule/sh:construct); port of SHACL‑AF; delegates to a SPARQL enginesh:order; same‑order inferences not mutually visibleSETrules are run‑once per layerBIND/blank nodes as in SPARQL CONSTRUCT; no run‑once concept*/+*/+COALESCE/BOUND/hashes;NOW()frozenFORextensionsh:condition,$thispre‑boundSERVICE) — afs's multi‑tenant security argumentSERVICEcall‑outBottom line: SRL trades full SPARQL expressiveness for a formally‑defined, order‑independent, terminating semantics and a self‑contained execution model. SHACL‑SPARQL Rules keeps full SPARQL CONSTRUCT expressiveness and native SHACL target/condition integration, but its multi‑round semantics are explicitly under‑specified, relies on manual
sh:order, and inherits SPARQL's pre‑binding restrictions.3. The camps
Camp H — "SHACL‑integrated / SHACL‑AF continuity" (HolgerKnublauch)
Author of SHACL‑AF; ships it commercially (TopBraid). Aligned with
nicholascaron naming precedent;liviorobaldoshares his desire to attach rules to shapes but sides with afs on formal safety.Core requirements/beliefs:
shnex:conformsToShape, Add function to check conformance of a node (shnex:hasShape,shnex:conformsTo) #964/#964: Added shnex:conformsToShape #972), temporary triples (SHACL-SPARQL Rules should support temporary triples #995), matching all instances of a class incl. subclasses (How to match all (SHACL) instances of a class in Rules? #961).Camp A — "SPARQL‑family / layered standalone" (afs)
Editor of the
shacl12-rules/SRL draft. Implementation corroboration fromrubensworks(prototype on the Comunica SPARQL engine) andsimonstey(implemented theFORextension + apy-srlpackage).Core requirements/beliefs:
sh:srlRuleSetto the SHACL Rules Framework #1072), stratification as the load‑bearing mechanism, clean grammar productions (PR Rules grammar upgrade #983), proper media‑type registration (SRL Media Type registration root #921), skolemized blank nodes (Use skolemization in blank node generation in head templates #1067).The third voice —
liviorobaldo(the decidability hawk)Doesn't fit either camp cleanly. Warns SPARQL‑based rules "may lead to infinite loops … and may also exhibit non-deterministic behaviour due to operators such as
NOT EXISTS" (PR #984, 9 Jul) and champions stratified run‑once rules — but also backs Holger's desire to attach rules to shapes/sets and supplies the technical rationale that stratification is inherently set‑level (#1072). The bridge personality.Editorial / process voices
TallTed(Ted Thibodeau): naming precision, version safety ("SPARQL 1.2 Rules" not "SPARQL Rules"), inclusivity of examples, and Code‑of‑Conduct guardianship.nicholascar: naming, related‑work section (Describe relation of Rules to previous W3C initiatives #967); argues in Update Profiles of SHACL #974 that Rules "won't present as a profile of a larger SHACL specification and should be removed" — an implicit tilt toward afs's standalone framing.mgberg: pragmatic reviewer who approved PR #766: Added SHACL-AF rules to SHACL-SPARQL #984 and extracted most spec‑gaps into follow‑up issues.caribouW3: W3C staff contact, who stepped in to de‑escalate Why *SHACL* rules? #939.simonstey: implementedFOR ?v IN <shape>andpy-srl; author of the Evaluation of parameterized rules #781 proposal that FOR ?v IN <shape> #1074 promotes.robsyc: outside observer who opened Why *SHACL* rules? #939.4. The core disagreements
4.1 One document or two? (the naming war — #939). Holger wants a single unified "SHACL Rules" document and proposes renaming SRL to "RDF Rules". afs counters "'RDF Rules' is too broad" and wants "SPARQL (1.2) Rules" as a SPARQL‑family document. TallTed insisted on a version number. This is where it turned personal (see §7.1 transcript).
4.2 Full SPARQL vs a tractable subset (#1073). Holger's OWL analogy: SPARQL‑Full (expressiveness) vs SPARQL‑RL (soundness), positioned as complementary. afs rejects the subset framing: "the relationship isn't -Full vs -RL in the OWL restriction sense… SRL can express UNION and OPTIONAL, and has more powerful property path expressions." They further disagree on whether SRL truly "runs backwards" and whether SRL needs a
TRANSITIVEkeyword.4.3 Termination semantics (#1069). afs presses the non‑terminating blank‑node case (
CONSTRUCT { [ ] :p :o } WHERE { ?s :p :o }). Holger: "treated like programming errors." Unresolved.4.4 Framework integration (#1072). afs proposes
sh:srlRuleSet. Holger questions the point (see §7.4). Consensus it shouldn't be typedsh:SPARQLRule; open debate on predicate vs type dispatch.4.5 RDF‑native encoding vs compact text (#954). Holger wants a single
srl:textstring (like SPIN'ssp:text); afs wants the engine‑buildable triple form. Closed as moot after #984.4.6 In‑language rule management (#956/#962/#982). Holger wants per‑rule
sh:deactivated; afs deems it "like commenting out one function in a codebase without checking the code still builds" and ‑1'd the PR (#982).6. Analysis: is #1074 the missing piece?
Question: could
FOR ?v IN <shape>(#1074) be the thing Holger thinks is lacking/missing in SRL?Answer: Yes — for the single requirement Holger cites most often, and by his own explicit statement — but it is necessary, not sufficient, for full reconciliation.
6.1 What #1074 is
afsopened #1074 on 2026‑07‑17 by promotingsimonstey's proposal from #781. It adds a rule‑level targeting clause to SRL:FOR ?v IN <shape>ties a single rule to a SHACL shape so it fires only for the shape's target focus nodes that conform to the shape, with an author‑named focus variable pre‑bound. The proposal is explicit that it is "an evolution of SHACL‑AF'ssh:rule+$this, refitted to current SRL semantics (solution mappings, stratification, run‑once/general layers)." The full formal proposal is reproduced in §6.2.6.2 The proposal in full — abstract syntax, grammar, evaluation, stratification
(Reproduced from the #1074 body; this is the material abridged in the transcript at §7.3.
Sis the shapes graph,Gthe current data/inference graph.)Placement. The clause is a rule‑level prefix, sitting between the rule keyword (and its optional IRI) and the head template. It is not a rule‑body element — the spec‑pure body grammar (triple patterns,
FILTER,NOT,SET) is untouched. Both concrete rule forms accept it:?thisis the focus variable → author‑chosen, any name. It is bound to each conforming focus node before the body runs, so it may appear in the body and the head.ex:AdultShapeis a SHACL shape resolved against a separately supplied SHACL shapes graph.Abstract syntax. Extend a rule with an optional targeting pair
(v, s)wherevis a variable (the focus variable) andsis an IRI (the shape). A rule carrying a targeting pair is a targeted rule; one without is an ordinary rule (unchanged).direction ∈ {rule-to-shape, shape-to-rule}records which surface expressed the attachment; both normalize to the same evaluation. (The proposal flags this as possibly over‑engineered — it "could be scrapped by choosing one direction only.")Concrete syntax (EBNF). The spec's current productions (verbatim):
The extension inserts one optional production and threads it into both forms:
Varandiriare the spec's existing terminals. Nothing else in the grammar changes — in particularBodyPattern,BodyNotTriples,Filter,Negation,Assignmentare untouched.Evaluation semantics. Let
focusNodes(s, S, G)be the set of focus nodes selected by shapes's targets, andconforms(n, s, S, G)the boolean conformance of nodentos. Define the eligible set:A targeted rule
(R, v, s)contributes, to the inference, the union over everyn ∈ F(s)of the head instantiations ofRevaluated with the body's initial solution sequence seeded to a single mapping binding the focus variable:This is the only departure from the spec's global rule, which starts from the sequence containing just the empty mapping
μ0:vis a conforming target ofs" and whose free occurrences ofvare pre‑bound.FOR v IN sbehaves as if a virtual, non‑expressible body elementTARGET(v, s)were prepended, producingSEQ0 = { {v ↦ n} : n ∈ F(s) }.FILTER,NOT,SET, head instantiation, blank‑node freshness per mapping — is the standard rule machinery, unchanged.Decoupling (why this doesn't force SHACL into the engine). The proposal "say[s] nothing about where or how
F(s)is computed. In particular it does not require the shapes graph, the data graph, and the rule engine to share a process or a machine." BecausefocusNodesis a union of triple‑pattern / property‑path queries andconformsis a bounded query over a node's neighbourhood, a conforming processor is free to:F(s)in‑process over an in‑memoryG; orF(s)down to a SPARQL endpoint or a remote triple store holding a very largeG.(This is afs's answer to his own #1073 security concern: targeting need not be a server‑side "call‑out" — it can be a client‑side query.)
Stratification. Targeting adds a gate — "
vconforms tos" — that reads the graph. SoF(s)must be frozen before the targeted rule fires, or its verdicts could shift mid‑iteration and the rule might never converge.G— it may admitsh:not,sh:maxCount,sh:xone,sh:uniqueLang,sh:maxListLength,sh:uniqueMembers. Convergence comes instead from the stratification gate.NOT/SET/ blank‑node dependency) runs from the targeted rule to any rule whose head can assert a predicate the shape reads — its target predicates plus its constraints' predicates. This places the targeted rule strictly above those rules.F(s)stays constant for the duration of the targeted rule's stratum (SEQ0doesn't move), so the wrapped rule iterates to fixpoint exactly like an ordinary rule. Monotonicity ofconformsis therefore not required for termination.Worked example. Shapes graph —
ex:AdultShapewithsh:targetClass ex:Person, requiringex:age ≥ 18:Rule:
Data:
Evaluation:
focusNodes(ex:AdultShape) = {Alice, Bob}(bothex:Person).Aliceconforms (30 ≥ 18) → the rule fires with?this ↦ Alice, inferringex:Alice ex:status ex:adult.Bobfailssh:minInclusive 18→ the gate skips him, no triple. And "if a plain rule first infersex:agefor a node, proper stratification places the targeted rule in a higher stratum so its gate sees the inferred age."6.3 Why it maps onto Holger's stated requirements
Holger's requirements, in his own words, and how #1074 answers them:
FOR ?v IN <shape>is the shape↔rule link.INSTANCEOF(#961, 25 Jun)sh:targetClassin the referenced shape already matches instances (incl. via SHACL target machinery); the conformance gate handles filtering. Holger himself agreed in #961, 26 Jun: "the parameterization should address most of the problems here … having general support for all targets sounds good and SHACL‑friendly."The decisive quote. In #939, 15 Jul Holger stated that restoring shape↔rule linking would dissolve his naming objection:
So by Holger's own framing, the "ability to link between shapes and rules" is exactly the thing whose absence made SRL "not a replacement for SHACL‑AF rules" and drove the naming war. #1074 supplies that ability.
6.4 What #1074 does not resolve
It is necessary but not sufficient:
FORclause would need a defined RDF encoding to satisfy this. Not yet done.FORadds targeting, not full SPARQL,OPTIONAL/UNIONsugar, transitive paths, or aggregates. Holger's "assembly vs higher‑level language" complaint stands.7. Common‑ground proposal
Grounded in the actual arguments each side made, here is a synthesis that gives both camps their non‑negotiables. It is essentially the "OWL profiles" resolution adapted to rules.
7.1 Adopt a three‑layer "SHACL Rules Framework" architecture
Reframe the space as one framework, two homogeneous profiles, optional bridges — close to what afs already proposed in #1072 and what Holger's OWL analogy in #1073 implies.
sh:rule), targeting,sh:condition,sh:deactivated, pre‑binding, and the optional temp‑triple cleanup. This answers Holger's "meaningfully linked to other SHACL definitions" requirement and afs's "is it required for compliance to SHACL 1.2?" question.$this, imperative ethos; its own conformance level so an implementer can support it without SRL.sh:srlRuleSet(Addsh:srlRuleSetto the SHACL Rules Framework #1072) lets an SRL set act as one framework rule when you want SHACL targeting;FOR ?v IN <shape>(FOR ?v IN <shape> #1074) adds targeting inside SRL; PR feat: Add migration guide and patterns for transitioning from SHACL-AF to SHACL 1.2 #879's CONSTRUCT→SRL translation lets simple SPARQL rules gain SRL's defined ordering.7.2 Settle naming with the version number TallTed and scott flagged
sh:SPARQLRulelegacy; usedfn local-lt="SPARQL Rules"so the short form resolves cleanly).application/sparql-rules(afs's SRL Media Type registration root #921 direction), keeping "SRL" as the short form afs prefers while the long form ties it to the family.This gives Holger a "SHACL Rules" umbrella that is about SHACL, gives afs a standalone SPARQL‑family language, and gives TallTed his version safety.
7.3 Resolve the open technical issues so both are served
FOR ?v IN <shape>as the shared targeting mechanism both converged on — and get Holger's explicit yes/no to simonstey's Addsh:srlRuleSetto the SHACL Rules Framework #1072 question first, since that single answer determines whether the naming fight is even still live.sh:tempTriple true) + optional cleanup step.sh:deactivatedat the framework level (afs's preferred home) so it works for both profiles — resolving the #954 and #962: Added example for sh:deactivated and srl:text #982 veto.TRANSITIVEkeyword /*for backward‑chaining (Holger's own suggestion) to blunt the "assembly vs higher‑level language" objection without abandoning stratification.7.4 The one decision the WG must actually make
The genuine either/or no synthesis can paper over is #1073's implicit question: do SPARQL‑Full and SPARQL‑RL rules ever share a rule set/graph? liviorobaldo argues emphatically no ("a single set should contain either SHACL 1.2 rules or SHACL‑SPARQL rules, but not both"), because you cannot stratify a set containing unbounded SPARQL. The cleanest common ground is to make that a hard rule: a rule set is homogeneous (all SRL or all SPARQL), and heterogeneous composition happens only at the framework level via
sh:order/sh:entailmentlayering (Holger's own suggestion in #1072). That preserves SRL's guarantees while letting a pipeline chain an SRL stage and a SPARQL stage.7.5 Why this addresses everyone's concerns
FOR/sh:srlRuleSetrestore shape linkage; Profile 1 is SHACL‑AF; framework ownssh:rule/sh:deactivated; SPARQL profile keeps full expressivenessComprehensive reference list
Open issues (in scope): #939 (naming/identity), #1073 (Full vs RL — the crux), #1072 (
sh:srlRuleSet— the unification mechanism), #1074 (FOR ?v IN <shape>— targeting bridge), #1071 (unattached rules), #1069 (iteration semantics), #1067 (skolemization), #996 (failure handling), #995 (temporary triples — near consensus), #967 (related‑work section), #964 (shnex:conformsToShape), #960 (default triples /NOT DATA/WHERE DATA), #932 (rule‑dependency editorial), #930 (running example), #921 (SRL media type), #974 (profiles listing). Open and central: #781 ("Evaluation of parameterized rules", @afs, opened Feb 2026 — the origin of #1074; @HolgerKnublauch referred to it as "POSTPONED" in his June #961 comment, but it currently carries only theSRLlabel).Closed issues (resolved or conceded, but they document requirements this framework must honour): #954 (head/body triples — #954 (comment)), #955 (keyword
RULE/INFER— #955 (comment)), #956 (URIs for rules), #957 (shnex inference), #961 (match all instances — #961 (comment)), #962 (deactivation — #962 (comment)), #929 (naming convention), #933 (if all of), #997 (CONSTRUCT WHERE {}), #917 (media‑type params). Predecessors: #766/#765 (bringing SHACL‑AF rules in).PRs: #984 (merged — SHACL SPARQL Rules), #983 (merged — SRL grammar upgrade), #952 (merged — SRL semantics), #941 (merged — well‑formedness/negation), #976 (open — SRL working copy), #982 (open —
sh:deactivated/srl:textexample, currently ‑1'd), #977 (closed — superseded by #982), #879 (open/draft — "Add migration guide and patterns for transitioning from SHACL‑AF to SHACL 1.2", @simonstey; the non‑normative migration/cookbook @afs pointed to in #939 as the CONSTRUCT→SRL evolutionary path), #793 (merged Feb 2026 — "Added infer() and query() among the definitions"; defined the SRLinfer/queryoperations).Motivating comments (the through‑line):
sh:srlRuleSetto the SHACL Rules Framework #1072 (comment)sh:srlRuleSetto the SHACL Rules Framework #1072 (comment)sh:entailmentlayering for stacking: @HolgerKnublauch, Addsh:srlRuleSetto the SHACL Rules Framework #1072 (comment)sh:srlRuleSetto the SHACL Rules Framework #1072 (comment)All reactions