13:51:20 RRSAgent has joined #sparql 13:51:20 logging to http://www.w3.org/2010/03/16-sparql-irc 13:51:22 RRSAgent, make logs world 13:51:23 Zakim has joined #sparql 13:51:24 Zakim, this will be 77277 13:51:24 ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 9 minutes 13:51:25 Meeting: SPARQL Working Group Teleconference 13:51:26 Date: 16 March 2010 13:51:26 zakim, this will be SPARQL 13:51:26 ok, LeeF; I see SW_(SPARQL)10:00AM scheduled to start in 9 minutes 13:51:34 Chair: LeeF 13:51:40 Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2010-03-16 13:54:41 Regrets: Ivan 13:56:36 Regrets +AxelPolleres 13:57:09 SW_(SPARQL)10:00AM has now started 13:57:16 +Lee_Feigenbaum 13:57:26 zakim, that's me! 13:57:26 I don't understand 'that's me!', LeeF 13:57:34 zakim, Lee_Feigenbaum is me 13:57:34 +LeeF; got it 13:57:57 SteveH_ has joined #sparql 13:58:11 + +1.518.276.aaaa 13:58:16 Zakim, aaaa is me 13:58:16 +kasei; got it 13:58:51 +[IPcaller] 13:59:06 zakim, IPCaller is me 13:59:08 +??P13 13:59:11 Zakim, ??P13 is me 13:59:12 +AndyS; got it 13:59:18 + +49.238.aabb 13:59:20 +SteveH_; got it 13:59:53 Zakim, aabb is me 13:59:53 +OlivierCorby; got it 14:00:15 Souri has joined #sparql 14:00:30 -me fighting with the phone in Karlsruhe... It doesnät allow me to enter the code Öß) 14:00:31 Scribenick: SteveH_ 14:00:36 MattPerry has joined #sparql 14:01:04 zakim, who's on the phone? 14:01:04 On the phone I see LeeF, kasei, AndyS, SteveH_, OlivierCorby 14:01:11 + +1.603.897.aacc 14:01:19 Zakim, mute me 14:01:19 kasei should now be muted 14:01:25 +??P16 14:01:39 +??P17 14:01:42 Zakim, ??P17 is me 14:01:42 +AlexPassant; got it 14:01:50 dcharbon2 has joined #sparql 14:01:50 zakim, ??P16 is me 14:01:50 +MattPerry; got it 14:01:52 hi 14:01:57 zakim, aacc us me 14:01:57 I don't understand 'aacc us me', Souri 14:02:05 Prateek has joined #sparql 14:02:06 zakim, aacc is me 14:02:06 +Souri; got it 14:02:39 + +1.919.332.aadd 14:02:45 +Sandro 14:02:49 Zakim, aadd is me 14:02:49 +dcharbon2; got it 14:03:05 + +1.312.863.aaee 14:03:22 zakim, mute me 14:03:22 dcharbon2 should now be muted 14:03:32 Zakim, aaee is me 14:03:32 +pgearon; got it 14:03:48 + +1.216.444.aaff 14:04:00 chimezie has joined #sparql 14:04:24 Zakim, mute me 14:04:24 sorry, chimezie, I do not know which phone connection belongs to you 14:04:31 Zakim, who is on the phone? 14:04:31 On the phone I see LeeF, kasei (muted), AndyS, SteveH_, OlivierCorby, Souri, MattPerry, AlexPassant, dcharbon2 (muted), Sandro, pgearon, +1.216.444.aaff 14:04:36 zakim, aaff is chimezie 14:04:37 +chimezie; got it 14:04:41 ty 14:05:10 Zakim, mute me 14:05:10 chimezie should now be muted 14:05:19 PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2010-03-09 14:06:10 RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2010-03-09 14:06:17 LeeF: minutes capture handling of blanknodes in delete 14:06:30 LeeF: try to have short call next week, 2 days before f2f 14:06:55 ... set for F2F, go over agenda on last time, logistical issues, 20 min call 14:07:00 can we restrict it to process thing please? 14:07:14 Next meeting: 2010-03-23 @ 14:00 UK / 10:00 EST (scribe: Matt) - NOTE ONE HOUR EARLIER THAN USUAL OUTSIDE OF THE US 14:07:29 LeeF: 4 hours difference to UK 14:07:53 LeeF: should look at comments at F2F 14:08:05 -AlexPassant 14:08:30 LeeF: RDB2RDF, noting to worry about 14:08:34 http://www.w3.org/2009/sparql/wiki/F2F3_Agenda 14:08:43 LeeF: agenda for F2F updated, ^ 14:08:56 + +33.7.21.60.8aagg 14:08:58 +??P26 14:09:03 Zakim, ??PP26 is me 14:09:03 sorry, AlexPassant, I do not recognize a party named '??PP26' 14:09:04 ... update on day 1, goal is to finalise language, what statements are in/out 14:09:07 Zakim, ?PP26 is me 14:09:07 sorry, AlexPassant, I do not recognize a party named '?PP26' 14:09:10 ... seperaters, delimiters 14:09:11 Zakim, ??P26 is me 14:09:11 +AlexPassant; got it 14:09:31 LeeF: testcases, update issues, concurrency, transactions etc. 14:09:43 bglimm has joined #sparql 14:09:45 ... punt on the or have some sort of informative content (?) 14:09:46 Zakim, who is on the phone? 14:09:46 On the phone I see LeeF, kasei (muted), AndyS, SteveH_, OlivierCorby, Souri, MattPerry, dcharbon2 (muted), Sandro, pgearon, chimezie (muted), +33.7.21.60.8aagg, AlexPassant 14:10:00 Zakim, +33.7.21.60.8aagg is me 14:10:00 +bglimm; got it 14:10:06 ... also a bit of time on a testsuite for update 14:10:17 ... afternoon, open issues in protocol, HTTP update docs 14:10:23 Zakim, mute me 14:10:23 bglimm should now be muted 14:10:32 ... protocol will be clearer when we've finished the update lang 14:10:46 ... day 2 big block of time to resolve open query issues 14:11:05 ... decide on minus v's not exists 14:11:21 ... resolve handling of errors in aggreagates, group by 14:12:25 ... property paths 14:12:33 ... afternoon, entailment issues 14:12:35 Zakim, unmute me 14:12:35 bglimm should no longer be muted 14:12:43 ... entailment moving ahead nicely 14:12:52 noise on line 14:13:10 zakim, mute bglimm 14:13:10 bglimm should now be muted 14:13:19 Zakim, unmute me 14:13:19 bglimm should no longer be muted 14:13:38 zakim, who is speaking? 14:13:43 bglimm, we have to mute you because there's too much noise on your line 14:13:47 Zakim, mute bglimm 14:13:47 bglimm should now be muted 14:13:48 ok 14:13:49 AndyS, listening for 10 seconds I heard sound from the following: AndyS (14%), bglimm (74%) 14:14:30 LeeF: entailment seems to have good progress, discuss status 14:14:35 bglimm, what I was saying is that I've seen very good progress on the entailment document over email and the entailment teleconferences, so we've set aside an hour to discuss with the whole group the status of the entailment work, but think that's in good shape and probably doesn't needmore time than that at the face to face 14:14:35 .. doesn't need more time than that 14:14:54 seems reasonable 14:14:58 ... 1h for service description issues, few hanging around, overall in good shape 14:15:18 ... ambitious agenda, but important F2F 14:15:27 .. finalising spec text, thinking about LC 14:15:34 ... finalising spec text, thinking about LC 14:16:04 AndyS: make sure time perm. features don't displace mandatory ones 14:16:19 AndyS: eg. property paths last in query 14:16:31 LeeF: I'm going to keen an eye on it 14:16:56 LeeF: property paths, func. lib. for almost all intents are deliverables, seen no show stopping issues, good progress 14:17:17 LeeF: do want to talk about them early on, more concerned with federated query, discusss and beginning 14:17:26 ... maybe relabel some 14:17:51 ... today, open issues for HTTP update, and property paths 14:18:03 ... less open issues on http update 14:18:09 Zakim, unmute me 14:18:09 chimezie should no longer be muted 14:18:12 ... improve visibility 14:18:15 http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0521.html 14:18:43 ... discussion around BASE URI for references and ?graph= 14:18:51 ... not totaly swapped in 14:19:10 http://www.w3.org/2009/sparql/docs/http-rdf-update/ 14:19:17 AxelPolleres has joined #sparql 14:19:19 chimezie: removed editorial notes re. type of RDF payload, whether doc described REST style 14:19:32 ... impl. of protocol should interpret contnet-type headers appropriately 14:19:42 ... issues around making base URIs clear 14:19:59 ... how do you determine what the base URI is 14:20:20 ... motivating usecase is where you you the ?graph=, in that scenario, depends how you interpret some RFC 14:20:43 ... 2 sections that are relevant, "encapsulating entity", layered messages 14:21:08 ... but it says that you can determine the base uri if there's [something] 14:21:24 ... can be a way of tagging metadata for specific formats 14:21:39 ... can say that ?graph= can specify the base URI 14:21:57 ... or can have conservative reading, should have RFC as normative reference 14:22:10 http://foo.example.com/sparql?graph=g 14:22:12 LeeF: goal of usecase is so that if do HTTP op like: 14:22:34 ... is there a reading that the RFC lets us treat as the base URI 14:23:01 chimezie: language suggests we can provide a way to give it in context 14:23:09 ... not neccesarily meant to support that 14:23:16 ... matter of how much you want this usecase 14:23:18 q+ 14:23:27 <> a :NamedGraph 14:23:38 ack SteveH_ 14:23:40 ... in some situation you want the name of the graph... 14:24:00 SteveH_: we use this approach a lot - without the base URI being the bit after graph=, it would be almost impossible to use it 14:24:13 ... we have a cache of a few million FOAF files, many of which use rdf:about="" to talk about the graph 14:24:19 ... if the graph had the SPARQL endpoint prefix, it would be unhelpful 14:24:52 LeeF: I'd be surprised is anyone in the group who doesn't support that usecase 14:24:57 ... does anyone not support? 14:25:15 ... question is, can we suport that usecase 14:25:49 ... do we hav a valid reading of the base URI stuff [to Sandro] 14:26:02 sandro: there's a lot of people who might give it some thought 14:26:12 ... formal way is as a editors comment in next draft 14:26:22 LeeF: I think that's a good way to proceeed 14:26:50 ... people looking at it from named graph p.o.v. will want it to work that way, but HTTP/REST people might not 14:27:06 ... chimezie will put some text in that calls out this problem 14:27:16 ... any more open issues? 14:27:23 chimezie: no, not really 14:27:38 ... issues-20 is relevant 14:27:50 LeeF: hoping to resolve in update language 14:28:19 Different issue -- g must be an absolute URI? Hope so. 14:28:55 +1 to AndyS 14:28:59 if it isn't the next level of precedence would be the retrieval URI 14:29:36 LeeF: overall doc looks to be in good shape 14:29:45 Maybe not - ?graph=../otherPlace/graph1 - hmm 14:29:52 ouch 14:30:05 LeeF: have we discussed what testcases will look like 14:30:18 chimezie: scope is well defined, I have some ideas 14:30:28 .. not up to date on tools, e.g. EARL 14:31:29 LeeF: will discuss testing at F2F 14:31:37 topic: property paths 14:31:39 ... property paths: 14:31:57 Zakim, mute me 14:31:57 chimezie should now be muted 14:31:59 http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0566.html 14:33:13 AndyS: description of multi-path issues 14:33:23 ... should you see duplicates of ways from A to B 14:33:27 :a foaf:knows :b . 14:33:27 :a foaf:knows :c . 14:33:27 :b foaf:knows :d . 14:33:27 :c foaf:knows :d . 14:33:27 {?x foaf:knows{2} ?y} 14:33:35 ... document is not clear 14:33:50 ... related to this is cycles 14:34:12 ... go round a loop and get back to where you started - those are important in the case of unbounded operators (*/+/,) 14:34:27 ... in those cases you don't want infinite answers 14:34:44 ... proposal is to define fixed length ones to triple expansions, define operators not to duplicate 14:34:58 ... equivalent to "simple paths" in graph theory 14:35:12 ... can get surprises, but it's a consequence of balance 14:35:19 ... of intuition 14:35:45 LeeF: so, fixed length property paths should be equiv to expansion pattern 14:35:54 ... can you repeat description of cycles proposal 14:35:59 AndyS: consider: 14:36:00 Consider ?x foaf:knows* ?y 14:36:09 ... on data above 14:36:24 :a foaf:knows* ?y 14:36:37 ... so there's two paths from :a to :b 14:36:53 s/:b/:c/ 14:36:59 to :d actually 14:37:04 but how do you rewrite that into standard BGPs without knowing the graph? 14:37:16 q+ 14:37:29 ah, so the non-fixed length ones are not being rewritten 14:37:43 q+ 14:37:46 ack SteveH_ 14:37:47 q+ 14:37:48 AndyS: proposal is that operators won't return dups 14:38:21 SteveH_: What values does ?y take? :a (zero length), :b, :c, :d -- one of each as proposed 14:39:38 ack LeeF 14:40:09 LeeF: was going to suggest not following same edge twice, need to thing about it 14:40:13 ack pgearon 14:40:26 pgearon: add comment about unbounded ops 14:40:44 ... agree with no dups, when loops are present 14:40:53 ... don't see any reason to stop at 2 14:41:07 ... if there's a loop, only the single result is relevant 14:42:50 Zakim, unmute me 14:42:50 chimezie should no longer be muted 14:43:02 AndyS: might be possible to define it in terms of not going through the same node twice 14:43:10 LeeF: might be worth sketching that out 14:43:17 AndyS: yes 14:43:35 chimezie: if you exlucde the dups, you have counter-intuative answers 14:43:48 ... I assumed it wouldn't affect cases where you didn't have cycles 14:44:10 LeeF: when you use a non-fixed operator, even without loops you can DISTINCT 14:44:20 ... as a simple way to solve problem 14:44:37 chimezie: I would agree that we should look at more direct soltuion to no loops 14:44:50 LeeF: I will try to write that up, but don't know if I can 14:44:58 ... leave open for ML discussion 14:45:19 AndyS: would still get different cardinalities, but may be more consistent 14:45:26 ... and maybe easier to implement 14:46:13 LeeF: cycles and dups, continue discussions 14:46:15 http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0568.html 14:46:22 ... negated prop. classes 14:46:52 AndyS: suggestion around neg clasess, other systems have something similar, it's quite natural 14:47:07 ... exclude some properties, e.g. is rdf:type, want to find non-type connections 14:47:31 ... wondering whether you need both forwards and backwards, not convinved in all cases, would be easier to impl. without backwards 14:47:45 LeeF: can ask if there's any connection whatsoever? 14:47:56 AndyS: yes 14:48:21 LeeF: that's not the same as allowing varaibles, because you can't ak what the path is 14:48:33 AndyS: don't have to decide how to return results 14:48:42 ... it doesn't open /that/ can of worms 14:48:50 LeeF: do you impl.? 14:49:05 AndyS: experiementally, fixed direction case is doable, and natural 14:49:24 ... not done forwards and reverse, think I understood it, ran out of time 14:49:51 chimezie: versa is most similar, we had negation, it was useful 14:50:00 ... it was straightforward 14:50:13 AndyS: did you allow negation of forwards and backwards at same time 14:50:15 q+ 14:50:32 ... my feeling at the moment is that the fixed direction case is OK, mixed is not easy 14:50:39 ack SteveH_ 14:50:55 SteveH_: what's the use case for the reverse direction? 14:51:00 ... in this scenario 14:52:26 +1 14:53:00 LeeF: like to poll group on neg in property paths 14:53:12 ... take Andy's email as a start, noodle on it a bit 14:53:20 ... see if we can resolve at F2F 14:53:37 straw poll: gut feeling on including ! (negation operator) in property paths 14:53:48 +1 (but not both) 14:53:58 +1 (but not both) 14:53:59 +1 14:54:03 +1 14:54:04 +1 14:54:06 i.e., not negation for bidrectional paths 14:54:14 0 14:54:15 0 14:54:21 -0 (seems making evaluation really harder) 14:54:23 0 14:55:24 I change to 0 14:55:29 scared! 14:55:34 I have to say 0 14:55:37 My impl is one Java class for the evaluator. 14:55:41 sdas2 has joined #sparql 14:56:31 q+ 14:56:42 ack AndyS 14:56:52 AndyS: impl. exp. would be good, but usecases also very useful 14:56:56 seconded - use cases here will let us know how useful this is 14:57:37 LeeF: not going to talk about update, out of time 14:58:05 AndyS: havent discusses binary/unary ^ operator 14:58:20 ... preference for unary in WG, binary outside 14:58:40 ... it's always a unary operator, q is if you can write short form 14:58:47 well, implementation experience is one thing, but I am also wondering whether that does not push BGP evaluation into higher complexity classes (regular expressions are so close to finite state automata and complement there causes an exponential blow up of the states, in OWL property negation makes reasoning undecidable, so all that raised some warnings to me) 14:59:05 didn't hear andy 14:59:33 ah, to me they suggested a breakfast 14:59:48 breakfast on 26th would make sense 14:59:58 -chimezie 15:00:00 -Souri 15:00:00 -SteveH_ 15:00:01 -LeeF 15:00:02 -kasei 15:00:03 -Sandro 15:00:04 -bglimm 15:00:05 -MattPerry 15:00:05 -dcharbon2 15:00:05 quit 15:00:07 -pgearon 15:00:09 -OlivierCorby 15:00:15 AndyS, did you see my question regarding the RV-2 response? 15:00:16 -AndyS 15:00:41 Err - no - pointer to email? 15:00:44 wondering if the @@ comments were for me, you, or somebody else (Steve?) 15:00:57 no email... was in here yesterday at some point. 15:01:15 I'd like to finish up that response and get it off if possible. 15:01:20 Ah - in the draft - @@ are "should be done (IMHO)" 15:01:41 If the SWIG does not plan for a dinner, I would suggest I reserve a table at some nearby restaurant, otherwise they might plan the evening? 15:02:09 as in, that's part of the response? 15:02:21 Mostly aggregates and the text so far didn't seen to cover it (steve?) RV split his comments up and scatter aggs over the whole email. 15:03:07 we should add text there - @@ is W3C speak for "to be done" 15:03:32 right. i was just wondering if that was for your benefit, or if somebody else should be looking at addressing the "to be done" state of things. 15:04:24 My part is done but if you think there is something I need to attend to then do say. aggs is SteveH_ 15:04:32 (sorry SteveH_) 15:04:39 ah, ok. that's what I was after. thanks. 15:04:46 SteveH_, still around? 15:04:49 yeah, hi 15:04:52 reading back 15:05:25 http://www.w3.org/2009/sparql/wiki/CommentResponse:RV-2 15:06:06 AxelPolleres has joined #sparql 15:06:42 I thought I'd addressed all the aggregate stuff 15:07:33 I think AndyS filled out my summarization of the issues that Rob talked about, leaving room for more responses :) 15:08:53 oh, he has some comments on issues 35,36,39,40 15:08:59 I'll write some text for those 15:09:40 thanks. appreciate it. can you ping me at some point after you do that? 15:11:45 -AlexPassant 15:11:47 SW_(SPARQL)10:00AM has ended 15:11:52 Attendees were LeeF, +1.518.276.aaaa, kasei, AndyS, +49.238.aabb, SteveH_, OlivierCorby, +1.603.897.aacc, AlexPassant, MattPerry, Souri, +1.919.332.aadd, Sandro, dcharbon2, 15:11:54 ... +1.312.863.aaee, pgearon, +1.216.444.aaff, chimezie, bglimm 15:13:27 kasei, AndyS. updated wiki page 15:14:04 ah, fantastic. thanks. 15:24:29 OlivierCorby has left #sparql 16:26:29 AxelPolleres has joined #sparql 16:57:20 AxelPolleres has joined #sparql 17:08:15 Zakim has left #sparql 17:21:24 ivan has joined #sparql 18:08:54 ivan has joined #sparql