Warning:
This wiki has been archived and is now read-only.
Chatlog 2010-02-23
From SPARQL Working Group
See original RRSAgent log and preview nicely formatted version.
Please justify/explain all edits to this page, in your "edit summary" text.
14:42:09 <RRSAgent> RRSAgent has joined #sparql 14:42:09 <RRSAgent> logging to http://www.w3.org/2010/02/23-sparql-irc 14:42:11 <trackbot> RRSAgent, make logs world 14:42:11 <Zakim> Zakim has joined #sparql 14:42:13 <trackbot> Zakim, this will be 77277 14:42:13 <Zakim> ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 18 minutes 14:42:14 <trackbot> Meeting: SPARQL Working Group Teleconference 14:42:14 <trackbot> Date: 23 February 2010 14:42:16 <LeeF> zakim, this will be SPARQL 14:42:16 <Zakim> ok, LeeF; I see SW_(SPARQL)10:00AM scheduled to start in 18 minutes 14:42:25 <LeeF> Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2010-02-23 14:42:39 <LeeF> Regrets: AlexP 14:42:49 <OlivierCorby> OlivierCorby has joined #sparql 14:47:31 <AxelPolleres> AxelPolleres has joined #sparql 14:54:30 <dcharbon2> dcharbon2 has joined #sparql 14:55:38 <Zakim> SW_(SPARQL)10:00AM has now started 14:55:45 <Zakim> +Lee_Feigenbaum 14:55:55 <LeeF> zakim, Lee_Feigenbaum is me 14:55:55 <Zakim> +LeeF; got it 14:55:57 <LeeF> Chair: LeeF 14:56:40 <LeeF> dcharbon2, any update on whether you'll be able to make the face to face in March? 14:56:42 <Zakim> +bglimm 14:57:57 <Zakim> +??P8 14:58:09 <AndyS> zakim, ??P8 is me 14:58:09 <Zakim> +AndyS; got it 14:58:29 <MattPerry> MattPerry has joined #sparql 14:58:56 <Zakim> +pgearon 14:59:07 <dcharbon2> 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 <Zakim> +OlivierCorby 14:59:21 <Zakim> + +1.603.897.aaaa 14:59:31 <Zakim> +kasei 14:59:35 <Prateek> Prateek has joined #sparql 15:00:04 <LeeF> zakim, aaaa is MattPerry 15:00:04 <Zakim> +MattPerry; got it 15:00:34 <LeeF> zakim, who's on the phone? 15:00:34 <Zakim> On the phone I see LeeF, bglimm, AndyS, pgearon, OlivierCorby, MattPerry, kasei 15:00:45 <bglimm> Zakim, mute me 15:00:45 <Zakim> bglimm should now be muted 15:00:56 <kasei> Zakim, mute me 15:00:56 <Zakim> kasei should now be muted 15:01:39 <LeeF> 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> chimezie has joined #sparql 15:02:17 <Zakim> +Sandro 15:02:18 <Zakim> + +1.919.332.aabb 15:02:32 <dcharbon2> zakim, aabb is me 15:02:32 <Zakim> +dcharbon2; got it 15:03:01 <kasei> not really 15:03:02 <bglimm> no 15:03:07 <kasei> sure 15:03:07 <bglimm> Zakim, unmute me 15:03:16 <Zakim> bglimm should no longer be muted 15:03:23 <kasei> scribenick: kasei 15:03:41 <Zakim> +Chimezie_Ogbuji 15:03:45 <ivan> zakim, dial ivan-voip 15:03:47 <Zakim> +??P34 15:03:50 <SteveH> Zakim, ??P34 is SteveH 15:04:03 <Zakim> ok, ivan; the call is being made 15:04:07 <Zakim> +Ivan 15:04:13 <Zakim> +SteveH; got it 15:04:25 <Zakim> +AxelPolleres 15:04:27 <AxelPolleres> Zakim, I don't know who I am ;-) 15:04:31 <Zakim> I'm glad that smiley is there, AxelPolleres 15:06:07 <kasei> topic: admin 15:06:08 <LeeF> PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2010-02-16 15:06:38 <LeeF> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2010-02-16 15:06:53 <sandro> ok 15:07:16 <AxelPolleres> ouch, I can't be there next week! 15:07:17 <kasei> LeeF: update on f2f. axel and lee to start coming up with agenda 15:07:35 <AxelPolleres> ... so regrets 15:07:37 <kasei> ... nail down big open issues, use f2f time to sort through them. work on test cases. 15:07:53 <chimezie> Zakim, mute me 15:07:53 <Zakim> Chimezie_Ogbuji should now be muted 15:07:56 <kasei> ... start to think about last call. 15:08:24 <kasei> LeeF: some new comments coming in. doing pretty well at dealing with them. 15:08:38 <kasei> ... will do a once over on the comments next week to make sure we're in good shape. 15:08:56 <kasei> topic: liaisons 15:09:19 <kasei> topic: update 15:09:34 <kasei> LeeF: pgearon sent out an email summarizing open issues. 15:09:55 <kasei> ... I'll summarize my understanding of the issues, then let pgearon take over. 15:09:57 <AndyS> Paul's email: http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0323.html 15:10:09 <kasei> pgearon: some discussion on mailing list, but didn't see concensus on them. 15:10:37 <kasei> LeeF: issue in editor's draft about ambiguous delete syntax 15:10:49 <kasei> ... proposal to seperate update statements in single request with semicolons. 15:10:57 <LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0298.html 15:11:08 <kasei> ... discussion on the list, most up to date from AndyS. 15:11:38 <AxelPolleres> 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 <kasei> ... summary: shortcut form (deletes everything matched in the pattern) 15:11:46 <LeeF> instead of the shortcut being "DELETE { template }" it would be "DELETE WHERE { template pattern }" 15:11:57 <kasei> ... DELETE WHERE { template pattern } 15:11:57 <SteveH> q+ 15:11:59 <AxelPolleres> aside from that +1 to make WHERE obligatory 15:12:13 <AxelPolleres> fine 15:12:32 <kasei> pgearon: nothing to add to this summary 15:12:33 <LeeF> ack SteveH 15:12:54 <kasei> SteveH: wanted to emphatically add +1, been playing with this recently and much more pleasant to deal with 15:13:12 <SteveH> DELETE WHERE { xxx } ; DELETE WHERE { yyy } 15:13:40 <kasei> SteveH: as human found easier to process visually with semicolons 15:13:47 <ivan> +1 to SteveH 15:13:54 <sandro> as a human, wouldn't you put each on its own line? 15:14:10 <kasei> LeeF: hearing general agreement for DELETE WHERE as shortcut form 15:14:18 <SteveH> sandro, yeah, but I have newlines in there anyway 15:14:19 <ivan> yes :-) 15:14:22 <AxelPolleres> @Steve... similar/related to question for ',' in SELECT? 15:14:28 <AndyS> s/triple patterns/quad templates/ 15:14:35 <kasei> ... advice to editor is shortcut form should be DELETE WHERE 15:15:03 <kasei> ... summarizing steveh, semicolons aren't necessary but nice to have 15:15:34 <kasei> ... probably just a matter of taste. any other strong feelings? 15:15:39 <AxelPolleres> -1 to require 15:15:41 <AndyS> q+ 15:15:51 <pgearon> +1 for allowing (not requiring) 15:15:53 <kasei> ivan: thought steve was wanting to allow, not require. 15:16:04 <AxelPolleres> 0 to allow 15:16:05 <kasei> SteveH: wanted to require, not forbid. 15:16:25 <kasei> AndyS: don't like them. if you append a statement, you have to go back to add semicolons. 15:16:32 <LeeF> ack AndyS 15:16:32 <pgearon> +q 15:16:37 <LeeF> ack pgearon 15:16:54 <kasei> pgearon: if we're talking about allowing, doesn't matter if it's there or not. 15:17:09 <kasei> SteveH: not talking about allowing, but requiring. 15:17:27 <kasei> pgearon: if it's optional, people who find it appealing can use it, others dont' have to. 15:17:44 <kasei> SteveH: then queries written by others are hard to read. doesn't help anybody. 15:18:01 <kasei> ... not an opinion from others. just a personal preference. 15:18:25 <kasei> LeeF: inclined to proceed without allowing them. 15:18:54 <kasei> axel: all on the same side on not wanting to require them, but what about allowing? 15:19:07 <kasei> LeeF: no strong agreement on making them optional. don't want to float that as a suggestion. 15:19:14 <LeeF> ack AxelPolleres 15:19:14 <Zakim> 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 <kasei> Axel: shortcut notation for DELETE, why not also for CONSTRUCT? 15:19:42 <SteveH> +1 to AxelPolleres 15:20:02 <kasei> LeeF: decided not to because it doesn't accomplish anything. it's a noop. 15:20:05 <AndyS> q+ to ask about protocol 15:20:14 <kasei> ... discussion about this on the mailing list. 15:20:25 <ivan> just for my understanding: CONSTRUCT WHERE XXX would mean CONSTRUCT {?s ?p ?o} WHERE XXX 15:20:41 <kasei> Axel: allowing arbitrary where patterns, unclear what it means. if you only allow restricted templates, it looks reasonable. 15:20:42 <SteveH> ivan, I thin it's 15:20:44 <LeeF> ack AndyS 15:20:44 <Zakim> AndyS, you wanted to ask about protocol 15:20:53 <SteveH> ... CONSTRUCT XXX WHERE XXX 15:21:07 <kasei> AndyS: unclear about the proposal. construct returns a result. what is the return type from construct? 15:21:14 <LeeF> I believe the proposal is "CONSTRUCT WHERE { XXX }""" 15:21:34 <ivan> aha 15:21:37 <kasei> LeeF: shortcut form would limit what's in the where clause. 15:21:59 <kasei> AndyS: slightly different restriction. pattern would have to be triple patterns. in DELETE the pattern allows quad patterns. 15:22:12 <kasei> Axel: having quad patterns in CONSTRUCT would be worth discussing. 15:22:33 <kasei> LeeF: we don't have any way to return quad results. can't point at any syntax. 15:22:53 <kasei> ... discussed quads in construct in the past, and not in a position to do it right now. 15:22:53 <SteveH> q+ 15:23:00 <LeeF> ack SteveH 15:23:36 <kasei> 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 <kasei> LeeF: falls within syntactic sugar. does anybody have reservations about this? 15:24:04 <kasei> AndyS: entirely around protocol issues. 15:24:11 <kasei> LeeF: not sure I see them. what are they? 15:24:38 <kasei> AndyS: setting expectations that we can return quads. happy to return quads, but that affects protocol and APIs. 15:25:04 <kasei> LeeF: so it's an expectation thing. 15:25:35 <kasei> 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 <AxelPolleres> 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 <LeeF> zakim, who's on the phone? 15:25:46 <Zakim> On the phone I see LeeF, bglimm, AndyS, pgearon, OlivierCorby, MattPerry, kasei, Sandro, dcharbon2, Chimezie_Ogbuji (muted), SteveH, Ivan, AxelPolleres 15:25:57 <SteveH> AxelPolleres, if we allowed GRAPH, yeah 15:26:00 <ivan> q+ 15:26:04 <kasei> LeeF: are others indifferent? passively in favor? 15:26:12 <LeeF> ack ivan 15:26:15 <AndyS> q+ about NQ and TriG 15:26:26 <kasei> ivan: like CONSTRUCT shortcut, but nervous about quad issue. 15:26:26 <AndyS> q+ to speak to NQ and TriG 15:26:33 <AxelPolleres> yes, I am afraid that is beyond our scope. :-( 15:26:36 <kasei> ... we don't have a standard in this direction. we shouldn't get into that. 15:26:51 <pgearon> q+ 15:27:02 <LeeF> ack AndyS 15:27:02 <Zakim> AndyS, you wanted to speak to NQ and TriG 15:27:05 <kasei> ... 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 <AxelPolleres> q+ 15:27:37 <kasei> AndyS: both nquads and trig aren't sufficiently defined to work as reliable transfer formats. details like bnodes. 15:27:50 <LeeF> q? 15:27:55 <kasei> ... solvable problems, but not enough detail right now for interop. 15:28:14 <kasei> LeeF: taking as a given that there aren't any sufficient quad formats at this time. 15:28:27 <LeeF> ack pgearon 15:28:34 <kasei> AndyS: wanted to raise issue that we're raising expectations. 15:28:34 <AndyS> ack me 15:28:38 <SteveH> q+ 15:29:04 <kasei> 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 <kasei> ... future WG should deal with it. 15:29:17 <AndyS> Good news: the SPARQL spec already has triple template. 15:29:23 <kasei> ... symmetry between CONSTRUCT and insertion. 15:29:46 <kasei> ... already have graphs inside pattern. can insert into multiple graphs at the same time. want symmetry with CONSTRUCT. 15:29:51 <LeeF> ack AxelPolleres 15:30:27 <kasei> Axel: maybe we could resolve that like sparql 1 did triple patterns (literals in subject position). 15:30:36 <AndyS> Different issue - literals in subject can't be stopped due to variables. 15:30:51 <AndyS> and owl:sameAs :-) 15:30:51 <kasei> ... spec shouldn't say it supports GRAPH in CONSTRUCT, but could still allow the shortcut. 15:30:56 <LeeF> q? 15:30:59 <LeeF> ack SteveH 15:31:00 <ivan> q+ 15:31:24 <kasei> SteveH: can see AndyS' concern, but don't agree. 15:31:31 <AxelPolleres> http://www.w3.org/2009/sparql/docs/query-1.1/rq25.xml#sparqlTriplePatterns also allows more than current RDF allows. 15:31:34 <kasei> ... does raise expectation, but INSERT does that all on its own. 15:31:40 <LeeF> ack ivan 15:32:08 <kasei> 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 <kasei> LeeF: don't understand why not kosher now? 15:32:26 <kasei> ivan: talking about GRAPH in CONSTRUCT. 15:32:35 <chimezie> Zakim, unmute me 15:32:35 <Zakim> Chimezie_Ogbuji should no longer be muted 15:32:40 <AxelPolleres> I asked (not suggested ;-) ) Why wouldn't it be kosher with leaving the return format undefined? 15:32:45 <SteveH> AndyS, yeah, well you know my opinion on the optional WHERE... 15:32:57 <AxelPolleres> ... but fair enough to not go that far 15:33:20 <kasei> LeeF: even if spec says CONSTRUCT has to use triple patterns, leads people to think they can use more complex patterns. 15:33:29 <AndyS> I'd say don't have WHERE at all - it adds nothing and the {} are more than enough. 15:33:41 <kasei> ... straw poll to see where people stand? 15:33:42 <SteveH> AndyS, yeah, except that it's needed in INSERT shortcut 15:34:13 <LeeF> straw poll: support for adding a CONSTRUCT WHERE { triple patterns } construct as a short cut for CONSTRUCT {XXX} WHERE {XXX} 15:34:16 <SteveH> +1 15:34:22 <ivan> +1 15:34:26 <LeeF> 0 15:34:28 <AxelPolleres> +1 15:34:30 <dcharbon2> 0 15:34:31 <MattPerry> 0 15:34:32 <bglimm> +1 15:34:32 <kasei> +1 15:34:34 <AndyS> +0.5 15:34:34 <chimezie> +1 15:34:41 <pgearon> +1 15:34:53 <kasei> LeeF: reasonable concensus in favor of adding shortcut. 15:35:14 <pgearon> +q 15:35:15 <SteveH> action? 15:35:39 <AndyS> Added to my ToDo list. Steve and I can work the detailed chnages out later. 15:35:54 <LeeF> ACTION: Steve to work with Andy to add CONSTRUCT WHERE { triple pattern } shortcut to query spec 15:35:55 <trackbot> 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 <kasei> pgearon: wanted to confirm that shortcut will be like selecting *. 15:36:28 <AndyS> Concrete example? 15:36:44 <kasei> having trouble following this and scribing :\ 15:36:58 <kasei> LeeF: request for more details on mailing list 15:37:07 <LeeF> http://www.w3.org/2009/sparql/track/issues/20 15:37:13 <kasei> ... next update issue is ISSUE-20. 15:37:25 <kasei> ... graph aware vs. quad stores vs. update. 15:37:32 <SteveH> q+ 15:37:47 <kasei> ... not sure exactly what it means. graphs that exist without anything in them. 15:38:00 <kasei> ... creating empty graphs and droping potentially empty graphs. 15:38:19 <kasei> ... what's the current state of the update spec? 15:38:29 <LeeF> ack pgearon 15:38:33 <kasei> pgearon: right now we allow graphs that have nothing in them. 15:38:50 <kasei> ... create graph will create a named graph with nothing in it. 15:39:06 <LeeF> ack SteveH 15:39:07 <kasei> ... nothing in spec says INSERT into a graph that doesn't exist will succeed, but note talking about it. 15:39:26 <kasei> SteveH: to halves to this. distinction between empty graph and a non-existent graph. no strong feelings on this. 15:39:44 <kasei> ... 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 <kasei> ... should create the graph. strong user feedback that this should work. 15:40:20 <kasei> LeeF: so shouldn't require the graph is created before triples can be put into it? 15:40:23 <kasei> SteveH: yes. 15:40:34 <kasei> pgearon: current spec says error if the graph doesn't exist. 15:40:44 <kasei> pgearon, did I get that right? 15:40:48 <AndyS> +1 to SteveH : example INSERT { GRAPH ?g { <s> <p> <o> } WHERE { ... ?g .... } } -- can't create ?g at present. 15:40:57 <SteveH> AndyS, exactly that case 15:40:59 <kasei> LeeF: does anybody think UPDATE shouldn't have CREATE and DROP? 15:41:12 <SteveH> DROP, yes, CREATE, don't care 15:41:20 <SteveH> yes = should have 15:41:21 <kasei> sandro: is there some way to find out if an empty graph exists? 15:41:39 <AxelPolleres> Steve, you mean CREATE could be implicit by inserting? 15:41:40 <LeeF> ASK FROM NAMED g1 { GRAPH <g1> { } } 15:41:46 <SteveH> AxelPolleres, yes 15:42:03 <kasei> LeeF: not clear if, in this query, g1 exists or not. 15:42:29 <kasei> AndyS: GRAPH with empty pattern asks if g1 is in the dataset names, regardless if there are any triples. 15:42:46 <kasei> LeeF: if g1 doesn't exist in store, unclear what the query should do. 15:43:02 <kasei> AndyS: that will always return true. 15:43:15 <kasei> LeeF: my impl would reject query if g1 doesnt' exist. but that's the FROM NAMED part. 15:43:33 <kasei> ... short answer is not strictly according to the standard. 15:44:02 <AndyS> ASK { GRAPH ?g { } } 15:44:25 <kasei> LeeF: depends on impl-defined details. 15:44:32 <AxelPolleres> this query asks "is this graph in the dataset" 15:44:37 <kasei> ... doesn't ask what graphs are potentially available. 15:45:05 <kasei> didn't catch that last bit from chimezie(?) 15:45:13 <AndyS> q+ 15:45:17 <LeeF> ack AndyS 15:45:30 <chimezie> You can determine if the dataset that is active for the query includes a named graph (even if it is empty) 15:45:38 <kasei> AndyS: sandro's question is good, raises larger question: what about conditional things in update generally? 15:45:55 <kasei> ... pre conditions? do we need an IF statement? 15:46:14 <kasei> ... at the moment you can kind of do it with multiple requests modulo atomicity issues. 15:46:17 <kasei> ... is that acceptable? 15:46:20 <chimezie> In which case, I do 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 <kasei> LeeF: speaking for myself, acceptable. anything more significant would be a big change from where we are right now. 15:47:26 <kasei> chimezie: seems like we do have a distinction between not having a graph and having a named graph that's empty. 15:47:33 <kasei> ... can't determine if a dataset has a named graph. 15:47:38 <AxelPolleres> q+ to ask about graphstore vs default dataset 15:47:41 <kasei> ... need to have ops for creating and dropping graphs. 15:47:52 <kasei> ... can still have default behaviour of creating graphs implicitly. 15:47:57 <LeeF> ack AxelPolleres 15:47:57 <Zakim> AxelPolleres, you wanted to ask about graphstore vs default dataset 15:48:36 <kasei> 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 <kasei> LeeF: default dataset isn't a standardized concept in SPARQL 1.0. 15:49:15 <kasei> 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 <kasei> 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 <kasei> ... more than we can handle at this point. 15:50:33 <AndyS> Disagree - it's defined as "what the impl chooses to provide" - a common usage. 15:50:37 <kasei> ... 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 <kasei> AndyS: i think default dataset concept is defined in the protocol document. 15:51:20 <kasei> LeeF: there's no concept of what the default dataset *is*. up to the implementation. 15:52:00 <SteveH> SteveH has joined #sparql 15:52:04 <kasei> 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 <kasei> ... by not having specified the behaviour, we wouldn't have this guarantee. 15:52:37 <kasei> ... LeeF convinced me that there's not a universal desired behaviour. 15:53:22 <kasei> missed most of that, AndyS 15:53:25 <AxelPolleres> ... at least there are implementations that don't do that (as their default dataeset is always empty) 15:53:36 <kasei> noisy office all of a sudden. 15:54:04 <kasei> LeeF: like to know if the rest of the group shares SteveH's preference? 15:54:07 <AxelPolleres> AndyS: default dataset = graphstore is still a common use case 15:54:15 <pgearon> I think it's always clear where the data is going 15:54:20 <kasei> ... is it always explicit where the triples end up? 15:54:29 <kasei> SteveH: yes. either a graph keyword or going into the default graph. 15:54:37 <kasei> LeeF: and the default graph already exists? 15:54:40 <kasei> SteveH: yes. 15:54:49 <kasei> thanks Axel 15:54:49 <AndyS> Can we draft proposal (devil, detail etc)? 15:54:50 <SteveH> q+ 15:55:00 <kasei> pgearon: not sure what insertion into default graph as union of other graphs means. 15:55:10 <kasei> chimezie: agree that's a problem. 15:55:12 <AndyS> q+ 15:55:16 <LeeF> ack SteveH 15:55:25 <AxelPolleres> so, if you an implementation doesn't have a default graph, what if you insert into it? 15:55:32 <kasei> SteveH: same situation. no default graph, just a union. 15:55:37 <kasei> ... haven't decided what to do. 15:55:55 <SteveH> ack me 15:55:57 <kasei> pgearon: more general problem than just this issue. 15:55:58 <LeeF> ack AndyS 15:56:10 <kasei> AndyS: graphs might be read only anyway. 15:56:37 <kasei> LeeF: hearing general concesus that shouldn't be an error to insert into a graph that doesn't exist. 15:56:38 <AxelPolleres> I'd suppose that implementations could reject insertions into the default graph? 15:56:50 <AxelPolleres> (those that don't have a default graph) 15:56:55 <kasei> ... since current draft is the other way around, let's make it a proposal. 15:57:28 <LeeF> PROPOSED: 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 <SteveH> seconded 15:57:37 <dcharbon2> +1 15:57:39 <AxelPolleres> +1 15:57:40 <MattPerry> +1 15:57:41 <pgearon> +0 15:57:44 <LeeF> 0 15:57:48 <chimezie> +1 15:57:49 <ivan> +1 15:57:49 <AndyS> +1 15:57:49 <kasei> +1 15:57:52 <bglimm> +1 15:57:58 <LeeF> 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 <AxelPolleres> (exception being the default graph...) 15:58:29 <kasei> LeeF: heard that create and drop should stick around. might return when we continue discussion about datasets. 15:58:35 <kasei> ... will discuss with protocol issues. 15:58:43 <AndyS> and LOAD ... INTO ... 15:59:16 <kasei> LeeF: didn't get to blank nodes in template for delete, and dataset clauses. 15:59:21 <kasei> ... will do them next week. 15:59:24 <AxelPolleres> just to put it in again... regrets for next week from me, BTW 15:59:55 <Zakim> -pgearon 15:59:58 <pgearon> sorry, 16:00:05 <pgearon> yes, I'm comfortable with that 16:00:14 <kasei> LeeF: will follow up with pgearon. 16:00:28 <bglimm> bye 16:00:30 <Zakim> -Ivan 16:00:31 <Zakim> -Chimezie_Ogbuji 16:00:31 <Zakim> -dcharbon2 16:00:32 <AxelPolleres> bye all 16:00:35 <AndyS> ADJOURNED 16:00:37 <Zakim> -MattPerry 16:00:43 <Zakim> -bglimm 16:00:47 <Zakim> -SteveH 16:00:53 <Zakim> -LeeF 16:00:57 <Zakim> -AxelPolleres 16:00:59 <Zakim> -kasei 16:01:01 <Zakim> -Sandro 16:01:11 <Zakim> -OlivierCorby 16:01:13 <Zakim> -AndyS 16:01:15 <Zakim> SW_(SPARQL)10:00AM has ended 16:01:17 <Zakim> Attendees were LeeF, bglimm, AndyS, pgearon, OlivierCorby, +1.603.897.aaaa, kasei, MattPerry, Sandro, +1.919.332.aabb, dcharbon2, Chimezie_Ogbuji, Ivan, SteveH, AxelPolleres # SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000381