Re: summary on options for JP-4 Comment about the semantics of property paths

Just for completeness and not to forget:

Birte's mail [1] indicated that marking Property paths informative/non-normative could also be 
considered, also because of the things that remained unclear wrt. entailment regimes [2].

I'd rather call this a "variant" of Options 1-3, since this seems to be orthogonal...
We had discussed this briefly in the last Telco [3] but I have the feeling that the last 
word here has not yet been spoken. Opinion on marking PPs optional (i.e. informative)
would be appreciated.

It'd be great to collect more on that per email (thanks all for the useful discussion!) 
and we'will sum up in the upcoming Telco.

Just to get together where I understand we are now (also regarding the "numbering" of options): 

Option 1... keep everything as it is in the grammar, and explain which DISTINCT path subqueries can be optimized 
            (which in my understanding was, explaining the there was a set of query transformations that are 
             equivalent to the possible semantics in the paper)
Option 2... Option 2 ... add DISTINCT around paths (which could be argued to be optimized, agreed?)
Option 3... leave things as they are, and pointing to a future WG regarding optimization.

Variants of these Options could be marking PPs informative (we may call them Option1*-Option3*),

Axel

1. http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0128.html
2. http://www.w3.org/TR/sparql11-entailment/#property-path
3. http://www.w3.org/2009/sparql/meeting/2012-02-07#line0084

On 12 Feb 2012, at 11:14, Andy Seaborne wrote:

> 
> 
> On 11/02/12 16:55, Andy Seaborne wrote:
> > == Short version
> >
> > I can live with either option.
> >
> > I prefer option 2 when done properly but as things stand, I have to say
> > that I can't see option 2 + quick 3LC as viable.
> >
> > I've implemented, experimentally, a form of option 2. It's available to
> > all.
> 
>  >>Just leaving things as they are, and pointing to a future WG is
> another Option. Should we call it Option3?
> 
> My understanding of option 1 was that it was to leave things as they
> are, with editorial text to point that some property paths are expensive
> and that SELECT DISTINCT can be used to control this, but to claim there
> was a set of query transformations that are equivalent to the possible
> semantics in the paper.  This is what Axel is calling option 3 now [1].
> 
> Given Axel's clarification: I want to restate my current position:
> 
> I can live with option 2 or option 3.  Option 1 is tolerable but it not
> currently sufficient detailed to know whether it is viable.
> 
> Option 1 would be OK if there were a set of transformations but to work
> them out it seems we might as well do option 2.  The fact that option 1
> might avoid a LC seems less important if it needs time to formally
> define and then check the transformations and their consequences.
> 
>         Andy
> 
> [1] http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0149.html
> 
>

Received on Sunday, 12 February 2012 13:08:53 UTC