13:55:38 <RRSAgent> RRSAgent has joined #sparql
13:55:38 <RRSAgent> logging to http://www.w3.org/2012/03/20-sparql-irc
13:55:40 <trackbot> RRSAgent, make logs world
13:55:40 <Zakim> Zakim has joined #sparql
13:55:42 <trackbot> Zakim, this will be 77277
13:55:42 <Zakim> ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 5 minutes
13:55:43 <trackbot> Meeting: SPARQL Working Group Teleconference
13:55:43 <trackbot> Date: 20 March 2012
13:55:48 <LeeF> zakim, this will be SPARQL
13:55:48 <Zakim> ok, LeeF; I see SW_(SPARQL)10:00AM scheduled to start in 5 minutes
13:56:04 <LeeF> Agenda: http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0262.html
13:56:10 <LeeF> Regrets: chimezie, kasei
13:56:30 <LeeF> Last week's minutes: http://www.w3.org/2009/sparql/meeting/2012-03-13
13:56:39 <AxelPolleres> AxelPolleres has joined #sparql
13:56:54 <LeeF> SteveH, any chance I could trouble you to scribe today?
13:57:19 <SteveH> LeeF, hm, think I did a stint not that long ago - it would be possible I think
13:57:59 <SteveH> …depending on voice quality, it's a bit variable over voip
13:57:59 <LeeF> I've no doubt that you're right - our scribe list is rather bit-rotted these days -- so no worries if you'd rather not
13:58:25 <SteveH> I would rather not, but if you can't get a volunteer I'll do it
13:58:29 <LeeF> thanks
13:58:35 <LeeF> pgearon, any chance you could scribe for us today?
13:58:49 <LeeF> zakim, code?
13:58:49 <Zakim> the conference code is 77277 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), LeeF
13:59:38 <pgearon> LeeF, I may have problems
13:59:38 <Zakim> SW_(SPARQL)10:00AM has now started
13:59:45 <Zakim> +LeeF
13:59:46 <Zakim> +??P10
13:59:52 <SteveH> Zakim, ??P10 is me
13:59:52 <Zakim> +SteveH; got it
14:00:03 <pgearon> I have JUST got a notification of "Tornado warning" for our neighborhood
14:00:10 <pgearon> like about 3 minutes ago
14:00:15 <LeeF> wow
14:00:27 <Zakim> +Olivier_
14:00:38 <LeeF> good ol' "can't scribe; tornado". it's like the "dog ate my homework" of standards work
14:00:53 <pgearon> we have storms forecast for today, I'm just trying to figure out if it's supposed to be a drill or something
14:00:53 <SteveH> we've got guys with jackhammers outside the office, which means I'll have to keep muting
14:01:04 <LeeF> seriously though, be careful, Paul!
14:01:23 <MattPerry> MattPerry has joined #sparql
14:01:36 <Zakim> +??P20
14:01:46 <bglimm> Zakim, ??P20 is me
14:01:46 <Zakim> +bglimm; got it
14:01:55 <LeeF> zakim, who's on the phone?
14:01:55 <Zakim> On the phone I see SteveH, LeeF, Olivier_, bglimm
14:02:10 <cbuilara> cbuilara has joined #sparql
14:02:17 <bglimm> Zakim, mute me
14:02:19 <Zakim> bglimm should now be muted
14:02:26 <Zakim> +MattPerry
14:02:28 <Zakim> +??P26
14:02:32 <AndyS> zakim, P26 is me
14:02:33 <Zakim> sorry, AndyS, I do not recognize a party named 'P26'
14:02:37 <AndyS> zakim, ??P26 is me
14:02:37 <Zakim> +AndyS; got it
14:03:00 <Zakim> +AxelPolleres
14:03:11 <bglimm> Zakim, unmute me
14:03:11 <Zakim> bglimm should no longer be muted
14:03:38 <bglimm> Zakim, mute me
14:03:38 <Zakim> bglimm should now be muted
14:03:51 <LeeF> zakim, who
14:03:51 <Zakim> I don't understand 'who', LeeF
14:03:54 <LeeF> zakim, who's here?
14:03:54 <Zakim> On the phone I see SteveH, LeeF, Olivier_, bglimm (muted), MattPerry, AndyS, AxelPolleres
14:03:56 <Zakim> On IRC I see cbuilara, MattPerry, AxelPolleres, Zakim, RRSAgent, LeeF, Olivier, MacTed, bglimm, SteveH, pgearon, AndyS, NickH, trackbot, kasei, ya, ericP, sandro
14:04:17 <LeeF> cbuilara, ericP, sandro, NickH -- will you be joining us today?
14:04:41 <AndyS> I'll scribe
14:04:56 <AndyS> but if the discussions get going, may need help.
14:05:12 <AndyS> scribenick: AndyS
14:05:17 <AndyS> topic: Admin
14:06:04 <AndyS> regrest: kasei, chimezie
14:06:06 <LeeF> Next meeting: March 27th, back to standard time everywhere
14:06:17 <bglimm> I am not around
14:06:17 <sandro> LeeF, sorry, regrets --- this meeting conflicts with eGov IG this week due to time zone craziness.
14:06:26 <bglimm> or at least at risk
14:06:29 <LeeF> Regrets +sandro
14:07:08 <LeeF> sandro, if you have a feeling on the property paths options as summarized in http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0262.html, it would be awesome to have you share it in IRC :)
14:07:42 <AndyS> regrets: kasei, chimezie
14:08:03 <LeeF> LeeF: anything we're likely to change based on recent grammar / escaping changes?
14:08:10 <AndyS> topic: RDF-WG
14:08:12 <LeeF> AndyS: not likely, editors not inclined to make changes -- nothing resolved in RDF WG yet
14:08:20 <cbuilara> cbuilara has joined #sparql
14:08:32 <AndyS> Turtle editors not inclined to make changes at this time but no decision yet.
14:08:43 <Zakim> + +1.917.522.aaaa
14:08:55 <cbuilara> zakim, +aaaa is me
14:08:55 <Zakim> sorry, cbuilara, I do not recognize a party named '+aaaa'
14:09:12 <cbuilara> zakim, +.aaaa is me
14:09:12 <Zakim> sorry, cbuilara, I do not recognize a party named '+.aaaa'
14:09:20 <Zakim> - +1.917.522.aaaa
14:09:36 <Zakim> + +1.917.522.aabb
14:09:44 <LeeF> topic: property paths
14:09:49 <LeeF> summary email: http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JanMar/0262.html
14:09:51 <AndyS> Topic: Property Paths
14:09:59 <cbuilara> zakim, +1.917.522.aabb is me
14:09:59 <Zakim> +cbuilara; got it
14:10:17 <AndyS> Goal - ask what people think currently and have a strawpoll.
14:10:25 <AndyS> LeeF: Goal - ask what people think currently and have a strawpoll.
14:10:27 <Zakim> +pgearon
14:10:37 <Zakim> +ericP
14:10:40 <AndyS> ... hopefully to choose a direction.
14:11:07 <AndyS> ... Opt 1 - as 2LC.  Rewrite using SELECT DISTINCT subquery.
14:11:22 <AndyS> ... no LC, no new issues from new designs.
14:11:52 <AndyS> ... but objections may be raised so needs a justification to the director
14:12:00 <AndyS> ... 3 commenters involved
14:12:30 <AndyS> ... and it may not the best choice (from experience and theory).
14:12:39 <ericP> do we have any use cases from the potential objecters where rewriting in a DISTINCT subselect won't suffice?
14:13:16 <AndyS> Opt 2 -- DISTINCT, non-counting * and +, counting {*}, {+}
14:13:33 <AndyS> ... addresses concerns (offlist private conversation had)
14:13:42 <AndyS> ... full range of possibilities.
14:14:02 <AndyS> ... but 3LC needed
14:14:08 <AndyS> ... more implementation tax
14:14:20 <AndyS> ... new and quite late.
14:14:36 <AndyS> (dragons of various colors possible)
14:15:10 <AndyS> Opt 3 -- just add DISTINCT around path  (?? part paths or full path only)
14:15:23 <AndyS> ... some expressivity choices
14:15:38 <AndyS> ... 3LC, and impl tax.
14:16:13 <AndyS> Opt 4 -- Just */+ and {*}/{+}, no DISTINCT operator.
14:16:33 <AndyS> ... 3LC, may not meeting comments.
14:16:51 <AndyS> Opt 5 -- make PP non-normative
14:17:11 <AndyS> ... 3LC? (unclear), lower impl tax, 
14:17:23 <ericP> i think that would require a new LC as folks are expecting property paths to e.g. traverse lists
14:17:40 <AndyS> ... but a significant feature, and in F&R, is removed
14:17:56 <AndyS> ... may lead to other objections
14:17:58 <AndyS> q+
14:18:00 <bglimm> q+ to ask about (2)
14:18:02 <LeeF> ack AndyS
14:18:14 <bglimm> Zakim, unmute me
14:18:14 <Zakim> bglimm should no longer be muted
14:18:15 <ericP> q+ to ask if we have any use cases from the potential objecters where rewriting in a DISTINCT subselect won't suffice
14:18:26 <LeeF> AndyS: technical question when you say DISTINCT(path) in 2 - do you mean whole path or some part of the path?
14:18:42 <LeeF> LeeF: whole path
14:18:50 <LeeF> ack bglimm
14:18:50 <Zakim> bglimm, you wanted to ask about (2)
14:18:53 <AndyS> Clarification of opt 2 : DISTINCT(path) means whole path not part of a path.
14:18:58 <SteveH> q+ to ask about other people's comfort
14:18:59 <AndyS> ack me
14:19:02 <LeeF> ack ericP
14:19:02 <Zakim> ericP, you wanted to ask if we have any use cases from the potential objecters where rewriting in a DISTINCT subselect won't suffice
14:19:21 <bglimm> Zakim, mute me
14:19:21 <Zakim> bglimm should now be muted
14:19:38 <AndyS> eric: question - any case where SELECT DISTINCT path does not work?
14:19:52 <AndyS> axel: bnodes in subj/obj.
14:19:55 <AndyS> q+
14:20:16 <AndyS> (basically the projection is messed up as bnodes are a sort of projection)
14:20:30 <AxelPolleres> somthing like that one ....  { ?S DISTINCT(path) [ ... ] } 
14:20:46 <AxelPolleres> ... exactly, as andy says.
14:21:32 <LeeF> AndyS: The problem with that would be that you'd be expecting implementations to recognize the distinct subqueries and do something special with it, so implementation cost wouldn't be changed at all
14:21:43 <AndyS> andy: Impl burden is not changed - assumes an impl spots an optimization
14:22:33 <AndyS> q-
14:22:36 <LeeF> q?
14:22:38 <LeeF> ack SteveH
14:22:38 <Zakim> SteveH, you wanted to ask about other people's comfort
14:23:13 <AndyS> SteveH: reservation about understanding of PP, and significant problems may yet arise.
14:23:51 <AxelPolleres> q?
14:24:02 <AxelPolleres> q+
14:24:04 <AndyS> ... want to hear how comfortable people are with the draft text
14:24:16 <LeeF> ack AxelPolleres
14:24:29 <AndyS> (andy can answer but want to hear others)
14:24:29 <ericP> I have not implemented them. sort of afraid of them
14:25:07 <AndyS> axel; Non-norm PP may address commenters concerns.
14:25:49 <pgearon> I have implemented DISTINCT property paths. Haven't done counted paths yet
14:26:28 <AndyS> steveH: make new design non-norm??
14:27:00 <MattPerry> We have seen a lot of interest in property paths as a poor man's inference for transitive properties.
14:27:01 <pgearon> we're using property paths all the time. We use them for list membership
14:28:22 <AndyS> leef: see significant interest in the feature ... driven by some UCs that can't be addressed by SPARQL 1.0  e.g lists, trans properties
14:28:36 <LeeF> AndyS: I've found pp quite easy to implement
14:28:51 <LeeF> ... i've implemented a recursive evaluator that takes the operator tree straight from parsing and runs eval() on it
14:29:23 <LeeF> ... some paths simply get rewritten into triple patterns and UNIONs
14:30:41 <LeeF> ... i've tried counting & non-counting versions on the Chileans examples (foaf:knows on clique graphs) makes huge implementation speed difference from just changing one or two lines of code
14:30:52 <LeeF> ... any questions about how I've implemented this?
14:31:21 <LeeF> SteveH: our concerns are that it's not worth implementing unless it's optimized, and that seems to be way too much of a challenge
14:31:30 <LeeF> AndyS: I've optimized for certain use cases
14:31:57 <LeeF> ... have not optimized for the case where subj and obj are both unconstrained, free variables
14:32:44 <LeeF> SteveH: seems like it requires an entire regex engine and evaluator for an unknown language
14:32:59 <LeeF> AndyS: it's not doing regexes on strings 
14:33:04 <LeeF> SteveH: it's significantly easier?
14:33:09 <LeeF> AndyS: yes
14:33:25 <LeeF> SteveH: i don't have the intuition for why it's significantl yeasier - it still has the same backtracking problems
14:33:37 <LeeF> AndyS: we don't have some regex features that makes them tricky, like capturing groups
14:33:51 <LeeF> ... this is jus the matching aspects of regexes
14:34:12 <LeeF> ... for non-counting, there's no backtracking because it's just a positive match, no negative features
14:34:39 <LeeF> q?
14:35:01 <LeeF> zakim, who's on the phone?
14:35:01 <Zakim> On the phone I see SteveH, LeeF, Olivier_, bglimm (muted), MattPerry, AndyS, AxelPolleres, cbuilara, pgearon, ericP
14:35:22 <LeeF> AndyS: Steve, does your organization have possible use cases for pp if they had been around?
14:35:30 <LeeF> SteveH: it's an assumption - i'm sure we do but don't know what they are
14:35:35 <LeeF> AndyS: OK
14:35:52 <LeeF> SteveH: we tend to have wacky use cases anyway 
14:36:07 <ericP> q+ try to factor those who need exhaustive vs. those who need distinct
14:36:11 <LeeF> ack ericP
14:37:39 <Zakim> -pgearon
14:37:47 <AndyS> EricP: Do they think non-counting is more intuitive?
14:38:01 <AndyS> LeeF: it looks that way
14:38:22 <AndyS> EricP: Who needs what?
14:38:51 <AndyS> LeeF: It's about performance not wrong results.
14:39:09 <AxelPolleres> q+
14:39:32 <AndyS> EricP: axel says bnodes mean SELECT DISTINCT may have problems.
14:39:44 <AndyS> ack try
14:39:44 <Zakim> try, you wanted to factor those who need exhaustive vs. those who need distinct
14:39:56 <LeeF> ack AxelPolleres
14:39:58 <AndyS> ack axel
14:40:17 <AndyS> Axel: { ?s path [] }
14:40:56 <ericP> { ?s path [] }
14:40:58 <AndyS> ... bnodes also generate dups so need careful handling (implicit projection).
14:41:10 <ericP> { ?s path [] } vs. { ?s path ?x }
14:41:16 <AndyS> ... DISTINCT(path) makes it easier to spot the right algorithm to use.
14:42:03 <Zakim> + +1.540.841.aacc
14:42:16 <AndyS> q+ to say there is a UC for non-counting 
14:42:33 <AxelPolleres> { ?s path1 [ path2 ... [ ...  ] ] }
14:43:04 <ericP> { ?s path [] } -> { ?s path ?x } -> { { SELECT ?s { ?s path ?x } GROUP BY ?x } }
14:43:10 <AndyS> ... rewrite is hard - need to specially redo as generated named variables that get hidden but at a different point to how bnodes go away
14:43:20 <LeeF> ack AndyS
14:43:20 <Zakim> AndyS, you wanted to say there is a UC for non-counting
14:44:00 <AxelPolleres> the common use case for non-counting is "reachability" 
14:44:05 <LeeF> AndyS: the use case for non-counting is not that you can't write it the other way is connectivity 
14:44:31 <LeeF> ...you can solve them the other way, but you're asking the query writer to transform a problem that was naturally expressed as reachability into counting and then back again
14:44:37 <LeeF> q?
14:46:04 <AndyS> LeeF: strawpoll on all five options -- standard way.  Will write each out - please +1/0/-1(objection possible), only integer values
14:46:23 <LeeF> STRAWPOLL on option 1, leave as-is in 2LC with no change
14:46:26 <ericP> +1 
14:46:27 <SteveH> 0
14:46:29 <bglimm> 0 (concerned about formal objection)
14:46:30 <MattPerry> 0
14:46:30 <cbuilara> 0
14:46:34 <AndyS> 0
14:46:35 <Olivier> 0
14:46:43 <LeeF> +1
14:47:16 <LeeF> pgearon: -1
14:47:36 <ericP> 0
14:47:56 <ericP> sorry, thouth it was already the next strawpoll
14:48:02 <LeeF> STRAWPOLL on option 2, include both DISTINCT(full-path) and {+}/{*} operators
14:48:05 <SteveH> -1
14:48:07 <ericP> 0
14:48:08 <MattPerry> 0
14:48:11 <Olivier> 0
14:48:14 <LeeF> 0
14:48:16 <cbuilara> 0
14:48:19 <AxelPolleres> 0
14:48:19 <AndyS> What about DISTINCT(path component)?
14:48:31 <bglimm> 0
14:48:41 <pgearon> pgearon has joined #sparql
14:48:53 <AxelPolleres> q+
14:49:23 <LeeF> ack AxelPolleres
14:50:10 <AndyS> +1 and pref general DISTINCT(path-component)
14:50:10 <pgearon> opt 2: +1
14:50:37 <LeeF> STRAWPOLL on option 3, add DISTINCT(full-path) only
14:50:44 <SteveH> +1, but with reservations
14:50:45 <bglimm> +1
14:50:46 <AxelPolleres> +1
14:50:49 <MattPerry> +1
14:50:49 <Olivier> +1
14:50:52 <LeeF> +1
14:50:53 <pgearon> +1
14:50:54 <ericP> 0
14:50:56 <cbuilara> +1
14:50:58 <AndyS> 0
14:51:27 <ericP> (in +3 months)
14:51:43 <LeeF> STRAWPOLL on option 5, mark property paths as non-normative
14:52:11 <ericP> 0
14:52:15 <pgearon> -1
14:52:16 <AxelPolleres> 0
14:52:18 <LeeF> STRAWPOLL on option 5, mark our best guess at what property paths should be as non-normative
14:52:19 <MattPerry> -1
14:52:21 <Olivier> 0
14:52:22 <LeeF> 0
14:52:24 <AndyS> -1
14:52:24 <bglimm> 0
14:52:25 <SteveH> +1
14:52:27 <cbuilara> 0
14:53:00 <AndyS> Best consensus is opt 3.
14:53:01 <ericP> +1 to LeeF's impending proposal on option 3
14:53:13 <Zakim> -ericP
14:57:16 <LeeF> PROPOSED: Add a DISTINCT modifier around full property paths to SPARQL 1.1 Query, and add work on counting & non-counting operators or partial paths to the future work list 
14:57:47 <SteveH> seconded
14:57:50 <AndyS> abstain
14:58:00 <Olivier> +1
14:58:00 <pgearon> abstain
14:58:11 <bglimm> +1
14:58:22 <LeeF> RESOLVED: Add a DISTINCT modifier around full property paths to SPARQL 1.1 Query, and add work on counting & non-counting operators or partial paths to the future work list 
14:58:35 <LeeF> ACTION: Lee to add the counting/noncounting operators and distinct partial paths to future work list
14:58:35 <trackbot> Created ACTION-604 - Add the counting/noncounting operators and distinct partial paths to future work list [on Lee Feigenbaum - due 2012-03-27].
14:59:47 <AndyS> Birte - this affects entailment.  Need to restrict entailment to BGPs without PP?
14:59:48 <Zakim> -LeeF
14:59:49 <Zakim> -Olivier_
14:59:53 <Zakim> -MattPerry
14:59:54 <Zakim> -bglimm
14:59:54 <Zakim> -SteveH
14:59:55 <bglimm> bze
14:59:56 <Zakim> -AxelPolleres
14:59:58 <Zakim> -cbuilara
15:00:01 <Zakim> - +1.540.841.aacc
15:00:06 <AndyS> adjourned
15:00:09 <Zakim> -AndyS
15:00:10 <Zakim> SW_(SPARQL)10:00AM has ended
15:00:10 <Zakim> Attendees were LeeF, SteveH, Olivier_, bglimm, MattPerry, AndyS, AxelPolleres, +1.917.522.aaaa, cbuilara, pgearon, ericP, +1.540.841.aacc
15:21:27 <AxelPolleres> AxelPolleres has joined #sparql
15:34:47 <AxelPolleres> AxelPolleres has joined #sparql
15:48:52 <AxelPolleres> AxelPolleres has joined #sparql
15:52:32 <AxelPolleres> AxelPolleres has joined #sparql
16:05:50 <AxelPolleres> AxelPolleres has joined #sparql
16:19:10 <AxelPolleres> AxelPolleres has joined #sparql
16:32:24 <AxelPolleres> AxelPolleres has joined #sparql
16:45:32 <AxelPolleres> AxelPolleres has joined #sparql
16:58:44 <AxelPolleres> AxelPolleres has joined #sparql
17:08:53 <Zakim> Zakim has left #sparql
17:12:49 <AxelPolleres> AxelPolleres has joined #sparql
17:16:31 <AxelPolleres> AxelPolleres has joined #sparql
17:20:06 <AxelPolleres> AxelPolleres has joined #sparql
17:33:31 <AxelPolleres> AxelPolleres has joined #sparql
17:46:46 <AxelPolleres> AxelPolleres has joined #sparql
17:50:20 <AxelPolleres> AxelPolleres has joined #sparql
17:54:11 <AxelPolleres> AxelPolleres has joined #sparql
17:57:52 <AxelPolleres> AxelPolleres has joined #sparql
18:01:32 <AxelPolleres> AxelPolleres has joined #sparql
18:05:10 <AxelPolleres> AxelPolleres has joined #sparql
18:55:04 <AndyS> AndyS has joined #sparql