Chatlog 2012-03-27

See original RRSAgent log and preview nicely formatted version.

Please justify/explain all edits to this page, in your "edit summary" text.

13:58:53 <RRSAgent> RRSAgent has joined #sparql
13:58:53 <RRSAgent> logging to http://www.w3.org/2012/03/27-sparql-irc
13:58:55 <trackbot> RRSAgent, make logs world
13:58:55 <Zakim> Zakim has joined #sparql
13:58:57 <trackbot> Zakim, this will be 77277
13:58:57 <Zakim> ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 2 minutes
13:58:58 <trackbot> Meeting: SPARQL Working Group Teleconference
13:58:58 <trackbot> Date: 27 March 2012
13:59:05 <AndyS> zakim, this is 77277
13:59:05 <Zakim> ok, AndyS; that matches SW_(SPARQL)10:00AM
13:59:15 <AndyS> zakim, who is on the phone?
13:59:15 <Zakim> On the phone I see pgearon, [IPcaller]
13:59:22 <AndyS> zakim, IPCaller is me
13:59:22 <Zakim> +AndyS; got it
13:59:46 <cbuilara> cbuilara has joined #sparql
13:59:50 <AxelPolleres> AxelPolleres has joined #sparql
14:00:21 <AxelPolleres> trackbot, start meeting
14:00:23 <Zakim> +Olivier_
14:00:23 <trackbot> RRSAgent, make logs world
14:00:25 <trackbot> Zakim, this will be 77277
14:00:25 <Zakim> ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start now
14:00:26 <trackbot> Meeting: SPARQL Working Group Teleconference
14:00:26 <trackbot> Date: 27 March 2012
14:00:29 <SteveH_> SteveH_ has joined #sparql
14:00:40 <MattPerry> MattPerry has joined #sparql
14:01:43 <SteveH> Zakim, who's on the phone?
14:01:44 <Zakim> I notice SW_(SPARQL)10:00AM has restarted
14:01:44 <Zakim> On the phone I see pgearon, AndyS, Olivier_, +43.517.073.aaaa, kasei, ??P6
14:01:49 <AxelPolleres> agenda: http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0276.html
14:01:51 <SteveH> Zakim, ??P6 is me
14:01:51 <Zakim> +SteveH; got it
14:02:08 <AxelPolleres> chair: AxelPolleres
14:02:18 <Zakim> +MattPerry
14:02:31 <cbuilara> cbuilara has joined #sparql
14:02:55 <AxelPolleres> scribe: PaulGearon
14:03:02 <Zakim> +??P14
14:03:06 <AxelPolleres> Zakim, who is on the phone?
14:03:06 <Zakim> On the phone I see pgearon, AndyS, Olivier_, +43.517.073.aaaa, kasei, SteveH, MattPerry, ??P14
14:03:10 <cbuilara> zakim, ??P14 is me
14:03:10 <Zakim> +cbuilara; got it
14:03:16 <AxelPolleres> Zakim, aaaa is me
14:03:16 <Zakim> +AxelPolleres; got it
14:03:27 <AxelPolleres> Zakim, who is on the phone?
14:03:28 <Zakim> On the phone I see pgearon, AndyS, Olivier_, AxelPolleres, kasei, SteveH, MattPerry, cbuilara
14:03:41 <chimezie> chimezie has joined #sparql
14:04:16 <pgearon> AxelPolleres: goal for this week is discussing the further procedures for publications of the 3 docs coming up for last call
14:04:21 <AxelPolleres> topic: admin
14:04:39 <AxelPolleres> PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2012-03-20
14:04:56 <Zakim> +sandro
14:05:03 <AxelPolleres> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2012-03-20
14:05:30 <Zakim> +LeeF
14:05:36 <AxelPolleres> Next regular meeting: 2012-04-03 @ 15:00 UK / 10:00 EST  any regrets?
14:05:44 <Zakim> +chimezie
14:05:45 <AxelPolleres> regrets form axel
14:05:58 <chimezie> Zakim, mute me
14:05:58 <Zakim> chimezie should now be muted
14:06:24 <pgearon> AxelPolleres: news from the RDF WG?
14:06:24 <AxelPolleres> topic: rdf liaison
14:06:33 <AxelPolleres> working towards LC for turtle
14:06:44 <pgearon> AndyS: working towards LC for Turtle, nothing special
14:06:51 <AxelPolleres> agenda: http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0276.html
14:07:26 <AxelPolleres> topic: next publications
14:07:32 <AxelPolleres> subtopic: CSV/TSV
14:07:47 <pgearon> AxelPolleres: AFAICT we have the necessary reviews
14:07:59 <pgearon> AxelPolleres: ACTION 593 594
14:08:43 <pgearon> AxelPolleres: 593 was just completed today. 2 small issues that have been resolved. Have not yet checked the updates in 594, but that has been done
14:08:58 <pgearon> AndyS: ready to publish
14:09:23 <pgearon> kasei: yes, ready to publish
14:09:27 <AxelPolleres> PROPOSED: to publish CSV/TSV as LC
14:09:43 <kasei> +1
14:09:50 <chimezie> +1 IE
14:09:52 <AxelPolleres> +1 (siemens)
14:09:54 <AndyS> +1 ASF
14:09:55 <pgearon> +1 Revelytix
14:09:56 <MattPerry> +1 (Oracle)
14:09:57 <sandro> +1 W3C
14:09:57 <LeeF> aye
14:09:58 <Olivier> +1 INRIA
14:10:18 <AxelPolleres> Zakim, who is on the phone?
14:10:18 <Zakim> On the phone I see pgearon, AndyS, Olivier_, AxelPolleres, kasei, SteveH, MattPerry, cbuilara, sandro, LeeF, chimezie (muted)
14:10:35 <SteveH> +1 Garlik/Experian
14:11:21 <AxelPolleres> RESOLVED: publish CSV/TSV as LC 
14:11:30 <pgearon> AxelPolleres: date TBD
14:11:47 <AxelPolleres> 7 +1, no objections or abstentions
14:12:02 <AxelPolleres> subtopic: overview
14:12:24 <Zakim> +EricP
14:12:56 <pgearon> AxelPolleres: only managed yesterday to finish. Some small examples. Will not have time to work on this document any more
14:13:02 <LeeF> Probably!
14:13:08 <pgearon> AxelPolleres: Lee, can you do the review int he next week?
14:13:16 <AxelPolleres> Lee to review within the coming week.
14:13:40 <pgearon> AxelPolleres: more comments/questions on the overview doc? Else wait for review
14:13:48 <AxelPolleres> subtopic: query
14:14:14 <pgearon> AxelPolleres: resolution from last week, discussed in mail from kasei
14:14:20 <LeeF> In fairness, last week we did NOT discuss the ALLPATHS(...) option or the default semantics, so I think Greg's comments were well in order
14:14:31 <pgearon> AxelPolleres: could kasei summarize concern?
14:15:03 <pgearon> kasei: concerned with path speccing 2 semantics, and then providing syntactic preference for one over the other
14:15:09 <ericP> isn't the exhaustive semantics the default for the rest of query?
14:15:18 <AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0272.html
14:15:33 <pgearon> kasei: this is premature since we don't know which is the semantics that will be more desirable
14:15:34 <ericP> i'd expect that changing that default for one part of the language would be surprising for users
14:15:48 <LeeF> ericP, yes, which is why that was how our design went for pp, too, but we now have significant feedback that for pp non-counting often makes more sense
14:15:50 <ericP> much as UNION ALL is catches SQL users up
14:15:56 <AndyS> I believe there is a preferred semantics.
14:16:21 <AxelPolleres> q?
14:16:25 <AndyS> EricP - the comments do not align with your point.
14:16:35 <pgearon> kasei: suggest DISTINCT/ALL PATHS as keywords. But concerned we're making the decision without any basis and I think that will come back to bite us
14:17:01 <pgearon> AndyS: another concern. The info brought to the WG last time was that all commentors had been contacted and were OK with the approach
14:17:17 <LeeF> Right, not all commenters have been contacted
14:17:22 <pgearon> AndyS: but the last contact was in Feb and isn't the latest
14:17:50 <pgearon> AndyS: and one commenter was not contacted
14:18:23 <pgearon> AxelPolleres: one contacted was in touch and said he was OK with suggested semantics
14:18:36 <pgearon> AxelPolleres: did not contact "Yin" (?)
14:19:15 <AxelPolleres> s/Yin/Jeen/
14:19:21 <pgearon> AxelPolleres: point of discussion was that semantics on paths was OK for them
14:19:48 <AndyS> action 600?
14:19:48 <trackbot> Sorry, bad ACTION syntax
14:20:19 <pgearon> AxelPolleres: danger is if we do not proceed with resolution from last week, then we may lock, and may end up having to do the entire discussion again
14:20:23 <sandro> q?
14:21:35 <AndyS> q+
14:21:43 <pgearon> kasei: not suggesting that default should be one or the other. We don't have the data to make the decision yet
14:22:08 <AxelPolleres> grep suggests to have both keywords fom path expressions ALLPATHS( ) and DISTINCT( )
14:22:08 <ericP> that's reasonably conservative
14:22:09 <pgearon> kasei: suggest using both keywords, and leave it up to implementations as to what to do if neither keyword is used
14:22:23 <ericP> takes up one new token in the grammar
14:22:38 <pgearon> +1 on kasei's idea
14:23:25 <pgearon> Sandro: we can use AT RISK so that if we get pushback from devs then we can choose which way to go at the end of CR
14:23:47 <pgearon> Sandro: so we can put off the decision for now
14:24:07 <sandro> (or, really, we can easily backtrack on this decision, if we mark it AT RISK.)
14:24:16 <pgearon> AxelPolleres: should we have a straw poll on this question?
14:24:37 <kasei> sandro, are you suggesting that the entire PP syntax would be at risk? I'm not sure what would be left below the 'at risk' part...
14:25:17 <ericP> how about "At risk: property paths require either the keyword DISTINCT or ALL to specify an exhaustive exploration of the path solutions. One of these keywords may be removed, making that semantics the default semantics for bare paths in graph patterns"?
14:25:32 <AxelPolleres> PROPOSED: Add alternative  DISTINCT() and ALLPATHS() modifiers around full property paths to SPARQL 1.1 Query as an AT RISK feature,  and add work on counting & non-counting operators or partial paths to the future work list
14:25:32 <ericP> (for the text in Query)
14:25:40 <AndyS> -1
14:27:10 <pgearon> AndyS: concerned we're just punting it to a later time
14:27:23 <ericP> how about "At risk: property paths require either the keyword DISTINCT or ALL to specify an exhaustive exploration of the path solutions. One of these keywords may be removed during CR, making that semantics the default semantics for bare paths in graph patterns. The SPARQL WG would appreciate relevent feedback to public-sparql-comments@w3.org from users and implementors."?
14:27:31 <AndyS> q?
14:27:37 <pgearon> AxelPolleres: if it's AT RISK then there's no fallback
14:27:47 <ericP> (specifies "during CR" and adds the plea for comments)
14:28:03 <pgearon> AxelPolleres: current fallback is the LC document
14:28:12 <pgearon> Sandro: the other fallback is to remove it completely
14:28:36 <pgearon> Sandro: reminded recently that PP is a time permitting feature
14:29:08 <pgearon> Sandro: trying to get an extension on the WG charter. This is hard to justify for a "time permitting" feature
14:29:41 <pgearon> AndyS: commenters are saying something reasonably clear: there IS a preferred set of semantics
14:30:08 <pgearon> AndyS: from outside, for *+ then non-counting makes more sense. It's more intuitive
14:30:37 <pgearon> AndyS: referring to the comments on list. There are 3 on the list
14:30:51 <pgearon> AxelPolleres: the Chilleans indicate they want an existential on the whole path
14:31:09 <pgearon> AxelPolleres: they want a non-counting semantics
14:31:37 <pgearon> AxelPolleres: Jeen is more towards what AndyS is saying.
14:31:40 <ericP> i note that our comment solicitation encourages only comments from those who aren't content with an ALL semantics
14:31:53 <pgearon> AndyS: Chilean paper is very much around *
14:32:00 <AxelPolleres> http://www.dcc.uchile.cl/~jperez/papers/www2012.pdf
14:32:01 <ericP> (here's a doc, shout if you don't like it)
14:32:34 <pgearon> AndyS: not that other things aren't mentioned. It's a question of emphasis
14:32:52 <pgearon> AxelPolleres: paper discusses existential on paths.
14:33:09 <pgearon> AxelPolleres: "cardinality of this mapping would be one"
14:34:18 <pgearon> AxelPolleres: with resolution from last time we can deal with this semantics just by putting DISTINCT around the expression
14:35:08 <pgearon> Sandro: according to AndyS, we can just change the semantics to meet the comments. Don't need any new keywords
14:35:12 <pgearon> AndyS: yes
14:35:19 <AxelPolleres> * + alone dont make existential semantics.
14:35:24 <pgearon> AxelPolleres: can't get existential semantics just by changing * +
14:35:44 <pgearon> AxelPolleres: Chileans don't want mixed semantics
14:35:51 <pgearon> AndyS: where's that in the paper?
14:36:04 <pgearon> sandro: there's no need to follow that paper
14:36:25 <pgearon> AxelPolleres: the problem is if WE are happy with things
14:37:05 <pgearon> AxelPolleres: addressing discussion from the week. Started by kasei, and includes AndyS and AxelPolleres
14:37:23 <pgearon> AxelPolleres: are we happy with resolution from last week?
14:37:50 <pgearon> AxelPolleres: will kasei (or anyone else) want to lie down in the road over this issue?
14:38:12 <pgearon> kasei: from my understanding of the resolution last week is a problem for me
14:38:28 <pgearon> kasei: but there appears to be more to the resolution than what I read in the minutes
14:38:46 <AxelPolleres> what we resolved to was Option 3 http://www.w3.org/2009/sparql/meeting/2012-03-20#line0225
14:38:47 <pgearon> AxelPolleres: last week we went with option 3
14:39:21 <pgearon> AxelPolleres: adding DISTINCT around full paths only. Other than that we leave the semantics. So the default semantics is around counting
14:39:42 <pgearon> AxelPolleres: DISTINCT changes to an existential semantics
14:40:34 <pgearon> AxelPolleres: proposal is to add an ALL keyword. kasei's concern is that the resolution has a lock-in to 1 default semantics
14:41:11 <AndyS> I prefer option 6. One implementation.  Lower support costs.  Natural semantics. Least block on future work.  Mixed counting is the minimal way forward.
14:41:17 <chimezie> the option to have both syntaxes with a later determination of which is the default seems more appealing to me now
14:41:51 <chimezie> esp. if both syntaxes/semantics can be (easily) made mutually exclusive
14:42:03 <kasei> it was a condorcet voting implementation.
14:42:40 <ericP> my order of prefs: default ALL, require DISTINCT & ALL, default DISTINCT
14:42:45 <pgearon> AxelPolleres: could add a switch at the query level, but probably don't want to add that as well
14:42:56 <ericP> (descending order)
14:44:14 <AxelPolleres> We have various intuitions floating around on what is "intuitive", I am afraid
14:44:17 <pgearon> AndyS: 2 classes of operations. Simple like sequence and alternation. Then others like working on arbitrary length paths
14:44:48 <pgearon> AndyS: what are the natural expectations and work with that, even if it means different counting in different places
14:45:06 <Zakim> +LeeF.a
14:45:10 <pgearon> AndyS: so far we have failed to find what the expectations are in various situations
14:46:09 <pgearon> AxelPolleres: agree with have subtleties on the lower levels, but think our approach can address can address 2 of the 3 concerns
14:46:30 <AxelPolleres> default ALL, require DISTINCT & ALL, default DISTINCT
14:47:25 <AndyS> q-
14:48:44 <AxelPolleres>  Andy: is "/" also distinct for you, paul? 
14:48:54 <AxelPolleres> Paul: have to think about that.
14:49:42 <AxelPolleres> Axel: the chileneans definition (p.8) in their paper makes "/" also distinct
14:50:35 <pgearon> speculating that if our use cases also need / then counting semantics are more likely to be what we'd want
14:50:44 <AxelPolleres> PROPOSED: require eithrt DISTINCT  or ALL around paths 
14:50:55 <AndyS> We can define { ?x :p/:q ?y }  ==> { ?x :p ?a . ?a :q ?y } ie. not as PP, but merely syntax short form.  PP is just *,+,?
14:51:03 <chimezie> +1
14:51:12 <AxelPolleres> +1 
14:51:13 <cbuilara> +1
14:51:21 <AndyS> -1
14:51:40 <AndyS> (fails on implementation cost issues)
14:51:42 <MattPerry> 0
14:51:44 <pgearon> 0
14:51:47 <sandro> 0
14:51:51 <kasei> 0 (like this, but would also want to allow syntax without a keyword and let the implementation decide the semantics)
14:51:56 <ericP> +0
14:52:07 <Olivier> 0
14:52:45 <MattPerry> I would be open to Andy's new simplification
14:52:53 <kasei> AndyS, what does (:p/:q)* do, then?
14:52:59 <AxelPolleres> The standing resolution is still the one from last time.
14:53:09 <pgearon> AndyS: that would be DISTINCT
14:53:32 <pgearon> isn't just the combination of operations. DISTINCT over something that isn't leads to an overall DISTINCT
14:55:33 <pgearon> AxelPolleres: changing the behavior of * and + did not find a majority last time
14:55:56 <MattPerry> I think last time we rejected addition of {*},{+},{?}
14:56:10 <pgearon> AndyS: approaching it from a minimal set of features and punt the rest to future work. This is why I'm suggesting getting rid of {}
14:56:34 <pgearon> AndyS: and also getting rid of counting features m/n
14:57:18 <pgearon> AndyS: can construct use cases that need it. This is a proposal that covers less
14:57:31 <MattPerry> I'm in favor of the simplification. I'm not even sure how I would explain all these variations to a user.
14:58:11 <pgearon> AxelPolleres: shouldn't ignore discussion from today, but we're no further than the resolution from last time
14:58:40 <Zakim> -EricP
14:58:45 <pgearon> AxelPolleres: recall that this is a time-permitting feature and this should not hold up the WG any further
14:59:03 <pgearon> AxelPolleres: need to discuss in email during the coming week
14:59:11 <AxelPolleres> let's take it to email
14:59:19 <AndyS> zakim, who is on the phone?
14:59:19 <Zakim> On the phone I see pgearon, AndyS, Olivier_, AxelPolleres, kasei, SteveH, MattPerry, cbuilara, sandro, LeeF, chimezie (muted), LeeF.a
14:59:41 <pgearon> adjourned
14:59:42 <AxelPolleres> adjourned
14:59:51 <Zakim> -sandro
14:59:55 <Zakim> -Olivier_
14:59:59 <Zakim> -cbuilara
15:00:01 <AxelPolleres> rrsagent, make records public
15:00:09 <Zakim> -SteveH
15:00:11 <Zakim> -chimezie
15:00:15 <Zakim> -MattPerry
15:00:21 <Zakim> -kasei
15:00:23 <Zakim> -LeeF
15:00:31 <Zakim> -AxelPolleres
15:00:48 <AndyS> What are your requirements for a PP design?  i.e. principles
15:00:58 <Zakim> -AndyS
15:01:10 <Zakim> -pgearon
15:02:04 <AxelPolleres> Andy, maybe a good question we should try to summarize on the list for next week...I think Lee's summary was a good start, but admittedly, I think it left out the lock-in aspect that Greg now brought in.
15:02:24 <AxelPolleres> need to run.
15:21:58 <kasei> The Chileans may have said they didn't want mixed semantics, but I note their paper doesn't use any examples where that would be an issue.
15:22:27 <kasei> They only discuss paths with * and + applied to a predicate (sometimes several times)
15:35:01 <Zakim> disconnecting the lone participant, LeeF, in SW_(SPARQL)10:00AM
15:35:02 <Zakim> SW_(SPARQL)10:00AM has ended
15:35:02 <Zakim> Attendees were pgearon, AndyS, Olivier_, +43.517.073.aaaa, kasei, SteveH, MattPerry, cbuilara, AxelPolleres, sandro, LeeF, chimezie, EricP
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000253