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.