Handling of SHACL-AF rules

[afs]

What should we do with SHACL-AF Rules?

Options include:

1. Leave alone
2. Incorporate (some of) them into the SHACL 1.2 Rules document

The AF Rule types:

• AF Triple Rules
• AF SPARQLRules
• AF Property Value Rules -- already in SHACL 1.2

See also:

• Attaching rules to shapes #765
• Difference between SHACL RULE and SPARQL CONSTRUCT? #516

[HolgerKnublauch]

I would leave them alone. Most use cases are covered by either sh:values or the new SHACL 1.2 Rules (which basically cover sh:SPARQLRules). I don't think sh:TripleRules were used much.

[afs]

I would leave them alone.

OK - let's have a default decision of not incorporating SHACL-AF rules.

For #765 we might use sh:rule if only because anotherNS:rule can be error prone as is differentiating between "rule" and "ruleset" when (common case) there is one rule.

[kvistgaard]

Here are some arguments in supprot for option (2), more specifically keeping sh:SPARQLrule in 1.2 (sh:TripleRule can be abandoned)

1. Protect the current investments in SHACL rules
2. Maintain trust in the SHACL specification, showing backward compatibility (I know SHACL-AF did not become a recommendation, sadly, but there was no viable alternative for inference rules, so, like RML, it became the de-fecto standard)
3. Re-usability. When rules are developed as SPARQL CONSTRUCT, and for some reason, it is decided that SHACL cannot be used, then all these rules can still be used with any SPARQL engine.
4. Inclusiveness: people who know SPARQL can write rules without additional knowledge

[veleda]

I agree with @kvistgaard . SPARQL CONSTRUCT is well-understood, well-tooled, and well used. Keeping sh:SPARQLRule in 1.2 preserves that continuity and lowers the barrier for adoption, since anyone comfortable with SPARQL can write rules instantly.

[ajnelson-nist]

A few other arguments for retaining SPARQL CONSTRUCT rules:

