Initial content for 'Inference Rules'

[afs]

First pass at content for SHACL rules.

• See this document rendered online here

While this is a draft pull request, the important concerns are structure and design.

[HolgerKnublauch]

Great start! I am assuming there will be some (RDF) vocabulary like sh:rule that links those rules to shapes, so that the target mechanisms come into the mix?

[afs]

Great start! I am assuming there will be some (RDF) vocabulary like sh:rule that links those rules to shapes, so that the target mechanisms come into the mix?

That's the plan - it's in gist sketch.

Targets sh:targetClass (and its implicit form), sh:targetSubjectsOf and sh:targetObjectsOf are equivalent to triple patterns so make that syntax logically map to a generator of $this -- $this a :Class, $this :property ??, ?? :property $this -- and can be made to work for forward and backward implementation.

sh:targetNodes with node expressions may need limiting to the node expressions evaluated over the base graph, not triples currently being inferred. Node expressions are opaque as to what they depend on so backward chaining breaks and forward chaining can only work by blindly re-evaluating.

Similarly sh:target [ a sh:SPARQLTarget ; - though often that can be triple patterns.

So for regularity, maybe all targets should be "base graph only" generators of $this - run the rule once at the start of general evaluation.

[recalcitrantsupplant]

Following from https://gist.github.com/afs/2547eac679b1411acc078959ac2b3d31#attaching-rules-to-shapes

Is there intention/scope for parameterisation, e.g. with sh:parameter, or must all inputs be in the data graph or provided inline as facts with DATA?

Where do the parameters come from?

Not from the datagraph - the idea would just be to define what must be substituted prior to the rules being valid & executable. An implementation would then provide some mechanism to supply the arguments. In the example below I've made up sh:argument to define what needs to be substituted, and sh:argval for where it's substituted in the rule. So ex:city would need to be supplied prior to running the rule.

What a happens if a rule is applied multiple times?

I believe if the params must be substituted once at the start this would be safe (?)

ex:DensityRule
   sh:argument [ sh:path ex:city ; sh:nodeKind sh:IRI ] ;
   sh:rule [
       sh:head ( 
           [ sh:subject [ sh:argval ex:city ] ;
             sh:predicate ex:density ;
             sh:object [ sh:var "density" ] 
           ] 
       ) ;
       sh:body ( 
           [ sh:subject [ sh:argval ex:city ] ;
             sh:predicate ex:area ;
             sh:object [ sh:var "area" ]
           ]
           [ sh:subject [ sh:argval ex:city ] ;
             sh:predicate ex:population ;
             sh:object [ sh:var "pop" ]
           ]
           [ sh:bind [ 
               sh:var "density" ;
               sh:expression [ sparql:divide ( [ sh:var "pop" ] [ sh:var "area" ] ) ]
           ]]
       ) 
   ] .

[HolgerKnublauch]

What are the plans with the existing SPARQL-based rules from SHACL-AF? We do have some users and I guess some people will find it easier to incrementally use their SPARQL strings instead of the new syntax.

Related: are there any scenarios where SPARQL-based rules can express more than the new, native SHACL rules?

[afs]

What are the plans with the existing SPARQL-based rules from SHACL-AF? We do have some users and I guess some people will find it easier to incrementally use their SPARQL strings instead of the new syntax.

Isn't that a question of what your engine chooses to support? I hope there isn't a conflict anywhere.

Some AF-rules can lead to problems (e.g. a CONTRUCT can increment a number ... which, if repeated applied, is an infinite loop).

I believe the best approach is to define the inf-rules then look at the where AF features fit in.

Triple rules look like that can be mapped although we are now in the situation where there are multiple ways of doing that only one of which is inf-rules.

Related: are there any scenarios where SPARQL-based rules can express more than the new, native SHACL rules?

SPARQL-based rules can go bad and using order to control means its a question about current usage. I don't think that can be answered except by seeing some actual rules.

Could we have issues labelled them as "UCR" and "Inference"?

[afs]

some mechanism to supply the arguments

@recalcitrantsupplant - We seem to have multiple ways to achieve same/similar tasks. How do you see this fitting with sh:defaultValue?

[HolgerKnublauch]

I think I can live with just supporting them (SPARQL rules) in our platform even if the standard excludes them. I just wanted to get your opinion. No ticket needed on that.

A good sample use cases for your work would be to support OWL RL...

[afs]

A good sample use cases for your work would be to support OWL RL...

The rules are given:
https://www.w3.org/TR/owl2-profiles/#Reasoning_in_OWL_2_RL_and_RDF_Graphs_using_Rules
and also:
https://www.w3.org/TR/rif-owl-rl/

[HolgerKnublauch]

Yes, and I still have a SPIN version of that somewhere in the product code... Yet it would be awesome to have this as a community project.

[afs]

@robert-david, @simonstey, @recalcitrantsupplant --

How do you want to process with this? Do you think it needs more material before becoming the initial content, especially as that's going to be editor-draft-published to shacl12-inf-rules?

[ajnelson-nist]

@afs @HolgerKnublauch I'd posted #220 (well, the comment ported to that Issue) because of the ability of Rules to do inferencing. 220's about RDFS, but #219 gets into an in-common subset of inferencing specifications between RDFS and OWL-RL.

219 may be a better Issue to continue on the topic of whether there's an example RDFS or OWL-RL Rules set the working-group is interested in. Holger, I'm not sure what you meant by community project - something external to the data-shapes group, or instead produced by the data-shapes group?

[afs]

RDFS and OWL-RL are themselves defined by rules sets.

There may be better ways to implement than the usual published rules as been noted.

The proposed rule language has a TRANSITIVE declaration so that engines can, for example, implement transitive without general rules recursion or have custom implementation of transitive properties for efficiency. The other declarations are for inverse and symmetric properties.

At the moment, we don't have a document with the base fundamentals we can make an editors draft.

[HolgerKnublauch]

I have meanwhile created a SHACL-AF version of the OWL RL rules, all in SPARQL. This is based on earlier work that I did for SPIN in TopBraid Composer. If anyone is interested I can send a copy.

[recalcitrantsupplant]

@robert-david, @simonstey, @recalcitrantsupplant --

How do you want to process with this? Do you think it needs more material before becoming the initial content, especially as that's going to be editor-draft-published to shacl12-inf-rules?

4.1 could be cleaned up perhaps - I'm not sure what all of the things there are referring to.
Otherwise, these two topics come to mind but as I understand the process they do not need to happen prior to publishing a draft(?):

1. stratification
2. parameterisation similar to the questions in Support User-Defined Node Expression Functions; Parametrization, "Partial Evaluation" #498

Would it be worth the editors meeting now to discuss these and any other sections?

[simonstey]

Given we introduced shnex as prefix for all things node expressions, and (for now) shnex-sparql do we want/should have a dedicated prefix for rules as well?

[simonstey]

@afs

@robert-david, @simonstey, @recalcitrantsupplant --
How do you want to process with this? Do you think it needs more material before becoming the initial content, especially as that's going to be editor-draft-published to shacl12-inf-rules?

It would certainly benefit from at least an initial Introduction draft. Primarily, to clarify how this document relates to the other specs (core, node-expr in particular) and what it aims to achieve.

Other than that, I think it's in a very good initial state and (imo) can be published as a first draft to get it into the "publishing cycle".

[afs]

Given we introduced shnex as prefix for all things node expressions, and (for now) shnex-sparql do we want/should have a dedicated prefix for rules as well?

Yes - introducing shnexpost-dates this content. shnex-sparql is new to me.

[afs]

It would certainly benefit from at least an initial Introduction draft. Primarily, to clarify how this document relates to the other specs (core, node-expr in particular) and what it aims to achieve.

Other than that, I think it's in a very good initial state and (imo) can be published as a first draft to get it into the "publishing cycle".

@simonstey - are you saying that an introduction is required in your opinion before merging to gh-pages?

[afs]

4.1 could be cleaned up perhaps - I'm not sure what all of the things there are referring to.

Made into editors notes.

[afs]

1. stratification
2. parameterisation similar to the questions in Support User-Defined Node Expression Functions; Parametrization, "Partial Evaluation" #498

Would it be worth the editors meeting now to discuss these and any other sections?

Yes - a meeting would be a good idea.

[TallTed]

My tweaks thus far are done.

I think we'll need a better wording for exactly one of subject - predicate - object, per body of head element, possibly starting from exactly one each of subject, predicate, and object, per body of head element...

[simonstey]

@afs

It would certainly benefit from at least an initial Introduction draft. Primarily, to clarify how this document relates to the other specs (core, node-expr in particular) and what it aims to achieve.
Other than that, I think it's in a very good initial state and (imo) can be published as a first draft to get it into the "publishing cycle".

@simonstey - are you saying that an introduction is required in your opinion before merging to gh-pages?

no, but it would certainly benefit from having one.

maybe something along the lines of:

Introduction

This document introduces the concept of Inference Rules for SHACL 1.2, a mechanism for deriving new RDF triples from existing data using declarative rules defined in shapes graphs. This extends SHACL’s capabilities beyond validation, enabling reasoning and data enrichment.

This document complements other SHACL 1.2 specifications, such as SHACL Core, by defining the syntax and semantics of rule-based inference. While SHACL Core focuses on constraint validation, the Inference Rules specification provides a standardized way to express and evaluate rules that generate new data.

[afs]

@simonstey - thanks - I'll put that text in.

We have to find a way to position rules. For me, Core is closely tied to "constraints" (history) whereas there is a larger "shapes" concept and rules is a new area.

[HolgerKnublauch]

Right, the positioning is important. Node expressions and sh:values in particular can also be used to derive new triples, so this is not unique for the rules spec.

The core spec has this intro section on relationship to RDFS and entailment regimes, and that should certainly point at the rules work.

[afs]

@HolgerKnublauch - question for you.

Do sh:values and sh:defaultValue provide anything that can not be written in rules (ignoring the fact that it may be unnatural and burdensome to write it that way)?

[HolgerKnublauch]

If rules can execute arbitrary node expressions then I don't see why they couldn't cover everything. In our own platform we have some algorithms that perform both types of inferences together, e.g. to assert anything implicit.

The values nodes produced by sh:values and defaultValue are, however, used for constraint checking and to pre-populate forms.

[afs]

Not arbitrary node expressions in arbitrary position: ones that touch the data graph (NX style aggregates), ones that evaluate to lists with >1 member (unless used only as seeds) or whatever comes along in the future (it's a open world).

[TallTed]

Suggested change

	<li>exactly one of subject - predicate - object, per body of head
	element</li>
	<li>exactly one each of subject, predicate, and object, per body of head
	element</li>