12:04:31 RRSAgent has joined #sparql 12:04:31 logging to http://www.w3.org/2010/03/25-sparql-irc 12:04:33 RRSAgent, make logs world 12:04:33 Zakim has joined #sparql 12:04:35 Zakim, this will be 77277 12:04:35 ok, trackbot; I see SW_(SPARQLF2F)8:00AM scheduled to start 4 minutes ago 12:04:36 Meeting: SPARQL Working Group Teleconference 12:04:36 Date: 25 March 2010 12:04:41 zakim, this will be SPARQL 12:04:41 ok, LeeF; I see SW_(SPARQLF2F)8:00AM scheduled to start 4 minutes ago 12:05:20 +MIT262 12:07:42 Present: AxelPolleres, bglimm, AndyS, SteveH, LeeF, Ivan, kasei, Souri, MattPerry, pgearon 12:08:08 Agenda: http://www.w3.org/2009/sparql/wiki/F2F3_Agenda 12:08:40 SteveH has joined #sparql 12:11:58 pgearon_ has joined #sparql 12:14:29 scribe: bglimm 12:15:05 Agendum: Process for time permitting features 12:15:13 http://www.w3.org/2009/05/sparql-phase-II-charter.html 12:15:13 http://www.w3.org/2009/sparql/wiki/FeatureProposal 12:15:24 AxelPolleres: some things are marked as time permitting 12:15:34 MattPerry has joined #sparql 12:15:41 ... there is good progress on entailments regimes and property paths 12:16:12 dcharbon2 has joined #sparql 12:16:19 ... we though we can move within the group to consider them as non-removable 12:16:32 PROPOSED: The working group will proceed the time-permitting feature Entailment to Rec 12:16:58 +1 12:17:49 PROPOSED: The working group will intends to take the time-permitting feature "Entailment" through to Rec 12:17:53 +1 12:17:56 +1 12:17:57 +1 12:18:01 +1 12:18:01 Souri has joined #sparql 12:18:28 RESOLVED: The working group will intends to take the time-permitting feature "Entailment" through to Rec 12:18:38 AxelPoelleres: This is for now mainly an internal decision and does not need to be advertised. 12:18:51 ... I think we can do the same for property paths 12:18:59 PROPOSED: The working group will intends to take the time-permitting feature "PropertyPaths" through to Rec 12:19:02 +1 12:19:26 +1 12:19:35 +1 12:19:53 RESOLVED: The working group will intends to take the time-permitting feature "PropertyPaths" through to Rec 12:20:08 AxelPolleres: These were the two easy ones 12:20:23 ... I want to check the progress of the other ones too. 12:20:36 ... Function library made some progress too 12:21:32 ... The comma-select lists seems to be resolved to not have commas 12:21:46 LeeF: That is resolved. 12:22:06 AxelPolleres: Ok, we don't need to address that any more. 12:22:20 ... Then there is absic federated queries 12:22:32 s/absic/basic 12:23:02 LeeF: Eric is writing something up for that. 12:23:11 Syntax feature was not just commas (have put IN,NOT IN to syntax) 12:23:33 ... Andy and I had a short conversation about it. I think we should keep it time permitting, but we may have something for this in the end 12:23:57 AxelPolleres: Lee, can you get a more precise timeline for the feature? 12:24:18 ... Can we put an action on LeeF to ask Eric for his timeline? 12:24:45 LeeF: Eric said he'll have something ready next week. 12:24:59 LeeF: I'll liase with Eric on this. 12:25:05 ACTION: LeeF to liase with Eric on BFQ and try to get a time schedule. 12:25:05 Created ACTION-203 - Liase with Eric on BFQ and try to get a time schedule. [on Lee Feigenbaum - due 2010-04-01]. 12:25:30 AxelPolleres: Any progress on IN and BETWEEN operators? 12:25:54 AndyS: IN is in the grammar, BETWEEN is not 12:26:11 IN is in the grammar, BETWEEN unclear.... no real enthusiasm. 12:26:32 ... I didn't see much enthusiasm for anything more than what we have now 12:27:17 SteveH has joined #sparql 12:27:23 IvanH: Adding features after last call, it is difficult to put them in. So we have to add it now if we want it. 12:28:28 .... if it is just a small feature that goes into one of the existing documents like IN, then it can possibly be added, but adding more ocuments is not really possible. 12:29:02 AndyS: Could we add some documents now and turn it into a note if we run out of time? 12:30:00 AxelPolleres: I just want to get some order into the time permitting features. 12:30:26 ... I want to decide which things go definitely in and which ones we will definitely not in 12:31:16 .... property path and entailment is clearly in, function library is being worked on, but we should push it a bit more 12:31:16 agreement that IN/BETWEEN is in the scope ofTF-Func, I am fine for the moment. 12:31:52 ... anything to add for the time permitting features discussion? 12:32:05 ... Ok, lets go to the update issues 12:32:20 ... The agenda lists several topics that need discussion 12:32:40 ... we want to nail down the syntax during the F2F 12:32:49 ... First: CREATE and DROP 12:33:15 ... CREATE and DROP are currently in the spec. 12:33:21 http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml is the current draft of the SPARQL Update spec 12:33:46 q+ to ask about SILENT 12:33:49 ?: We decided that we want to be able to create a graph explicitly 12:33:57 s/?/pgearon/ 12:34:02 q+ 12:34:06 RRSAgent, pointer? 12:34:06 See http://www.w3.org/2010/03/25-sparql-irc#T12-34-06 12:34:08 INSERT GRAPH WHERE {} 12:34:31 AxelPolleres: Is that the same as create graph ? 12:35:06 INSERT { GRAPH { } } WHERE { } is equivalent to CREATE GRAPH ? 12:35:44 LeeF: I am not sure it is the same 12:35:55 INSERT { GRAPH { } } WHERE { FILTER(false) } 12:36:13 pgearon: Some implementations might treat it as the same, others might not 12:37:34 LeeF: Difference between my and AndyS is that in Andy's the filter fails the only identity solution, in both cases I think the graph store wouldn't do anything 12:37:35 agreement that "empty insertion" doesn't create graph? 12:37:37 SteveH has joined #sparql 12:37:49 q+ 12:38:10 IvanH: We always agree that creating graphs is useful, so what are we discussing here? 12:38:18 ack LeeF 12:38:18 LeeF, you wanted to ask about SILENT 12:38:48 LeeF: I wanted to discuss whether we want to keep silent for CREATE and DROP 12:38:59 ... from a syntax point of view 12:39:07 ... What does it do? 12:39:19 AxelPolleres: It throws no errors. 12:39:44 LeeF: We need to tighten up the way the spec talks about errors 12:39:51 we have the errors already defined in protocol, BTW, GraphDoesNotExist, GraphAlreadyExists... 12:40:08 q+ on non-silent if the graph exists and and create occurs 12:40:20 LeeF: I am happy about the idea of having SILENT 12:40:55 AxelPolleres: Would we need SILENT also for other update constructs? 12:41:12 LeeF: It is a common thing for CREATE and DROP 12:41:50 As for SILENT in other statements, I wouldn't see any errors except query syntax errors in other statements except CREATE/FROP to be honest, though 12:41:59 pgearon: Implementations at the moment give you an error or not. It would be good if we can configure this. 12:42:21 SteveH: In SQL you can also force it to not raise error for key violations etc 12:42:38 LeeF: Is anybody proposing to add that for other constructors? 12:42:46 AxelPolleres: I don't think so. 12:42:51 LeeF: Lets move on then. 12:42:52 q? 12:43:10 ack Souri 12:43:35 Souri: How do you want to see a store as graph store or quad store? 12:44:27 ... If a query comes in, are we distinguishing between the case when we have an empty graph or the graph just does not exist? 12:44:48 LeeF: If we have drop and create, this implies that we can have empty graphs 12:45:09 ... you can also insert into a graph that does not exist, that will just create the graph 12:45:47 Souri: If a query comes in for an empty graph and the query want to select something it is different from the situation when there is no such graph 12:46:37 q? 12:46:38 ... we don't really know beforehand which graphs are there, there are not really any graphs beforehand 12:47:02 ASK {GRAPH {} } 12:47:04 ? 12:47:18 SELECT ?g { GRAPH ?g {}} 12:47:19 ASK { GRAPH { } } 12:47:46 LeeF: Both queries distinguish this difference 12:47:50 q? 12:47:55 ack AndyS 12:47:59 ack AndyS 12:48:08 AndyS: I think the behaviour is clear in the query spec. 12:48:15 Souri has joined #sparql 12:48:40 ... RDF assumes that if there are no triples, then there is no graph 12:49:25 +q 12:49:37 ... the difference is whether you do data management or not and I think we need a clear model for what we want 12:49:48 I thought we did have an emerging consensus model :) 12:50:15 ... I don't think there is one model that suits all situations 12:51:03 andy: 1 -- all named graphs exist [except RDF has no empty graphs] 12:51:03 andy: 2 -- auto-create: add+remove ... then exists? (sql insert row) 12:51:03 andy: 3 -- fixed dataset (sql create table) 12:51:03 andy: 4 -- explicit add new graphs 12:51:32 I'm not sure that the model that I thought was emerging is captured in those 4 :-) 12:51:58 I hear: 12:51:59 AndyS: There might be even more model 12:51:59 * OPTION 1: all named graphs exist 12:51:59 * OPTION 2: created (explicitly or implicitly) graphs exist (whether empty or not) 12:52:00 * OPTION 3: only graphs with triples in them exist (invalidates CREATE/DROP) = quads 12:52:40 LeeF: Model I heard emerging is that graphs exist as an entity of their own 12:53:03 ... I haven't heard support for explicit dropping of empty graphs 12:53:41 ... System can refuse queries, e.g., they can refuse queries to create a graph if they have just a fixed data set 12:53:46 I had thought we are heading towards Option 2 so far... 12:53:54 AndyS: Implicit graph creation seems important to people 12:54:39 q? 12:54:41 q? 12:55:01 ... It would be best if a processor can decide upfront whether it will reject the query and not generate a runtime error half way through processing a query 12:55:07 SteveH has joined #sparql 12:55:15 ... pure quad stores need some extra triples to decribe graphs for Option 2 to get around that 12:55:27 ack ivan 12:55:27 ivan, you wanted to comment on non-silent if the graph exists and and create occurs 12:55:30 IvanH: I am not sure that there cannot be empty graphs. 12:55:59 q+ ivan 12:56:10 ack pgearon 12:56:11 AndyS: There is just one empty set, so all empty graphs are the same under this view 12:56:53 I liked the suggestion of graph store as set of defaul graph + (name, graph) tuples 12:56:56 q+ ivan to comment on non-silent if the graph exists and and create occurs 12:57:25 pgearon: The fact that RDF does not have an idea about changing graphs, but the way we look at this in update means that graphs can evolve over time 12:57:40 ... from that point of view we can have different empty graphs 12:57:53 zakim, who is here? 12:57:53 SW_(SPARQLF2F)8:00AM has not yet started, sandro 12:57:54 On IRC I see SteveH, Souri, dcharbon2, MattPerry, pgearon, Zakim, RRSAgent, ivan, AndyS, LeeF, AxelPolleres, bglimm, iv_an_ru, karl, sandro, AlexPassant, kasei, trackbot 12:58:27 Present+ dcharbon2, Souri, MattPerry, AlexPassant 12:58:29 ... we are diverging here anyway from RDF because RDF itself does not consider any changes to a graph, but we do 12:59:08 AxelPolleres: Can I interpret this as support for having empty graphs? 12:59:25 ... The fact that we have drop and create also seems to go in this direction 13:00:12 pgearon: it would be odd to assume that everything that was not dropped exists 13:01:09 Test case: SELECT ?g { GRAPH ?g {} } => ? ; add quads (q,s,p,o) ; delete (q,s,p,o) ; SELECT ?g { GRAPH ?g {} } => ? 13:01:16 LeeF: The approach that all named graphs exists worries me a bit because this might prevent two graph stores with the same graphs 13:01:17 s/quads/quad 13:01:26 lee: I'd like us to be supportive of the (unfortunate?) state of the world where the same named graph occurs with different contents in multiple quadstores. 13:01:33 q? 13:01:34 q+ 13:01:56 s/two graph stores with the same graphs/two graph stores with the same graph names with different contents/ 13:02:06 ack Souri 13:02:20 q+ 13:02:24 Souri: If we don't have to explicitly create a graph, that would be more clear conceptually. 13:02:28 q+ to ask souri if graph names are dynamic in RDF2RDB? 13:02:47 q+ to ask whether we can narrow down to 2 options over all 13:02:50 q- 13:02:57 ack dcharbon2 13:02:59 ack dcharbon 13:04:05 dcharbon2: Couldn't we codify that by assuming there is a graph of graphs (like a dataset) nd you can query this extra graph? 13:04:22 "system gaph" seems to be the way to encode empty graph existence in quad stores. 13:04:30 Souri: We do not know which graphs are in the data. 13:05:15 Sandro: Can you not query the data to see which graphs exist? 13:05:29 Souri: We would have to do that for each query. 13:05:38 AlexPassant2 has joined #sparql 13:05:44 q? 13:06:40 Souri: Every query would have to create a corresponding view 13:07:21 souri: [[maybe?]] the set of graphs which exist, in our RDB2RDF approach, is only defined for a particular query 13:07:27 ack AndyS 13:07:27 AndyS, you wanted to ask souri if graph names are dynamic in RDF2RDB? 13:09:04 SteveH: I like the approach that if you remove the last triple, the graph can disappear. 13:09:21 SteveH: A lot of the trivial implementation of sparql are pure quads, where removing the last quad removes the graph. 13:09:40 AndyS has joined #sparql 13:09:58 q+ 13:10:07 SteveH: This ould be implementation defined. 13:10:15 s/ould/would/ 13:10:23 q+ to argue against implementation defined, since it's pretty trivial to go either way 13:10:47 AxelPolleres: This all ends up in the question whether we allow for empty graphs or not 13:11:37 .... you could implicitly create a graph on insert and implicitly drop it when it is empty 13:11:58 Souri has joined #sparql 13:13:54 q- 13:14:05 AxelPolleres: I see 3 ways to go: 1) Having empty graphs (quads only) 2) not having them 3) allow both and service descriptions are used to declare what the store does 13:14:08 q? 13:14:14 ack Axel 13:14:14 AxelPolleres, you wanted to ask whether we can narrow down to 2 options over all 13:14:45 Sandro: A graph that you don't know is not the same as the empty graph 13:15:02 If you are asked to create it, then you know it is empty 13:15:12 q+ 13:15:15 s/If/...If/ 13:15:33 My thoughts are at: http://www.w3.org/2009/sparql/wiki/Lees_Update_Graph_Model 13:15:59 Souri: If we are querying an empty graph is that different from querying something that does not exist? 13:16:13 sandro: think about stores which can sometimes query the web.... what does CREATE mean in that case? I think it means "I know this graph, and it's empty." 13:16:24 ... it gets difficult to distinguish the two situations 13:16:30 q+ if we allow a choice, don't we need to spec what happens in each case? 13:16:42 q+ 13:16:51 ack souri 13:16:53 Can we go around and ask what current implementations do on queries for "non-existinent/non-known" graphs? 13:17:41 pgearon: Systems that want permissions on who can read and write to a graph are complicated when we assume that all possible graphs exist 13:18:03 ... If you have to explicitly create something, then setting permissions would be easier 13:18:31 Sandro: You could do that by setting this on the quad level 13:18:54 seems Paul's use case needs "default" permissions then for implicit creation? 13:19:11 pgearon: I know permissions are outside of the spec, but they are still necessary 13:19:14 q? 13:19:27 ack pgearon 13:19:58 Souri, I think the case that you are concerned about for RDBs can be handled by an engine that posits a universe that contains all possible graphs, many of which are empty -- then any FROM NAMED in a query always refers to an existing graph, and you can just do the natural thing (which is to treat nonexistent graphs as empty). The problem occurs if someone asks this query: SELECT ?g { GRAPH ?g { } } -- what would you _like_ the results of that query to be in the RD 13:21:09 pgearon: If we have create permissions are easy. If we create implicitly it is more difficult 13:21:40 SteveH: You could just have a command for setting permission. I can't see how create makes a real difference 13:21:59 SteveH: setting permission could implicitely create it. 13:22:31 q? 13:22:37 Lee, I agree. The query you mentioned would be a bit difficult to answer. We could return the SELECT distinct FROM all the relational views (needs a UNION). The semantics may be that "these are the non-empty graphs" 13:22:39 AndyS: I see you want CREATE so that you can set permission at creation time, but would you object to also have systems that do it differently? 13:22:43 q+ 13:22:51 ack dcharbon2 13:22:52 ack dcharbon 13:22:53 pgearon: No, but I would like to have CREATE in the language 13:23:05 q+ to ask whether we have "graph created", "graph dropped" in the protocol? 13:24:14 dcharbon2: If the endpoint supports having empty graphs, we would have to define the behaviour in this case, e.g., getting a UR back for an empty but existing graph versus getting an empty answer 13:25:02 AndyS: There could be 2 different definitions, one for systems with bookkeeping and one for systems without 13:25:27 "bookkeeping" 13:25:48 q? 13:25:50 q+ 13:25:51 andy: I like "bookkeeping" functions, which are perhaps optional. 13:26:00 q- 13:26:06 ack ivan 13:26:20 +1 for andy's book keeping concept 13:27:52 IvanH: I don't understand what's happening. A graph has a URI, no data store knows whether that graph is empty or not. We only add a URI to our knowledge, we just add a URI to those graphs we know about, so create is probably not even the right keyword, it is more add 13:27:54 +1 to ivan 13:28:43 sandro: A very safe form of CREATE is where the URI is owned by this quadstore. 13:28:44 q? 13:28:54 ... There is a process of minting a new fresh URI, but normally, you just add an existing URI to the store 13:29:04 sandro, even when it's owned by you, someone else might have asserted triples in it previously, no? 13:29:12 so, maybe just safeER. 13:29:25 perhaps, kasei 13:29:29 ack axel 13:29:29 AxelPolleres, you wanted to ask whether we have "graph created", "graph dropped" in the protocol? 13:29:40 pgearon: I do create a local version of the graph that sits somewhere for a given URI, so there is a difference 13:30:27 AxelPolleres: Renaming CREATE into ADD solves Ivan's concern, but gives a slightly different view. 13:31:14 Can we go around and ask what current implementations do on queries for "non-existinent/non-known" graphs? 13:31:20 AndyS: I have a pure quad store and one where empty graphs can be in the store if it has been mentioned before 13:32:21 SteveH: 4Store has a difference between empty graphs and non-existing graphs (pure quad store), but we hide this difference from users as good as we can 13:32:29 {GRAPH {}} 13:32:38 Perhaps no one wants the answer to SELECT ?g WHERE { GRAPH ?g {} } if we assume all graphs exist - or we'd need to specify that you get nothing back in that case 13:32:51 else - it's an infinite list 13:32:57 what about SELECT * FROM WHERE {} 13:33:05 SteveH: 5store is a pure quadstore so it doesn't distinquish existing from empty. 13:33:30 ^ - non-existing 13:34:10 pgearon: mulgara is quadstore with bookkeeping, so you can query for empty graphs 13:34:27 ... if you select from a graph that does not exist it gives an error 13:35:14 LeeF: same as pgearon. If you specify a graph that is not in the graph store, then it's an error 13:36:24 dcharbon2: Stores I know of mostly don't have bookkeeping 13:36:55 Souri: Oracle has a triple store, no named graphs support 13:37:40 ... queries for non-existing graphs return empty results, we are planning to support named graphs 13:39:22 ... for security, we thought about having certain namespaces that are allowed for inserts, like private datasets for users 13:39:54 AxelPolleres: In that model if you ask for a model that does not exist would that give an error 13:40:02 Souri: Yes. 13:40:53 ... if you don't have the privildges to see it, then it is an error 13:41:08 ... we say it doesn't exist 13:42:42 Greg: My new store is a quad store with no bookkeeping, my old one had support for empty graphs 13:43:00 AxelPolleres: It seems we have a clear undecided situation 13:43:23 I don't really understand the full question that Axel is asking :) 13:43:25 a clear win for punting to the service description! 13:43:39 ... it seems we should allow for both cases 13:44:15 ... one problem that could arise in the spec is that the update behaviour differs for the two cases 13:44:28 IvanH: I am worried about allowing both options 13:44:41 we could define select ?g where { graph ?g {} } to be empty... but then we need to figure out how to clean up bookkeeping systems... I'm leaning toward defining this to be empty 13:44:43 ... interoperability is limited then 13:44:49 I see a problem for "no bookkeeping" implementations with this sequence of statements: CREATE ; ASK FROM NAMED { GRAPH { } } -- a no bookkeeping impl would return FALSE, right? 13:44:55 Did I get this right? on query { GRAPH {}} where is "unknown": andy : false; steve: false; paul : error; lee: error; david: false; matt: don't deal with named graphs yet, but prefer false ; greg: both 13:45:04 i don't see how we can include a CREATE statement and still have the spec bless this returning FALSE 13:45:22 IvanH: Some systems give error, while others give an empty answer. That's not good 13:45:41 q+ 13:46:01 q? 13:46:28 axel - right for me - I also have an impl that can return true (empty graphs exist) 13:46:36 What about: SELECT COUNT(*) WHERE { GRAPH { ?x ?y ?z } } ? 13:47:05 AxelPolleres, I'm sorry, I don't know if that's right for me - I need more context of the full query (incl. RDF dataset) 13:47:10 dcharbon2: A select for empty graphs could either return an infinite list or an empty answer 13:48:03 THat one is NOT asking for empty graphs {GRAPH ?G {} } 13:48:44 SELECT * {GRAPH ?G {} } 13:48:51 so, really... got the query wrong - query for all empty should return empty, otherwise it's an infinite list 13:49:05 ASK {GRAPH {} } 13:50:11 AndyS: This shows the difference between a dataset and a graph store 13:50:22 CREATE ; ASK FROM NAMED { GRAPH { } } 13:51:02 Souri has joined #sparql 13:51:10 LeeF: Should be true, but requires bookkeeping 13:51:58 SteveH: Create affects the graph store and asks is for the datasets 13:52:22 CREATE ; ASK { GRAPH { } } 13:53:17 LeeF: Here the query does not define a dataset, so the implemenation decides on the default dataset 13:54:16 LeeF: What would the update spec say for this? 13:54:49 SteveH: Graph stores and datasets are different things 13:55:16 q+ 13:55:20 q- 13:55:57 q? 13:56:02 LeeF: I think there needs to be some relationship between the graph store and the datasets 13:56:12 AndyS, if it's already true, then I'm in agreement with you :) 13:56:37 http://www.w3.org/TR/rdf-sparql-query/#namedGraphs 13:56:57 kasei: section 8.2.2 of the spec means that you have to return true or an error 13:57:27 SteveH: I am happy to return an error from a quad store 13:57:46 Sandro: Would you also be happy to support bookkeeping? 13:58:18 SteveH: No, I removed that from my last store because it is so much extra effort that I don't want it. Too many indexes. 13:58:55 q+ 13:58:57 q+ to wonder if his update proposal makes the quad store people unhappy 13:59:00 AxelPolleres: It seems we have 2 issues 1) bookkeeping yes or no 2) difference between datasets and graph stores 13:59:04 2 issues floating around ... i) bookkeeping yes/no and ii) dateaset vs. graphstore 13:59:39 SteveH: I read section 8.2.2. and I can't see it says anything about the { } pattern 13:59:59 AndyS: There is an explicit algebra operator that deals with that section 5.2.1 14:00:01 q? 14:00:09 Zakim, ack me 14:00:09 I see kasei, LeeF on the speaker queue 14:00:13 http://www.w3.org/TR/rdf-sparql-query/#defn_evalGraph 14:00:30 LeeF: Maybe we can just agree on specific details of the update language. 14:00:37 http://www.w3.org/2009/sparql/wiki/Lees_Update_Graph_Model 14:00:46 ... it seems we need to make a decision on ii) 14:01:06 ... I wonder whether the stuff on the wiki page does not satisfy anyones requirements 14:01:28 3rd bullet is troublesome to me 14:01:51 q+ 14:01:52 "A SPARQL Update operation is performed in the context of a GraphStore" 14:02:08 (and haven't properly read the email yet - sorry) 14:02:09 q- 14:02:15 ack LeeF 14:02:15 LeeF, you wanted to wonder if his update proposal makes the quad store people unhappy 14:02:30 AxelPolleres: Lets wrap up because the break is coming up. 14:02:50 LeeF: The wiki page mainly reflects my view. 14:03:42 q+ 14:04:04 ... I can't see that the ASK query should be allowed to return false by the spec 14:04:27 sandro: we could say "empty graphs MAY be implicitely deleted". 14:04:45 +1 to sandro's suggestion 14:04:53 +1 to sandro's suggestion 14:04:59 +1 14:05:00 +1 14:05:09 +1 14:05:23 -0 14:05:27 :-) 14:05:44 +1 14:06:00 can someone else take over scribing on MIT side? 14:06:01 +1 14:06:27 lee: not the best solution for interoperability, but maybe the best we can do. 14:06:28 For clarification: when? during update or immediately after whole request done (multiple oerations)? 14:25:14 Souri has joined #sparql 14:39:28 scribenick: pgearon 14:39:35 scribe: paul gearon 14:39:48 discussing http://www.w3.org/2009/sparql/wiki/Lees_Update_Graph_Model 14:39:59 ... asa a proposal to move forward. 14:40:23 LeeF: would like to have consensus on the wiki page http://www.w3.org/2009/sparql/wiki/Lees_Update_Graph_Model and work this into the spec 14:40:25 q? 14:40:32 q- 14:40:43 zakim, clear the q! 14:40:43 I don't understand 'clear the q!', LeeF 14:40:47 q+ 14:40:58 ack AndyS 14:41:13 AndyS: like the proposal on the wiki, but nervous about point 3 14:41:35 prop 3 links dataset and graph store 14:41:57 LeeF: removed this point 14:43:14 http://www.w3.org/2009/sparql/wiki/index.php?title=Lees_Update_Graph_Model&oldid=1995 14:43:29 PROPOSED: Close ISSUE-20 via adoption http://www.w3.org/2009/sparql/wiki/index.php?title=Lees_Update_Graph_Model&oldid=1995 in SPARQL Update 14:43:38 +1 14:43:41 +1 14:43:41 +1 14:43:46 +1 14:43:49 +1 14:43:53 +1 14:43:53 +1 14:44:04 +0 (I guess it's good enough, but I wish I understand the semweb implications better) 14:44:25 +1 14:45:25 SteveH: points out that different order of loading data can lead to different results. Not sure if this is a significant enough use case to be a problem for us 14:45:38 +1 14:45:52 +1 14:45:52 q+ to add sd: extension proposal 14:46:03 RESOLVED: Close ISSUE-20 via adoption http://www.w3.org/2009/sparql/wiki/index.php?title=Lees_Update_Graph_Model&oldid=1995 in SPARQL Update, no objections, Sandro abstaining 14:46:41 ISSUE-20: RESOLVED: Close ISSUE-20 via adoption http://www.w3.org/2009/sparql/wiki/index.php?title=Lees_Update_Graph_Model&oldid=1995 in SPARQL Update, no objections, Sandro abstaining 14:46:42 ISSUE-20 Graphs aware stores vs. quad stores for SPARQL/update (empty graphs) notes added 14:46:46 AxelPolleres: wants to have an sd flag to indicate if implementations always preserve empty graphs 14:46:48 trackbot, close ISSUE-20 14:46:48 ISSUE-20 Graphs aware stores vs. quad stores for SPARQL/update (empty graphs) closed 14:48:11 q? 14:48:14 ack AxelPolleres 14:48:14 AxelPolleres, you wanted to add sd: extension proposal 14:48:33 not going to add sd: at the moment 14:49:23 q+ 14:50:04 Ivan: concerned about SILENT on CREATE, but spec is already clear 14:50:41 ack kasei 14:51:05 kasei: SILENT on DROP is different in that different implementations may or may not have errors on a DROP without SILENT 14:51:32 AxelPassant: this is similar to CREATE, and depends on the implementation. SILENT will always cover the user 14:51:45 greg: CREATE/DROP is not necessarily a noop on graph stores that drop empty graphs immediately, but could be an error note should be made in the spec. 14:52:56 paul: It's an ERROR in all implementations if you CREATE when the graph isn't empty. 14:53:40 I'm ambivalent about CREATE GRAPH vs. ADD GRAPH 14:53:41 reponse to Souri: are we covered for calling CREATE on graphs which already exist and have data 14:54:20 ADD is as bad - may presume GET deref 14:54:52 INSERT GRAPH ? 14:55:35 CREATE isn't perfect, but ADD is worse. OBTAIN? PREPARE? BEGIN? OPEN? 14:55:48 Ivan: concerned that CREATE is used when we are simple referring to a graph that already exists (even if it's just conceptually) 14:55:50 STORE? REMEMBER? HOLD? 14:56:37 USING? 14:57:38 INSERT GRAPH ; INSERT { } ; DELETE { } ; DELETE GRAPH 14:57:51 INSERT GRAPH , no? 14:58:14 INSERT { GRAPH ..} WHERE ... is too close 14:59:24