Chatlog 2010-02-23

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