From SPARQL Working Group
Please justify/explain all edits to this page, in your "edit summary" text.
<kasei> Present: Lee, kasei, AlexPassant, AndyS, SimonKJ, pgearon, SimonS, SteveH, LukeWM, bglimm, Prateek, chimezie 13:48:18 <trackbot> Meeting: SPARQL Working Group Teleconference 13:48:18 <trackbot> Date: 04 August 2009 13:48:22 <Zakim> ok, LeeF; I see SW_(SPARQL)10:00AM scheduled to start in 12 minutes 13:48:26 <LeeF> Chair: LeeF 13:48:35 <LeeF> Regrets: Axel, EricP, IvanH 13:48:50 <kasei> scribenick: kasei 13:48:50 <LeeF> Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2009-08-04 13:56:30 <Zakim> SW_(SPARQL)10:00AM has now started 14:03:59 <LeeF> topic: Admin 14:04:07 <LeeF> PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-07-28 14:04:16 <LeeF> agenda - http://www.w3.org/2009/sparql/wiki/Agenda-2009-08-04 14:04:31 <bglimm> +1 14:04:42 <LeeF> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-07-28 14:05:18 <LeeF> next mtg Aug-11 SimonS to scribe 14:05:27 <LeeF> http://www.w3.org/2009/sparql/wiki/Vacation_List 14:06:34 <kasei> topic: Liasons 14:07:02 <kasei> nothing to report 14:07:09 <LeeF> topic: TPAC face to face 14:07:33 <kasei> LeeF: reminder next face to face at TPAC 14:07:58 <kasei> LeeF: 2 day meeting 14:08:40 <kasei> ... try to arrange virtual call as well 14:08:47 <kasei> ... comments? 14:09:10 <bglimm> I have to see what the travel budget says... 14:09:12 <kasei> ... will ask on mailing list again who intends to go 14:09:07 <LeeF> topic: Actions 14:09:43 <LeeF> trackbot, close ACTION-55 14:09:43 <trackbot> ACTION-55 Summarize ISSUE-32 closed 14:10:21 <LeeF> trackbot, close ACTION-64 14:10:22 <trackbot> ACTION-64 Draft subqueries in template closed 14:11:08 <kasei> AndyS: trying to work out more formal relationship between not exists and diff 14:11:30 <kasei> LeeF: will probably turn attention back to that in a few weeks. 14:11:31 <LeeF> trackbot, close ACTION-67 14:11:31 <trackbot> ACTION-67 Draft negation closed 14:11:55 <kasei> chimezie: hope to have something on aggregates later this week 14:12:10 <kasei> LeeF: hope to have mailing list discussion and discuss aggregates next week 14:12:22 <LeeF> trackbot, close ACTION-73 14:12:22 <trackbot> ACTION-73 Kick of BGP entailment TF closed 14:12:31 <LeeF> trackbot, close ACTION-74 14:12:31 <trackbot> ACTION-74 Kick off property paths TF closed 14:13:10 <LeeF> trackbot, close ACTION-76 14:13:11 <trackbot> ACTION-76 Kick off Basic Federated Query TF closed 14:13:25 <LeeF> topic: Document editors 14:13:26 <kasei> SimonS: sent email to kick off basic federated query TF 14:13:54 <kasei> LeeF: asked for editors for sparql query and update documents. 14:14:05 <kasei> ... AndyS and SteveH will serve as editors of query 14:14:13 <kasei> ... pgearon and SimonS editors of update 14:14:59 <kasei> AndyS: is update for protocol and language? 14:15:07 <kasei> LeeF: not decided yet. 14:15:32 <kasei> AndyS: meant REST by "protocol" 14:15:42 <pgearon> I think that the update protocol will need its own document. I'm prepared to work on both 14:16:58 <kasei> topic: Status of SPARQL/Query design template actions 14:17:12 <kasei> LeeF: any issues worth discussing now? 14:17:20 <LeeF> http://www.w3.org/2009/sparql/wiki/Design:SubSelect 14:17:29 <kasei> SteveH: syntax for allowing projected variable renaming 14:17:42 <kasei> ... need new syntax because existing syntax doesn't have room for it. 14:18:15 <kasei> ... expressing subselects in obvious way loses internal ordering 14:18:42 <kasei> ... according to current semantics, order isn't preseved in join. 14:18:59 <kasei> ... lots of dependencies between project expressions and aggregates. 14:19:11 <kasei> LeeF: open issue whether we'll do other types of subqueries 14:19:59 <kasei> LeeF: summing up, syntax and ordering are issues. 14:20:22 <kasei> AndyS: big change to existing implementations to address ordering 14:20:57 <kasei> LeeF: have you had any feedback on ordering? 14:21:06 <kasei> AndyS: no, but use case for it. 14:21:30 <kasei> ... case for having ORDER BY in subquery 14:21:46 <kasei> LeeF: need order by and limit to do limit by resource 14:22:02 <kasei> AndyS: or "top blogger by number of comments" 14:22:40 <pgearon> no allergic reaction. I might sneeze :-) 14:22:44 <kasei> LeeF: does anybody find an ORDER BY in subquery with order disappering in outer query problematic? 14:23:17 <kasei> LeeF: seems to be concensus on keeping ORDER BY in subquery but that order isn't preserved in merging results with main query 14:23:32 <kasei> ... less inclined to move ahead on syntax right now. 14:23:47 <kasei> ... will note that it's an open issue. 14:24:00 <kasei> SteveH: from logical point of view, straightforward 14:24:43 <LeeF> S,t,e,v,e H,a,r,r,i,s ? 14:24:54 <kasei> ... syntax is a bit off-scope, would like to see if concensus for ways to write rename. 14:25:02 <SteveH> E1: SELECT (?x+3 AS ?xp3) ?y WHERE ... 14:25:09 <SteveH> E2: SELECT (?x+3) AS ?xp3 ?y WHERE ... 14:25:16 <SteveH> E3: SELECT ?x+3 AS ?xp3, ?y WHERE ... 14:25:37 <kasei> LeeF: 3 ways to express selecting and projecting to a different name. 14:25:58 <AndyS> I don't like adjacent, unseparated use of variables (the "SELECT (expr) as ?x ?y WHERE" case) 14:25:59 <kasei> ... using an AS keyword in parens, the whole thing in parens, or leaving off parens and adding commas between items. 14:26:11 <kasei> AndyS++ 14:26:27 <kasei> SteveH: semantically equivalent, just some easier for humans 14:26:40 <chimezie> E3 +1 14:26:43 <kasei> LeeF: strawpoll 14:26:48 <LeeF> poll on E1 14:26:52 <SteveH> +0 14:26:55 <bglimm> +0 14:26:56 <LukeWM_> 0 14:26:57 <AndyS> +1 E1 14:26:58 <LeeF> +1 14:26:59 <kasei> +1 14:27:00 <Prateek> +1 14:27:02 <pgearon> +1 14:27:02 <AlexPassant> +1 14:27:05 <chimezie> 0 14:27:14 <LeeF> poll on E2 14:27:15 <SteveH> -1 14:27:16 <LukeWM_> -1 14:27:16 <AndyS> q+ to ask about E3 14:27:16 <AlexPassant> -1 14:27:22 <LeeF> -1 14:27:24 <chimezie> -1 14:27:24 <pgearon> -1 14:27:24 <bglimm> 0 14:27:26 <kasei> -1 14:27:28 <AndyS> -0.5 E2 14:27:29 <SimonS> 0 14:27:46 <LeeF> ack AndyS 14:27:46 <Zakim> AndyS, you wanted to ask about E3 14:28:00 <kasei> AndyS: is it a change that will affect existing queries (commas)? 14:28:12 <pgearon> +q 14:28:21 <kasei> SteveH: named projection would require commas. doesn't change existing queries. 14:29:07 <kasei> SteveH: want impressions on overall look and feel, not details 14:29:19 <LeeF> ack pgearon 14:30:01 <kasei> pgearon: if we're considering commas in variables in select clause, wouldn't examples 2 and 3 be similar? 14:30:22 <kasei> SteveH: E2 doesn't have commas 14:30:36 <kasei> pgearon: but if commas were optional and could be put in E2, ... 14:30:56 <kasei> SteveH: same as AndyS's question, if commas were necessary. 14:30:58 <LeeF> poll on general feeling of E3 14:31:00 <SteveH> +1 14:31:01 <LukeWM_> 0 14:31:05 <chimezie> +1 14:31:05 <AlexPassant> +1 on E3 14:31:08 <kasei> 0 14:31:13 <AndyS> +0 E3 14:31:27 <LeeF> +1 14:31:29 <SimonS> +1 14:31:36 <pgearon> +1 on E3, but would like a comma-free syntax to be possible as well 14:31:41 <bglimm> 0 14:31:47 <Prateek> 0 14:32:11 <kasei> SteveH: based on strawpoll, will keep examples. 14:32:26 <kasei> LeeF: seems to be support for E1 and E3, but will look at reasons to do one or the other. 14:32:39 <LeeF> topic: Update via SPARQL/Protocol 14:33:14 <kasei> LeeF: pgearon summarized issues in taking update query strings and using them over SPARQL Query protocol. 14:33:18 <LeeF> paul's summary is http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0096.html 14:34:13 <kasei> ... take away: sparql update should be issued over HTTP POST only 14:34:33 <kasei> ... consensus over that? 14:35:00 <kasei> pgearon: approached thinking update protocol would be similar to query protocol. not necessarily the case. 14:35:12 <kasei> ... various options: write an unrelated protocol 14:35:19 <kasei> ... would be nice to have a related protcol 14:35:29 <kasei> ... build on what we already have 14:35:40 <kasei> ... option: all updates go through POST 14:36:11 <kasei> ... PUT is supposed to add data to resource, DELETE deletes, POST is only method that is flexible enough 14:36:21 <kasei> ... query or update can be handled by specifying parameters 14:36:37 <LeeF> q+ to confirm that this works ok with a WSDL specification + HTTP bindings 14:36:39 <kasei> ... option: PUT and POST. subverts PUT. 14:36:58 <kasei> ... option: use different HTTP methods. requires parsing HTTP methods before intention is clear. 14:37:33 <kasei> ... people seem to like option 2 (all updates through POST) 14:38:17 <kasei> LeeF: if we did this, we could specify abstract WSDL interface, HTTP bindings, etc. correct? 14:38:44 <AndyS> q+ to ask about WSDL and errors. 14:39:12 <LeeF> ack LeeF 14:39:12 <Zakim> LeeF, you wanted to confirm that this works ok with a WSDL specification + HTTP bindings 14:39:14 <kasei> chimezie: yes. 14:39:17 <LeeF> ack AndyS 14:39:17 <Zakim> AndyS, you wanted to ask about WSDL and errors. 14:39:46 <kasei> AndyS: issue from last time, WSDL is SOAP-centric. have to enumerate error codes. 14:40:01 <kasei> ... does anyone know current state? 14:40:55 <LeeF> ISSUE: Can we use the correct meaning of the full slate of HTTP errors when specifying the update protocol via WSDL? 14:40:55 <trackbot> Created ISSUE-33 - Can we use the correct meaning of the full slate of HTTP errors when specifying the update protocol via WSDL? ; please complete additional details at http://www.w3.org/2009/sparql/track/issues/33/edit . 14:40:58 <kasei> ... can we use the correct meaning of all the HTTP errors? will come up with update protocol. 14:41:26 <kasei> LeeF: any SOAP people on the call? 14:42:05 <kasei> ... will investigate answers. 14:42:24 <LeeF> ACTION: Lee to investigate ISSUE-33 14:42:24 <trackbot> Created ACTION-77 - Investigate ISSUE-33 [on Lee Feigenbaum - due 2009-08-11]. 14:42:28 <kasei> ... how much desire is there to continue SOAP support? 14:42:52 <AndyS> q+ 14:42:55 <SteveH> +1 to POST only 14:43:00 <LeeF> ack AndyS 14:43:03 <kasei> LeeF: are people happy with making update protocol use POST with ?update=... ? 14:43:31 <pgearon> +q about single or multiple endpoints 14:43:35 <chimezie> I'm not sure what the role of the csgi parameter is in this scenario 14:43:38 <pgearon> +q 14:43:44 <SteveH> +1 to AndyS 14:43:45 <kasei> AndyS: if everything is on one endpoint, hard to use external security. 14:43:53 <LeeF> ack pgearon 14:44:08 <SimonS> +1 for allowing both same and different endpoint for update 14:44:16 <kasei> pgearon: think we need to have a read-only endpoint. useful to do all read operations on read/write endpoint, but seperate issue. 14:44:48 <chimezie> R+W shouldn't be required, if i understand the question 14:44:55 <kasei> LeeF: (clarifying) can't be the case that all endpoints must support read and write? 14:45:02 <chimezie> but it should be *okay* to bind two services to the same network address 14:45:27 <chimezie> +q about cgi param 14:45:35 <LeeF> ack chimezie 14:45:50 <AndyS> I'm OK with read-only endpoint and read-write endpoint. Just care about framing to stress read-only is publishing safely. 14:46:03 <bglimm> soory, fire alarm here 14:46:06 <bglimm> I have to leave 14:46:08 <kasei> chimezie: what did you have in mind with update=? 14:46:22 <AndyS> q+ to ask about caching 14:46:50 <kasei> pgearon: by having update=, only allows update operations. no query operations following update=. 14:47:04 <LukeWM_> q+ 14:47:35 <kasei> chimezie: address you're POSTing to implies action you want. 14:48:19 <kasei> pgearon: want seperation to allow decisions based on security concerns. 14:48:36 <kasei> ... want code that doesn't know how to do any writing to data store. 14:48:37 <LeeF__> q? 14:48:48 <kasei> ... want to protect write code much more strongly. 14:49:05 <kasei> ... would be nice to read from write endpoint, but not necessary. 14:49:24 <LeeF> ack LukeWM_ 14:50:07 <kasei> can someone scribe what Luke is saying? I can't make it out. 14:50:26 <chimezie> I guess you can enforce separation (for security purposes) either at the protocol level or leave it up to the 'query engine' to manage access control (below the level of the protocol) 14:50:32 <LeeF> ack AndyS 14:50:32 <Zakim> AndyS, you wanted to ask about caching 14:50:48 <kasei> AndyS: like the idea of having read/write endpoints. useful. 14:51:08 <kasei> ... if you do GET as read, might see inconsistent views. maybe only allow POST on read/write endpoints. 14:51:36 <kasei> ... want to put security outside the endpoint. implementation choice. 14:52:16 <SteveH> I like required POST, and update= 14:52:25 <AndyS> +1 14:52:28 <kasei> LeeF: consensus in support of HTTP POST. no consensus yet regarding ?query= and ?update= seperation. 14:53:05 <LeeF> PROPOSED: HTTP version of SPARQL/Protocol for SPARQL/Update statements involves always sending the update statements over HTTP POST 14:53:30 <AndyS> Seconded 14:53:39 <pgearon> +1 14:53:49 <LeeF> RESOLVED: HTTP version of SPARQL/Protocol for SPARQL/Update statements involves always sending the update statements over HTTP POST 14:53:57 <LeeF> no objections or abstentions 14:54:14 <LukeWM_> My point before was: although separate read/write and read endpoints seem more convenient, in practice applications will end up simply using read/write for everything. 14:54:21 <kasei> LeeF: is question of whether parameter is query= or update= something to be continued on mailing list? 14:54:32 <kasei> chimezie: yes. 14:54:41 <LeeF> ACTION: chimezie to continue discussion of update= vs. query= on the mailing list 14:54:41 <trackbot> Created ACTION-78 - Continue discussion of update= vs. query= on the mailing list [on Chimezie Ogbuji - due 2009-08-11]. 14:55:12 <kasei> LeeF: want to allow read only and read/write endpoints. 14:55:22 <SteveH> if we have read/write endpoints then using query= everywhere will be problematic for some implementations 14:55:32 <kasei> ... punt on service descriptions until next week. 14:56:02 <SteveH> bye 14:56:02 <LeeF> adjourned # SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000362