Chatlog 2010-03-25

See original RRSAgent log and preview nicely formatted version.

Please justify/explain all edits to this page, in your "edit summary" text.

# clockwise from the top
<sandro> PRESENT: bglimm, axel, andy, steveh, paul_gearon, lee, davidc, alex, souri, perry, sandro, kasei, ivan, ericP
12:04:31 <RRSAgent> RRSAgent has joined #sparql
12:04:31 <RRSAgent> logging to http://www.w3.org/2010/03/25-sparql-irc
12:04:33 <trackbot> RRSAgent, make logs world
12:04:33 <Zakim> Zakim has joined #sparql
12:04:35 <trackbot> Zakim, this will be 77277
12:04:35 <Zakim> ok, trackbot; I see SW_(SPARQLF2F)8:00AM scheduled to start 4 minutes ago
12:04:36 <trackbot> Meeting: SPARQL Working Group Teleconference
12:04:36 <trackbot> Date: 25 March 2010
12:04:41 <LeeF> zakim, this will be SPARQL
12:04:41 <Zakim> ok, LeeF; I see SW_(SPARQLF2F)8:00AM scheduled to start 4 minutes ago
12:05:20 <LeeF> +MIT262
#12:07:42 <LeeF> Present: AxelPolleres, bglimm, AndyS, SteveH, LeeF, Ivan, kasei, Souri, MattPerry, pgearon
12:08:08 <LeeF> Agenda: http://www.w3.org/2009/sparql/wiki/F2F3_Agenda
12:08:40 <SteveH> SteveH has joined #sparql
12:11:58 <pgearon_> pgearon_ has joined #sparql
12:14:29 <bglimm> scribe: bglimm
12:15:05 <bglimm> Topic: Process for time permitting features
12:15:13 <AxelPolleres> http://www.w3.org/2009/05/sparql-phase-II-charter.html
12:15:13 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/FeatureProposal
12:15:24 <bglimm> AxelPolleres: some things are marked as time permitting
12:15:34 <MattPerry> MattPerry has joined #sparql
12:15:41 <bglimm> ... there is good progress on entailments regimes and property paths
12:16:12 <dcharbon2> dcharbon2 has joined #sparql
12:16:19 <bglimm> ... we though we can move within the group to consider them as non-removable 
12:16:32 <AxelPolleres> PROPOSED: The working group will proceed the time-permitting feature Entailment to Rec
12:16:58 <bglimm> +1
12:17:49 <AxelPolleres> PROPOSED: The working group will intends to take the time-permitting feature "Entailment" through to Rec
12:17:53 <bglimm> +1
12:17:56 <AxelPolleres> +1
12:17:57 <AndyS> +1
12:18:01 <dcharbon2> +1
12:18:01 <Souri> Souri has joined #sparql
12:18:28 <AxelPolleres> RESOLVED: The working group will intends to take the time-permitting feature "Entailment" through to Rec
12:18:38 <bglimm> AxelPolleres: This is for now mainly an internal decision and does not need to be advertised. 
12:18:51 <bglimm> ... I think we can do the same for property paths
12:18:59 <AxelPolleres> PROPOSED: The working group will intends to take the time-permitting feature "PropertyPaths" through to Rec
12:19:02 <pgearon_> +1
12:19:26 <AxelPolleres> +1
12:19:35 <MattPerry> +1
12:19:53 <AxelPolleres> RESOLVED: The working group will intends to take the time-permitting feature "PropertyPaths" through to Rec
12:20:08 <bglimm> AxelPolleres: These were the two easy ones
12:20:23 <bglimm> ... I want to check the progress of the other ones too. 
12:20:36 <bglimm> ... Function library made some progress too
12:21:32 <bglimm> ...  The comma-select lists seems to be resolved to not have commas
12:21:46 <bglimm> LeeF: That is resolved. 
12:22:06 <bglimm> AxelPolleres: Ok, we don't need to address that any more. 
12:22:20 <bglimm> ... Then there is absic federated queries
12:22:32 <bglimm> s/absic/basic
12:23:02 <bglimm> LeeF: Eric is writing something up for that. 
12:23:11 <AndyS> Syntax feature was not just commas (have put IN,NOT IN to syntax)
12:23:33 <bglimm> ... 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 <bglimm> AxelPolleres: Lee, can you get a more precise timeline for the feature? 
12:24:18 <bglimm> ... Can we put an action on LeeF to ask Eric for his timeline?
12:24:45 <bglimm> LeeF: Eric said he'll have something ready next week.
12:24:59 <bglimm> LeeF: I'll liase with Eric on this.
12:25:05 <AxelPolleres> ACTION: LeeF to liase with Eric on BFQ and try to get a time schedule.
12:25:05 <trackbot> 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 <bglimm> AxelPolleres: Any progress on IN and BETWEEN operators?
12:25:54 <bglimm> AndyS: IN is in the grammar, BETWEEN is not
12:26:11 <AxelPolleres>  IN is in the grammar, BETWEEN unclear.... no real enthusiasm.
12:26:32 <bglimm> ... I didn't see much enthusiasm for anything more than what we have now 
12:27:17 <SteveH> SteveH has joined #sparql
12:27:23 <bglimm> 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 <bglimm> .... 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 <bglimm> AndyS: Could we add some documents now and turn it into a note if we run out of time?
12:30:00 <bglimm> AxelPolleres: I just want to get some order into the time permitting features. 
12:30:26 <bglimm> ... I want to decide which things go definitely in and which ones we will definitely not in
12:31:16 <bglimm> .... property path and entailment is clearly in, function library is being worked on, but we should push it a bit more
12:31:16 <AxelPolleres> agreement that IN/BETWEEN is in the scope ofTF-Func, I am fine for the moment. 
12:31:52 <bglimm> ... anything to add for the time permitting features discussion?
<sandro> Topic: CREATE and DROP
12:32:05 <bglimm> ... Ok, lets go to the update issues
12:32:20 <bglimm> ... The agenda lists several topics that need discussion
12:32:40 <bglimm> ... we want to nail down the syntax during the F2F
12:32:49 <bglimm> ... First: CREATE and DROP
12:33:15 <bglimm> ... CREATE and DROP are currently in the spec.
12:33:21 <LeeF> http://www.w3.org/2009/sparql/docs/update-1.1/Overview.xml is the current draft of the SPARQL Update spec
12:33:46 <LeeF> q+ to ask about SILENT
12:33:49 <bglimm> ?: We decided that we want to be able to create a graph explicitly
12:33:57 <LeeF> s/?/pgearon/
12:34:02 <Souri> q+
12:34:06 <sandro> RRSAgent, pointer?
12:34:06 <RRSAgent> See http://www.w3.org/2010/03/25-sparql-irc#T12-34-06
12:34:08 <AxelPolleres> INSERT GRAPH <a> WHERE {}
12:34:31 <bglimm> AxelPolleres: Is that the same as create graph <a>?
12:35:06 <LeeF> INSERT { GRAPH <a> { } } WHERE { }   is equivalent   to  CREATE GRAPH <a> ?
12:35:44 <bglimm> LeeF:  I am not sure it is the same
12:35:55 <AndyS> INSERT { GRAPH <a> { } } WHERE { FILTER(false) } 
12:36:13 <bglimm> pgearon: Some implementations might treat it as the same, others might not
12:37:34 <bglimm> 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 <AxelPolleres> agreement that "empty insertion" doesn't create graph? 
12:37:37 <SteveH> SteveH has joined #sparql
12:37:49 <AndyS> q+
12:38:10 <bglimm> IvanH: We always agree that creating graphs is useful, so what are we discussing here?
12:38:18 <AxelPolleres> ack LeeF
12:38:18 <Zakim> LeeF, you wanted to ask about SILENT
12:38:48 <bglimm> LeeF: I wanted to discuss whether we want to keep silent for CREATE and DROP
12:38:59 <bglimm> ... from a syntax point of view
12:39:07 <bglimm> ... What does it do?
12:39:19 <bglimm> AxelPolleres: It throws no errors.
12:39:44 <bglimm> LeeF: We need to tighten up the way the spec talks about errors
12:39:51 <AxelPolleres> we have the errors already defined in protocol, BTW,  GraphDoesNotExist,  GraphAlreadyExists...
12:40:08 <ivan> q+ on non-silent if the graph exists and and create occurs
12:40:20 <bglimm> LeeF: I am happy about the idea of having SILENT
12:40:55 <bglimm> AxelPolleres: Would we need SILENT also for other update constructs?
12:41:12 <bglimm> LeeF: It is a common thing for CREATE and DROP
12:41:50 <AxelPolleres> 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 <bglimm> pgearon: Implementations at the moment give you an error or not. It would be good if we can configure this.
12:42:21 <bglimm> SteveH: In SQL you can also force it to not raise error for key violations etc
12:42:38 <bglimm> LeeF: Is anybody proposing to add that for other constructors?
12:42:46 <bglimm> AxelPolleres: I don't think so. 
12:42:51 <bglimm> LeeF: Lets move on then. 
12:42:52 <AndyS> q?
12:43:10 <AxelPolleres> ack Souri
12:43:35 <bglimm> Souri: How do you want to see a store as graph store or quad store?
12:44:27 <bglimm> ... 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 <bglimm> LeeF: If we have drop and create, this implies that we can have empty graphs
12:45:09 <bglimm> ... you can also insert into a graph that does not exist, that will just create the graph
12:45:47 <bglimm> 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 <AxelPolleres> q?
12:46:38 <bglimm> ... we don't really know beforehand which graphs are there, there are not really any graphs beforehand
12:47:02 <AxelPolleres> ASK {GRAPH <g> {} }
12:47:04 <AxelPolleres> ?
12:47:18 <AndyS> SELECT ?g { GRAPH ?g {}}
12:47:19 <LeeF> ASK { GRAPH <a> { } }
12:47:46 <bglimm> LeeF: Both queries distinguish this difference
12:47:50 <AxelPolleres> q?
12:47:55 <AxelPolleres> ack AndyS
12:47:59 <LeeF> ack AndyS
12:48:08 <bglimm> AndyS: I think the behaviour is clear in the query spec.
12:48:15 <Souri> Souri has joined #sparql
12:48:40 <bglimm> ... RDF assumes that if there are no triples, then there is no graph
12:49:25 <pgearon> +q
12:49:37 <bglimm> ... 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 <LeeF> I thought we did have an emerging consensus model :)
12:50:15 <bglimm> ... I don't think there is one model that suits all situations
12:51:03 <sandro> andy: 1 -- all named graphs exist     [except RDF has no empty graphs]
12:51:03 <sandro> andy: 2 -- auto-create:   add+remove ... then exists?  (sql insert row)
12:51:03 <sandro> andy: 3 -- fixed dataset     (sql create table)
12:51:03 <sandro> andy: 4 -- explicit add new graphs
12:51:32 <LeeF> I'm not sure that the model that I thought was emerging is captured in those 4 :-)
12:51:58 <AxelPolleres> I hear:
12:51:59 <bglimm> AndyS: There might be even more model
12:51:59 <AxelPolleres> * OPTION 1: all named graphs exist
12:51:59 <AxelPolleres> * OPTION 2: created (explicitly or implicitly) graphs exist (whether empty or not)
12:52:00 <AxelPolleres> * OPTION 3: only graphs with triples in them exist (invalidates CREATE/DROP) = quads
12:52:40 <bglimm> LeeF: Model I heard emerging is that  graphs exist as an entity of their own
12:53:03 <bglimm> ... I haven't heard support for explicit  dropping of empty graphs
12:53:41 <bglimm> ... 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 <AxelPolleres> I had thought we are heading towards Option 2 so far...
12:53:54 <bglimm> AndyS: Implicit graph creation seems important to people
12:54:39 <LeeF> q?
12:54:41 <sandro> q?
12:55:01 <bglimm> ... 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> SteveH has joined #sparql
12:55:15 <AxelPolleres> ... pure quad stores need some extra triples to decribe  graphs for Option 2 to get around that
12:55:27 <AxelPolleres> ack ivan
12:55:27 <Zakim> ivan, you wanted to comment on non-silent if the graph exists and and create occurs
12:55:30 <bglimm> IvanH: I am not sure that there cannot be empty graphs. 
12:55:59 <LeeF> q+ ivan
12:56:10 <LeeF> ack pgearon
12:56:11 <bglimm> AndyS: There is just one empty set, so all empty graphs are the same under this view
12:56:53 <AndyS> I liked the suggestion of graph store as set of defaul graph + (name, graph) tuples
12:56:56 <LeeF> q+ ivan to comment on non-silent if the graph exists and and create occurs
12:57:25 <bglimm> 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 <bglimm> ... from that point of view we can have different empty graphs
12:57:53 <sandro> zakim, who is here?
12:57:53 <Zakim> SW_(SPARQLF2F)8:00AM has not yet started, sandro
12:57:54 <Zakim> 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 <LeeF> Present+ dcharbon2, Souri, MattPerry, AlexPassant
12:58:29 <bglimm> ... we are diverging here anyway from RDF because RDF itself does not consider any changes to a graph, but we do
12:59:08 <bglimm> AxelPolleres: Can I interpret this as support for having empty graphs? 
12:59:25 <bglimm> ... The fact that we have drop and create also seems to go in this direction
13:00:12 <bglimm> pgearon:  it would be odd to assume that everything that was not dropped exists
13:01:09 <AndyS> Test case: SELECT ?g { GRAPH ?g {} } => ? ; add quads (q,s,p,o) ; delete (q,s,p,o) ; SELECT ?g { GRAPH ?g {} } => ?
13:01:16 <bglimm> 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 <AndyS> s/quads/quad
13:01:26 <sandro> 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 <AxelPolleres> q?
13:01:34 <Souri> q+
13:01:56 <LeeF> s/two graph stores with the same graphs/two graph stores with the same graph names with different contents/
13:02:06 <LeeF> ack Souri
13:02:20 <dcharbon2> q+
13:02:24 <bglimm> Souri: If we don't have to explicitly create a graph, that would be more clear conceptually. 
13:02:28 <AndyS> q+ to ask souri if graph names are dynamic in RDF2RDB?
13:02:47 <AxelPolleres> q+ to ask whether we can narrow down to 2 options over all
13:02:50 <ivan> q-
13:02:57 <LeeF> ack dcharbon2
13:02:59 <LeeF> ack dcharbon
13:04:05 <bglimm> 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 <AxelPolleres> "system gaph" seems to be  the way to encode empty graph existence in quad stores. 
13:04:30 <bglimm> Souri: We do not know which graphs are in the data. 
13:05:15 <bglimm> Sandro: Can you not query the data to see which graphs exist? 
13:05:29 <bglimm> Souri: We would have to do that for each query. 
13:05:38 <AlexPassant2> AlexPassant2 has joined #sparql
13:05:44 <AxelPolleres> q?
13:06:40 <bglimm> Souri: Every query would have to create a corresponding view
13:07:21 <sandro> souri: [[maybe?]]  the set of graphs which exist, in our RDB2RDF approach, is only defined for a particular query
13:07:27 <LeeF> ack AndyS
13:07:27 <Zakim> AndyS, you wanted to ask souri if graph names are dynamic in RDF2RDB?
13:09:04 <bglimm> SteveH: I like the approach that if you remove the last triple, the graph can disappear. 
13:09:21 <sandro> SteveH: A lot of the trivial implementation of sparql are pure quads, where removing the last quad removes the graph.
13:09:40 <AndyS> AndyS has joined #sparql
13:09:58 <Souri> q+
13:10:07 <bglimm> SteveH: This ould be implementation defined.
13:10:15 <bglimm> s/ould/would/
13:10:23 <sandro> q+ to argue against implementation defined, since it's pretty trivial to go either way
13:10:47 <bglimm> AxelPolleres: This all ends up in the question whether we allow for empty graphs or not
13:11:37 <bglimm> .... you could implicitly create a graph on insert and implicitly drop it when it is empty
13:11:58 <Souri> Souri has joined #sparql
13:13:54 <sandro> q-
13:14:05 <bglimm> 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 <AxelPolleres> q?
13:14:14 <AxelPolleres> ack Axel
13:14:14 <Zakim> AxelPolleres, you wanted to ask whether we can narrow down to 2 options over all
13:14:45 <bglimm> Sandro: A graph that you don't know is not the same as the empty graph
13:15:02 <bglimm> If you are asked to create it, then you know it is empty
13:15:12 <pgearon> q+
13:15:15 <bglimm> s/If/...If/
13:15:33 <LeeF> My thoughts are at: http://www.w3.org/2009/sparql/wiki/Lees_Update_Graph_Model
13:15:59 <bglimm> Souri: If we are querying an empty graph is that different from querying something that does not exist? 
13:16:13 <sandro> 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 <bglimm> ... it gets difficult to distinguish the two situations
13:16:30 <dcharbon2> q+ if we allow a choice, don't we need to spec what happens in each case?
13:16:42 <dcharbon2> q+
13:16:51 <LeeF> ack souri
13:16:53 <AxelPolleres> Can we go around and ask what current implementations do on queries for "non-existinent/non-known" graphs? 
13:17:41 <bglimm> 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 <bglimm> ... If you have to explicitly create something, then setting permissions would be easier
13:18:31 <bglimm> Sandro: You could do that by setting this on the quad level
13:18:54 <AxelPolleres> seems Paul's use case needs "default" permissions then for implicit creation?  
13:19:11 <bglimm> pgearon: I know permissions are outside of the spec, but they are still necessary 
13:19:14 <AxelPolleres> q?
13:19:27 <ivan> ack pgearon 
13:19:58 <LeeF> 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 <bglimm> pgearon: If we have create permissions are easy. If we create implicitly it is more difficult
13:21:40 <bglimm> SteveH: You could just have a command for setting permission. I can't see how create makes a real difference
13:21:59 <sandro> SteveH: setting permission could implicitely create it.
13:22:31 <ivan> q?
13:22:37 <Souri> Lee, I agree. The query you mentioned would be a bit difficult to answer. We could return the SELECT distinct <graphURI> FROM all the relational views (needs a UNION). The semantics may be that "these are the non-empty graphs"
13:22:39 <bglimm> 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 <ivan> q+
13:22:51 <LeeF> ack dcharbon2
13:22:52 <LeeF> ack dcharbon
13:22:53 <bglimm> pgearon: No, but I would like to have CREATE in the language
13:23:05 <AxelPolleres> q+ to ask whether we have "graph created", "graph dropped" in the protocol?
13:24:14 <bglimm> 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 <bglimm> AndyS: There could be 2 different definitions, one for systems with bookkeeping and one for systems without
13:25:27 <sandro> "bookkeeping"
13:25:48 <AxelPolleres> q?
13:25:50 <Souri> q+
13:25:51 <sandro> andy: I like "bookkeeping" functions, which are perhaps optional.
13:26:00 <Souri> q-
13:26:06 <LeeF> ack ivan
13:26:20 <pgearon> +1 for andy's book keeping concept
13:27:52 <bglimm> 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 <SteveH> +1 to ivan 
13:28:43 <sandro> sandro: A very safe form of CREATE is where the URI is owned by this quadstore.
13:28:44 <AxelPolleres> q?
13:28:54 <bglimm> ... There is a process of minting a new fresh URI, but normally, you just add an existing URI to the store
13:29:04 <kasei> sandro, even when it's owned by you, someone else might have asserted triples in it previously, no?
13:29:12 <kasei> so, maybe just safeER.
13:29:25 <sandro> perhaps, kasei 
13:29:29 <AxelPolleres> ack axel
13:29:29 <Zakim> AxelPolleres, you wanted to ask whether we have "graph created", "graph dropped" in the protocol?
13:29:40 <bglimm> 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 <bglimm> AxelPolleres: Renaming CREATE into ADD solves Ivan's concern, but gives a slightly different view. 
13:31:14 <AxelPolleres> Can we go around and ask what current implementations do on queries for "non-existinent/non-known" graphs?
13:31:20 <bglimm> 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 <bglimm> 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 <AxelPolleres> {GRAPH <g> {}}
13:32:38 <dcharbon2> 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 <dcharbon2> else - it's an infinite list
13:32:57 <pgearon> what about SELECT * FROM <g> WHERE {}
13:33:05 <sandro> SteveH: 5store is a pure quadstore so it doesn't distinquish existing from empty.
13:33:30 <SteveH> ^ - non-existing
13:34:10 <bglimm> pgearon: mulgara is quadstore with bookkeeping, so you can query for empty graphs
13:34:27 <bglimm> ... if you select from a graph that does not exist it gives an error
13:35:14 <bglimm> LeeF: same as pgearon. If you specify a graph that is not in the graph store, then it's an error
13:36:24 <bglimm> dcharbon2: Stores I know of mostly don't have bookkeeping
13:36:55 <bglimm> Souri: Oracle has a triple store, named graph support is provided by storing triples in units of storage called RDF "models"
13:37:40 <bglimm> ... queries for non-existing graphs return empty results, we are considering support for named graphs at a finer granularity
13:39:22 <bglimm> ... for security, we thought about having certain namespaces (represented by RDF models) that are allowed for inserts, like private datasets for users
13:39:54 <bglimm> AxelPolleres: In that model if you ask for a model that does not exist would that give an error
13:40:02 <bglimm> Souri: Yes. 
13:40:53 <bglimm> ... if you don't have the privildges to see it, then it is an error
13:41:08 <bglimm> ... we say it doesn't exist
13:42:42 <bglimm> Greg: My new store is a quad store with no bookkeeping, my old one had support for empty graphs
13:43:00 <bglimm> AxelPolleres: It seems we have a clear undecided situation
13:43:23 <LeeF> I don't really understand the full question that Axel is asking :)
13:43:25 <kasei> a clear win for punting to the service description!
13:43:39 <bglimm> ... it seems we should allow for both cases 
13:44:15 <bglimm> ... one problem that could arise in the spec is that the update behaviour differs for the two cases
13:44:28 <bglimm> IvanH: I am worried about allowing both options
13:44:41 <dcharbon2> 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 <bglimm> ... interoperability is limited then
13:44:49 <LeeF> I see a problem for "no bookkeeping" implementations with this sequence of statements: CREATE <g1> ; ASK FROM NAMED <g1> { GRAPH <g1> { } }  -- a no bookkeeping impl would return FALSE, right?
13:44:55 <AxelPolleres> Did I get this right? on query { GRAPH <g> {}} where <g> 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 <LeeF> i don't see how we can include a CREATE statement and still have the spec bless this returning FALSE
13:45:22 <bglimm> IvanH: Some systems give error, while others give an empty answer. That's not good
13:45:41 <dcharbon2> q+
13:46:01 <AxelPolleres> q?
13:46:28 <AndyS> axel - right for me - I also have an impl that can return true (empty graphs exist)
13:46:36 <SteveH> What about: SELECT COUNT(*) WHERE { GRAPH <g> { ?x ?y ?z } } ?
13:47:05 <LeeF> 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 <bglimm> dcharbon2: A select for empty graphs could either return an infinite list or an empty answer
13:48:03 <AxelPolleres> THat one is NOT asking for empty graphs {GRAPH  ?G  {} }
13:48:44 <AxelPolleres> SELECT *  {GRAPH  ?G  {} }
13:48:51 <dcharbon2> so, really... got the query wrong - query for all empty should return empty, otherwise it's an infinite list
13:49:05 <AxelPolleres> ASK  {GRAPH  <g>  {} }
13:50:11 <bglimm> AndyS: This shows the difference between a dataset and a graph store
13:50:22 <LeeF> CREATE <g> ; ASK FROM NAMED <g> { GRAPH <g> { } }
13:51:02 <Souri> Souri has joined #sparql
13:51:10 <bglimm> LeeF: Should be true, but requires bookkeeping
13:51:58 <bglimm> SteveH: Create affects the graph store and asks is for the datasets
13:52:22 <AxelPolleres> CREATE <g> ; ASK { GRAPH <g> { } }
13:53:17 <bglimm> LeeF: Here the query does not define a dataset, so the implemenation decides on the default dataset
13:54:16 <bglimm> LeeF: What would the update spec say for this?
13:54:49 <bglimm> SteveH: Graph stores and datasets are different things
13:55:16 <kasei> q+
13:55:20 <dcharbon2> q-
13:55:57 <AxelPolleres> q?
13:56:02 <bglimm> LeeF: I think there needs to be some relationship between the graph store and the datasets
13:56:12 <LeeF> AndyS, if it's already true, then I'm in agreement with you :)
13:56:37 <LeeF> http://www.w3.org/TR/rdf-sparql-query/#namedGraphs
13:56:57 <bglimm> kasei: section 8.2.2 of the spec means that you have to return true or an error
13:57:27 <bglimm> SteveH: I am happy to return an error from a quad store
13:57:46 <bglimm> Sandro: Would you also be happy to support bookkeeping?
13:58:18 <bglimm> 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 <SteveH> q+
13:58:57 <LeeF> q+ to wonder if his update proposal makes the quad store people unhappy
13:59:00 <bglimm> AxelPolleres: It seems we have 2 issues 1) bookkeeping yes or no 2) difference between datasets and graph stores
13:59:04 <AxelPolleres> 2 issues floating around ... i) bookkeeping yes/no and ii) date�aset vs. graphstore
13:59:39 <bglimm> SteveH: I read section 8.2.2. and I can't see it says anything about the { } pattern
13:59:59 <bglimm> AndyS: There is an explicit algebra operator that deals with that section 5.2.1
14:00:01 <AxelPolleres> q?
14:00:09 <SteveH> Zakim, ack me
14:00:09 <Zakim> I see kasei, LeeF on the speaker queue
14:00:13 <AndyS> http://www.w3.org/TR/rdf-sparql-query/#defn_evalGraph
14:00:30 <bglimm> LeeF: Maybe we can just agree on  specific details of the update language. 
14:00:37 <LeeF> http://www.w3.org/2009/sparql/wiki/Lees_Update_Graph_Model
14:00:46 <AxelPolleres> ... it seems we need to make a decision on ii)
14:01:06 <bglimm> ... I wonder whether the stuff on the wiki page does not satisfy anyones requirements
14:01:28 <AndyS> 3rd bullet is troublesome to me
14:01:51 <SteveH> q+
14:01:52 <AndyS> "A SPARQL Update operation is performed in the context of a GraphStore"
14:02:08 <AndyS> (and haven't properly read the email yet - sorry)
14:02:09 <kasei> q-
14:02:15 <LeeF> ack LeeF
14:02:15 <Zakim> LeeF, you wanted to wonder if his update proposal makes the quad store people unhappy
14:02:30 <bglimm> AxelPolleres: Lets wrap up because the break is coming up. 
14:02:50 <bglimm> LeeF: The wiki page mainly reflects my view. 
14:03:42 <AndyS> q+
14:04:04 <bglimm> ... I can't see that the ASK query should be allowed to return false by the spec
14:04:27 <sandro> sandro: we could say "empty graphs MAY be implicitely deleted".
14:04:45 <SteveH> +1 to sandro's suggestion
14:04:53 <LeeF> +1 to sandro's suggestion
14:04:59 <Souri> +1
14:05:00 <Souri> +1
14:05:09 <MattPerry> +1
14:05:23 <sandro> -0
14:05:27 <sandro> :-)
14:05:44 <pgearon> +1
14:06:00 <AxelPolleres> can someone else take over scribing on MIT side?
14:06:01 <dcharbon2> +1
14:06:27 <sandro> lee: not the best solution for interoperability, but maybe the best we can do.
14:06:28 <AndyS> For clarification: when? during update or immediately after whole request done (multiple oerations)?
14:25:14 <Souri> Souri has joined #sparql
14:39:28 <LeeF> scribenick: pgearon
14:39:35 <AxelPolleres> scribe: paul gearon
14:39:48 <AxelPolleres> discussing  http://www.w3.org/2009/sparql/wiki/Lees_Update_Graph_Model
14:39:59 <AxelPolleres> ... asa a proposal to move forward.
14:40:23 <pgearon> 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 <AxelPolleres> q?
14:40:32 <SteveH> q-
14:40:43 <LeeF> zakim, clear the q!
14:40:43 <Zakim> I don't understand 'clear the q!', LeeF
14:40:47 <AndyS> q+
14:40:58 <LeeF> ack AndyS
14:41:13 <pgearon> AndyS: like the proposal on the wiki, but nervous about point 3
14:41:35 <pgearon> prop 3 links dataset and graph store
14:41:57 <pgearon> LeeF: removed this point
14:43:14 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/index.php?title=Lees_Update_Graph_Model&oldid=1995
14:43:29 <LeeF> 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 <kasei> +1
14:43:41 <bglimm> +1
14:43:41 <dcharbon2> +1
14:43:46 <MattPerry> +1
14:43:49 <Souri> +1
14:43:53 <AndyS> +1
14:43:53 <AxelPolleres> +1
14:44:04 <sandro> +0 (I guess it's good enough, but I wish I understand the semweb implications better)
14:44:25 <pgearon> +1
14:45:25 <pgearon> 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 <ivan> +1
14:45:52 <AlexPassant> +1
14:45:52 <AxelPolleres> q+ to add sd: extension proposal
14:46:03 <LeeF> 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 <trackbot> ISSUE-20 Graphs aware stores vs. quad stores for SPARQL/update (empty graphs) notes added
14:46:46 <pgearon> AxelPolleres: wants to have an sd flag to indicate if implementations always preserve empty graphs
14:46:48 <LeeF> trackbot, close ISSUE-20
14:46:48 <trackbot> ISSUE-20 Graphs aware stores vs. quad stores for SPARQL/update (empty graphs) closed
14:48:11 <LeeF> q?
14:48:14 <LeeF> ack AxelPolleres
14:48:14 <Zakim> AxelPolleres, you wanted to add sd: extension proposal
14:48:33 <pgearon> not going to add sd: at the moment
14:49:23 <kasei> q+
14:50:04 <pgearon> Ivan: concerned about SILENT on CREATE, but spec is already clear
14:50:41 <LeeF> ack kasei
14:51:05 <pgearon> kasei: SILENT on DROP is different in that different implementations may or may not have errors on a DROP without SILENT
14:51:32 <pgearon> AlexPassant: this is similar to CREATE, and depends on the implementation. SILENT will always cover the user
14:51:45 <AxelPolleres> 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 <sandro> paul: It's an ERROR in all implementations if you CREATE when the graph isn't empty.
14:53:40 <LeeF> I'm ambivalent about CREATE GRAPH vs. ADD GRAPH 
14:53:41 <pgearon> reponse to Souri: are we covered for calling CREATE on graphs which already exist and have data
14:54:20 <AndyS> ADD is as bad - may presume GET deref 
14:54:52 <AxelPolleres> INSERT GRAPH ?
14:55:35 <sandro> CREATE isn't perfect, but ADD is worse.    OBTAIN?   PREPARE?   BEGIN?     OPEN?      
14:55:48 <pgearon> 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 <sandro> STORE?   REMEMBER?   HOLD?
14:56:37 <pgearon> USING?
14:57:38 <AxelPolleres> INSERT GRAPH ;  INSERT { } ; DELETE { } ; DELETE GRAPH 
14:57:51 <SteveH> INSERT GRAPH <g>, no?
14:58:14 <AndyS> INSERT { GRAPH ..} WHERE ... is too close
14:59:24 <AxelPolleres> q?
14:59:34 <ivan> q?
14:59:41 <sandro> q+
15:00:20 <AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0539.html
15:00:48 <pgearon> AxelPolleres: do we need certain syntactic constructs in the language, or do we want to change them (INSERT/CREATE and DELETE/DROP)
15:00:53 <AndyS> Origin of this: Difference between  CREATE / DROP are graph mgt ; INSERT / DELETE are data manipulation
15:01:08 <AxelPolleres> q?
15:01:54 <pgearon> Sandro: what is the use case for creating a graph in the store?
15:03:17 <pgearon> LeeF: application developers often create graphs knowing that triples will not be available for it for some time (eg a week)
15:03:26 <pgearon> Sandro: so CREATE sounds like a reasonable name
15:03:36 <pgearon> Ivan: still unhappy with CREATE
15:03:47 <AndyS> q+
15:04:09 <pgearon> Ivan: since the concept of the "graph" continues to exist whether it is in the local store or not
15:04:15 <AlexPassant> q+
15:04:21 <AxelPolleres> q?
15:04:39 <AxelPolleres> ack sandro
15:05:18 <AxelPolleres> ack AndyS
15:05:24 <sandro> sandro: read CREATE as "create storage for" 
15:06:27 <AxelPolleres> q?
15:06:28 <pgearon> AndyS: LeeF is emphasizing the local storage of the data, the other approach is more about the entire web
15:06:42 <AxelPolleres> ack AlexPassant
15:07:23 <AxelPolleres> INSERT GRAPH ;  INSERT { } ; DELETE { } ; DELETE GRAPH
15:07:30 <betehess> betehess has joined #sparql
15:07:58 <AndyS> qck me
15:08:01 <AndyS> ack me
15:08:08 <sandro> guest: Alexandre Bertails, W3C
15:08:16 <pgearon> AlexPassant: the CREATE operation is about referring to the graph as being expressed locally, as opposed to being elsewhere on the web
15:08:56 <Souri> Souri has joined #sparql
15:09:23 <pgearon> Axel: do we still want CLEAR?
15:09:28 <AlexPassant> pgearon: not only CREATE actually but any SPARUL operations
15:09:47 <kasei> q+
15:11:06 <pgearon> AndyS: CREATE/DROP explicitly for book keeping operations. DELETE/INSERT are for data
15:11:19 <LeeF> ack kasei
15:11:53 <AxelPolleres> OPTION 1:  keep with CREATE/DROP/INSERT/DELETE
15:12:14 <AxelPolleres> OPTION 2: INSERT/DELETE GRAPH INSERT/DELETE pattern
15:12:31 <AxelPolleres> OPTION 3: INSERT DROP GRAPH INSERT/DELETE pattern
15:12:36 <dcharbon2> q+
15:12:48 <LeeF> ack dcharbon2
15:13:42 <pgearon> dcharbon2: if CREATE scoped, then across a federation this makes more sense, since you're creating on an individual server
15:13:47 <LeeF> +1 to dcharbon2 scope-oriented view
15:13:58 <sandro> dcharbon2: Create is always within some scope.    A federated end-point might do the create in the right place.     Otherwise, it's creating a local version.
15:14:04 <sandro> +1 dcharbon2 
15:14:04 <AndyS> +1 - ultimate is scope = web
15:14:45 <SteveH> LOAD <file:///dev/null> INTO <g>   :)
15:14:52 <LeeF> :D
15:15:00 <Souri> Souri has joined #sparql
15:15:03 <pgearon> Ivan: if you're considering a foreign graph, then your local assertion of a graph is referring to the foreign graph and bringing it in locally. In this case the graph is not be "created"
15:15:20 <pgearon> LeeF: It is creation, just in a scope
15:15:21 <AxelPolleres> q+ to (seriously) �ask ivan whether that is not LOAD
15:15:47 <pgearon> pgearon has left #sparql
15:15:49 <ivan> ack dcharbon2 
15:15:57 <LeeF> ack dcharbon
15:15:58 <AndyS> ack dcharbon
15:15:58 <LeeF> ack AxelPolleres
15:15:59 <Zakim> AxelPolleres, you wanted to (seriously) �ask ivan whether that is not LOAD
15:16:09 <pgearon> pgearon has joined #sparql
15:16:43 <sandro> q+
15:17:05 <sandro> q+ to suggest endpoints SHOULD reject creates for which a LOAD is possible and they dont have write access
15:17:54 <pgearon> Axel: could use LOAD to handle Ivan's usecase. LOAD could create an error if the data does not exist
15:17:57 <Souri> q+
15:18:42 <AndyS1> AndyS1 has joined #sparql
15:18:50 <LeeF> ack sandro
15:18:50 <Zakim> sandro, you wanted to suggest endpoints SHOULD reject creates for which a LOAD is possible and they dont have write access
15:19:51 <LeeF> q+ to say I don't see any way that the Update spec. can't embrace local copies that are likely divergent from authoritative copies
15:20:19 <AxelPolleres> ack Souri
15:20:23 <SteveH> q+
15:20:30 <Souri> q+
15:20:36 <ivan> ack LeeF 
15:20:36 <Zakim> LeeF, you wanted to say I don't see any way that the Update spec. can't embrace local copies that are likely divergent from authoritative copies
15:20:51 <SteveH> q-
15:20:53 <AxelPolleres> sorry, souri should go first.
15:21:19 <sandro> sandro: Let's advise people to only CREATE for URIs for which they are authoritative.    
15:21:21 <pgearon> +q to ask if we need to revisit the need to create/delete graphs
15:21:36 <sandro> pgearon, you mean q+
15:21:42 <AxelPolleres> q+ to suggest that text for CREATE makes clear that CREATE creates a local copy?
15:21:49 <AndyS> AndyS has joined #sparql
15:22:24 <AlexPassant> cannot we say in the spec that the scope of SPARUL is LOCAL by default ? i.e. all operations apply on local copies of the graphs
15:22:59 <pgearon> Souri: CREATE is creating a "fragment" of the data in a local store
15:24:40 <LeeF> ack Souri
15:24:47 <AndyS> +1 to scope view - too much like web-in-a-box if scope only state of the web
15:25:12 <LeeF> ack pgearon
15:25:12 <Zakim> pgearon, you wanted to ask if we need to revisit the need to create/delete graphs
15:26:06 <SteveH> What about INSERT { GRAPH <g> {} }
15:26:07 <SteveH> ?
15:26:46 <LeeF> ack AxelPolleres
15:26:46 <Zakim> AxelPolleres, you wanted to suggest that text for CREATE makes clear that CREATE creates a local copy?
15:26:49 <dcharbon2> What does DELETE { GRAPH <g> } do?
15:27:12 <Souri> I am fine with option 1 (for now, implicitly meaning local scope)
15:27:18 <LeeF> dcharbon2, nothing as far as I can tell - the template doesn't "generate" any triples, so there's nothing to remove from anywhere
15:28:11 <kasei> CREAT GRAPH?
15:28:30 <AndyS> pgearon: OPTION 4: No CREATE, DROP
15:28:38 <AxelPolleres> OPTION 4: drop create/drop alltogether?
15:29:03 <SteveH> I'm mildly in favour of not having CREATE 
15:29:26 <AndyS> dcharbon: could design for bookkeepingless systems
15:30:03 <dcharbon2> +0.5 to option 4
15:30:15 <AxelPolleres> OPTION 1:  keep with CREATE/DROP/INSERT/DELETE
15:30:16 <AxelPolleres> OPTION 2: INSERT/DELETE GRAPH INSERT/DELETE pattern
15:30:16 <AxelPolleres> OPTION 3: INSERT DROP GRAPH INSERT/DELETE pattern
15:30:16 <AxelPolleres> OPTION 4: Drop CREATE/DROP alltogether
15:30:31 <ivan> OPTION 5: Add/DROP/INSERT/DELETE
15:30:51 <AndyS> ADD implies LOAD to me
15:30:57 <SteveH> me too
15:31:06 <sandro> is ADD really ADD GRAPH ?
15:31:20 <sandro> ivan: yes.
15:33:03 <AndyS> +1 / -1 / -1 / maybe, need more time to consider / -1
15:33:17 <LeeF> +1 / -1 / -1 / 0
15:33:32 <ivan> -1/-1/1/maybe/1
15:33:39 <pgearon> +1 / -1 / -1 / +0.5 / -1
15:33:47 <kasei> 0.5 / 0 / 0 / 0 / 0
15:33:48 <LeeF> +1 / -1 / -1 / 0 / 0
15:33:49 <MattPerry> 0 / -1 / -1 / +1 / -1
15:33:50 <AlexPassant> 0 / 0 / 0 / +1 / 0
15:33:53 <SteveH> +0 / -1 / -1 / +0.5 / -1
15:33:55 <Souri> 0.5/-1/-1/+1/-1
15:34:01 <AxelPolleres> +1/0/0/0/+1
15:34:02 <sandro> +0 / -1 / -1 / -0 / +0
15:34:11 <bglimm> +1 / 0 / -1 / 0 / 0
15:34:57 <dcharbon2> 0/0/0/0
15:35:07 <dcharbon2> 0
15:35:29 <AndyS> 0x01FFFF--FF
15:36:16 <kasei> q+
15:37:30 <LeeF> option 1
15:37:36 <kasei> 0
15:37:36 <AndyS> option 1
15:37:40 <SteveH> option 1
15:38:01 <MattPerry> option 1
15:38:05 <bglimm> 1
15:38:06 <AxelPolleres> STRAWPOLL: 1 (prefer Option 1)�/5 (prefer Option 5 )/0 (don't care between those two
15:38:07 <AxelPolleres> 1
15:38:13 <dcharbon2> option 1
15:38:21 <AlexPassant> 0 (but need to mention the scope in the spec. for both imo)
15:38:26 <sandro> 1 is  "CREATE GRAPH", 5 is "ADD GRAPH"
15:38:47 <sandro> option 5
15:38:56 <AndyS> Option 4: DROp -> CLEAR
15:38:58 <SteveH> CLEAR <g> == DROP GRAPH <g> 
15:39:04 <LeeF> DELETE WHERE { GRAPH <g1> { ?s ?p ?o } }
15:39:39 <Souri> 1
15:39:51 <LeeF> AxelPolleres: Clear preference for Option 1 over Option 5
15:40:22 <Souri> Souri has joined #sparql
15:40:36 <AxelPolleres> PROPOSED: mark CREATE/DROP at risk
15:41:16 <pgearon> +1
15:41:23 <AxelPolleres> not now...?
15:41:52 <AxelPolleres> paul: already in the spec.
15:42:06 <LeeF> ACTION: Lee and AxelPolleres to solicit feedback from community regarding CREATE/DROP upon publication of next Update working draft�
15:42:07 <trackbot> Could not create new action (failed to parse response from server) - please contact sysreq with the details of what happened.
15:42:07 <trackbot> Could not create new action (unparseable data in server response: local variable 'd' referenced before assignment) - please contact sysreq with the details of what happened.
15:42:22 <AxelPolleres> subtopic: Keep CLEAR? http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0539.html
15:42:49 <pgearon> +q
15:42:58 <LeeF> ack kasei
15:42:58 <kasei> q-
15:43:04 <SteveH> we're now talking about http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0539.html
15:43:07 <LeeF> ACTION: Lee and AxelPolleres to solicit feedback from community regarding CREATE/DROP upon publication of next Update working draft�
15:43:07 <trackbot> Could not create new action (failed to parse response from server) - please contact sysreq with the details of what happened.
15:43:07 <trackbot> Could not create new action (unparseable data in server response: local variable 'd' referenced before assignment) - please contact sysreq with the details of what happened.
15:43:34 <SteveH> q?
15:43:39 <Souri> q+
15:43:48 <ivan> ack pgearon 
15:43:49 <SteveH> q+
15:44:05 <LeeF> ack Souri
15:44:39 <LeeF> is CLEAR <g1> identical to DELETE WHERE { GRAPH <g1> { ?s ?p ?o } } ?
15:44:50 <SteveH> LeeF, yes
15:45:03 <AxelPolleres> q?
15:45:08 <LeeF> thanks. I don't care whether or not we keep CLEAR :)
15:45:46 <LeeF> q?
15:45:52 <LeeF> ack SteveH
15:46:32 <pgearon> SteveH: no longer things that DELETE <graph> to be a good idea, since it reads like the removal of the graph rather than the contents
15:47:36 <Souri> CLEAR graph <g1> graph <g2> ?
15:47:40 <pgearon> Souri: can CLEAR be applied to multiple graphs?
15:48:01 <LeeF> LeeF: Consensus in group to keep CLEAR syntax as is.
15:48:26 <pgearon> pgearon: was this like the recent email which referred to multiple graphs (in a LOAD command)
15:48:41 <SteveH> There's also the question of the CLEAR [default graph] syntax: http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0538.html
15:48:43 <LeeF> subtopic: delimiters / separators
15:48:45 <LeeF> see http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0538.html
15:48:50 <pgearon> AxelPolleres: we will keep CLEAR (for the moment)
15:49:01 <AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0538.html
15:49:01 <AndyS> I put optional separators in grammar to check there is no clash problems.
15:49:06 <sandro> sandro: Why no "DELETE FROM" as in SQL?        Answer from Lee: because in SPARQL, "FROM" means stuff.....
15:49:18 <AndyS> This is not an opinion.
15:50:14 <pgearon> SteveH: easy to mistype a query such that it is ambiguous for a human to determine what it means
15:50:25 <AndyS> Nice to have when one line, several operations -- nuisence multi line
15:50:30 <LeeF> I'm quite happy to have operations in SPARQL Update have a terminating character
15:51:02 <pgearon> SteveH: would like compulsory separators, but violently opposed to making them optional
15:51:13 <pgearon> +q
15:51:50 <SteveH> CLEAR DELETE DATA { <x> <y> <z> }
15:52:55 <pgearon> -q
15:53:05 <AndyS> Now have "CLEAR DEFAULT" , not just CLEAR
15:53:43 <AndyS> q+
15:53:46 <AndyS> http://www.w3.org/2009/sparql/docs/sparql-grammar-11.html
15:54:42 <Souri> Souri has joined #sparql
15:54:52 <SteveH> CLEAR DEFAULT DELETE DATA { <x> <y> <z> } - but draft combined grammar
15:54:56 <SteveH> s/but/by/
15:55:06 <AxelPolleres> DFT in the grammar should be 'DEFAULT'
15:56:14 <SteveH> CLEAR
15:56:16 <SteveH> DEFAULT
15:56:21 <SteveH> ELETE DATA { <x> <y> <z> } 
15:59:00 <pgearon> +q to ask SteveH why he's so opposed to an optional separator
15:59:06 <AndyS> ack me
15:59:14 <AndyS> this is a command line issue?
15:59:32 <pgearon> Ivan: doesn't see why CLEAR DEFAULT DELETE DATA ... is ambiguous
15:59:51 <AndyS> Are we saying cmd line is exactly same as HTTP request body? May be different.
15:59:55 <AxelPolleres> OPTION 1: ";" Obligatory
15:59:55 <AxelPolleres> OPTION 2: no separators 
15:59:55 <AxelPolleres> OPTION 3: ";" optional (steve objects)
16:00:28 <AndyS> OPT 3 does not work on command line BTW
16:00:37 <Souri> option 1
16:01:07 <AndyS> q+
16:01:11 <LeeF> ack pgearon
16:01:11 <Zakim> pgearon, you wanted to ask SteveH why he's so opposed to an optional separator
16:01:13 <LeeF> ack AndyS
16:02:17 <AndyS> separator has problems as well
16:02:22 <pgearon> SteveH: optional separators makes it much harder for people to learn, since if they only ever see the separator, then they will get confused when it is not used
16:02:50 <AndyS> here an example: See CLEAR DEFAULT -- now unclear (cmd line example)
16:03:36 <pgearon> sandro: would like to see a separator and not a terminator (to avoid "separating" a null command)
16:03:40 <Souri> Souri has joined #sparql
16:04:00 <sandro> sandro: lets do semicolon terminator like in SQL -- may be necessary as terminator on command line, but optional as terminator in API.
16:04:37 <kasei> option 1
16:04:44 <LeeF> 0
16:04:46 <SteveH> +1 / -1 / -Inf
16:04:53 <MattPerry> option 1
16:04:57 <SteveH> option 1
16:04:57 <AlexPassant> 1
16:04:59 <bglimm> 1
16:04:59 <AndyS> opt 2
16:05:04 <dcharbon2> option 2
16:05:04 <AxelPolleres> Option 1
16:05:05 <sandro> option 1
16:05:06 <Souri> option 1 (';' as terminator)
16:05:12 <ivan> option 3 (sorry steve)
16:05:16 <AndyS> (can live with opt 1 as sep)
16:05:18 <pgearon> Option 2
16:06:08 <Souri> Souri has joined #sparql
16:07:13 <LeeF> are we talking about a command line or about an interactive query shell type thing?
16:07:43 <Souri> Souri has joined #sparql
16:08:34 <Souri> q+
16:08:38 <AndyS> Let us not spec cmd line usage
16:08:38 <AxelPolleres> Option 1: 7       Option 2: 3     Option 3:  1
16:09:51 <Souri> in SQL-92, ';' is a terminator
16:10:41 <AxelPolleres> ";" as separator seems to be agreeable to everyone. 
16:10:50 <AxelPolleres> terminator?
16:11:00 <LeeF> ack Souri
16:11:03 <sandro> PROPOSED: semicolons are a required separator.    (we're not talking about whether they are allowed as terminators as well.)
16:11:22 <AndyS> q+
16:11:47 <sandro> lee: why no ";" as terminator?    because people want to be able to leave off a trailing ";".
16:12:01 <LeeF> ack AndyS
16:14:20 <Souri> I prefer terminator, but may go with separator
16:14:24 <AndyS> Need (';' | <EOF>) to terminate
16:14:35 <SteveH> +1 to AndyS 
16:14:37 <Souri> +1
16:15:31 <AxelPolleres> why?
16:15:32 <AxelPolleres> update := atomicupdate | update ';' atomicupdate
16:15:52 <AndyS> That fixes cmd line (which I don't care if diff systems do diff things anyway)
16:16:04 <sandro> update := atomicupdate | update ';' atomicupdate | 
16:17:01 <AndyS> "that" refers to (';' | <EOF>)
16:17:40 <kasei> why not sandro's?
16:17:54 <sandro> PROPOSED: semicolons are a required separator, and either ";" or <EOF> terminates
16:17:56 <pgearon> SteveH: likes Andy's suggestion since it handles having a ; at the end or not, for both protocol and a command line
16:18:46 <sandro> PROPOSED: semicolons are a required separator, and either ";" or <EOF> terminates (and empty-string is an acceptable command)
16:18:59 <AxelPolleres> q?
16:19:02 <sandro> +1
16:19:05 <ivan> +1
16:19:07 <AxelPolleres> +1
16:19:09 <dcharbon2> +1
16:19:10 <MattPerry> +1 
16:19:11 <SteveH> +1
16:19:12 <Souri> +1
16:19:13 <pgearon> +1
16:19:24 <AndyS> +0.5 (need to check it works!)
16:19:37 <LeeF> 's fine with me
16:19:46 <sandro> RESOLVED: semicolons are a required separator for update operations, and either ";" or <EOF> terminates (and empty-string is an acceptable command)
16:19:47 <kasei> +1
16:21:42 <LeeF> subtopic: datasets and update
16:21:43 <LeeF> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0616.html
16:25:51 <AxelPolleres> the fundamental thing here seems the base assumption: "I'd _like_ to be able to say that the RDF Dataset is a subset of the Graph Store, but given that the Graph Store defines a single unnamed 
16:25:51 <AxelPolleres> graph whereas the RDF Dataset allows me to craft a default graph as the merge of multiple graphs, I don't know how to formally specify this subset relationship."
16:26:03 <AndyS> Minor : reads as INSERT ... FROM which is, to me, odd.  Maybe can live with.
16:27:15 <AndyS> Think single FROM clause rule is way too clever.
16:27:34 <pgearon> SteveH: observes that it's strange that INSERT/DELETE would be affected by a "FROM"
16:28:21 <pgearon> WITH g1 INSERT { x y z } DELETE { a b c } WHERE { ... }
16:28:24 <sandro> SteveH: How about WITH is for the INSERT/DELETE and FROM is for the WHERE.
16:28:54 <AxelPolleres> q+
16:29:18 <LeeF> SteveH: What about moving FROM to the top? 
16:29:27 <AndyS> Prefer FROM only applies to WHERE.
16:29:30 <LeeF> LeeF: Not a strong feeling; diverges from what Query does
16:29:38 <pgearon> AxelPolleres: thinks there's an alternative to the base assumption
16:29:53 <pgearon> ... presumes this would only apply to the WHERE part
16:30:41 <AndyS> then prefer no WITH at all or WITH applies only to INSERT, DELETE (based on separation of concepts)
16:30:56 <pgearon> AxelPolleres: gets back to conversation at the beginning, re: graphstore-vs-dataset
16:31:22 <LeeF> AndyS, I would be OK with FROM/FROM NAMED applying only to WHERE and no WITH at all, but still think having 2 distinct concepts of a default graph for the operation is confusing
16:31:53 <AndyS> LeeF - good point.
16:44:41 <AndyS> AndyS has joined #sparql
17:11:14 <LeeF> AndyS, can you begin scribing following this break?
17:21:31 <Souri> Souri has joined #sparql
17:29:52 <Mattperry> Mattperry has joined #sparql
17:29:58 <dcharbon2> dcharbon2 has joined #sparql
17:38:49 <ericP> ericP has joined #sparql
17:39:19 <bglimm> bglimm has joined #sparql
17:39:52 <LeeF> Chair: LeeF
17:40:25 <AndyS1> AndyS1 has joined #sparql
17:40:33 <AxelPolleres> AxelPolleres has joined #sparql
17:40:38 <AndyS1> For ericP: http://www.openjena.org/ARQ/service.html
17:40:58 <SteveH> SteveH has joined #sparql
17:41:05 <ericP> tx AndyS1 
17:41:18 <LeeF> scribenick: AndyS
17:41:32 <AndyS1> scribenick: AndyS1
17:41:37 <AndyS1> ... for some reason
17:41:44 <Souri> Souri has joined #sparql
17:41:48 <AndyS1> LeeF: update continues
17:42:02 <AxelPolleres> an additional thing people brought up was the LOAD <uri1�> LOAD <uri2> vs LOAD <uri1> <uri2> issue (which might imply other shortcuts like that as well)... in case we get there
17:42:08 <AndyS1> report from Boston lunch discussions
17:42:24 <AndyS1> pgearon: multiple load issue
17:43:22 <AndyS1> keyword WITH - introducing FROM could be along side WITH - layered appraoch
17:43:36 <AndyS1> ... explicit GRAP => use named graph
17:43:50 <AndyS1> ... else FROM / FROM NAMED 
17:43:55 <AndyS1> ... else WITH
17:44:01 <AndyS1> ... else default
17:44:09 <AndyS1> s/GRAP/GRAPH/
17:44:23 <AndyS1> Lee, others: confusing
17:44:48 <AxelPolleres> q+
17:45:02 <LeeF> ack AxelPolleres
17:45:17 <ivan> ack AxelPolleres 
17:45:53 <AndyS1> AxelPolleres: alternative FROM only for WHERE not INSERT DELETE
17:46:13 <AndyS1> q+
17:46:33 <AndyS1> LeeF: confusing even though no lex order (Steve point)
17:46:36 <LeeF> ack AndyS
17:47:11 <LeeF> q+ AndyS
17:47:15 <LeeF> ack AndyS
17:47:49 <LeeF> AndyS: I find it slightly odd to use FROM to constrain the INSERT/DELETE template because of the case of multiple FROMs
17:48:17 <AndyS1> LeeF: compromise design
17:48:49 <AndyS1> So do we need to change scope for default graph in update part?
17:49:05 <AxelPolleres> What I want to say is that the decoupling dataset and graphstore is confusing anyways from one point of view.
17:50:36 <LeeF> q?
17:52:16 <LeeF> AndyS: What if unadorned triple patterns in INSERT/DELETE templates went against the Graph Store's default graph, and FROM only controlled the default graph for the query pattern?
17:52:27 <LeeF> LeeF: Think it's still a little weird because there are distinct default graph concepts, but I can live with it
17:52:33 <AndyS1> AndyS: error case of union FROM is confusing to me
17:53:14 <AndyS1> AndyS: do see value of setting dft graph for WHERE part
17:54:03 <pgearon> INSERT { GRAPH <g1> { x y z } } DELETE { GRAPH <g1> { a b c } } WHERE FROM <g1> { ... }
17:54:16 <pgearon> WITH <g1> INSERT { x y z } DELETE { a b c } WHERE { ... }
17:54:35 <AndyS1> Alt : either WITH or FROM not both
17:54:57 <AndyS1> pgearon: common use pattern
17:55:10 <AndyS1> ... operations on a single graph
17:55:13 <pgearon> INSERT { GRAPH <g1> { x y z } } DELETE { GRAPH <g1> { a b c } } WHERE FROM <g2> { ... }
17:55:49 <pgearon> WITH <g1> INSERT { x y z } DELETE { a b c } FROM <g2> WHERE { ... }
17:56:03 <LeeF> now what happens when i put this in the protocol with default-graph-uri=g3 
17:56:46 <AxelPolleres> my understnding is that default-graph-uri= only overwrites FROM
17:57:09 <LeeF> what principle is that understanding based on, AxelPolleres?
17:57:22 <LeeF> IvanH: the above example reads confusing to me because of the DELETE { ... } FROM part 
17:57:54 <AxelPolleres> leeF, same as in query, isn't it?
17:58:00 <LeeF> query doesn't have with
17:58:14 <LeeF> i don't see any principle that would make me think that default-graph-uri doesn't also override WITH
17:58:17 <LeeF> or override WITH instead
17:58:20 <AndyS1> pgearon: value DRY
17:58:30 <AndyS1> (Dont Repeat Yourself)
17:58:57 <AxelPolleres> LeeF, but protocol has default-graph-uri= which corressponds to FROM, which I suggest to just keep
17:59:35 <AndyS1> LeeF: now tending INS DEL effect real dft graph.
18:01:23 <AxelPolleres> I think the proposal is useful, exactly because it allows to insert/modify based on querying graphs possibly external to the graphstore.
18:01:31 <AxelPolleres> q?
18:01:33 <AxelPolleres> q+
18:01:41 <LeeF> ack AxelPolleres
18:01:43 <AndyS1> ack AxelPolleres
18:01:48 <Souri> q+
18:02:03 <sandro> sandro: The confusion in    DELETE { ... } FROM ...  WHERE ...       is pretty bad.
18:02:33 <AndyS1> LeeF: if no spec - graph store = impl decision c.f. query
18:02:56 <LeeF> ack Souri
18:03:02 <dcharbon2> could where come first? so, FROM... WHERE... DELETE { ... }
18:03:31 <SteveH> dcharbon2's suggesting is interesting
18:03:35 <SteveH> *suggestion
18:03:42 <AndyS1> Souri: WITH clause: common use case update is on a graph that is also the WHERE part
18:03:54 <pgearon> FROM... WHERE ... INSERT .... DELETE ...
18:04:22 <SteveH> DELETE ... INSERT ... probably
18:04:55 <dcharbon2> FROM... WHERE... WITH... INSERT... DELETE...
18:05:05 <AndyS1> If we chnage order, FROM => USING maybe 
18:05:39 <AxelPolleres> the proposal on the comments list was more along the lines: SELECT ... FROM ... WHERE ... INSERT ... DELETE 
18:05:53 <AndyS1> Souri: SQL is declare the thing to change then WHERE data
18:05:58 <AxelPolleres> ... i.e. allowing SELECT i.e. query parts together with updates
18:05:59 <LeeF> to me, CONSTRUCT foo and INSERT foo are very similar ideas, and having them be so different is pretty weird to me
18:06:01 <AndyS1> q+
18:06:08 <LeeF> ack AndyS1
18:06:12 <LeeF> ack AndyS
18:06:25 <AxelPolleres> q+
18:06:33 <AndyS1> ack me
18:06:48 <LeeF> ack AxelPolleres
18:07:02 <LeeF> Souri: SQL has a returning clause for return results from a DML statement
18:08:31 <pgearon> I've recently been getting requests to return multiple result sets using an XML format that Mulgara had prior to SPARQL
18:08:58 <AndyS1> LeeF: general sentiment on whether order of works is like SQL? like query?
18:10:01 <AxelPolleres> obvious question is... if we allow SELECT ... FROM ... WHERE ... INSERT ... DELETE then why not CONSTRUCT ... FROM ... WHERE ... INSERT ... DELETE ?
18:10:34 <AndyS1> Ivan: given CONSTRUCT go that way
18:10:35 <pgearon> I've just checked, DELETE is always before INSERT (sorry about any confusion up to now)
18:11:01 <AndyS1> LeeF: what about souri's idea of WITH xor FROM ?
18:11:16 <AndyS1> ... WITH is shortcut for GRAPH everywhere
18:11:48 <AndyS1> SteveH: protocol interactions
18:11:59 <LeeF> q?
18:12:53 <AxelPolleres> interactions with protocol is e.g. if in the protocol someone uses e.g. default-graph-uri
18:13:22 <pgearon> q+
18:13:27 <LeeF> ack pgearon
18:13:31 <AndyS1> AndyS: suggest default-graph + FROM in update => error
18:13:45 <AndyS1> ... unlike query 
18:14:17 <AndyS1> ... overide can chnage a two different grah update now be a one graph update
18:15:00 <SteveH> LeeF, we do
18:15:06 <SteveH> for security, only access one graph
18:15:12 <AndyS1> same here
18:15:17 <AndyS1> q+
18:15:25 <LeeF> INSERT T1 DELETE T2 FROM G1 { ... }
18:15:34 <LeeF> T1 and T2 act on the Graph Store's default graph
18:15:46 <LeeF> and the query pattern queries G1 as its default graph
18:15:46 <SteveH> missing WHERE?
18:16:09 <LeeF> INSERT T1 DELETE T2 FROM G1 WHERE { ... }
18:16:43 <AndyS1> LeeF: hearing consensus around the above
18:18:00 <AndyS1> AndyS: deafult-graph-uri= is whole request = many operations, some with FROM , some with WITH, some with none.
18:18:54 <LeeF> * If you use default-graph-uri, the request can't use WITH or FROM at all
18:19:12 <LeeF> * If you don't use default-graph-uri, then each operation within the request can use WITH or FROM/FROM NAMED, but not both
18:19:28 <Souri> q+
18:19:33 <LeeF> ack AndyS
18:19:35 <kasei> q+
18:19:55 <LeeF> ack Souri
18:20:35 <dcharbon2> q+ to ask about just ... adding [with] [delete] [insert] at the end of a query - with support for select, construct and ask for returning values
18:20:51 <AxelPolleres> q+ to ask why interaction of WITH with FROM (NAMED) is a problem *at all* 
18:21:26 <LeeF> ack kasei
18:22:04 <AxelPolleres> WITH <g> FROM <g1> INSERT P1 WHERE P2  =  FROM <g1> INSERT {GRAPH <g> P1} WHERE {GRAPH <g> P2} 
18:22:09 <LeeF> kasei: seems very strange to forbid default-graph-uri overriding FROM in the case of a single update operation
18:22:11 <AxelPolleres> ... so what?
18:22:17 <LeeF> ack dcharbon
18:22:17 <Zakim> dcharbon, you wanted to ask about just ... adding [with] [delete] [insert] at the end of a query - with support for select, construct and ask for returning values
18:23:23 <AndyS1> dcharbon: query-ish thing followed by updates
18:23:42 <dcharbon2> [query] update-clause
18:24:28 <LeeF> dcharbon2: suggests-- [optional SPARQL result clause] [optional SPARQL dataset clause] SPARQL query pattern [optional SPARQL modifiers] [optional WITH] [optional DELETE template] [optional INSERT tempalte]
18:24:49 <AxelPolleres> ack AxelPolleres
18:24:49 <Zakim> AxelPolleres, you wanted to ask why interaction of WITH with FROM (NAMED) is a problem *at all*
18:24:49 <LeeF> ack AxelPolleres
18:24:58 <AndyS1> q+ to ask for clarification
18:26:43 <LeeF> ack AndyS
18:26:43 <Zakim> AndyS, you wanted to ask for clarification
18:27:59 <Souri> q+
18:29:04 <LeeF> AndyS: We haven't really talked about solution modifiers with update
18:29:16 <LeeF> AndyS: does this let us return results based on the post-update state of the store?
18:29:19 <LeeF> LeeF: No, not really
18:29:33 <AxelPolleres> so�, one thing that puzzles me:  if I want to ask a SELECT query to the endpoint's *graphstore* instead of the *default dataset*, I will just use the "update" protocol operation instead of the "query" operation?
18:29:36 <Souri> q-
18:29:37 <LeeF> IvanH: but you could chain multiple operations together with the subsequent one being the one to return something about the state of the graph store after update
18:29:51 <dcharbon2> AxelPolleres: good point
18:30:37 <dcharbon2> It's subversive... too subversive or abusive?
18:30:44 <AxelPolleres> q+ 
18:30:50 <AndyS1> AndyS: issue with multiple SELECT in one request (mix CONSTRUCT and SELECT)
18:32:21 <LeeF> ack AxelPolleres
18:32:43 <AndyS1> AxelPolleres: mixes query on dataset and query on graph store
18:33:03 <AndyS> scribenick: AndyS
18:33:07 <kasei> q+
18:33:13 <LeeF> ack kasei
18:33:16 <AndyS> ivan: assumed treated uniformly
18:33:51 <AndyS> kasei: why query on graph store? why not endpoint makes dataset as query
18:35:23 <AndyS> AxelPolleres: dft graph for Q can be different from dft from update ?
18:36:15 <AxelPolleres> we have both "default graph" and "unnamed graph" in Update.
18:37:30 <AndyS> LeeF: do we want to include results to update other than success/failure
18:37:51 <AndyS> ... or givenb where we are now and our lifecycle do we stick to current posn
18:38:08 <AxelPolleres> I think, if we leave querying out of update, we spare the problem of unifying the dataset and graphstore.
18:38:08 <AxelPolleres> �
18:39:14 <AndyS> Feeling is stick to current update with success/failure only (time concerns)
18:39:39 <LeeF> PROPOSED: SPARQL Update requests return either success or failure only
18:39:46 <ivan> +1
18:39:54 <bglimm> +1
18:39:58 <LeeF> RESOLVED: SPARQL Update requests return either success or failure only, no abstentions or objections
18:39:58 <sandro> +1 (given time constraints)
18:40:00 <AlexPassant> q+
18:40:05 <Souri> +1
18:40:06 <LeeF> ack AlexPassant
18:41:53 <AxelPolleres> q+ to ask, didn't we at some point have a suggestion on the table that payload for protocol has number of added/deleted triples (or was that just in some implementation)
18:42:15 <LeeF> ack AxelPolleres
18:42:15 <Zakim> AxelPolleres, you wanted to ask, didn't we at some point have a suggestion on the table that payload for protocol has number of added/deleted triples (or was that just in some
18:42:16 <sandro> we're not ruling out having various error messages; we're ruling out requring query results as part of an update operations.
18:42:19 <Zakim> ... implementation)
18:43:21 <AlexPassant> ARC2 does that as well re. number of added triples
18:43:39 <AxelPolleres> right, Alex, that's where I saw it
18:43:56 <AndyS> would be costly for one of my impls to test if triple existed everythime
18:44:16 <ivan> ivan has changed the topic to: http://www.w3.org/2009/sparql/wiki/F2F3_Agenda
18:44:32 <AndyS> LeeF: want subgroup to meet and make concrete proposal for WITH/FROM/default-graph-uri=
18:44:42 <AndyS> ... inc pgearon, LeeF
18:44:59 <AndyS> ... SteveH, AndyS
18:45:20 <AlexPassant> AxelPolleres: I'm using ARC2 in lots of apps but never used that feature (success / failure is generally enough)
18:45:26 <AxelPolleres> should we action someone to answer to http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Mar/0000.html along the lines of the Resolution?
18:45:32 <AndyS> (but don't want to slow things down)
18:45:42 <LeeF> ACTION: Lee to coordinate with Paul, Steve, and Andy to form a coherent proposal re: datasets, FROM, FROM NAMED, WITH, default-graph-uri, and named-graph-uri 
18:45:43 <trackbot> Created ACTION-206 - Coordinate with Paul, Steve, and Andy to form a coherent proposal re: datasets, FROM, FROM NAMED, WITH, default-graph-uri, and named-graph-uri  [on Lee Feigenbaum - due 2010-04-01].
18:46:00 <LeeF> ACTION: AxelPolleres to respond to http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Mar/0000.html 
18:46:00 <trackbot> Sorry, couldn't find user - AxelPolleres
18:46:05 <LeeF> ACTION: Axel to respond to http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Mar/0000.html 
18:46:05 <trackbot> Created ACTION-207 - Respond to http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Mar/0000.html  [on Axel Polleres - due 2010-04-01].
18:47:34 <kasei> i can scribe
18:47:36 <AndyS> LeeF: more update via protocol
18:47:39 <kasei> scribenick: kasei
18:48:20 <kasei> LeeF: anybody run into issues with protocol?
18:48:28 <kasei> ivan: how does it handle semicolons?
18:48:42 <kasei> LeeF: just part of the http request body
18:48:53 <AxelPolleres> q+
18:48:58 <betehess_> betehess_ has joined #sparql
18:48:59 <LeeF> ack AxelPolleres
18:49:23 <kasei> AxelPolleres: with implicit dropping, wouldn't see a response indicating that the drop happened.
18:49:30 <kasei> dcharbon2: correct
18:49:59 <kasei> LeeF: we'll still have to define what happens if several operations succeed and some others fail
18:50:24 <kasei> pgearon: since only returning sucess/failure, probably just fail
18:50:46 <kasei> LeeF: gets into concurrency/atomicity issues
18:51:02 <LeeF> this is http://www.w3.org/2009/sparql/track/issues/26
18:51:16 <kasei> pgearon: not sure about atomicity. would like to recommend group of statements be done atomically where possible.
18:51:33 <kasei> ... for systems that don't support atomic operations, still should work. so atomicity should be defined as SHOULD.
18:51:34 <AndyS> +1 to SHOULD be atomic
18:51:41 <LeeF> +1 as well
18:51:58 <kasei> dcharbon2: if we want transactional, statements should be ordered based on syntax.
18:52:08 <kasei> pgearon: yes. will need to guarantee execution order.
18:52:18 <kasei> sandro: don't want to rule out eventually consistent systems.
18:52:28 <kasei> ... SHOULD may not be the right wording.
18:52:43 <kasei> pgearon: was expecting an indication in the service description indicating this.
18:53:15 <kasei> sandro: SHOULD in strict interpretation is do it unless there's a good reason not to.
18:53:23 <kasei> ... not sure being distributed is a good reason.
18:53:29 <AndyS> q+
18:53:36 <LeeF> ack AndyS
18:53:58 <sandro> sandro: but, yeah, I guess being distributed is a good reason.
18:54:06 <kasei> AndyS: would like to say SHOULD. two cases. 1: person doing update sees consistent state of the world. 
18:54:36 <kasei> ... 2: eventually consistent, but person doing update might not see consistency.
18:54:50 <kasei> pgearon: for those systems that are able to do it, needs to be service description support.
18:55:05 <kasei> sandro: ok, understanding distributed is a good reason not to do it.
18:55:36 <kasei> AndyS: should just use SHOULD, not over-interpret how people implement their systems.
18:56:02 <kasei> sandro: implementors might interpret that as shouldn't be doing distributed systems.
18:56:20 <kasei> LeeF: hearing concensus. can we close ISSUE-26?
18:56:34 <sandro> sandro: I think we should include some text saying: FOR EXAMPLE, eventually-consistent stores are fine.
18:57:54 <LeeF> PROPOSED: Close ISSUE-26 by noting that update requests SHOUDL be processed atomically and that SPARQL update provides no other transactional mechanisms
18:58:07 <ivan> s/SHOUDL/SHOULD/
18:58:11 <AxelPolleres> +1
18:58:15 <ivan> +1
18:58:17 <pgearon> +1
18:58:18 <LeeF> PROPOSED: Close ISSUE-26 by noting that update requests SHOULD be processed atomically and that SPARQL update provides no other transactional mechanisms
18:58:20 <AndyS> +1
18:58:21 <dcharbon2> +
18:58:23 <dcharbon2> +1
18:58:28 <Mattperry> +1
18:58:31 <sandro> +1
18:58:32 <Souri> +1
18:58:38 <bglimm> +1
18:58:43 <LeeF> RESOLVED: Close ISSUE-26 by noting that update requests SHOULD be processed atomically and that SPARQL update provides no other transactional mechanisms, no abstentions or objections
18:58:49 <ivan> q+
18:59:00 <kasei> LeeF: ISSUE-19
18:59:04 <LeeF> ack ivan
18:59:08 <sandro> issue-19?
18:59:08 <trackbot> ISSUE-19 -- Security issues on SPARQL/UPdate -- OPEN
18:59:08 <trackbot> http://www.w3.org/2009/sparql/track/issues/19
18:59:20 <kasei> ivan: what do we do about HTTP PATCH?
18:59:33 <kasei> LeeF: need chimezie to be involved in that discussion.
18:59:52 <kasei> ivan: spec says must use HTTP POST. might we allow PATCH?
19:00:59 <LeeF> ISSUE: Does HTTP PATCH affect either the SPARQL Protocol or the SPARQL Uniform etc. HTTP etc. Protocol?
19:00:59 <trackbot> Created ISSUE-56 - Does HTTP PATCH affect either the SPARQL Protocol or the SPARQL Uniform etc. HTTP etc. Protocol? ; please complete additional details at http://www.w3.org/2009/sparql/track/issues/56/edit .
19:01:01 <ivan> -> http://tinyurl.com/yfjdc3s 
19:01:15 <sandro> issue-56 : http://tools.ietf.org/html/rfc5789
19:01:15 <trackbot> ISSUE-56 Does HTTP PATCH affect either the SPARQL Protocol or the SPARQL Uniform etc. HTTP etc. Protocol? notes added
19:01:35 <kasei> LeeF: don't want to spend time on this now. will follow up later.
19:01:36 <ivan> -> http://tools.ietf.org/html/rfc5789 PATCH RFC on Patch
19:01:55 <kasei> ... Next: Security in SPARQL Update.
19:02:36 <kasei> SteveH: my concerns is around making the endpoint perform HTTP requests.
19:02:45 <kasei> LeeF: did we address that in SPARQL 1.0 Query?
19:03:07 <kasei> SteveH: sort of waved at. some people do it with FROM, but not everyone does this.
19:03:09 <AndyS> q+ to say that covered by any processor can reject a request in query
19:03:27 <kasei> ... we require explicitly saying you want that feature at endpoint startup.
19:03:27 <LeeF> ack AndyS
19:03:27 <Zakim> AndyS, you wanted to say that covered by any processor can reject a request in query
19:03:28 <AndyS> ack me
19:03:59 <kasei> AndyS: you can just refuse the query if you don't want to make the request.
19:04:08 <kasei> ... obligated to write a security section for the Update doc.
19:04:34 <kasei> ... usually will implement inside a container that affects this. no one single model.
19:04:51 <kasei> LeeF: does anyone think we need to do more than just a security section in the document?
19:05:01 <kasei> ivan: anything more than that will be too much given our timeline.
19:05:40 <kasei> LeeF: hoping to give advice in the spec. get a list of issues that are important.
19:05:56 <kasei> ... let's list some of the things we know are important.
19:06:06 <LeeF> * loading external data (LOAD <uri>)
19:06:24 <LeeF> ** (related: overflowing your internal store with loaded data)
19:06:44 <AxelPolleres> * similar: interpreting FROM/FROM NAMED as HTTP request 
19:07:00 <LeeF> * access control
19:07:02 <AxelPolleres> ... just as in Query
19:07:02 <SteveH> and multiple LOADs gives an escalation attack
19:07:53 <LeeF> * chain authorization to foreign servers?
19:08:14 <SteveH> LOAD is a flexible pivot
19:08:52 <LeeF> * extension functions (applies to both query and update)
19:10:10 <LeeF> ISSUE-19 : Group consensus to address security considerations in SPARQL Update via Security Considerations informative text in Update spec.
19:10:10 <trackbot> ISSUE-19 Security issues on SPARQL/UPdate notes added
19:10:30 <kasei> LeeF: Concurrency (ISSUE-18)
19:10:46 <AxelPolleres> Appendix A in update doc should be updateded with that list!
19:11:12 <SteveH> http://www.w3.org/2009/sparql/track/issues/18
19:11:19 <kasei> ... any proposals for locking or other concurrency facilities?
19:11:42 <kasei> pgearon: I lumped it together with atomicity issues.
19:12:00 <kasei> LeeF: covered by previous atomicity discussion.
19:12:31 <kasei> ... our system rejects updates if you try to update an old version of data (pass in the version of data you think you're updating)
19:12:49 <kasei> dcharbon2: some people will never need such features.
19:13:08 <LeeF> PROPOSED: Close ISSUE-18 noting the atomicity recommendation in the resolution to ISSUE-26 and noting no plans to add any explicit mechanism for concurrency
19:13:19 <ivan> +1
19:13:25 <bglimm> +1
19:13:30 <AxelPolleres> +1
19:13:32 <AndyS> +1
19:13:35 <LeeF> RESOLVED: Close ISSUE-18 noting the atomicity recommendation in the resolution to ISSUE-26 and noting no plans to add any explicit mechanism for concurrency, no abstentions or objections
19:13:40 <pgearon> +1
19:14:46 <LeeF> kasei: Consider in protocol making use of HTTP 204 Accepted For Processing ?
19:15:15 <kasei> s/204/202/
19:15:41 <kasei> pgearon: what happens if you load half a document and run into an error?
19:16:09 <kasei> sandro: that's just a kind of error ('your data is now corrupt')
19:16:48 <kasei> LeeF: now passed the agenda items scheduled through 10:00 this morning.
19:17:28 <kasei> LeeF: Moving on to test suite.
19:17:37 <kasei> ... sent overview on how tests were done in DAWG.
19:17:39 <AxelPolleres> topic: testing
19:18:00 <kasei> ... super manifest listing manifests which described in RDF the tests.
19:18:14 <kasei> ... each tests gave info on seting up, running, and evaluating results of the test.
19:18:19 <kasei> ... syntax tests were just the query.
19:18:39 <kasei> ... eval tests had data in default (and any named) graph(s), the query, and expected results.
19:19:01 <kasei> ... additional semantics for things like required ordering.
19:19:38 <kasei> ... asked people to return results in EARL. ericP put together system to put results in a database, generate readable reports.
19:19:57 <kasei> ... every test was characterized by facets of query language it was testing.
19:20:24 <kasei> ... when failing test X, attribute failure to the proper part of the language.
19:21:00 <kasei> ericP: we were clever in figuring out what features each query used, not sure about taking that into account on grading the results.
19:21:40 <kasei> LeeF: for update, need to start with a dataset, an update request, and expected results.
19:21:54 <kasei> ... expected results are success/failure and a state of the graphstore after the update.
19:22:10 <kasei> ... need to decide if we'll use the same manifest/vocab approach.
19:22:32 <kasei> ... ericP had suggested the use of TriG for serializing quads.
19:22:55 <kasei> ... then need to start collecting tests.
19:23:03 <ericP> http://swobjects.svn.sourceforge.net/viewvc/swobjects/trunk/tests/sparul/
19:23:11 <SteveH> q+
19:23:18 <ericP> http://swobjects.svn.sourceforge.net/viewvc/swobjects/trunk/tests/sparul/ -> SWObjects SPARUL tests
19:23:20 <LeeF> ack SteveH
19:23:31 <kasei> SteveH: support for using TriG.
19:23:50 <kasei> bglimm: don't know how to parse that.
19:24:04 <kasei> ... if existing tools can't parse it...
19:25:02 <kasei> ... using OWL API. can parse turtle.
19:25:20 <AndyS> While TriG is great it's not a spec and some details need to be worked out.  And it's not a superset of N-Quads
19:25:58 <kasei> SteveH: could develop framework to turn TriG into HTTP updates
19:26:05 <AndyS> q+
19:26:06 <LeeF> q+ to mention that maybe we need someone to first put forth a version of http://www.w3.org/2001/sw/DataAccess/tests/README.html for us
19:26:06 <kasei> SteveH, did I get that right?
19:26:29 <SteveH> kasei, not just Trig, the whole thing
19:26:36 <kasei> bglimm: not able to run dawg tests right now.
19:26:56 <kasei> SteveH, could you scribe what you said?
19:27:26 <SteveH> SteveH: maybe we could colaboratively develop a test harness, which reads the manifests, and judges pass/fail
19:27:39 <kasei> ericP: in trig all the individual pieces come together in a single document. parsing burden is probably less than bookkeeping burden.
19:27:57 <kasei> ivan: don't want to put too much burden on implementors.
19:28:44 <kasei> LeeF: at some point tradeoff with our time and effort in producing a good test suite.
19:28:50 <kasei> ... this was a source of pain the first time around.
19:29:26 <kasei> ericP: will be asking a lot less of people this time even with TriG than we did last time with 1.0.
19:29:33 <SteveH> q+
19:29:44 <LeeF> ack AndyS
19:29:45 <AxelPolleres> TriG would be used for dataset and before/after graphstore, yes? anything else?
19:29:46 <kasei> sandro: TriG only brings together the data, though? not the results or other pieces?
19:29:59 <kasei> LeeF: correct.
19:30:08 <kasei> AndyS: don't see that TriG adds much.
19:30:19 <kasei> ... not all toolkits will have support.
19:30:19 <AxelPolleres> q+
19:31:06 <kasei> ivan: RDFa test suite, you submitted the URLs for different convertors. tool could run whole test suite.
19:31:22 <kasei> ... sent off data to various distillers, got results and ran SPARQL queries against them and checked with expected result.
19:31:39 <AxelPolleres> I *think* that this is what resulted out of that work of Michael Hausenblas for RDFa: http://ld2sd.deri.org/corrib/
19:31:41 <kasei> ... each test has HTML file, and what results of SPARQL query should look like. entirely automatic. yes/no for each test.
19:31:56 <kasei> ... worked well, but requirements are much simpler than for SPARQL's case.
19:32:17 <kasei> ... setup was very simple.
19:32:19 <AxelPolleres> but he said to me that it is kinda alpha at the moment (stable mid-end 2010)
19:32:24 <LeeF> q?
19:33:04 <kasei> ivan: all tests we have for 1.0 are valid for 1.1, so starting a new testing framework would be lost time.
19:33:21 <LeeF> ack SteveH
19:33:27 <pgearon> +1 on reusing current framework
19:33:52 <kasei> SteveH: agree with ericP that going to TriG is easier.
19:33:59 <kasei> ... current manifest is really complicated.
19:34:02 <AxelPolleres> q?
19:34:27 <kasei> AndyS: hearing proposal to flatten manifest files.
19:35:02 <kasei> LeeF: implementors are going to need to write new code anyway to support update tests.
19:35:24 <kasei> ivan: but we're going to add tests to Query also.
19:35:36 <ericP> -> http://swobjects.svn.sourceforge.net/viewvc/swobjects/trunk/tests/test_SPARUL.cpp?view=markup SPARUL tests
19:36:00 <LeeF> ack AxelPolleres
19:36:15 <kasei> ivan: how many implementors are going to be upset at having to make big changes to testing infrastructure?
19:36:46 <kasei> AxelPolleres: trig sounds like good idea for results of update.
19:37:20 <kasei> ... do we need something in protocol to dump the graphstore?
19:39:13 <kasei> ivan: readapting rdfa framework for sparql would make it alpha-quality code.
19:39:33 <kasei> pgearon: in favor of leaving things as they are. queries will work the same way. update is almost the same.
19:40:16 <kasei> ... different datastructure for supporting update. will be a major change to test suite to work with that.
19:40:25 <LeeF> ack LeeF
19:40:25 <Zakim> LeeF, you wanted to mention that maybe we need someone to first put forth a version of http://www.w3.org/2001/sw/DataAccess/tests/README.html for us
19:41:29 <kasei> LeeF: suggest we need couple of people to re-cast existing DAWG test document to describe how we'll do update tests. maybe service descriptions.
19:41:43 <kasei> ... until we do that we can't start collecting test cases.
19:41:57 <kasei> ... need volunteers.
19:42:05 <kasei> *crickets*
19:42:44 <kasei> ... otherwise will move to CR without any way to tell if features are properly implemented.
19:42:53 <kasei> ... bad for all sorts of reasons.
19:43:26 <kasei> AxelPolleres: looking for somebody to update dawg test doc and/or people to maintain manifests and tests cases.
19:43:49 <kasei> LeeF: can do it by committee if we get some basic work done. first is the dawg test doc. needs to handle update test cases.
19:44:05 <kasei> ... in ideal world we'd have test editors.
19:44:16 <AxelPolleres> I can do a first shot
19:45:08 <LeeF> ACTION: AxelPolleres to recast http://www.w3.org/2001/sw/DataAccess/tests/README.html into SPARQL WG space and update to handle SPARQL Update test cases by April 13, 2010
19:45:08 <trackbot> Sorry, couldn't find user - AxelPolleres
19:45:15 <LeeF> ACTION: Axel to recast http://www.w3.org/2001/sw/DataAccess/tests/README.html into SPARQL WG space and update to handle SPARQL Update test cases by April 13, 2010
19:45:15 <trackbot> Created ACTION-208 - Recast http://www.w3.org/2001/sw/DataAccess/tests/README.html into SPARQL WG space and update to handle SPARQL Update test cases by April 13, 2010 [on Axel Polleres - due 2010-04-01].
19:46:33 <kasei> pgearon: Axel can get in touch with me about changes needed for update syntax. Have existing thoughts on the changes.
19:47:34 <kasei> LeeF: not sure what SD testing looks like. protocol we have existing work we can build on.
19:47:52 <kasei> ... HTTP Update Protocol testing probably has to be similar to protocol+update testing.
19:48:03 <kasei> ... entailment similar to query testing.
19:48:17 <kasei> ivan: if we wanted to be formal, entailment would involve the OWL tests.
19:48:50 <LeeF> q?
19:48:56 <kasei> bglimm: could manually translate OWL tests into SPARQL queries.
19:49:23 <kasei> ivan: not testing inference engines. SPARQL should consider them correct.
19:49:34 <kasei> ... have to test relation of those inference engines to SPARQL.
19:49:46 <kasei> bglimm: you wouldn't get that with the OWL tests.
19:50:03 <kasei> ivan: right. that's not our job.
19:50:20 <kasei> ... test mechanism should be simple to show that the inference does happen.
19:50:44 <kasei> bglimm: can use same format as query tests. maybe more results.
19:51:37 <kasei> AxelPolleres: how are non-deterministic queries treated?
19:52:05 <kasei> LeeF: there were test cases for REDUCED. bits in manifest to indicate to use reduced semantics.
19:52:22 <kasei> ... don't know how that would apply to SAMPLE, for example. maybe we could come up with something.
19:52:36 <kasei> AxelPolleres: if results aren't completely ordered, not sure what we do.
19:53:10 <kasei> ... small enough test cases could list all possible results.
19:54:35 <kasei> LeeF: tomorrow's plan: query issues, not exists vs. minus
19:54:41 <kasei> ... propose we go with not exists
19:54:56 <kasei> ... property path issues
19:55:01 <betehess_> betehess_ has joined #sparql
19:55:02 <kasei> ... entailment issues
19:55:07 <kasei> ... SD issues and testing
19:55:48 <AndyS1> AndyS1 has joined #sparql
20:06:50 <LeeF> Adjourned.
20:41:11 <AndyS> AndyS has joined #sparql
20:45:53 <pgearon> pgearon has joined #sparql
23:13:52 <AxelPolleres> AxelPolleres has joined #sparql
23:59:31 <AxelPolleres> AxelPolleres has joined #sparql
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00001141