Inverse Property Value Rules

[tpluscode]

At the moment SHACL-AF only defines the shorthand syntax and behaviour of Property Value Rules when the path is an IRI

I think it should also be allowed to have property rules set on properties whose property is sh:InversePath. That can be trivially achieved by switching places of sh:object and sh:subject of the implicit triple rule:

8.5.2 Inverse Property Value Rules

Similar to [Property Value Rule](#8.5.2) but with `sh:object` and `sh:subject` reversed, 
that is for the implicit rule `T`:

- T sh:subject V
- T sh:object sh:this

[HolgerKnublauch]

Sounds plausible.

[tpluscode]

Would you accept PR, actually?

[HolgerKnublauch]

Have you implemented this and encountered problems? I do remember that I thought about this but didn't go there because that inverse case caused complications. I guess it is because they may produce "cycles" where inferring one "forward" value may later also infer an "inverse" value. Or, at the minimum, I didn't see enough value to include that feature, although from a symmetry point of view it would make sense.

What is your specific use case?

[tpluscode]

I don't remember exact details now but I found this missing when implementing a SPARQL Query generator

[HolgerKnublauch]

In my implementation of sh:path node expressions, the system will automatically "infer" properties that have a sh:values rule. If we were to add this for the inverse direction, it would at least complicate these cases. Unless there is a strong use case and evidence that this has a reasonable cost-benefits ratio, I would rather table this for a future WG.

[tpluscode]

I would rather table this for a future WG.

Fair enough

[HolgerKnublauch]

With Node Expressions directly used at sh:path, I believe this ticket can be closed, @tpluscode?

[tpluscode]

Can you point to an example of what you have in mind?

[HolgerKnublauch]

https://github.com/w3c/data-shapes/blob/issue-222-node-expressions/shacl12-core/index.html#L1640

What you are originally asking here assumes that there is a separate property that will be inferred (because sh:values was separate from the sh:path). Above these two are linked.

The SHACL inference rules spec may introduce a new property sh:alias or sh:inferredProperty that would materialize the derived properties. Maybe that could be inverse too and your ticket remains valid?

[tpluscode]

Hm, are we talking about the same? Here's an example of a valid Property Shape (as per SHACL-AF).

[]
  sh:path ex:foo ;
  sh:values ex:bar ;
.

Using a constant node expression, this translates to an inferred triples which looks like $this ex:foo ex:bar.

What I found missing, was to allow sh:path [ sh:inversePath ex:foo ] in a Property Value Rule to produce triples like ex:bar ex:foo $this