• (Building on @kvistgaard 's 4th note) Sometimes, knowledge of SPARQL is a shape editor's on-ramp for attaining functionality that could later be crafted with specific SHACL vocabulary. Before I'd learned much of SHACL, I already knew enough SPARQL to write SELECTs to validate specifications I later realized could be done with simpler just-SHACL constraints.
• The first SHACL spec provided SPARQL implementations of constraints. These were another way I personally had learned some of the less-obvious constraints' nuances.
  • I'll note I am not suggesting this be done again, as I'm not one of the people editing those documents; but, it might be helpful if someone has the time.
  • I'm also split on whether it'd be helpful or painful to see SPARQL CONSTRUCT and Rules syntax side-by-side.

[afs]

since anyone comfortable with SPARQL can write rules instantly.

I would hope that anyone that can write SPARQL will find the SHACL Rules Syntax natural.

A RULE is like CONSTRUCT with restrictions to make it predictable for repeated application.

[MathiasVDA]

I would like to voice my support to keep SPARQL rules in SHACL (option 2).

I'm working at a railway infrastructure manager, building a knowledge graph for their infrastructure model. For that we are doing a two step process:

1. mapping from source systems
2. infer new triples from the mapped data

That second step is currently done using SPARQL insert/delete.

We have on our roadmap to convert this into SHACL rules as it would allow us to add more data lineage information and other things. Since everything is currently SPARQL, the first step would be to convert everything using SHACL SPARQL rules.

But actually, I think the first two reasons of Ivo should already be sufficient (protect current investment + maintain trust)

[HolgerKnublauch]

How different is the coverage of SHACL 1.2 Rules and SPARQL? If the differences are marginal, and rules are a decent subset of SPARQL, couldn't the parser just convert them to rules on the fly, i.e. so that sh:rule/SPARQLRule remains as syntactic sugar?

(I also agree that it's convenient to be able to copy and paste CONSTRUCTs from the query editor to the sh:rule field during development. Round-tripping is easier this way)

[afs]

SHACL-AF rule isn't going away. The vocabulary defined in SHACL-AF is being left alone, not redefined or repurposed. SHACL 1.2 Rule uses a different namespace.

There is a SPARQL-like syntax (SRL) as well as an RDF syntax. They are equivalent concrete syntaxes for an abstract syntax, and evaluation is defined by the abstract syntax.

I think the main uses of the RDF syntax are for manipulation and analysis of rules (cf. SPIN RDF).

SRL rules look very like SPARQL CONSTRUCT with the word RULE instead of CONSTRUCT.

There are limitations on the WHERE clause to ensure a rule set always evaluates to the same set of inference
triples, regardless of implementation. The WHERE is triple patterns, FILTER, (maybe) BIND, and negation-by-failure NOT.

RULE { ?x :childOf ?y } WHERE { ?y :fatherOf ?x }
RULE { ?x :childOf ?y } WHERE { ?y :motherOf ?x }

RULE { ?x :descendedFrom ?y } WHERE { ?x :childOf ?y }
RULE { ?x :descendedFrom ?y } WHERE { ?x :childOf ?z . ?z :childOf ?y }

# Default value - calculate a name
RULE { ?x :name ?FN } WHERE { 
    ?x rdf:type :Person 
    NOT { ?x :name ?someName }
    ?x :givenName ?name1 ;
       :familyName ?name2 .
    BIND(concat(?name1, " ", ?name2) AS ?FN)
}

NOT is a tamed form of NOT EXISTS - the NOT pattern is only triple patterns and FILTER.

The work on defining SHACL Rules is limited by time and resources. My priority is a solid foundation (syntax and evaluation). The current charter runs until the end of Dec '26. There is may well be a "maintenance and new features" activity after the working group charter ends which can add new features in a backwards-compatibility way but it requires the foundation to be in place.

[afs]

@kvistgaard, @veleda, @MathiasVDA, everyone,

Please do check your uses cases are covered and add use case if you think it's not adequately represented:

is:issue state:open label:Rules label:UCR

[afs]

@kvistgaard, @veleda, @MathiasVDA

A few questions to help understand the details:

• Which SHACL-AF implementation do you use?

• Do each of your rules "run once"?
  That is, the rule does not depend on other rules, only on the data graph.

• If they do depend on other rules, how do you complete rule evaluation (it's undefined in SHACL-AF)

• Do you attach SHACL AF Rules to shapes that do not have targets?

We have this issue discussing attaching rules to shapes -- #765

[MathiasVDA]

@afs Sorry I needed some time to study your comments and understand the situation better. As I said, my experience with SHACL-AF rules and the direction where SHACL 1.2 rules is going, is still very limited. I have some trouble seeing the path forward as well as the path backwards :)

The work on defining SHACL Rules is limited by time and resources. My priority is a solid foundation (syntax and evaluation). The current charter runs until the end of Dec '26. There is may well be a "maintenance and new features" activity after the working group charter ends which can add new features in a backwards-compatibility way but it requires the foundation to be in place.

I completely understand and support your position in this. I have an incomplete view and understanding of the priorities and am not able to contribute much beyond informing about my experience so that you can make a better informed decision. Whatever is decided to be a priority, I will support it.

As to answering your questions:

Which SHACL-AF implementation do you use?

I'm mainly working with maplib and they are nearly ready with implementing SHACL-AF rules. In the mean time Topbraid EDG SHACL. But as i said before, what I have in production are SPARQL UPDATE queries, not SHACL-AF rules (yet).

Do each of your rules "run once"?
That is, the rule does not depend on other rules, only on the data graph.

They run once but the result is merged with the data graph before other rules are run on it. Currently, there is an execution order in the queries to handle the dependencies. It is very very difficult to make them independent.

If they do depend on other rules, how do you complete rule evaluation (it's undefined in SHACL-AF)

I know there is the strategy of running all the rules multiple times until no further triples are added. Combined with some smart optimization of the rule order depending on the history, this is a viable strategy. Although I'll need to optimize my rules for this strategy to not have a big impact on performance.

I now have over 50 SPARQL UPDATE queries (each would be translated into multiple separate SHACL rules when we do), and maintaining the dependencies is already proving difficult. Not having to worry about dependencies would be best.

Do you attach SHACL AF Rules to shapes that do not have targets?
We have this issue discussing attaching rules to shapes -- #765

I went through the queries that we have now and I think everything can be attached to shapes with a target. Every rule is always about "start from here and do something with it".

I now have shapes for constraint validation and for UI generation (sparnatural). I was planning on having a separate set of shapes for rules. I'm not at the level yet where I can mix all SHACL use cases together and I'm not sure it would always make sense. In that way, I control when validation happens. Right now that's after inference. But I foresee SHACL constraint validation use cases that need to happen before as well as a way to validate source data.

Please do check your uses cases are covered and add use case if you think it's not adequately represented:
is:issue state:open label:Rules label:UCR

Looks like the most important use case for me that is missing (also in SHACL-AF), is a way to delete triples using rules. I will not be able to convert the DELETE SPARQL queries.