Re: Comments about the semantics of property paths

Hi all,

given these results, wouldn't it be worth considering again to leave
property paths as an optional feature, outside of the main Query spec?
In addition to the computational complexity issue, I also still see it
as a  problem that there is no semantics defined for them in any of
the specs that are relevant for entailment regimes, i.e., when using
RDF(S) or OWL entailment. Normally one can rely on existing entailment
relations, but with property paths one no longer can do this. The
latter is not new information, but PPs seem a problematic feature more
than one reason.

An obvious problem of specifying PPs as an extra spec might be that
also Query has to undergo a third LC phase, which would be very
annoying.

I have a conflicting meeting today, so I am not sure yet which meeting
I should skip. I might only be able to be on IRC, but I am interested
in this, so it would be a shame to be able to discuss this.

Regards,

Birte

On 6 February 2012 22:52, Andy Seaborne <andy.seaborne@epimorphics.com> wrote:
>
>
> On 02/02/12 21:01, Axel Polleres wrote:
>>
>> To get the discussion going, my personal opinion on that one is as
>> follows:
>>
>>  a) I also think this is new and relevant information.
>>  b) I think it would be important to point to the fact that a naive
>> implementation
>>     of property paths may become very inefficient/blowing up on even
>> relatively harmelsssly looking examples, and that Property PATHs
>>     wrapped into DISTINCT subqueries can be evaluated more efficiently ...
>> I'd be even more than happy
>>     to point in an informal reference to their work, however I feel
>> honestly very uncomfortable with their
>>     title.
>>  c) As for their conclusion, proposing a default semantics that uses
>> distinct paths semantics,
>>     whereas a separate keyword ALL-PATHS would be indicating the current
>> semantics:
>>     it seems that (looking at their results in Section 7.1) that this is
>> orthogonally possible with our current semantics
>>     by just wrapping any TriplesSameSubjectPath containing a property path
>> into a DISTINCT subquery.
>>     It seems their result in section 7.1 indicates something along these
>> lines, but I need some help there:
>>     admittedly don't have a formal proof for this equivalence yet (to be
>> cautious, I am not yet 100% clear how/whether there is
>>     any interference possible with bnodes within TriplesSameSubjectPath
>> and duplicates coming from those bnodes)
>>
>> This all said, I unfortunately haven't had the time yet to check all their
>> claims in all detail.
>>
>> Axel
>
>
> I agree with your comment about the title.  To me, SPARQL 1.1 adds
> aggregation and grouping, and SPARQL Update, as the important features, more
> important than property paths.  In the extreme - if property paths don't
> find acceptance I think the evidence is already in that SPARQL 1.1 is being
> adopted; aggregation and grouping are drivers (as is SPARQL Update) IMO.
>  This reflects a difference of approaches - whether use case driven or
> theory driven.  We stated with a features and requirements analysis.
>
> The original property path design involved unique solutions (it had various
> problems) but even then the WG was concerned with the use of property paths
> to meet cases where duplicates matter.  There was also the matter of not
> obstructing path lengths.
>
> In our reply last time, we illustrated how duplicates are important in the
> presence of aggregation.
>
> We also pointed to the use of DISTINCT to remove duplicates by sub-query
> [1].
>
> Let's start this discussion by assuming that there are expensive path/data
> combinations and deciding if that is a major concern.
>
> On their investigation of ARQ - graph with large cliques are not something
> I've put any time into.  Uses cases are typically for short chains, and
> dealing with variability of connections.
>
> The order/component*/item example we gave last time is important - having
> aggregation work intuitively is something I think we need to weight highly.
>
>    Andy
>
> [1]
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2011Feb/0005.html
>



-- 
Jun. Prof. Dr. Birte Glimm            Tel.:    +49 731 50 24125
Inst. of Artificial Intelligence         Secr:  +49 731 50 24258
University of Ulm                         Fax:   +49 731 50 24188
D-89069 Ulm                               birte.glimm@uni-ulm.de
Germany

Received on Tuesday, 7 February 2012 14:39:44 UTC