CommentResponse:PropertyPathComments

Hello,

Thanks very much for your comment on the challenges of efficiently evaluating property paths given the current semantics. We have received several comments along these lines.

The Working Group agreed to adopt an alternative design for property paths that we believe balances several of our design goals:

• Use case expressivity
• Users' learning curve / intuition
• Ease of implementation
• Potential for efficient evaluation
• Schedule

The changes from the current Last Call working draft are as follows:

• The semantics of *, +, and ? are changed to be non-counting (they no longer preserve duplicates)
• The /, |, and ! remain unchanged as in the current draft (they preserve duplicates)
• The curly brace forms -- {n}, {n,m}, {n,}, {,m} -- have all been removed

There are several motivations for these design changes:

• Changing the semantics of * and + to non-counting is expected to address the evaluation performance concerns raised by your comment.
• The /, |, and ! operators are often used as shortcuts for writing out equivalent graph patterns longhand. By leaving these operators with counting semantics (just as the equivalent graph pattern expansions have), SPARQL 1.1 property paths will continue to yield intuitive results. Two examples that the Working Group has considered in coming to this conclusion are:

   SELECT (sum(?cost) AS ?total)
   {
     :order :hasItem/:price ?cost
   }

and

   SELECT ?member { ?list rdf:rest*/rdf:first ?member }

...when applied to a list with duplicate items, such as (1 2 1). (This type of query was one motivation for the property paths feature that the WG documented in the SPARQL 1.1 New Features & Rationale document: http://www.w3.org/TR/sparql-features/#Property_paths)

In both cases, users' intuitive expectations demands that '/' preserve duplicates.

• The group decided to remove the curly brace forms due to a lack of experience with appropriate counting/non-counting semantics for these forms. We believe that implementations will likely extend SPARQL 1.1 Property Paths with support for these forms, and we will gather implementation experience to use for future standardization work. We've included this item on a list of work items for a future working group - http://www.w3.org/2009/sparql/wiki/Future_Work_Items

We would be grateful if you would acknowledge that your comment has been answered by sending a reply to this mailing list.

Lee On behalf of the SPARQL Working Group