14:42:09 RRSAgent has joined #sparql 14:42:09 logging to http://www.w3.org/2010/02/23-sparql-irc 14:42:11 RRSAgent, make logs world 14:42:11 Zakim has joined #sparql 14:42:13 Zakim, this will be 77277 14:42:13 ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 18 minutes 14:42:14 Meeting: SPARQL Working Group Teleconference 14:42:14 Date: 23 February 2010 14:42:16 zakim, this will be SPARQL 14:42:16 ok, LeeF; I see SW_(SPARQL)10:00AM scheduled to start in 18 minutes 14:42:25 Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2010-02-23 14:42:39 Regrets: AlexP 14:42:49 OlivierCorby has joined #sparql 14:47:31 AxelPolleres has joined #sparql 14:54:30 dcharbon2 has joined #sparql 14:55:38 SW_(SPARQL)10:00AM has now started 14:55:45 +Lee_Feigenbaum 14:55:55 zakim, Lee_Feigenbaum is me 14:55:55 +LeeF; got it 14:55:57 Chair: LeeF 14:56:40 dcharbon2, any update on whether you'll be able to make the face to face in March? 14:56:42 +bglimm 14:57:57 +??P8 14:58:09 zakim, ??P8 is me 14:58:09 +AndyS; got it 14:58:29 MattPerry has joined #sparql 14:58:56 +pgearon 14:59:07 Hi Lee, I'm working on arranging the travel - it hinges on having a customer to talk to while I'm in Boston. The outlook is good at this point, but still not fixed 14:59:12 +OlivierCorby 14:59:21 + +1.603.897.aaaa 14:59:31 +kasei 14:59:35 Prateek has joined #sparql 15:00:04 zakim, aaaa is MattPerry 15:00:04 +MattPerry; got it 15:00:34 zakim, who's on the phone? 15:00:34 On the phone I see LeeF, bglimm, AndyS, pgearon, OlivierCorby, MattPerry, kasei 15:00:45 Zakim, mute me 15:00:45 bglimm should now be muted 15:00:56 Zakim, mute me 15:00:56 kasei should now be muted 15:01:39 Before we get started, suggest people take a look at last week's minutes - http://www.w3.org/2009/sparql/meeting/2010-02-16 15:01:43 chimezie has joined #sparql 15:02:17 +Sandro 15:02:18 + +1.919.332.aabb 15:02:32 zakim, aabb is me 15:02:32 +dcharbon2; got it 15:03:01 not really 15:03:02 no 15:03:07 sure 15:03:07 Zakim, unmute me 15:03:16 bglimm should no longer be muted 15:03:23 scribenick: kasei 15:03:41 +Chimezie_Ogbuji 15:03:45 zakim, dial ivan-voip 15:03:47 +??P34 15:03:50 Zakim, ??P34 is SteveH 15:04:03 ok, ivan; the call is being made 15:04:07 +Ivan 15:04:13 +SteveH; got it 15:04:25 +AxelPolleres 15:04:27 Zakim, I don't know who I am ;-) 15:04:31 I'm glad that smiley is there, AxelPolleres 15:06:07 topic: admin 15:06:08 PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2010-02-16 15:06:38 RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2010-02-16 15:06:53 ok 15:07:16 ouch, I can't be there next week! 15:07:17 LeeF: update on f2f. axel and lee to start coming up with agenda 15:07:35 ... so regrets 15:07:37 ... nail down big open issues, use f2f time to sort through them. work on test cases. 15:07:53 Zakim, mute me 15:07:53 Chimezie_Ogbuji should now be muted 15:07:56 ... start to think about last call. 15:08:24 LeeF: some new comments coming in. doing pretty well at dealing with them. 15:08:38 ... will do a once over on the comments next week to make sure we're in good shape. 15:08:56 topic: liaisons 15:09:19 topic: update 15:09:34 LeeF: pgearon sent out an email summarizing open issues. 15:09:55 ... I'll summarize my understanding of the issues, then let pgearon take over. 15:09:57 Paul's email: http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0323.html 15:10:09 pgearon: some discussion on mailing list, but didn't see concensus on them. 15:10:37 LeeF: issue in editor's draft about ambiguous delete syntax 15:10:49 ... proposal to seperate update statements in single request with semicolons. 15:10:57 http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0298.html 15:11:08 ... discussion on the list, most up to date from AndyS. 15:11:38 q+ to mention small side issue, which is why not allow the same shortcut that we allwo for INSERT/DELETE for CONSTRUCT as well? 15:11:39 ... summary: shortcut form (deletes everything matched in the pattern) 15:11:46 instead of the shortcut being "DELETE { template }" it would be "DELETE WHERE { template pattern }" 15:11:57 ... DELETE WHERE { template pattern } 15:11:57 q+ 15:11:59 aside from that +1 to make WEHRE obligatory 15:12:13 fine 15:12:25 s/WEHRE/WHERE/ 15:12:32 pgearon: nothing to add to this summary 15:12:33 ack SteveH 15:12:54 SteveH: wanted to emphatically add +1, been playing with this recently and much more pleasant to deal with 15:13:12 DELETE WHERE { xxx } ; DELETE WHERE { yyy } 15:13:40 SteveH: as human found easier to process visually with semicolons 15:13:47 +1 to SteveH 15:13:54 as a human, wouldn't you put each on its own line? 15:14:10 LeeF: hearing general agreement for DELETE WHERE as shortcut form 15:14:18 sandro, yeah, but I have newlines in there anyway 15:14:19 yes:-) 15:14:22 @Steve... similar/related to question for ',' in SELECT? 15:14:28 s/triple patterns/quad templates/ 15:14:35 ... advice to editor is shortcut form should be DELETE WHERE 15:15:03 ... summarizing steveh, semicolons aren't necessary but nice to have 15:15:34 ... probably just a matter of taste. any other strong feelings? 15:15:39 -1 to require 15:15:41 q+ 15:15:51 +1 for allowing (not requiring) 15:15:53 ivan: thought steve was wanting to allow, not require. 15:16:04 0 to allow 15:16:05 SteveH: wanted to allow, not forbit. 15:16:17 require not forbid 15:16:25 AndyS: don't like them. if you append a statement, you have to go back to add semicolons. 15:16:32 ack AndyS 15:16:32 +q 15:16:37 s/allow/require/ 15:16:37 ack pgearon 15:16:40 (sorry steve) 15:16:44 s/forbit/forbid/ 15:16:54 pgearon: if we're talking about allowing, doesn't matter if it's there or not. 15:17:09 SteveH: not talking about allowing, but requiring. 15:17:27 pgearon: if it's optional, people who find it appealing can use it, others dont' have to. 15:17:44 SteveH: then queries written by others are hard to read. doesn't help anybody. 15:18:01 ... not an opinion from others. just a personal preference. 15:18:25 LeeF: inclined to proceed without requiring them. 15:18:33 s/requiring/allowing 15:18:54 axel: all on the same side on not wanting to require them, but what about allowing? 15:19:07 LeeF: no strong agreement on making them optional. don't want to float that as a suggestion. 15:19:14 ack AxelPolleres 15:19:14 AxelPolleres, you wanted to mention small side issue, which is why not allow the same shortcut that we allwo for INSERT/DELETE for CONSTRUCT as well? 15:19:41 Axel: shortcut notation for DELETE, why not also for CONSTRUCT? 15:19:42 +1 to AxelPolleres 15:20:02 LeeF: decided not to because it doesn't accomplish anything. it's a noop. 15:20:05 q+ to ask about protocol 15:20:14 ... discussion about this on the mailing list. 15:20:25 just for my understanding: CONSTRUCT WHERE XXX would mean CONSTRUCT {?s ?p ?o} WHERE XXX 15:20:41 Axel: allowing arbitrary where patterns, unclear what it means. if you only allow restricted templates, it looks reasonable. 15:20:42 ivan, I thin it's 15:20:44 ack AndyS 15:20:44 AndyS, you wanted to ask about protocol 15:20:53 ... CONSTRUCT XXX WHERE XXX 15:21:07 AndyS: unclear about the proposal. construct returns a result. what is the return type from construct? 15:21:14 I believe the proposal is "CONSTRUCT WHERE { XXX }""" 15:21:34 aha 15:21:37 LeeF: shortcut form would limit what's in the where clause. 15:21:59 AndyS: slightly different restriction. pattern would have to be triple patterns. in DELETE the pattern allows quad patterns. 15:22:12 Axel: having quad patterns in CONSTRUCT would be worth discussing. 15:22:33 LeeF: we don't have any way to return quad results. can't point at any syntax. 15:22:53 ... discussed quads in construct in the past, and not in a position to do it right now. 15:22:53 q+ 15:23:00 ack SteveH 15:23:36 SteveH: seems like a natural thing to do. leaves it open for next WG when there is a quad syntax they can point at. 15:23:52 LeeF: falls within syntactic sugar. does anybody have reservations about this? 15:24:04 AndyS: entirely around protocol issues. 15:24:11 LeeF: not sure I see them. what are they? 15:24:38 AndyS: setting expectations that we can return quads. happy to return quads, but that affects protocol and APIs. 15:25:04 LeeF: so it's an expectation thing. 15:25:35 SteveH: if we say it's not a valid 1.1 query if it includes the GRAPH keyword, don't see the problem. 15:25:41 we would essentially need to push forward to rubbber-stamp NQuads or TriG ... to be able to return something... is that the concern? 15:25:46 zakim, who's on the phone? 15:25:46 On the phone I see LeeF, bglimm, AndyS, pgearon, OlivierCorby, MattPerry, kasei, Sandro, dcharbon2, Chimezie_Ogbuji (muted), SteveH, Ivan, AxelPolleres 15:25:57 AxelPolleres, if we allowed GRAPH, yeah 15:26:00 q+ 15:26:04 LeeF: are others indifferent? passively in favor? 15:26:12 ack ivan 15:26:15 q+ about NQ and TriG 15:26:26 ivan: like CONSTRUCT shortcut, but nervous about quad issue. 15:26:26 q+ to speak to NQ and TriG 15:26:33 yes, I am afraid that is beyond our scope. :-( 15:26:36 ... we don't have a standard in this direction. we shouldn't get into that. 15:26:51 q+ 15:27:02 ack AndyS 15:27:02 AndyS, you wanted to speak to NQ and TriG 15:27:05 ... that's a SPARQL 2 issue. if we have a WG that handles quad issue, SPARQL can come back and deal with it. not the other way around. 15:27:09 q+ 15:27:37 AndyS: both nquads and trig aren't sufficiently defined to work as reliable transfer formats. details like bnodes. 15:27:50 q? 15:27:55 ... solvable problems, but not enough detail right now for interop. 15:28:14 LeeF: taking as a given that there aren't any sufficient quad formats at this time. 15:28:27 ack pgearon 15:28:34 AndyS: wanted to raise issue that we're raising expectations. 15:28:34 ack me 15:28:38 q+ 15:29:04 pgearon: agree that quad format will be coming. we should look at doing something when that happens. until then can't consider it. 15:29:14 ... future WG should deal with it. 15:29:17 Good news: the SPARQL spec already has triple template. 15:29:23 ... symmetry between CONSTRUCT and insertion. 15:29:46 ... already have graphs inside pattern. can insert into multiple graphs at the same time. want symmetry with CONSTRUCT. 15:29:51 ack AxelPolleres 15:30:27 Axel: maybe we could resolve that like sparql 1 did triple patterns (literals in subject position). 15:30:36 Different issue - literals in subject can't be stopped due to variables. 15:30:51 and owl:sameAs :-) 15:30:51 ... spec shouldn't say it supports GRAPH in CONSTRUCT, but could still allow the shortcut. 15:30:56 q? 15:30:59 ack SteveH 15:31:00 q+ 15:31:24 SteveH: can see AndyS' concern, but don't agree. 15:31:31 http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#sparqlTriplePatterns also allows more than current RDF allows. 15:31:34 ... does raise expectation, but INSERT does that all on its own. 15:31:40 ack ivan 15:32:08 ivan: not in favor of that. shouldn't do anything which will make it possible later to add it. but not kosher to add it now. 15:32:17 LeeF: don't understand why not kosher now? 15:32:26 ivan: talking about GRAPH in CONSTRUCT. 15:32:35 Zakim, unmute me 15:32:35 Chimezie_Ogbuji should no longer be muted 15:32:40 I asked (not suggested ;-) ) Why wouldn't it be kosher with leaving the return format undefined? 15:32:45 AndyS, yeah, well you know my opinion on the optional WHERE... 15:32:57 ... but fair enough to not go that far 15:33:20 LeeF: even if spec says CONSTRUCT has to use triple patterns, leads people to think they can use more complex patterns. 15:33:29 I'd say don't have WHERE at all - it adds nothing and the {} are more than enough. 15:33:41 ... straw poll to see where people stand? 15:33:42 AndyS, yeah, except that it's needed in INSERT shortcut 15:34:13 straw poll: support for adding a CONSTRUCT WHERE { triple patterns } construct as a short cut for CONSTRUCT {XXX} WHERE {XXX} 15:34:16 +1 15:34:22 +1 15:34:26 0 15:34:28 +1 15:34:30 0 15:34:31 0 15:34:32 +1 15:34:32 +1 15:34:34 +0.5 15:34:34 +1 15:34:41 +1 15:34:53 LeeF: reasonable concensus in favor of adding shortcut. 15:35:14 +q 15:35:15 action? 15:35:39 Added to my ToDo list. Steve and I can work the detailed chnages out later. 15:35:54 ACTION: Steve to work with Andy to add CONSTRUCT WHERE { triple pattern } shortcut to query spec 15:35:55 Created ACTION-200 - Work with Andy to add CONSTRUCT WHERE { triple pattern } shortcut to query spec [on Steve Harris - due 2010-03-02]. 15:36:11 pgearon: wanted to confirm that shortcut will be like selecting *. 15:36:28 Concrete example? 15:36:44 having trouble following this and scribing :\ 15:36:58 LeeF: request for more details on mailing list 15:37:07 http://www.w3.org/2009/sparql/track/issues/20 15:37:13 ... next update issue is ISSUE-20. 15:37:25 ... graph aware vs. quad stores vs. update. 15:37:32 q+ 15:37:47 ... not sure exactly what it means. graphs that exist without anything in them. 15:38:00 ... creating empty graphs and droping potentially empty graphs. 15:38:19 ... what's the current state of the update spec? 15:38:29 ack pgearon 15:38:33 pgearon: right now we allow graphs that have nothing in them. 15:38:50 ... create graph will create a named graph with nothing in it. 15:39:06 ack SteveH 15:39:07 ... nothing in spec says INSERT into a graph that doesn't exist will succeed, but note talking about it. 15:39:26 SteveH: to halves to this. distinction between empty graph and a non-existent graph. no strong feelings on this. 15:39:44 ... do feel strongly that it shouldn't be error to try to insert a triple into a graph that doesn't exist. 15:39:54 ... should create the graph. strong user feedback that this should work. 15:40:20 LeeF: so shouldn't require the graph is created before triples can be put into it? 15:40:23 SteveH: yes. 15:40:34 pgearon: current spec says error if the graph doesn't exist. 15:40:44 pgearon, did I get that right? 15:40:48 +1 to SteveH : example INSERT { GRAPH ?g {

} WHERE { ... ?g .... } } -- can't create ?g at present. 15:40:57 AndyS, exactly that case 15:40:59 LeeF: does anybody think UPDATE shouldn't have CREATE and DROP? 15:41:12 DROP, yes, CREATE, don't care 15:41:20 yes = should have 15:41:21 sandro: is there some way to find out if an empty graph exists? 15:41:39 Steve, you mean CREATE could be implicit by inserting? 15:41:40 ASK FROM NAMED g1 { GRAPH { } } 15:41:46 AxelPolleres, yes 15:42:03 LeeF: not clear if, in this query, g1 exists or not. 15:42:29 AndyS: GRAPH with empty pattern asks if g1 is in the dataset names, regardless if there are any triples. 15:42:46 LeeF: if g1 doesn't exist in store, unclear what the query should do. 15:43:02 AndyS: that will always return true. 15:43:15 LeeF: my impl would reject query if g1 doesnt' exist. but that's the FROM NAMED part. 15:43:33 ... short answer is not strictly according to the standard. 15:44:02 ASK { GRAPH ?g { } } 15:44:25 LeeF: depends on impl-defined details. 15:44:32 this query asks "is this graph in the dataset" 15:44:37 ... doesn't ask what graphs are potentially available. 15:45:05 didn't catch that last bit from chimezie(?) 15:45:13 q+ 15:45:17 ack AndyS 15:45:30 You can determine if the dataset that is active for the query includes a named graph (even if it is empty) 15:45:38 AndyS: sandro's question is good, raises larger question: what about conditional things in update generally? 15:45:55 ... pre conditions? do we need an IF statement? 15:46:14 ... at the moment you can kind of do it with multiple requests modulo atomicity issues. 15:46:17 ... is that acceptable? 15:46:20 In which case, I don't think we *do* need to have a way to create and drop graphs (but that is orthogonal with the implicit behavior SteveH wants) 15:46:38 LeeF: speaking for myself, acceptable. anything more significant would be a big change from where we are right now. 15:46:41 s/I don't think/I do think 15:47:26 chimezie: seems like we do have a distinction between not having a graph and having a named graph that's empty. 15:47:33 ... can't determine if a dataset has a named graph. 15:47:38 q+ to ask about graphstore vs default dataset 15:47:41 ... need to have ops for creating and dropping graphs. 15:47:52 ... can still have default behaviour of creating graphs implicitly. 15:47:57 ack AxelPolleres 15:47:57 AxelPolleres, you wanted to ask about graphstore vs default dataset 15:48:36 Axel: akward that we don't have anythign specified that if i insert something it isn't guaranteed to be in the default dataset. 15:48:51 LeeF: default dataset isn't a standardized concept in SPARQL 1.0. 15:49:15 Axel: do we want that to be undefined? what would be a usecase for doing an insert and a subsequent query doesn't get an answer? 15:49:57 LeeF: my thought on broader question, only way to provide a guarantee would be to revise query spec and provide formal notion of default dataset. 15:50:07 ... more than we can handle at this point. 15:50:33 Disagree - it's defined as "what the impl chooses to provide" - a common usage. 15:50:37 ... if spec had said from day 1 an impl needs to have a universal graph, would have implemented that, but that's not the case. 15:51:06 AndyS: i think default dataset concept is defined in the protocol document. 15:51:20 LeeF: there's no concept of what the default dataset *is*. up to the implementation. 15:52:00 SteveH has joined #sparql 15:52:04 Axel: motivated by question about inserting into a named graph, then pose a query to the default dataset, should you get back the inserted graph? 15:52:18 ... by not having specified the behaviour, we wouldn't have this guarantee. 15:52:37 ... LeeF convinced me that there's not a universal desired behaviour. 15:53:22 missed most of that, AndyS 15:53:25 ... at least there are implementations that don't do that (as ther default dataeset is always empty) 15:53:33 s/ther/their/ 15:53:36 noisy office all of a sudden. 15:54:04 LeeF: like to know if the rest of the group shares SteveH's preference? 15:54:07 AndyS: default dataset = graphstore is still a common use case 15:54:15 I think it's always clear where the data is going 15:54:20 ... is it always explicit where the triples end up? 15:54:29 SteveH: yes. either a graph keyword or going into the default graph. 15:54:37 LeeF: and the default graph already exists? 15:54:40 SteveH: yes. 15:54:49 thanks Axel 15:54:49 Can we draft proposal (devil, detail etc)? 15:54:50 q+ 15:55:00 pgearon: not sure what insertion into default graph as union of other graphs means. 15:55:10 chimezie: agree that's a problem. 15:55:12 q+ 15:55:16 ack SteveH 15:55:25 so, if you an implementation doesn't have a default graph, what if you insert into it? 15:55:32 SteveH: same situation. no default graph, just a union. 15:55:37 ... haven't decided what to do. 15:55:55 ack me 15:55:57 pgearon: more general problem than just this issue. 15:55:58 ack AndyS 15:56:10 AndyS: graphs might be read only anyway. 15:56:37 LeeF: hearing general concesus that shouldn't be an error to insert into a graph that doesn't exist. 15:56:38 I'd suppose that implementations could reject insertions into the default graph? 15:56:50 (those that don't have a default graph) 15:56:55 ... since current draft is the other way around, let's make it a proposal. 15:57:28 PROPOSE: SPARQL Update should make it legal to insert triples into a graph that does not yet exist, with the result being that the graph now exists and has those triples in it 15:57:33 seconded 15:57:37 +1 15:57:39 +1 15:57:40 +1 15:57:41 +0 15:57:44 0 15:57:48 +1 15:57:49 +1 15:57:49 +1 15:57:49 +1 15:57:52 +1 15:57:58 RESOLVED: SPARQL Update should make it legal to insert triples into a graph that does not yet exist, with the result being that the graph now exists and has those triples in it 15:58:05 (exception being the default graph...) 15:58:29 LeeF: heard that create and drop should stick around. might return when we continue discussion about datasets. 15:58:35 ... will discuss with protocol issues. 15:58:43 and LOAD ... INTO ... 15:59:16 LeeF: didn't get to blank nodes in template for delete, and dataset clauses. 15:59:21 ... will do them next week. 15:59:24 just to put it in again... regrets for next week from me, BTW 15:59:55 -pgearon 15:59:58 sorry, 16:00:05 yes, I'm comfortable with that 16:00:14 LeeF: will follow up with pgearon. 16:00:28 bye 16:00:30 -Ivan 16:00:31 -Chimezie_Ogbuji 16:00:31 -dcharbon2 16:00:32 bye all 16:00:35 ADJOURNED 16:00:37 -MattPerry 16:00:42 pointer to the scribe instructions for posting? 16:00:43 -bglimm 16:00:47 -SteveH 16:00:53 -LeeF 16:00:57 -AxelPolleres 16:00:57 http://www.w3.org/2009/CommonScribe/ 16:00:59 -kasei 16:01:01 -Sandro 16:01:10 thanks 16:01:11 -OlivierCorby 16:01:13 -AndyS 16:01:15 SW_(SPARQL)10:00AM has ended 16:01:17 Attendees were LeeF, bglimm, AndyS, pgearon, OlivierCorby, +1.603.897.aaaa, kasei, MattPerry, Sandro, +1.919.332.aabb, dcharbon2, Chimezie_Ogbuji, Ivan, SteveH, AxelPolleres 16:01:29 (quite self-explanatory, if you have trouble, I'll still be around for some minutes on IRC) 16:01:54 thanks axel. i did it once before, so I'm sure I can manage again. 16:07:47 hmmm... actually 16:08:12 Axel, is all of this necessary? must I include the "present: ..." line, or is Zakim's attendees list enough? 16:08:17 AxelPolleres has left #sparql 16:33:09 kasei, you do need the present: line 16:33:52 really? i tried looking at earlier minutes, and didn't see it being used. 16:34:29 can i regenerate the page? 16:38:13 yeah 16:38:16 maybe something changed 16:38:20 you used to need the present: line 16:38:31 if the process succeeded without it, then you didn't need it :) 16:38:57 minutes look OK to me as is :) 16:39:21 ok, good to know. 16:39:22 thanks 16:55:14 AndyS_ has joined #sparql 17:05:26 AndyS has joined #sparql 18:17:35 Zakim has left #sparql 19:25:50 SteveH has joined #sparql 20:58:42 bglimm has joined #sparql 22:46:28 AndyS has joined #sparql 23:02:49 bglimm has joined #sparql