Support for the {n,m} form for property paths

[jerdebsp]

In SPARQL you can have a complex property path with the {n,m} form e.g ?otherClass (sh:property/sh:class){2,3} ?nodeShape . or the {n} form ?otherClass (sh:property/sh:class){2} ?nodeShape ..

Is it possible to add this to the SHACL property path for property shapes?

Thanks,
Jer

[HolgerKnublauch]

Yes I think this was requested by others too, and would potentially make sense for SHACL 1.2 for symmetry reasons with SPARQL alone.

[TallTed]

Note that the {n,m} property path notation is not in SPARQL 1.0 nor SPARQL 1.1. It was in a draft of SPARQL 1.1, and has been raised as potentially a part of a future SPARQL version. It has also been raised specifically regarding the SPARQL 1.2 specification now in development.

[VladimirAlexiev]

@jerdebsp Can you list some realistic use cases that use such a feature?

[ajnelson-nist]

Would these boundaries be implemented with extra predicates on the node that is the subject of sh:oneOrMorePath or sh:zeroOrMorePath? Or would a third predicate be used instead, something like sh:pathInRange?

[jerdebsp]

@VladimirAlexiev sorry I missed this notification! We used it to get a particular sub-graph starting from a node and we only wanted to traverse up to a particular number of hops. A simple example could be a family tree - I want to get only up to 2nd generation of people from this particular node.

@ajnelson-nist I think it should be sh:pathInRange because sh:zeroOrMorePath would be equivalent to {0,m} and the sh:oneOrMorePath {1,m}, we might want to do {4,7} for example. Most probably the hardest part would be how engines will implement this efficiently

Other possibility could be that instead of having functionality and predicates, we can have some abstract property that would need to have it's implementation plugged in the SHACL engine - similar to Jena's Abstract Functions. @HolgerKnublauch what do you think? That would ensure that the specs will only have what's commonly used, but on the other hand we can have additional predicates and functionality that can be shared (DASH comes into my mind - DASH + engine specific implementation?)

[HolgerKnublauch]

See 3. on #215 I suggest to generalize sh:path to allow any Node Expression. Then see if the existing node expression types are sufficient to express what you need here, otherwise add a new expression type.

[ajnelson-nist]

@ajnelson-nist I think it should be sh:pathInRange because sh:zeroOrMorePath would be equivalent to {0,m} and the sh:oneOrMorePath {1,m}, we might want to do {4,7} for example. Most probably the hardest part would be how engines will implement this efficiently

I'm willing to think out loud about the alternative to @HolgerKnublauch 's generalization-of-sh:path expression a little bit more. Hopefully seeing a potential implementation of the alternative written down will clarify whether generalized sh:path is the group preference.

@jerdebsp : I see a single predicate sh:pathInRange leading to introducing a step of grammar specification and string parsing for just this one property. E.g., which of these would be valid?

• [] sh:pathInRange '{4,7}' .
• [] sh:pathInRange '4,7' .
• [] sh:pathInRange '{-7,-4}' . (I could see people comfortable with Python's negative slice indexing advocating for this to suggest inverse paths.)
• [] sh:pathInRange '{-1,1}' .
• [] sh:pathInRange '{4,aaaaaaaaaaaa' .

I would prefer a pair of properties, with at least one being required to be provided. I'm not attached to these suggested property names.

ex:SomePropertyShape
  a sh:PropertyShape ;
  sh:path (
      [
        sh:zeroOrMorePath ex:a ;
        sh:atLeastPath 4 ;
        sh:atMostPath 7 ;
      ]
      [
        sh:oneOrMorePath ex:b ;
        sh:atLeastPath 0 ;
        sh:atMostPath 3 ;
      ]
    ) ;
.

We hadn't explicitly dived into it, but if this design were adopted, there's an argument for SHACL-SHACL being updated to flag that path component about ex:b with a sh:Warning about the lower bound of 0 being weird next to sh:oneOrMorePath.

Meanwhile, kind of a side note, I just thought of it while sketching the string examples - would the range of these properties need to be bounded to non-negative integers? I followed @TallTed 's link a bit, but didn't see number bounds specifically, unless they were bundled into the discussion on counting alluded to in SEP-0003 (current state linked).

[jerdebsp]

Yes I agree. Holger's suggestion is neat and less ambiguous

[ajnelson-nist]

@jerdebsp , I'm not as read up on the node expressions Holger had linked. Are you able to have a try at using that solution to model that weird property shape I'd done? I.e., adapting this SPARQL (purposefully avoiding {m,n}, since apparently that isn't yet a standard syntax)?

SELECT ?focus
WHERE {
#       1    2    3    4    5?    6?    7?    1?    2?    3?
  $this ex:a/ex:a/ex:a/ex:a/ex:a?/ex:a?/ex:a?/ex:b?/ex:b?/ex:b? ?focus .
}

[HolgerKnublauch]

I suggest closing this ticket. The use cases can probably be handled by sh:targetNode node expressions, and I see little appetite to change the sh:path syntax for a feature that isn't even in SPARQL 1.2

(We need to do house keeping on open tickets as the WG is bogged down right now)