I still don't understand why the semantic of property paths is defined allowing different results for equivalent regular expressions.
In the previous reply, we pointed out that equivalences you describe are not part of the property path specification. The working group has reviewed your comments and has decided that the design in the published documents is the most appropriate design.
That design of property paths is a balance and needs to integrate in with the overall evaluation of a SPARQL query. I would stress that it is a balance - there are competing design dimensions that need to be resolved, in particular, fitting in with expectations driven by reading a property path expression as a short form of paths that can be written out in full without property paths. The working group feels that the expansion approach reduces implementation burden, exploiting implementation techniques used in SPARQL 1.0, and provides convenient shorter forms for BGPs that could be written out in full.
But I couldn't find any use case that motivates the semantics of "Property Paths" proposed in the SPARQL 1.1 draft document. In fact, in the second document there are only 3 simple examples that justify neither the need to define the semantics of "Property Paths" as it is done in the SPARQL 1.1 draft document, nor the need to have repeated mappings on the query result. Is there another document where I can find more detailed examples or use cases?
The "SPARQL New Features and Rationale" document is not a complete design for property paths; that is not the purpose of the document. The working group created the design through discussions within the working group as well as experience from existing systems. This is documented in the email archive for the working group, including discussions on test cases, especially around the operators for * and +.
We would be grateful if you would acknowledge that your comment has been answered by sending a reply to this mailing list.
Andy, on behalf of the working group.