Small bug in 18.5 Property Path Patterns

[jitsedesmet]

Hi all.

I was reading through 18.5 Property Path Patterns and I think it contains a small mistake.

Thereafter, the translation of property path patterns converts some of these algebraic property path expressions to other SPARQL graph patterns, such as converting property paths of length one to triple patterns, which in turn are combined into basic graph patterns. This leaves algebraic property path expressions with the operators ZeroOrOnePath, ZeroOrMorePath, OneOrMorePath, and NegatedPropertySets, as well as algebraic property path expressions contained within these operators.

I specifically think the list of "algebraic property path expressions" also contains ALT because 18.3.2.4 Translate Property Path Patterns does not mention any transformation of ALT.
(I tested this on the SPARQLAlgebra.js project and there I also see top-level ALT is still present after conversion)

[jitsedesmet]

I thus suggest the following:

This leaves algebraic property path expressions with the operators Alt, ZeroOrOnePath, ZeroOrMorePath, OneOrMorePath, and NegatedPropertySets, as well as algebraic property path expressions contained within these operators.

[Tpt]

Indeed. Thank you for spotting!

I think we need also to fix the definition of Alt evaluation is relying on Union even if ppeval is returning a set and not a multiset.

I would tend to be in favor of changing instead Translate Property Path Patterns to rewrite x alt(ppe1, ppe2) y into Union(Path(x, ppe1, y), Path(x, ppe2, y)). It looks more consistent to me with SPARQL that seems to rewrite path patterns to other operators as much as possible and this is not a breaking change because the existing definition of Alt is not doing deduplication.

[hartig]

Nice catch @jitsedesmet ! I agree with your proposed change.

@Tpt Where did you find that ppeval returns sets rather than multisets?
The "Notation" box in Section 18.5 Property Path Patterns says explicitly:

This produces a multiset of solution mappings, each solution mapping having a binding for variables used (each of X and Y can be a variable). Some operators only produce a set of solution mappings.

[Tpt]

@Tpt Where did you find that ppeval returns sets rather than multisets?

Indeed. my bad. Thank you for the correction.

In any case, it still seems like that the option of updating Translate Property Path Patterns to rewrite x alt(ppe1, ppe2) y into Union(Path(x, ppe1, y), Path(x, ppe2, y)) is still a possibility. If we do that I think that the root of the property path expression is ZeroOrOnePath, ZeroOrMorePath, ZeroOrOnePath or NPS, meaning that we can redefine ppeval to return a set if we want to.

[hartig]

In any case, it still seems like that the option of updating Translate Property Path Patterns to rewrite x alt(ppe1, ppe2) y into Union(Path(x, ppe1, y), Path(x, ppe2, y)) is still a possibility.

It is a possibility, but doing so would not add anything, because will need to keep the definition of Alt evaluation in any case.

If we do that I think that the root of the property path expression is ZeroOrOnePath, ZeroOrMorePath, ZeroOrOnePath or NPS, meaning that we can redefine ppeval to return a set if we want to.

I don't think that this would be trivial because several of the cases of the definition of ppeval are based on algebra operators that return multiset (such as the aforementioned definition of Alt evaluation, as well as the one of seq). Therefore, for a clean formalization, we would have to add some multiset-to-set operator. I think it is better to avoid that and simply implement the change proposed by @jitsedesmet

[Tpt]

Good point! Thank you! +1 to @jitsedesmet proposal