<sandro> PRESENT: bglimm, axel, andy, steveh, paul_gearon, lee, davidc, alex, souri, perry, sandro, kasei, ivan, ericP
12:04:31 <RRSAgent> logging to http://www.w3.org/2010/03/25-sparql-irc
RRSAgent IRC Bot: logging to http://www.w3.org/2010/03/25-sparql-irc ←
12:04:33 <trackbot> RRSAgent, make logs world
Trackbot IRC Bot: RRSAgent, make logs world ←
12:04:35 <trackbot> Zakim, this will be 77277
Trackbot IRC Bot: Zakim, this will be 77277 ←
12:04:35 <Zakim> ok, trackbot; I see SW_(SPARQLF2F)8:00AM scheduled to start 4 minutes ago
Zakim IRC Bot: 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
Lee Feigenbaum: zakim, this will be SPARQL ←
12:04:41 <Zakim> ok, LeeF; I see SW_(SPARQLF2F)8:00AM scheduled to start 4 minutes ago
Zakim IRC Bot: ok, LeeF; I see SW_(SPARQLF2F)8:00AM scheduled to start 4 minutes ago ←
12:05:20 <LeeF> +MIT262
Lee Feigenbaum: +MIT262 ←
12:08:08 <LeeF> Agenda: http://www.w3.org/2009/sparql/wiki/F2F3_Agenda
12:14:29 <bglimm> scribe: bglimm
(No events recorded for 9 minutes)
(Scribe set to Birte Glimm)
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
Axel Polleres: http://www.w3.org/2009/05/sparql-phase-II-charter.html ←
12:15:13 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/FeatureProposal
Axel Polleres: http://www.w3.org/2009/sparql/wiki/FeatureProposal ←
12:15:24 <bglimm> AxelPolleres: some things are marked as time permitting
Axel Polleres: some things are marked as time permitting ←
12:15:41 <bglimm> ... there is good progress on entailments regimes and property paths
... there is good progress on entailments regimes and property paths ←
12:16:19 <bglimm> ... we though we can move within the group to consider them as non-removable
... 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
PROPOSED: The working group will proceed the time-permitting feature Entailment to Rec ←
12:16:58 <bglimm> +1
+1 ←
12:17:49 <AxelPolleres> PROPOSED: The working group will intends to take the time-permitting feature "Entailment" through to Rec
PROPOSED: The working group will intends to take the time-permitting feature "Entailment" through to Rec ←
12:17:53 <bglimm> +1
+1 ←
12:17:56 <AxelPolleres> +1
Axel Polleres: +1 ←
12:17:57 <AndyS> +1
Andy Seaborne: +1 ←
12:18:01 <dcharbon2> +1
David Charboneau: +1 ←
12:18:28 <AxelPolleres> RESOLVED: The working group will intends to take the time-permitting feature "Entailment" through to Rec
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.
Axel Polleres: 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
... 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
PROPOSED: The working group will intends to take the time-permitting feature "PropertyPaths" through to Rec ←
12:19:02 <pgearon_> +1
Paul Gearon: +1 ←
12:19:26 <AxelPolleres> +1
Axel Polleres: +1 ←
12:19:35 <MattPerry> +1
Matthew Perry: +1 ←
12:19:53 <AxelPolleres> RESOLVED: The working group will intends to take the time-permitting feature "PropertyPaths" through to Rec
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
Axel Polleres: These were the two easy ones ←
12:20:23 <bglimm> ... I want to check the progress of the other ones too.
... I want to check the progress of the other ones too. ←
12:20:36 <bglimm> ... Function library made some progress too
... Function library made some progress too ←
12:21:32 <bglimm> ... The comma-select lists seems to be resolved to not have commas
... The comma-select lists seems to be resolved to not have commas ←
12:21:46 <bglimm> LeeF: That is resolved.
Lee Feigenbaum: That is resolved. ←
12:22:06 <bglimm> AxelPolleres: Ok, we don't need to address that any more.
Axel Polleres: Ok, we don't need to address that any more. ←
12:22:20 <bglimm> ... Then there is absic federated queries
... Then there is absic federated queries ←
12:22:32 <bglimm> s/absic/basic
s/absic/basic ←
12:23:02 <bglimm> LeeF: Eric is writing something up for that.
Lee Feigenbaum: Eric is writing something up for that. ←
12:23:11 <AndyS> Syntax feature was not just commas (have put IN,NOT IN to syntax)
Andy Seaborne: 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
... 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?
Axel Polleres: 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?
... 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.
Lee Feigenbaum: Eric said he'll have something ready next week. ←
12:24:59 <bglimm> LeeF: I'll liase with Eric on this.
Lee Feigenbaum: 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.
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].
Trackbot IRC Bot: 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?
Axel Polleres: Any progress on IN and BETWEEN operators? ←
12:25:54 <bglimm> AndyS: IN is in the grammar, BETWEEN is not
Andy Seaborne: IN is in the grammar, BETWEEN is not ←
12:26:11 <AxelPolleres> IN is in the grammar, BETWEEN unclear.... no real enthusiasm.
Axel Polleres: 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
... I didn't see much enthusiasm for anything more than what we have now ←
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.
Ivan Herman: 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.
.... 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?
Andy Seaborne: 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.
Axel Polleres: 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
... 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
.... 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.
Axel Polleres: 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?
... 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
... Ok, lets go to the update issues ←
12:32:20 <bglimm> ... The agenda lists several topics that need discussion
... The agenda lists several topics that need discussion ←
12:32:40 <bglimm> ... we want to nail down the syntax during the F2F
... we want to nail down the syntax during the F2F ←
12:32:49 <bglimm> ... First: CREATE and DROP
... First: CREATE and DROP ←
12:33:15 <bglimm> ... CREATE and DROP are currently in the spec.
... 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
Lee Feigenbaum: 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
Lee Feigenbaum: q+ to ask about SILENT ←
12:33:49 <bglimm> ?: We decided that we want to be able to create a graph explicitly
?: We decided that we want to be able to create a graph explicitly ←
12:33:57 <LeeF> s/?/pgearon/
Lee Feigenbaum: s/?/pgearon/ ←
12:34:02 <Souri> q+
Souripriya Das: q+ ←
12:34:06 <sandro> RRSAgent, pointer?
Sandro Hawke: RRSAgent, pointer? ←
12:34:06 <RRSAgent> See http://www.w3.org/2010/03/25-sparql-irc#T12-34-06
RRSAgent IRC Bot: See http://www.w3.org/2010/03/25-sparql-irc#T12-34-06 ←
12:34:08 <AxelPolleres> INSERT GRAPH <a> WHERE {}
Axel Polleres: INSERT GRAPH <a> WHERE {} ←
12:34:31 <bglimm> AxelPolleres: Is that the same as create graph <a>?
Axel Polleres: Is that the same as create graph <a>? ←
12:35:06 <LeeF> INSERT { GRAPH <a> { } } WHERE { } is equivalent to CREATE GRAPH <a> ?
Lee Feigenbaum: INSERT { GRAPH <a> { } } WHERE { } is equivalent to CREATE GRAPH <a> ? ←
12:35:44 <bglimm> LeeF: I am not sure it is the same
Lee Feigenbaum: I am not sure it is the same ←
12:35:55 <AndyS> INSERT { GRAPH <a> { } } WHERE { FILTER(false) }
Andy Seaborne: INSERT { GRAPH <a> { } } WHERE { FILTER(false) } ←
12:36:13 <bglimm> pgearon: Some implementations might treat it as the same, others might not
Paul Gearon: 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
Lee Feigenbaum: 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?
Axel Polleres: agreement that "empty insertion" doesn't create graph? ←
12:37:49 <AndyS> q+
Andy Seaborne: q+ ←
12:38:10 <bglimm> IvanH: We always agree that creating graphs is useful, so what are we discussing here?
Ivan Herman: We always agree that creating graphs is useful, so what are we discussing here? ←
12:38:18 <AxelPolleres> ack LeeF
Axel Polleres: ack LeeF ←
12:38:18 <Zakim> LeeF, you wanted to ask about SILENT
Zakim IRC Bot: 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
Lee Feigenbaum: I wanted to discuss whether we want to keep silent for CREATE and DROP ←
12:38:59 <bglimm> ... from a syntax point of view
... from a syntax point of view ←
12:39:07 <bglimm> ... What does it do?
... What does it do? ←
12:39:19 <bglimm> AxelPolleres: It throws no errors.
Axel Polleres: It throws no errors. ←
12:39:44 <bglimm> LeeF: We need to tighten up the way the spec talks about errors
Lee Feigenbaum: 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...
Axel Polleres: 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
Ivan Herman: 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
Lee Feigenbaum: I am happy about the idea of having SILENT ←
12:40:55 <bglimm> AxelPolleres: Would we need SILENT also for other update constructs?
Axel Polleres: Would we need SILENT also for other update constructs? ←
12:41:12 <bglimm> LeeF: It is a common thing for CREATE and DROP
Lee Feigenbaum: 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
Axel Polleres: 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.
Paul Gearon: 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
Steve Harris: 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?
Lee Feigenbaum: Is anybody proposing to add that for other constructors? ←
12:42:46 <bglimm> AxelPolleres: I don't think so.
Axel Polleres: I don't think so. ←
12:42:51 <bglimm> LeeF: Lets move on then.
Lee Feigenbaum: Lets move on then. ←
12:42:52 <AndyS> q?
Andy Seaborne: q? ←
12:43:10 <AxelPolleres> ack Souri
Axel Polleres: ack Souri ←
12:43:35 <bglimm> Souri: How do you want to see a store as graph store or quad store?
Souripriya Das: 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?
... 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
Lee Feigenbaum: 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
... 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
Souripriya Das: 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?
Axel Polleres: q? ←
12:46:38 <bglimm> ... we don't really know beforehand which graphs are there, there are not really any graphs beforehand
... we don't really know beforehand which graphs are there, there are not really any graphs beforehand ←
12:47:02 <AxelPolleres> ASK {GRAPH <g> {} }
Axel Polleres: ASK {GRAPH <g> {} } ←
12:47:04 <AxelPolleres> ?
Axel Polleres: ? ←
12:47:18 <AndyS> SELECT ?g { GRAPH ?g {}}
Andy Seaborne: SELECT ?g { GRAPH ?g {}} ←
12:47:19 <LeeF> ASK { GRAPH <a> { } }
Lee Feigenbaum: ASK { GRAPH <a> { } } ←
12:47:46 <bglimm> LeeF: Both queries distinguish this difference
Lee Feigenbaum: Both queries distinguish this difference ←
12:47:50 <AxelPolleres> q?
Axel Polleres: q? ←
12:47:55 <AxelPolleres> ack AndyS
Axel Polleres: ack AndyS ←
12:47:59 <LeeF> ack AndyS
Lee Feigenbaum: ack AndyS ←
12:48:08 <bglimm> AndyS: I think the behaviour is clear in the query spec.
Andy Seaborne: I think the behaviour is clear in the query spec. ←
12:48:40 <bglimm> ... RDF assumes that if there are no triples, then there is no graph
... RDF assumes that if there are no triples, then there is no graph ←
12:49:25 <pgearon> +q
Paul Gearon: +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
... 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 :)
Lee Feigenbaum: 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
... 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]
Andy Seaborne: 1 -- all named graphs exist [except RDF has no empty graphs] [ Scribe Assist by Sandro Hawke ] ←
12:51:03 <sandro> andy: 2 -- auto-create: add+remove ... then exists? (sql insert row)
Andy Seaborne: 2 -- auto-create: add+remove ... then exists? (sql insert row) [ Scribe Assist by Sandro Hawke ] ←
12:51:03 <sandro> andy: 3 -- fixed dataset (sql create table)
Andy Seaborne: 3 -- fixed dataset (sql create table) [ Scribe Assist by Sandro Hawke ] ←
12:51:03 <sandro> andy: 4 -- explicit add new graphs
Andy Seaborne: 4 -- explicit add new graphs [ Scribe Assist by Sandro Hawke ] ←
12:51:32 <LeeF> I'm not sure that the model that I thought was emerging is captured in those 4 :-)
Lee Feigenbaum: I'm not sure that the model that I thought was emerging is captured in those 4 :-) ←
12:51:58 <AxelPolleres> I hear:
Axel Polleres: I hear: ←
12:51:59 <bglimm> AndyS: There might be even more model
Andy Seaborne: There might be even more model ←
12:51:59 <AxelPolleres> * OPTION 1: all named graphs exist
Axel Polleres: * OPTION 1: all named graphs exist ←
12:51:59 <AxelPolleres> * OPTION 2: created (explicitly or implicitly) graphs exist (whether empty or not)
Axel Polleres: * 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
Axel Polleres: * 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
Lee Feigenbaum: 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
... 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
... 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...
Axel Polleres: I had thought we are heading towards Option 2 so far... ←
12:53:54 <bglimm> AndyS: Implicit graph creation seems important to people
Andy Seaborne: Implicit graph creation seems important to people ←
12:54:39 <LeeF> q?
Lee Feigenbaum: q? ←
12:54:41 <sandro> q?
Sandro Hawke: 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
... 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:15 <AxelPolleres> ... pure quad stores need some extra triples to decribe graphs for Option 2 to get around that
Axel Polleres: ... pure quad stores need some extra triples to decribe graphs for Option 2 to get around that ←
12:55:27 <AxelPolleres> ack ivan
Axel Polleres: ack ivan ←
12:55:27 <Zakim> ivan, you wanted to comment on non-silent if the graph exists and and create occurs
Zakim IRC Bot: 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.
Ivan Herman: I am not sure that there cannot be empty graphs. ←
12:55:59 <LeeF> q+ ivan
Lee Feigenbaum: q+ ivan ←
12:56:10 <LeeF> ack pgearon
Lee Feigenbaum: ack pgearon ←
12:56:11 <bglimm> AndyS: There is just one empty set, so all empty graphs are the same under this view
Andy Seaborne: 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
Andy Seaborne: 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
Lee Feigenbaum: 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
Paul Gearon: 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
... from that point of view we can have different empty graphs ←
12:57:53 <sandro> zakim, who is here?
Sandro Hawke: zakim, who is here? ←
12:57:53 <Zakim> SW_(SPARQLF2F)8:00AM has not yet started, sandro
Zakim IRC Bot: 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
Zakim IRC Bot: 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:29 <bglimm> ... we are diverging here anyway from RDF because RDF itself does not consider any changes to a graph, but we do
... 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?
Axel Polleres: 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
... 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
Paul Gearon: 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 {} } => ?
Andy Seaborne: 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
Lee Feigenbaum: 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
Andy Seaborne: 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.
Lee Feigenbaum: 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. [ Scribe Assist by Sandro Hawke ] ←
13:01:33 <AxelPolleres> q?
Axel Polleres: q? ←
13:01:34 <Souri> q+
Souripriya Das: q+ ←
13:01:56 <LeeF> s/two graph stores with the same graphs/two graph stores with the same graph names with different contents/
Lee Feigenbaum: 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
Lee Feigenbaum: ack Souri ←
13:02:20 <dcharbon2> q+
David Charboneau: q+ ←
13:02:24 <bglimm> Souri: If we don't have to explicitly create a graph, that would be more clear conceptually.
Souripriya Das: 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?
Andy Seaborne: 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
Axel Polleres: q+ to ask whether we can narrow down to 2 options over all ←
13:02:50 <ivan> q-
Ivan Herman: q- ←
13:02:57 <LeeF> ack dcharbon2
Lee Feigenbaum: ack dcharbon2 ←
13:02:59 <LeeF> ack dcharbon
Lee Feigenbaum: 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?
David Charboneau: 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.
Axel Polleres: "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.
Souripriya Das: 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?
Sandro Hawke: 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.
Souripriya Das: We would have to do that for each query. ←
13:05:44 <AxelPolleres> q?
Axel Polleres: q? ←
13:06:40 <bglimm> Souri: Every query would have to create a corresponding view
Souripriya Das: 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
Souripriya Das: [[maybe?]] the set of graphs which exist, in our RDB2RDF approach, is only defined for a particular query [ Scribe Assist by Sandro Hawke ] ←
13:07:27 <LeeF> ack AndyS
Lee Feigenbaum: ack AndyS ←
13:07:27 <Zakim> AndyS, you wanted to ask souri if graph names are dynamic in RDF2RDB?
Zakim IRC Bot: 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.
Steve Harris: 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.
Steve Harris: A lot of the trivial implementation of sparql are pure quads, where removing the last quad removes the graph. [ Scribe Assist by Sandro Hawke ] ←
13:09:58 <Souri> q+
Souripriya Das: q+ ←
13:10:07 <bglimm> SteveH: This ould be implementation defined.
Steve Harris: This ould be implementation defined. ←
13:10:15 <bglimm> s/ould/would/
s/ould/would/ ←
13:10:23 <sandro> q+ to argue against implementation defined, since it's pretty trivial to go either way
Sandro Hawke: 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
Axel Polleres: 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
.... you could implicitly create a graph on insert and implicitly drop it when it is empty ←
13:13:54 <sandro> q-
Sandro Hawke: 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
Axel Polleres: 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?
Axel Polleres: q? ←
13:14:14 <AxelPolleres> ack Axel
Axel Polleres: ack Axel ←
13:14:14 <Zakim> AxelPolleres, you wanted to ask whether we can narrow down to 2 options over all
Zakim IRC Bot: 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
Sandro Hawke: 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
If you are asked to create it, then you know it is empty ←
13:15:12 <pgearon> q+
Paul Gearon: q+ ←
13:15:15 <bglimm> s/If/...If/
s/If/...If/ ←
13:15:33 <LeeF> My thoughts are at: http://www.w3.org/2009/sparql/wiki/Lees_Update_Graph_Model
Lee Feigenbaum: 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?
Souripriya Das: 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."
Sandro Hawke: 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." [ Scribe Assist by Sandro Hawke ] ←
13:16:24 <bglimm> ... it gets difficult to distinguish the two situations
... 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?
David Charboneau: q+ if we allow a choice, don't we need to spec what happens in each case? ←
13:16:42 <dcharbon2> q+
David Charboneau: q+ ←
13:16:51 <LeeF> ack souri
Lee Feigenbaum: ack souri ←
13:16:53 <AxelPolleres> Can we go around and ask what current implementations do on queries for "non-existinent/non-known" graphs?
Axel Polleres: 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
Paul Gearon: 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
... 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
Sandro Hawke: 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?
Axel Polleres: 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
Paul Gearon: I know permissions are outside of the spec, but they are still necessary ←
13:19:14 <AxelPolleres> q?
Axel Polleres: q? ←
13:19:27 <ivan> ack pgearon
Ivan Herman: 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
Lee Feigenbaum: 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
Paul Gearon: 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
Steve Harris: 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.
Steve Harris: setting permission could implicitely create it. [ Scribe Assist by Sandro Hawke ] ←
13:22:31 <ivan> q?
Ivan Herman: 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"
Souripriya Das: 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?
Andy Seaborne: 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+
Ivan Herman: q+ ←
13:22:51 <LeeF> ack dcharbon2
Lee Feigenbaum: ack dcharbon2 ←
13:22:52 <LeeF> ack dcharbon
Lee Feigenbaum: ack dcharbon ←
13:22:53 <bglimm> pgearon: No, but I would like to have CREATE in the language
Paul Gearon: 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?
Axel Polleres: 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
David Charboneau: 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
Andy Seaborne: There could be 2 different definitions, one for systems with bookkeeping and one for systems without ←
13:25:27 <sandro> "bookkeeping"
Sandro Hawke: "bookkeeping" ←
13:25:48 <AxelPolleres> q?
Axel Polleres: q? ←
13:25:50 <Souri> q+
Souripriya Das: q+ ←
13:25:51 <sandro> andy: I like "bookkeeping" functions, which are perhaps optional.
Andy Seaborne: I like "bookkeeping" functions, which are perhaps optional. [ Scribe Assist by Sandro Hawke ] ←
13:26:00 <Souri> q-
Souripriya Das: q- ←
13:26:06 <LeeF> ack ivan
Lee Feigenbaum: ack ivan ←
13:26:20 <pgearon> +1 for andy's book keeping concept
Paul Gearon: +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
Ivan Herman: 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
Steve Harris: +1 to ivan ←
13:28:43 <sandro> sandro: A very safe form of CREATE is where the URI is owned by this quadstore.
Sandro Hawke: A very safe form of CREATE is where the URI is owned by this quadstore. [ Scribe Assist by Sandro Hawke ] ←
13:28:44 <AxelPolleres> q?
Axel Polleres: 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
... 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?
Gregory Williams: 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.
Gregory Williams: so, maybe just safeER. ←
13:29:25 <sandro> perhaps, kasei
Sandro Hawke: perhaps, kasei ←
13:29:29 <AxelPolleres> ack axel
Axel Polleres: ack axel ←
13:29:29 <Zakim> AxelPolleres, you wanted to ask whether we have "graph created", "graph dropped" in the protocol?
Zakim IRC Bot: 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
Paul Gearon: 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.
Axel Polleres: 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?
Axel Polleres: 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
Andy Seaborne: 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
Steve Harris: 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> {}}
Axel Polleres: {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
David Charboneau: 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
David Charboneau: else - it's an infinite list ←
13:32:57 <pgearon> what about SELECT * FROM <g> WHERE {}
Paul Gearon: what about SELECT * FROM <g> WHERE {} ←
13:33:05 <sandro> SteveH: 5store is a pure quadstore so it doesn't distinquish existing from empty.
Steve Harris: 5store is a pure quadstore so it doesn't distinquish existing from empty. [ Scribe Assist by Sandro Hawke ] ←
13:33:30 <SteveH> ^ - non-existing
Steve Harris: ^ - non-existing ←
13:34:10 <bglimm> pgearon: mulgara is quadstore with bookkeeping, so you can query for empty graphs
Paul Gearon: 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
... 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
Lee Feigenbaum: 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
David Charboneau: 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"
Souripriya Das: 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
... 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
... 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
Axel Polleres: In that model if you ask for a model that does not exist would that give an error ←
13:40:02 <bglimm> Souri: Yes.
Souripriya Das: Yes. ←
13:40:53 <bglimm> ... if you don't have the privildges to see it, then it is an error
... 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
... 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
Gregory Williams: 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
Axel Polleres: It seems we have a clear undecided situation ←
13:43:23 <LeeF> I don't really understand the full question that Axel is asking :)
Lee Feigenbaum: 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!
Gregory Williams: a clear win for punting to the service description! ←
13:43:39 <bglimm> ... it seems we should allow for both cases
... 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
... 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
Ivan Herman: 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
David Charboneau: 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
... 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?
Lee Feigenbaum: 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
Axel Polleres: 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
Lee Feigenbaum: 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
Ivan Herman: Some systems give error, while others give an empty answer. That's not good ←
13:45:41 <dcharbon2> q+
David Charboneau: q+ ←
13:46:01 <AxelPolleres> q?
Axel Polleres: q? ←
13:46:28 <AndyS> axel - right for me - I also have an impl that can return true (empty graphs exist)
Andy Seaborne: 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 } } ?
Steve Harris: 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)
Lee Feigenbaum: 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
David Charboneau: 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 {} }
Axel Polleres: THat one is NOT asking for empty graphs {GRAPH ?G {} } ←
13:48:44 <AxelPolleres> SELECT * {GRAPH ?G {} }
Axel Polleres: 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
David Charboneau: 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> {} }
Axel Polleres: ASK {GRAPH <g> {} } ←
13:50:11 <bglimm> AndyS: This shows the difference between a dataset and a graph store
Andy Seaborne: This shows the difference between a dataset and a graph store ←
13:50:22 <LeeF> CREATE <g> ; ASK FROM NAMED <g> { GRAPH <g> { } }
Lee Feigenbaum: CREATE <g> ; ASK FROM NAMED <g> { GRAPH <g> { } } ←
13:51:10 <bglimm> LeeF: Should be true, but requires bookkeeping
Lee Feigenbaum: Should be true, but requires bookkeeping ←
13:51:58 <bglimm> SteveH: Create affects the graph store and asks is for the datasets
Steve Harris: Create affects the graph store and asks is for the datasets ←
13:52:22 <AxelPolleres> CREATE <g> ; ASK { GRAPH <g> { } }
Axel Polleres: 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
Lee Feigenbaum: 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?
Lee Feigenbaum: What would the update spec say for this? ←
13:54:49 <bglimm> SteveH: Graph stores and datasets are different things
Steve Harris: Graph stores and datasets are different things ←
13:55:16 <kasei> q+
Gregory Williams: q+ ←
13:55:20 <dcharbon2> q-
David Charboneau: q- ←
13:55:57 <AxelPolleres> q?
Axel Polleres: q? ←
13:56:02 <bglimm> LeeF: I think there needs to be some relationship between the graph store and the datasets
Lee Feigenbaum: 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 :)
Lee Feigenbaum: 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
Lee Feigenbaum: 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
Gregory Williams: 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
Steve Harris: I am happy to return an error from a quad store ←
13:57:46 <bglimm> Sandro: Would you also be happy to support bookkeeping?
Sandro Hawke: 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.
Steve Harris: 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+
Steve Harris: q+ ←
13:58:57 <LeeF> q+ to wonder if his update proposal makes the quad store people unhappy
Lee Feigenbaum: 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
Axel Polleres: 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
Axel Polleres: 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
Steve Harris: 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
Andy Seaborne: There is an explicit algebra operator that deals with that section 5.2.1 ←
14:00:01 <AxelPolleres> q?
Axel Polleres: q? ←
14:00:09 <SteveH> Zakim, ack me
Steve Harris: Zakim, ack me ←
14:00:09 <Zakim> I see kasei, LeeF on the speaker queue
Zakim IRC Bot: I see kasei, LeeF on the speaker queue ←
14:00:13 <AndyS> http://www.w3.org/TR/rdf-sparql-query/#defn_evalGraph
Andy Seaborne: 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.
Lee Feigenbaum: 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
Lee Feigenbaum: 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)
Axel Polleres: ... 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
... I wonder whether the stuff on the wiki page does not satisfy anyones requirements ←
14:01:28 <AndyS> 3rd bullet is troublesome to me
Andy Seaborne: 3rd bullet is troublesome to me ←
14:01:51 <SteveH> q+
Steve Harris: q+ ←
14:01:52 <AndyS> "A SPARQL Update operation is performed in the context of a GraphStore"
Andy Seaborne: "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)
Andy Seaborne: (and haven't properly read the email yet - sorry) ←
14:02:09 <kasei> q-
Gregory Williams: q- ←
14:02:15 <LeeF> ack LeeF
Lee Feigenbaum: ack LeeF ←
14:02:15 <Zakim> LeeF, you wanted to wonder if his update proposal makes the quad store people unhappy
Zakim IRC Bot: 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.
Axel Polleres: Lets wrap up because the break is coming up. ←
14:02:50 <bglimm> LeeF: The wiki page mainly reflects my view.
Lee Feigenbaum: The wiki page mainly reflects my view. ←
14:03:42 <AndyS> q+
Andy Seaborne: q+ ←
14:04:04 <bglimm> ... I can't see that the ASK query should be allowed to return false by the spec
... 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".
Sandro Hawke: we could say "empty graphs MAY be implicitely deleted". [ Scribe Assist by Sandro Hawke ] ←
14:04:45 <SteveH> +1 to sandro's suggestion
Steve Harris: +1 to sandro's suggestion ←
14:04:53 <LeeF> +1 to sandro's suggestion
Lee Feigenbaum: +1 to sandro's suggestion ←
14:04:59 <Souri> +1
Souripriya Das: +1 ←
14:05:00 <Souri> +1
Souripriya Das: +1 ←
14:05:09 <MattPerry> +1
Matthew Perry: +1 ←
14:05:23 <sandro> -0
Sandro Hawke: -0 ←
14:05:27 <sandro> :-)
Sandro Hawke: :-) ←
14:05:44 <pgearon> +1
Paul Gearon: +1 ←
14:06:00 <AxelPolleres> can someone else take over scribing on MIT side?
Axel Polleres: can someone else take over scribing on MIT side? ←
14:06:01 <dcharbon2> +1
David Charboneau: +1 ←
14:06:27 <sandro> lee: not the best solution for interoperability, but maybe the best we can do.
Lee Feigenbaum: not the best solution for interoperability, but maybe the best we can do. [ Scribe Assist by Sandro Hawke ] ←
14:06:28 <AndyS> For clarification: when? during update or immediately after whole request done (multiple oerations)?
Andy Seaborne: For clarification: when? during update or immediately after whole request done (multiple oerations)? ←
14:39:28 <LeeF> scribenick: pgearon
(No events recorded for 33 minutes)
(Scribe set to Paul Gearon)
14:39:35 <AxelPolleres> scribe: paul gearon
14:39:48 <AxelPolleres> discussing http://www.w3.org/2009/sparql/wiki/Lees_Update_Graph_Model
Axel Polleres: discussing http://www.w3.org/2009/sparql/wiki/Lees_Update_Graph_Model ←
14:39:59 <AxelPolleres> ... asa a proposal to move forward.
Axel Polleres: ... 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
Lee Feigenbaum: 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?
Axel Polleres: q? ←
14:40:32 <SteveH> q-
Steve Harris: q- ←
14:40:43 <LeeF> zakim, clear the q!
Lee Feigenbaum: zakim, clear the q! ←
14:40:43 <Zakim> I don't understand 'clear the q!', LeeF
Zakim IRC Bot: I don't understand 'clear the q!', LeeF ←
14:40:47 <AndyS> q+
Andy Seaborne: q+ ←
14:40:58 <LeeF> ack AndyS
Lee Feigenbaum: ack AndyS ←
14:41:13 <pgearon> AndyS: like the proposal on the wiki, but nervous about point 3
Andy Seaborne: like the proposal on the wiki, but nervous about point 3 ←
14:41:35 <pgearon> prop 3 links dataset and graph store
prop 3 links dataset and graph store ←
14:41:57 <pgearon> LeeF: removed this point
Lee Feigenbaum: removed this point ←
14:43:14 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/index.php?title=Lees_Update_Graph_Model&oldid=1995
Axel Polleres: 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
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
Gregory Williams: +1 ←
14:43:41 <bglimm> +1
Birte Glimm: +1 ←
14:43:41 <dcharbon2> +1
David Charboneau: +1 ←
14:43:46 <MattPerry> +1
Matthew Perry: +1 ←
14:43:49 <Souri> +1
Souripriya Das: +1 ←
14:43:53 <AndyS> +1
Andy Seaborne: +1 ←
14:43:53 <AxelPolleres> +1
Axel Polleres: +1 ←
14:44:04 <sandro> +0 (I guess it's good enough, but I wish I understand the semweb implications better)
Sandro Hawke: +0 (I guess it's good enough, but I wish I understand the semweb implications better) ←
14:44:25 <pgearon> +1
+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
Steve Harris: 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
Ivan Herman: +1 ←
14:45:52 <AlexPassant> +1
Alexandre Passant: +1 ←
14:45:52 <AxelPolleres> q+ to add sd: extension proposal
Axel Polleres: 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
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
Trackbot IRC Bot: 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
Axel Polleres: wants to have an sd flag to indicate if implementations always preserve empty graphs ←
14:46:48 <LeeF> trackbot, close ISSUE-20
Lee Feigenbaum: trackbot, close ISSUE-20 ←
14:46:48 <trackbot> ISSUE-20 Graphs aware stores vs. quad stores for SPARQL/update (empty graphs) closed
Trackbot IRC Bot: ISSUE-20 Graphs aware stores vs. quad stores for SPARQL/update (empty graphs) closed ←
14:48:11 <LeeF> q?
Lee Feigenbaum: q? ←
14:48:14 <LeeF> ack AxelPolleres
Lee Feigenbaum: ack AxelPolleres ←
14:48:14 <Zakim> AxelPolleres, you wanted to add sd: extension proposal
Zakim IRC Bot: AxelPolleres, you wanted to add sd: extension proposal ←
14:48:33 <pgearon> not going to add sd: at the moment
not going to add sd: at the moment ←
14:49:23 <kasei> q+
Gregory Williams: q+ ←
14:50:04 <pgearon> Ivan: concerned about SILENT on CREATE, but spec is already clear
Ivan Herman: concerned about SILENT on CREATE, but spec is already clear ←
14:50:41 <LeeF> ack kasei
Lee Feigenbaum: 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
Gregory Williams: 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
Alexandre Passant: 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.
Gregory Williams: 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. [ Scribe Assist by Axel Polleres ] ←
14:52:56 <sandro> paul: It's an ERROR in all implementations if you CREATE when the graph isn't empty.
Paul Gearon: It's an ERROR in all implementations if you CREATE when the graph isn't empty. [ Scribe Assist by Sandro Hawke ] ←
14:53:40 <LeeF> I'm ambivalent about CREATE GRAPH vs. ADD GRAPH
Lee Feigenbaum: 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
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
Andy Seaborne: ADD is as bad - may presume GET deref ←
14:54:52 <AxelPolleres> INSERT GRAPH ?
Axel Polleres: INSERT GRAPH ? ←
14:55:35 <sandro> CREATE isn't perfect, but ADD is worse. OBTAIN? PREPARE? BEGIN? OPEN?
Sandro Hawke: 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)
Ivan Herman: 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?
Sandro Hawke: STORE? REMEMBER? HOLD? ←
14:56:37 <pgearon> USING?
USING? ←
14:57:38 <AxelPolleres> INSERT GRAPH ; INSERT { } ; DELETE { } ; DELETE GRAPH
Axel Polleres: INSERT GRAPH ; INSERT { } ; DELETE { } ; DELETE GRAPH ←
14:57:51 <SteveH> INSERT GRAPH <g>, no?
Steve Harris: INSERT GRAPH <g>, no? ←
14:58:14 <AndyS> INSERT { GRAPH ..} WHERE ... is too close
Andy Seaborne: INSERT { GRAPH ..} WHERE ... is too close ←
14:59:24 <AxelPolleres> q?
Axel Polleres: q? ←
14:59:34 <ivan> q?
Ivan Herman: q? ←
14:59:41 <sandro> q+
Sandro Hawke: q+ ←
15:00:20 <AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0539.html
Axel Polleres: 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)
Axel Polleres: 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
Andy Seaborne: Origin of this: Difference between CREATE / DROP are graph mgt ; INSERT / DELETE are data manipulation ←
15:01:08 <AxelPolleres> q?
Axel Polleres: q? ←
15:01:54 <pgearon> Sandro: what is the use case for creating a graph in the store?
Sandro Hawke: 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)
Lee Feigenbaum: 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
Sandro Hawke: so CREATE sounds like a reasonable name ←
15:03:36 <pgearon> Ivan: still unhappy with CREATE
Ivan Herman: still unhappy with CREATE ←
15:03:47 <AndyS> q+
Andy Seaborne: q+ ←
15:04:09 <pgearon> Ivan: since the concept of the "graph" continues to exist whether it is in the local store or not
Ivan Herman: since the concept of the "graph" continues to exist whether it is in the local store or not ←
15:04:15 <AlexPassant> q+
Alexandre Passant: q+ ←
15:04:21 <AxelPolleres> q?
Axel Polleres: q? ←
15:04:39 <AxelPolleres> ack sandro
Axel Polleres: ack sandro ←
15:05:18 <AxelPolleres> ack AndyS
Axel Polleres: ack AndyS ←
15:05:24 <sandro> sandro: read CREATE as "create storage for"
Sandro Hawke: read CREATE as "create storage for" [ Scribe Assist by Sandro Hawke ] ←
15:06:27 <AxelPolleres> q?
Axel Polleres: q? ←
15:06:28 <pgearon> AndyS: LeeF is emphasizing the local storage of the data, the other approach is more about the entire web
Andy Seaborne: LeeF is emphasizing the local storage of the data, the other approach is more about the entire web ←
15:06:42 <AxelPolleres> ack AlexPassant
Axel Polleres: ack AlexPassant ←
15:07:23 <AxelPolleres> INSERT GRAPH ; INSERT { } ; DELETE { } ; DELETE GRAPH
Axel Polleres: INSERT GRAPH ; INSERT { } ; DELETE { } ; DELETE GRAPH ←
15:07:58 <AndyS> qck me
Andy Seaborne: qck me ←
15:08:01 <AndyS> ack me
Andy Seaborne: 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
Alexandre Passant: the CREATE operation is about referring to the graph as being expressed locally, as opposed to being elsewhere on the web ←
15:09:23 <pgearon> Axel: do we still want CLEAR?
Axel Polleres: do we still want CLEAR? ←
15:09:28 <AlexPassant> pgearon: not only CREATE actually but any SPARUL operations
Paul Gearon: not only CREATE actually but any SPARUL operations [ Scribe Assist by Alexandre Passant ] ←
15:09:47 <kasei> q+
Gregory Williams: q+ ←
15:11:06 <pgearon> AndyS: CREATE/DROP explicitly for book keeping operations. DELETE/INSERT are for data
Andy Seaborne: CREATE/DROP explicitly for book keeping operations. DELETE/INSERT are for data ←
15:11:19 <LeeF> ack kasei
Lee Feigenbaum: ack kasei ←
15:11:53 <AxelPolleres> OPTION 1: keep with CREATE/DROP/INSERT/DELETE
Axel Polleres: OPTION 1: keep with CREATE/DROP/INSERT/DELETE ←
15:12:14 <AxelPolleres> OPTION 2: INSERT/DELETE GRAPH INSERT/DELETE pattern
Axel Polleres: OPTION 2: INSERT/DELETE GRAPH INSERT/DELETE pattern ←
15:12:31 <AxelPolleres> OPTION 3: INSERT DROP GRAPH INSERT/DELETE pattern
Axel Polleres: OPTION 3: INSERT DROP GRAPH INSERT/DELETE pattern ←
15:12:36 <dcharbon2> q+
David Charboneau: q+ ←
15:12:48 <LeeF> ack dcharbon2
Lee Feigenbaum: 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
David Charboneau: 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
Lee Feigenbaum: +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.
David Charboneau: 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. [ Scribe Assist by Sandro Hawke ] ←
15:14:04 <sandro> +1 dcharbon2
Sandro Hawke: +1 dcharbon2 ←
15:14:04 <AndyS> +1 - ultimate is scope = web
Andy Seaborne: +1 - ultimate is scope = web ←
15:14:45 <SteveH> LOAD <file:///dev/null> INTO <g> :)
Steve Harris: LOAD <file:///dev/null> INTO <g> :) ←
15:14:52 <LeeF> :D
Lee Feigenbaum: :D ←
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"
Ivan Herman: 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
Lee Feigenbaum: It is creation, just in a scope ←
15:15:21 <AxelPolleres> q+ to (seriously) �ask ivan whether that is not LOAD
Axel Polleres: q+ to (seriously) �ask ivan whether that is not LOAD ←
15:15:49 <ivan> ack dcharbon2
Ivan Herman: ack dcharbon2 ←
15:15:57 <LeeF> ack dcharbon
Lee Feigenbaum: ack dcharbon ←
15:15:58 <AndyS> ack dcharbon
Andy Seaborne: ack dcharbon ←
15:15:58 <LeeF> ack AxelPolleres
Lee Feigenbaum: ack AxelPolleres ←
15:15:59 <Zakim> AxelPolleres, you wanted to (seriously) �ask ivan whether that is not LOAD
Zakim IRC Bot: AxelPolleres, you wanted to (seriously) �ask ivan whether that is not LOAD ←
15:16:43 <sandro> q+
Sandro Hawke: q+ ←
15:17:05 <sandro> q+ to suggest endpoints SHOULD reject creates for which a LOAD is possible and they dont have write access
Sandro Hawke: 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
Axel Polleres: could use LOAD to handle Ivan's usecase. LOAD could create an error if the data does not exist ←
15:17:57 <Souri> q+
Souripriya Das: q+ ←
15:18:50 <LeeF> ack sandro
Lee Feigenbaum: 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
Zakim IRC Bot: 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
Lee Feigenbaum: 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
Axel Polleres: ack Souri ←
15:20:23 <SteveH> q+
Steve Harris: q+ ←
15:20:30 <Souri> q+
Souripriya Das: q+ ←
15:20:36 <ivan> ack LeeF
Ivan Herman: 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
Zakim IRC Bot: 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-
Steve Harris: q- ←
15:20:53 <AxelPolleres> sorry, souri should go first.
Axel Polleres: sorry, souri should go first. ←
15:21:19 <sandro> sandro: Let's advise people to only CREATE for URIs for which they are authoritative.
Sandro Hawke: Let's advise people to only CREATE for URIs for which they are authoritative. [ Scribe Assist by Sandro Hawke ] ←
15:21:21 <pgearon> +q to ask if we need to revisit the need to create/delete graphs
+q to ask if we need to revisit the need to create/delete graphs ←
15:21:36 <sandro> pgearon, you mean q+
Sandro Hawke: pgearon, you mean q+ ←
15:21:42 <AxelPolleres> q+ to suggest that text for CREATE makes clear that CREATE creates a local copy?
Axel Polleres: q+ to suggest that text for CREATE makes clear that CREATE creates a local copy? ←
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
Alexandre Passant: 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
Souripriya Das: CREATE is creating a "fragment" of the data in a local store ←
15:24:40 <LeeF> ack Souri
Lee Feigenbaum: ack Souri ←
15:24:47 <AndyS> +1 to scope view - too much like web-in-a-box if scope only state of the web
Andy Seaborne: +1 to scope view - too much like web-in-a-box if scope only state of the web ←
15:25:12 <LeeF> ack pgearon
Lee Feigenbaum: ack pgearon ←
15:25:12 <Zakim> pgearon, you wanted to ask if we need to revisit the need to create/delete graphs
Zakim IRC Bot: 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> {} }
Steve Harris: What about INSERT { GRAPH <g> {} } ←
15:26:07 <SteveH> ?
Steve Harris: ? ←
15:26:46 <LeeF> ack AxelPolleres
Lee Feigenbaum: ack AxelPolleres ←
15:26:46 <Zakim> AxelPolleres, you wanted to suggest that text for CREATE makes clear that CREATE creates a local copy?
Zakim IRC Bot: 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?
David Charboneau: What does DELETE { GRAPH <g> } do? ←
15:27:12 <Souri> I am fine with option 1 (for now, implicitly meaning local scope)
Souripriya Das: 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
Lee Feigenbaum: 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?
Gregory Williams: CREAT GRAPH? ←
15:28:30 <AndyS> pgearon: OPTION 4: No CREATE, DROP
Paul Gearon: OPTION 4: No CREATE, DROP [ Scribe Assist by Andy Seaborne ] ←
15:28:38 <AxelPolleres> OPTION 4: drop create/drop alltogether?
Axel Polleres: OPTION 4: drop create/drop alltogether? ←
15:29:03 <SteveH> I'm mildly in favour of not having CREATE
Steve Harris: I'm mildly in favour of not having CREATE ←
15:29:26 <AndyS> dcharbon: could design for bookkeepingless systems
David Charboneau: could design for bookkeepingless systems [ Scribe Assist by Andy Seaborne ] ←
15:30:03 <dcharbon2> +0.5 to option 4
David Charboneau: +0.5 to option 4 ←
15:30:15 <AxelPolleres> OPTION 1: keep with CREATE/DROP/INSERT/DELETE
Axel Polleres: OPTION 1: keep with CREATE/DROP/INSERT/DELETE ←
15:30:16 <AxelPolleres> OPTION 2: INSERT/DELETE GRAPH INSERT/DELETE pattern
Axel Polleres: OPTION 2: INSERT/DELETE GRAPH INSERT/DELETE pattern ←
15:30:16 <AxelPolleres> OPTION 3: INSERT DROP GRAPH INSERT/DELETE pattern
Axel Polleres: OPTION 3: INSERT DROP GRAPH INSERT/DELETE pattern ←
15:30:16 <AxelPolleres> OPTION 4: Drop CREATE/DROP alltogether
Axel Polleres: OPTION 4: Drop CREATE/DROP alltogether ←
15:30:31 <ivan> OPTION 5: Add/DROP/INSERT/DELETE
Ivan Herman: OPTION 5: Add/DROP/INSERT/DELETE ←
15:30:51 <AndyS> ADD implies LOAD to me
Andy Seaborne: ADD implies LOAD to me ←
15:30:57 <SteveH> me too
Steve Harris: me too ←
15:31:06 <sandro> is ADD really ADD GRAPH ?
Sandro Hawke: is ADD really ADD GRAPH ? ←
15:31:20 <sandro> ivan: yes.
Ivan Herman: yes. [ Scribe Assist by Sandro Hawke ] ←
15:33:03 <AndyS> +1 / -1 / -1 / maybe, need more time to consider / -1
Andy Seaborne: +1 / -1 / -1 / maybe, need more time to consider / -1 ←
15:33:17 <LeeF> +1 / -1 / -1 / 0
Lee Feigenbaum: +1 / -1 / -1 / 0 ←
15:33:32 <ivan> -1/-1/1/maybe/1
Ivan Herman: -1/-1/1/maybe/1 ←
15:33:39 <pgearon> +1 / -1 / -1 / +0.5 / -1
+1 / -1 / -1 / +0.5 / -1 ←
15:33:47 <kasei> 0.5 / 0 / 0 / 0 / 0
Gregory Williams: 0.5 / 0 / 0 / 0 / 0 ←
15:33:48 <LeeF> +1 / -1 / -1 / 0 / 0
Lee Feigenbaum: +1 / -1 / -1 / 0 / 0 ←
15:33:49 <MattPerry> 0 / -1 / -1 / +1 / -1
Matthew Perry: 0 / -1 / -1 / +1 / -1 ←
15:33:50 <AlexPassant> 0 / 0 / 0 / +1 / 0
Alexandre Passant: 0 / 0 / 0 / +1 / 0 ←
15:33:53 <SteveH> +0 / -1 / -1 / +0.5 / -1
Steve Harris: +0 / -1 / -1 / +0.5 / -1 ←
15:33:55 <Souri> 0.5/-1/-1/+1/-1
Souripriya Das: 0.5/-1/-1/+1/-1 ←
15:34:01 <AxelPolleres> +1/0/0/0/+1
Axel Polleres: +1/0/0/0/+1 ←
15:34:02 <sandro> +0 / -1 / -1 / -0 / +0
Sandro Hawke: +0 / -1 / -1 / -0 / +0 ←
15:34:11 <bglimm> +1 / 0 / -1 / 0 / 0
Birte Glimm: +1 / 0 / -1 / 0 / 0 ←
15:34:57 <dcharbon2> 0/0/0/0
David Charboneau: 0/0/0/0 ←
15:35:07 <dcharbon2> 0
15:35:29 <AndyS> 0x01FFFF--FF
Andy Seaborne: 0x01FFFF--FF ←
15:36:16 <kasei> q+
Gregory Williams: q+ ←
15:37:30 <LeeF> option 1
Lee Feigenbaum: option 1 ←
15:37:36 <kasei> 0
15:37:36 <AndyS> option 1
Andy Seaborne: option 1 ←
15:37:40 <SteveH> option 1
Steve Harris: option 1 ←
15:38:01 <MattPerry> option 1
Matthew Perry: option 1 ←
15:38:05 <bglimm> 1
Birte Glimm: 1 ←
15:38:06 <AxelPolleres> STRAWPOLL: 1 (prefer Option 1)�/5 (prefer Option 5 )/0 (don't care between those two
STRAWPOLL: 1 (prefer Option 1)�/5 (prefer Option 5 )/0 (don't care between those two ←
15:38:07 <AxelPolleres> 1
Axel Polleres: 1 ←
15:38:13 <dcharbon2> option 1
David Charboneau: option 1 ←
15:38:21 <AlexPassant> 0 (but need to mention the scope in the spec. for both imo)
Alexandre Passant: 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"
Sandro Hawke: 1 is "CREATE GRAPH", 5 is "ADD GRAPH" ←
15:38:47 <sandro> option 5
Sandro Hawke: option 5 ←
15:38:56 <AndyS> Option 4: DROp -> CLEAR
Andy Seaborne: Option 4: DROp -> CLEAR ←
15:38:58 <SteveH> CLEAR <g> == DROP GRAPH <g>
Steve Harris: CLEAR <g> == DROP GRAPH <g> ←
15:39:04 <LeeF> DELETE WHERE { GRAPH <g1> { ?s ?p ?o } }
Lee Feigenbaum: DELETE WHERE { GRAPH <g1> { ?s ?p ?o } } ←
15:39:39 <Souri> 1
Souripriya Das: 1 ←
15:39:51 <LeeF> AxelPolleres: Clear preference for Option 1 over Option 5
Axel Polleres: Clear preference for Option 1 over Option 5 [ Scribe Assist by Lee Feigenbaum ] ←
15:40:36 <AxelPolleres> PROPOSED: mark CREATE/DROP at risk
PROPOSED: mark CREATE/DROP at risk ←
15:41:16 <pgearon> +1
+1 ←
15:41:23 <AxelPolleres> not now...?
Axel Polleres: not now...? ←
15:41:52 <AxelPolleres> paul: already in the spec.
Paul Gearon: already in the spec. [ Scribe Assist by Axel Polleres ] ←
15:42:06 <LeeF> ACTION: Lee and AxelPolleres to solicit feedback from community regarding CREATE/DROP upon publication of next Update working draft�
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.
Trackbot IRC Bot: 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.
Trackbot IRC Bot: 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
+q ←
15:42:58 <LeeF> ack kasei
Lee Feigenbaum: ack kasei ←
15:42:58 <kasei> q-
Gregory Williams: q- ←
15:43:04 <SteveH> we're now talking about http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0539.html
Steve Harris: 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�
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.
Trackbot IRC Bot: 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.
Trackbot IRC Bot: 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?
Steve Harris: q? ←
15:43:39 <Souri> q+
Souripriya Das: q+ ←
15:43:48 <ivan> ack pgearon
Ivan Herman: ack pgearon ←
15:43:49 <SteveH> q+
Steve Harris: q+ ←
15:44:05 <LeeF> ack Souri
Lee Feigenbaum: ack Souri ←
15:44:39 <LeeF> is CLEAR <g1> identical to DELETE WHERE { GRAPH <g1> { ?s ?p ?o } } ?
Lee Feigenbaum: is CLEAR <g1> identical to DELETE WHERE { GRAPH <g1> { ?s ?p ?o } } ? ←
15:44:50 <SteveH> LeeF, yes
Steve Harris: LeeF, yes ←
15:45:03 <AxelPolleres> q?
Axel Polleres: q? ←
15:45:08 <LeeF> thanks. I don't care whether or not we keep CLEAR :)
Lee Feigenbaum: thanks. I don't care whether or not we keep CLEAR :) ←
15:45:46 <LeeF> q?
Lee Feigenbaum: q? ←
15:45:52 <LeeF> ack SteveH
Lee Feigenbaum: 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
Steve Harris: 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> ?
Souripriya Das: CLEAR graph <g1> graph <g2> ? ←
15:47:40 <pgearon> Souri: can CLEAR be applied to multiple graphs?
Souripriya Das: can CLEAR be applied to multiple graphs? ←
15:48:01 <LeeF> LeeF: Consensus in group to keep CLEAR syntax as is.
Lee Feigenbaum: Consensus in group to keep CLEAR syntax as is. [ Scribe Assist by Lee Feigenbaum ] ←
15:48:26 <pgearon> pgearon: was this like the recent email which referred to multiple graphs (in a LOAD command)
Paul Gearon: 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
Steve Harris: 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
Lee Feigenbaum: 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)
Axel Polleres: we will keep CLEAR (for the moment) ←
15:49:01 <AxelPolleres> http://lists.w3.org/Archives/Public/public-rdf-dawg/2010JanMar/0538.html
Axel Polleres: 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.
Andy Seaborne: 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.....
Sandro Hawke: Why no "DELETE FROM" as in SQL? Answer from Lee: because in SPARQL, "FROM" means stuff..... [ Scribe Assist by Sandro Hawke ] ←
15:49:18 <AndyS> This is not an opinion.
Andy Seaborne: 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
Steve Harris: 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
Andy Seaborne: 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
Lee Feigenbaum: 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
Steve Harris: would like compulsory separators, but violently opposed to making them optional ←
15:51:13 <pgearon> +q
+q ←
15:51:50 <SteveH> CLEAR DELETE DATA { <x> <y> <z> }
Steve Harris: CLEAR DELETE DATA { <x> <y> <z> } ←
15:52:55 <pgearon> -q
-q ←
15:53:05 <AndyS> Now have "CLEAR DEFAULT" , not just CLEAR
Andy Seaborne: Now have "CLEAR DEFAULT" , not just CLEAR ←
15:53:43 <AndyS> q+
Andy Seaborne: q+ ←
15:53:46 <AndyS> http://www.w3.org/2009/sparql/docs/sparql-grammar-11.html
Andy Seaborne: http://www.w3.org/2009/sparql/docs/sparql-grammar-11.html ←
15:54:52 <SteveH> CLEAR DEFAULT DELETE DATA { <x> <y> <z> } - but draft combined grammar
Steve Harris: CLEAR DEFAULT DELETE DATA { <x> <y> <z> } - but draft combined grammar ←
15:54:56 <SteveH> s/but/by/
Steve Harris: s/but/by/ ←
15:55:06 <AxelPolleres> DFT in the grammar should be 'DEFAULT'
Axel Polleres: DFT in the grammar should be 'DEFAULT' ←
15:56:14 <SteveH> CLEAR
Steve Harris: CLEAR ←
15:56:16 <SteveH> DEFAULT
Steve Harris: DEFAULT ←
15:56:21 <SteveH> ELETE DATA { <x> <y> <z> }
Steve Harris: ELETE DATA { <x> <y> <z> } ←
15:59:00 <pgearon> +q to ask SteveH why he's so opposed to an optional separator
+q to ask SteveH why he's so opposed to an optional separator ←
15:59:06 <AndyS> ack me
Andy Seaborne: ack me ←
15:59:14 <AndyS> this is a command line issue?
Andy Seaborne: this is a command line issue? ←
15:59:32 <pgearon> Ivan: doesn't see why CLEAR DEFAULT DELETE DATA ... is ambiguous
Ivan Herman: 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.
Andy Seaborne: Are we saying cmd line is exactly same as HTTP request body? May be different. ←
15:59:55 <AxelPolleres> OPTION 1: ";" Obligatory
Axel Polleres: OPTION 1: ";" Obligatory ←
15:59:55 <AxelPolleres> OPTION 2: no separators
Axel Polleres: OPTION 2: no separators ←
15:59:55 <AxelPolleres> OPTION 3: ";" optional (steve objects)
Axel Polleres: OPTION 3: ";" optional (steve objects) ←
16:00:28 <AndyS> OPT 3 does not work on command line BTW
Andy Seaborne: OPT 3 does not work on command line BTW ←
16:00:37 <Souri> option 1
Souripriya Das: option 1 ←
16:01:07 <AndyS> q+
Andy Seaborne: q+ ←
16:01:11 <LeeF> ack pgearon
Lee Feigenbaum: ack pgearon ←
16:01:11 <Zakim> pgearon, you wanted to ask SteveH why he's so opposed to an optional separator
Zakim IRC Bot: pgearon, you wanted to ask SteveH why he's so opposed to an optional separator ←
16:01:13 <LeeF> ack AndyS
Lee Feigenbaum: ack AndyS ←
16:02:17 <AndyS> separator has problems as well
Andy Seaborne: 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
Steve Harris: 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)
Andy Seaborne: 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)
Sandro Hawke: would like to see a separator and not a terminator (to avoid "separating" a null command) ←
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.
Sandro Hawke: lets do semicolon terminator like in SQL -- may be necessary as terminator on command line, but optional as terminator in API. [ Scribe Assist by Sandro Hawke ] ←
16:04:37 <kasei> option 1
Gregory Williams: option 1 ←
16:04:44 <LeeF> 0
Lee Feigenbaum: 0 ←
16:04:46 <SteveH> +1 / -1 / -Inf
Steve Harris: +1 / -1 / -Inf ←
16:04:53 <MattPerry> option 1
Matthew Perry: option 1 ←
16:04:57 <SteveH> option 1
Steve Harris: option 1 ←
16:04:57 <AlexPassant> 1
16:04:59 <bglimm> 1
Birte Glimm: 1 ←
16:04:59 <AndyS> opt 2
Andy Seaborne: opt 2 ←
16:05:04 <dcharbon2> option 2
David Charboneau: option 2 ←
16:05:04 <AxelPolleres> Option 1
Axel Polleres: Option 1 ←
16:05:05 <sandro> option 1
Sandro Hawke: option 1 ←
16:05:06 <Souri> option 1 (';' as terminator)
Souripriya Das: option 1 (';' as terminator) ←
16:05:12 <ivan> option 3 (sorry steve)
Ivan Herman: option 3 (sorry steve) ←
16:05:16 <AndyS> (can live with opt 1 as sep)
Andy Seaborne: (can live with opt 1 as sep) ←
16:05:18 <pgearon> Option 2
Option 2 ←
16:07:13 <LeeF> are we talking about a command line or about an interactive query shell type thing?
Lee Feigenbaum: are we talking about a command line or about an interactive query shell type thing? ←
16:08:34 <Souri> q+
Souripriya Das: q+ ←
16:08:38 <AndyS> Let us not spec cmd line usage
Andy Seaborne: Let us not spec cmd line usage ←
16:08:38 <AxelPolleres> Option 1: 7 Option 2: 3 Option 3: 1
Axel Polleres: Option 1: 7 Option 2: 3 Option 3: 1 ←
16:09:51 <Souri> in SQL-92, ';' is a terminator
Souripriya Das: in SQL-92, ';' is a terminator ←
16:10:41 <AxelPolleres> ";" as separator seems to be agreeable to everyone.
Axel Polleres: ";" as separator seems to be agreeable to everyone. ←
16:10:50 <AxelPolleres> terminator?
Axel Polleres: terminator? ←
16:11:00 <LeeF> ack Souri
Lee Feigenbaum: 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.)
PROPOSED: semicolons are a required separator. (we're not talking about whether they are allowed as terminators as well.) ←
16:11:22 <AndyS> q+
Andy Seaborne: q+ ←
16:11:47 <sandro> lee: why no ";" as terminator? because people want to be able to leave off a trailing ";".
Lee Feigenbaum: why no ";" as terminator? because people want to be able to leave off a trailing ";". [ Scribe Assist by Sandro Hawke ] ←
16:12:01 <LeeF> ack AndyS
Lee Feigenbaum: ack AndyS ←
16:14:20 <Souri> I prefer terminator, but may go with separator
Souripriya Das: I prefer terminator, but may go with separator ←
16:14:24 <AndyS> Need (';' | <EOF>) to terminate
Andy Seaborne: Need (';' | <EOF>) to terminate ←
16:14:35 <SteveH> +1 to AndyS
Steve Harris: +1 to AndyS ←
16:14:37 <Souri> +1
Souripriya Das: +1 ←
16:15:31 <AxelPolleres> why?
Axel Polleres: why? ←
16:15:32 <AxelPolleres> update := atomicupdate | update ';' atomicupdate
Axel Polleres: update := atomicupdate | update ';' atomicupdate ←
16:15:52 <AndyS> That fixes cmd line (which I don't care if diff systems do diff things anyway)
Andy Seaborne: That fixes cmd line (which I don't care if diff systems do diff things anyway) ←
16:16:04 <sandro> update := atomicupdate | update ';' atomicupdate |
Sandro Hawke: update := atomicupdate | update ';' atomicupdate | ←
16:17:01 <AndyS> "that" refers to (';' | <EOF>)
Andy Seaborne: "that" refers to (';' | <EOF>) ←
16:17:40 <kasei> why not sandro's?
Gregory Williams: why not sandro's? ←
16:17:54 <sandro> PROPOSED: semicolons are a required separator, and either ";" or <EOF> terminates
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
Steve Harris: 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)
PROPOSED: semicolons are a required separator, and either ";" or <EOF> terminates (and empty-string is an acceptable command) ←
16:18:59 <AxelPolleres> q?
Axel Polleres: q? ←
16:19:02 <sandro> +1
Sandro Hawke: +1 ←
16:19:05 <ivan> +1
Ivan Herman: +1 ←
16:19:07 <AxelPolleres> +1
Axel Polleres: +1 ←
16:19:09 <dcharbon2> +1
David Charboneau: +1 ←
16:19:10 <MattPerry> +1
Matthew Perry: +1 ←
16:19:11 <SteveH> +1
Steve Harris: +1 ←
16:19:12 <Souri> +1
Souripriya Das: +1 ←
16:19:13 <pgearon> +1
+1 ←
16:19:24 <AndyS> +0.5 (need to check it works!)
Andy Seaborne: +0.5 (need to check it works!) ←
16:19:37 <LeeF> 's fine with me
Lee Feigenbaum: '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)
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
Gregory Williams: +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
Lee Feigenbaum: 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
Axel Polleres: 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."
Axel Polleres: 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.
Andy Seaborne: 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.
Andy Seaborne: 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"
Steve Harris: 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 { ... }
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.
Steve Harris: How about WITH is for the INSERT/DELETE and FROM is for the WHERE. [ Scribe Assist by Sandro Hawke ] ←
16:28:54 <AxelPolleres> q+
Axel Polleres: q+ ←
16:29:18 <LeeF> SteveH: What about moving FROM to the top?
Steve Harris: What about moving FROM to the top? [ Scribe Assist by Lee Feigenbaum ] ←
16:29:27 <AndyS> Prefer FROM only applies to WHERE.
Andy Seaborne: Prefer FROM only applies to WHERE. ←
16:29:30 <LeeF> LeeF: Not a strong feeling; diverges from what Query does
Lee Feigenbaum: Not a strong feeling; diverges from what Query does [ Scribe Assist by Lee Feigenbaum ] ←
16:29:38 <pgearon> AxelPolleres: thinks there's an alternative to the base assumption
Axel Polleres: thinks there's an alternative to the base assumption ←
16:29:53 <pgearon> ... presumes this would only apply to the WHERE part
... 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)
Andy Seaborne: 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
Axel Polleres: 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
Lee Feigenbaum: 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.
Andy Seaborne: LeeF - good point. ←
17:11:14 <LeeF> AndyS, can you begin scribing following this break?
(No events recorded for 39 minutes)
Lee Feigenbaum: AndyS, can you begin scribing following this break? ←
17:39:52 <LeeF> Chair: LeeF
17:40:38 <AndyS1> For ericP: http://www.openjena.org/ARQ/service.html
(No events recorded for 29 minutes)
Andy Seaborne: For ericP: http://www.openjena.org/ARQ/service.html ←
17:41:05 <ericP> tx AndyS1
Eric Prud'hommeaux: tx AndyS1 ←
17:41:18 <LeeF> scribenick: AndyS
(Scribe set to Andy Seaborne)
17:41:32 <AndyS1> scribenick: AndyS1
17:41:37 <AndyS1> ... for some reason
... for some reason ←
17:41:48 <AndyS1> LeeF: update continues
Lee Feigenbaum: 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
Axel Polleres: 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
report from Boston lunch discussions ←
17:42:24 <AndyS1> pgearon: multiple load issue
Paul Gearon: multiple load issue ←
17:43:22 <AndyS1> keyword WITH - introducing FROM could be along side WITH - layered appraoch
keyword WITH - introducing FROM could be along side WITH - layered appraoch ←
17:43:36 <AndyS1> ... explicit GRAP => use named graph
... explicit GRAP => use named graph ←
17:43:50 <AndyS1> ... else FROM / FROM NAMED
... else FROM / FROM NAMED ←
17:43:55 <AndyS1> ... else WITH
... else WITH ←
17:44:01 <AndyS1> ... else default
... else default ←
17:44:09 <AndyS1> s/GRAP/GRAPH/
s/GRAP/GRAPH/ ←
17:44:23 <AndyS1> Lee, others: confusing
Lee, others: confusing ←
17:44:48 <AxelPolleres> q+
Axel Polleres: q+ ←
17:45:02 <LeeF> ack AxelPolleres
Lee Feigenbaum: ack AxelPolleres ←
17:45:17 <ivan> ack AxelPolleres
Ivan Herman: ack AxelPolleres ←
17:45:53 <AndyS1> AxelPolleres: alternative FROM only for WHERE not INSERT DELETE
Axel Polleres: alternative FROM only for WHERE not INSERT DELETE ←
17:46:13 <AndyS1> q+
q+ ←
17:46:33 <AndyS1> LeeF: confusing even though no lex order (Steve point)
Lee Feigenbaum: confusing even though no lex order (Steve point) ←
17:46:36 <LeeF> ack AndyS
Lee Feigenbaum: ack AndyS ←
17:47:11 <LeeF> q+ AndyS
Lee Feigenbaum: q+ AndyS ←
17:47:15 <LeeF> ack AndyS
Lee Feigenbaum: 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
Andy Seaborne: I find it slightly odd to use FROM to constrain the INSERT/DELETE template because of the case of multiple FROMs [ Scribe Assist by Lee Feigenbaum ] ←
17:48:17 <AndyS1> LeeF: compromise design
Lee Feigenbaum: compromise design ←
17:48:49 <AndyS1> So do we need to change scope for default graph in update part?
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.
Axel Polleres: 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?
Lee Feigenbaum: 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?
Andy Seaborne: 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? [ Scribe Assist by Lee Feigenbaum ] ←
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
Lee Feigenbaum: Think it's still a little weird because there are distinct default graph concepts, but I can live with it [ Scribe Assist by Lee Feigenbaum ] ←
17:52:33 <AndyS1> AndyS: error case of union FROM is confusing to me
Andy Seaborne: error case of union FROM is confusing to me ←
17:53:14 <AndyS1> AndyS: do see value of setting dft graph for WHERE part
Andy Seaborne: 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> { ... }
Paul Gearon: 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 { ... }
Paul Gearon: WITH <g1> INSERT { x y z } DELETE { a b c } WHERE { ... } ←
17:54:35 <AndyS1> Alt : either WITH or FROM not both
Alt : either WITH or FROM not both ←
17:54:57 <AndyS1> pgearon: common use pattern
Paul Gearon: common use pattern ←
17:55:10 <AndyS1> ... operations on a single graph
... operations on a single graph ←
17:55:13 <pgearon> INSERT { GRAPH <g1> { x y z } } DELETE { GRAPH <g1> { a b c } } WHERE FROM <g2> { ... }
Paul Gearon: 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 { ... }
Paul Gearon: 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
Lee Feigenbaum: 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
Axel Polleres: my understnding is that default-graph-uri= only overwrites FROM ←
17:57:09 <LeeF> what principle is that understanding based on, AxelPolleres?
Lee Feigenbaum: 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
Ivan Herman: the above example reads confusing to me because of the DELETE { ... } FROM part [ Scribe Assist by Lee Feigenbaum ] ←
17:57:54 <AxelPolleres> leeF, same as in query, isn't it?
Axel Polleres: leeF, same as in query, isn't it? ←
17:58:00 <LeeF> query doesn't have with
Lee Feigenbaum: 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
Lee Feigenbaum: 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
Lee Feigenbaum: or override WITH instead ←
17:58:20 <AndyS1> pgearon: value DRY
Paul Gearon: value DRY ←
17:58:30 <AndyS1> (Dont Repeat Yourself)
(Dont Repeat Yourself) ←
17:58:57 <AxelPolleres> LeeF, but protocol has default-graph-uri= which corressponds to FROM, which I suggest to just keep
Axel Polleres: 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.
Lee Feigenbaum: 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.
Axel Polleres: 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?
Axel Polleres: q? ←
18:01:33 <AxelPolleres> q+
Axel Polleres: q+ ←
18:01:41 <LeeF> ack AxelPolleres
Lee Feigenbaum: ack AxelPolleres ←
18:01:43 <AndyS1> ack AxelPolleres
ack AxelPolleres ←
18:01:48 <Souri> q+
Souripriya Das: q+ ←
18:02:03 <sandro> sandro: The confusion in DELETE { ... } FROM ... WHERE ... is pretty bad.
Sandro Hawke: The confusion in DELETE { ... } FROM ... WHERE ... is pretty bad. [ Scribe Assist by Sandro Hawke ] ←
18:02:33 <AndyS1> LeeF: if no spec - graph store = impl decision c.f. query
Lee Feigenbaum: if no spec - graph store = impl decision c.f. query ←
18:02:56 <LeeF> ack Souri
Lee Feigenbaum: ack Souri ←
18:03:02 <dcharbon2> could where come first? so, FROM... WHERE... DELETE { ... }
David Charboneau: could where come first? so, FROM... WHERE... DELETE { ... } ←
18:03:31 <SteveH> dcharbon2's suggesting is interesting
Steve Harris: dcharbon2's suggesting is interesting ←
18:03:35 <SteveH> *suggestion
Steve Harris: *suggestion ←
18:03:42 <AndyS1> Souri: WITH clause: common use case update is on a graph that is also the WHERE part
Souripriya Das: WITH clause: common use case update is on a graph that is also the WHERE part ←
18:03:54 <pgearon> FROM... WHERE ... INSERT .... DELETE ...
Paul Gearon: FROM... WHERE ... INSERT .... DELETE ... ←
18:04:22 <SteveH> DELETE ... INSERT ... probably
Steve Harris: DELETE ... INSERT ... probably ←
18:04:55 <dcharbon2> FROM... WHERE... WITH... INSERT... DELETE...
David Charboneau: FROM... WHERE... WITH... INSERT... DELETE... ←
18:05:05 <AndyS1> If we chnage order, FROM => USING maybe
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
Axel Polleres: 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
Souripriya Das: 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
Axel Polleres: ... 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
Lee Feigenbaum: 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+
q+ ←
18:06:08 <LeeF> ack AndyS1
Lee Feigenbaum: ack AndyS1 ←
18:06:12 <LeeF> ack AndyS
Lee Feigenbaum: ack AndyS ←
18:06:25 <AxelPolleres> q+
Axel Polleres: q+ ←
18:06:33 <AndyS1> ack me
ack me ←
18:06:48 <LeeF> ack AxelPolleres
Lee Feigenbaum: ack AxelPolleres ←
18:07:02 <LeeF> Souri: SQL has a returning clause for return results from a DML statement
Souripriya Das: SQL has a returning clause for return results from a DML statement [ Scribe Assist by Lee Feigenbaum ] ←
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
Paul Gearon: 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?
Lee Feigenbaum: 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 ?
Axel Polleres: 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
Ivan Herman: 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)
Paul Gearon: 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 ?
Lee Feigenbaum: what about souri's idea of WITH xor FROM ? ←
18:11:16 <AndyS1> ... WITH is shortcut for GRAPH everywhere
... WITH is shortcut for GRAPH everywhere ←
18:11:48 <AndyS1> SteveH: protocol interactions
Steve Harris: protocol interactions ←
18:11:59 <LeeF> q?
Lee Feigenbaum: q? ←
18:12:53 <AxelPolleres> interactions with protocol is e.g. if in the protocol someone uses e.g. default-graph-uri
Axel Polleres: interactions with protocol is e.g. if in the protocol someone uses e.g. default-graph-uri ←
18:13:22 <pgearon> q+
Paul Gearon: q+ ←
18:13:27 <LeeF> ack pgearon
Lee Feigenbaum: ack pgearon ←
18:13:31 <AndyS1> AndyS: suggest default-graph + FROM in update => error
Andy Seaborne: suggest default-graph + FROM in update => error ←
18:13:45 <AndyS1> ... unlike query
... unlike query ←
18:14:17 <AndyS1> ... overide can chnage a two different grah update now be a one graph update
... overide can chnage a two different grah update now be a one graph update ←
18:15:00 <SteveH> LeeF, we do
Steve Harris: LeeF, we do ←
18:15:06 <SteveH> for security, only access one graph
Steve Harris: for security, only access one graph ←
18:15:12 <AndyS1> same here
same here ←
18:15:17 <AndyS1> q+
q+ ←
18:15:25 <LeeF> INSERT T1 DELETE T2 FROM G1 { ... }
Lee Feigenbaum: INSERT T1 DELETE T2 FROM G1 { ... } ←
18:15:34 <LeeF> T1 and T2 act on the Graph Store's default graph
Lee Feigenbaum: 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
Lee Feigenbaum: and the query pattern queries G1 as its default graph ←
18:15:46 <SteveH> missing WHERE?
Steve Harris: missing WHERE? ←
18:16:09 <LeeF> INSERT T1 DELETE T2 FROM G1 WHERE { ... }
Lee Feigenbaum: INSERT T1 DELETE T2 FROM G1 WHERE { ... } ←
18:16:43 <AndyS1> LeeF: hearing consensus around the above
Lee Feigenbaum: 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.
Andy Seaborne: 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
Lee Feigenbaum: * 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
Lee Feigenbaum: * 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+
Souripriya Das: q+ ←
18:19:33 <LeeF> ack AndyS
Lee Feigenbaum: ack AndyS ←
18:19:35 <kasei> q+
Gregory Williams: q+ ←
18:19:55 <LeeF> ack Souri
Lee Feigenbaum: 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
David Charboneau: 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*
Axel Polleres: q+ to ask why interaction of WITH with FROM (NAMED) is a problem *at all* ←
18:21:26 <LeeF> ack kasei
Lee Feigenbaum: ack kasei ←
18:22:04 <AxelPolleres> WITH <g> FROM <g1> INSERT P1 WHERE P2 = FROM <g1> INSERT {GRAPH <g> P1} WHERE {GRAPH <g> P2}
Axel Polleres: 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
Gregory Williams: seems very strange to forbid default-graph-uri overriding FROM in the case of a single update operation [ Scribe Assist by Lee Feigenbaum ] ←
18:22:11 <AxelPolleres> ... so what?
Axel Polleres: ... so what? ←
18:22:17 <LeeF> ack dcharbon
Lee Feigenbaum: 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
Zakim IRC Bot: 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
David Charboneau: query-ish thing followed by updates ←
18:23:42 <dcharbon2> [query] update-clause
David Charboneau: [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]
David Charboneau: suggests-- [optional SPARQL result clause] [optional SPARQL dataset clause] SPARQL query pattern [optional SPARQL modifiers] [optional WITH] [optional DELETE template] [optional INSERT tempalte] [ Scribe Assist by Lee Feigenbaum ] ←
18:24:49 <AxelPolleres> ack AxelPolleres
Axel Polleres: ack AxelPolleres ←
18:24:49 <Zakim> AxelPolleres, you wanted to ask why interaction of WITH with FROM (NAMED) is a problem *at all*
Zakim IRC Bot: AxelPolleres, you wanted to ask why interaction of WITH with FROM (NAMED) is a problem *at all* ←
18:24:49 <LeeF> ack AxelPolleres
Lee Feigenbaum: ack AxelPolleres ←
18:24:58 <AndyS1> q+ to ask for clarification
q+ to ask for clarification ←
18:26:43 <LeeF> ack AndyS
Lee Feigenbaum: ack AndyS ←
18:26:43 <Zakim> AndyS, you wanted to ask for clarification
Zakim IRC Bot: AndyS, you wanted to ask for clarification ←
18:27:59 <Souri> q+
Souripriya Das: q+ ←
18:29:04 <LeeF> AndyS: We haven't really talked about solution modifiers with update
Andy Seaborne: We haven't really talked about solution modifiers with update [ Scribe Assist by Lee Feigenbaum ] ←
18:29:16 <LeeF> AndyS: does this let us return results based on the post-update state of the store?
Andy Seaborne: does this let us return results based on the post-update state of the store? [ Scribe Assist by Lee Feigenbaum ] ←
18:29:19 <LeeF> LeeF: No, not really
Lee Feigenbaum: No, not really [ Scribe Assist by Lee Feigenbaum ] ←
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?
Axel Polleres: 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-
Souripriya Das: 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
Ivan Herman: 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 [ Scribe Assist by Lee Feigenbaum ] ←
18:29:51 <dcharbon2> AxelPolleres: good point
Axel Polleres: good point [ Scribe Assist by David Charboneau ] ←
18:30:37 <dcharbon2> It's subversive... too subversive or abusive?
David Charboneau: It's subversive... too subversive or abusive? ←
18:30:44 <AxelPolleres> q+
Axel Polleres: q+ ←
18:30:50 <AndyS1> AndyS: issue with multiple SELECT in one request (mix CONSTRUCT and SELECT)
Andy Seaborne: issue with multiple SELECT in one request (mix CONSTRUCT and SELECT) ←
18:32:21 <LeeF> ack AxelPolleres
Lee Feigenbaum: ack AxelPolleres ←
18:32:43 <AndyS1> AxelPolleres: mixes query on dataset and query on graph store
Axel Polleres: mixes query on dataset and query on graph store ←
18:33:03 <AndyS> scribenick: AndyS
18:33:07 <kasei> q+
Gregory Williams: q+ ←
18:33:13 <LeeF> ack kasei
Lee Feigenbaum: ack kasei ←
18:33:16 <AndyS> ivan: assumed treated uniformly
Ivan Herman: assumed treated uniformly ←
18:33:51 <AndyS> kasei: why query on graph store? why not endpoint makes dataset as query
Gregory Williams: 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 ?
Axel Polleres: 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.
Axel Polleres: 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
Lee Feigenbaum: 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
... 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.
Axel Polleres: I think, if we leave querying out of update, we spare the problem of unifying the dataset and graphstore. ←
18:38:08 <AxelPolleres> �
Axel Polleres: � ←
18:39:14 <AndyS> Feeling is stick to current update with success/failure only (time concerns)
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
PROPOSED: SPARQL Update requests return either success or failure only ←
18:39:46 <ivan> +1
Ivan Herman: +1 ←
18:39:54 <bglimm> +1
Birte Glimm: +1 ←
18:39:58 <LeeF> RESOLVED: SPARQL Update requests return either success or failure only, no abstentions or objections
RESOLVED: SPARQL Update requests return either success or failure only, no abstentions or objections ←
18:39:58 <sandro> +1 (given time constraints)
Sandro Hawke: +1 (given time constraints) ←
18:40:00 <AlexPassant> q+
Alexandre Passant: q+ ←
18:40:05 <Souri> +1
Souripriya Das: +1 ←
18:40:06 <LeeF> ack AlexPassant
Lee Feigenbaum: 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)
Axel Polleres: 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
Lee Feigenbaum: 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
Zakim IRC Bot: 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.
Sandro Hawke: 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)
Zakim IRC Bot: ... implementation) ←
18:43:21 <AlexPassant> ARC2 does that as well re. number of added triples
Alexandre Passant: ARC2 does that as well re. number of added triples ←
18:43:39 <AxelPolleres> right, Alex, that's where I saw it
Axel Polleres: 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
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
Ivan Herman: 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=
Lee Feigenbaum: want subgroup to meet and make concrete proposal for WITH/FROM/default-graph-uri= ←
18:44:42 <AndyS> ... inc pgearon, LeeF
... inc pgearon, LeeF ←
18:44:59 <AndyS> ... SteveH, 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)
Axel Polleres: I'm using ARC2 in lots of apps but never used that feature (success / failure is generally enough) [ Scribe Assist by Alexandre Passant ] ←
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?
Axel Polleres: 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)
(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
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].
Trackbot IRC Bot: 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
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
Trackbot IRC Bot: 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
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].
Trackbot IRC Bot: 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
Gregory Williams: i can scribe ←
18:47:36 <AndyS> LeeF: more update via protocol
Lee Feigenbaum: more update via protocol ←
18:47:39 <kasei> scribenick: kasei
(Scribe set to Gregory Williams)
18:48:20 <kasei> LeeF: anybody run into issues with protocol?
Lee Feigenbaum: anybody run into issues with protocol? ←
18:48:28 <kasei> ivan: how does it handle semicolons?
Ivan Herman: how does it handle semicolons? ←
18:48:42 <kasei> LeeF: just part of the http request body
Lee Feigenbaum: just part of the http request body ←
18:48:53 <AxelPolleres> q+
Axel Polleres: q+ ←
18:48:59 <LeeF> ack AxelPolleres
Lee Feigenbaum: ack AxelPolleres ←
18:49:23 <kasei> AxelPolleres: with implicit dropping, wouldn't see a response indicating that the drop happened.
Axel Polleres: with implicit dropping, wouldn't see a response indicating that the drop happened. ←
18:49:30 <kasei> dcharbon2: correct
David Charboneau: correct ←
18:49:59 <kasei> LeeF: we'll still have to define what happens if several operations succeed and some others fail
Lee Feigenbaum: 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
Paul Gearon: since only returning sucess/failure, probably just fail ←
18:50:46 <kasei> LeeF: gets into concurrency/atomicity issues
Lee Feigenbaum: gets into concurrency/atomicity issues ←
18:51:02 <LeeF> this is http://www.w3.org/2009/sparql/track/issues/26
Lee Feigenbaum: 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.
Paul Gearon: 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.
... 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
Andy Seaborne: +1 to SHOULD be atomic ←
18:51:41 <LeeF> +1 as well
Lee Feigenbaum: +1 as well ←
18:51:58 <kasei> dcharbon2: if we want transactional, statements should be ordered based on syntax.
David Charboneau: if we want transactional, statements should be ordered based on syntax. ←
18:52:08 <kasei> pgearon: yes. will need to guarantee execution order.
Paul Gearon: yes. will need to guarantee execution order. ←
18:52:18 <kasei> sandro: don't want to rule out eventually consistent systems.
Sandro Hawke: don't want to rule out eventually consistent systems. ←
18:52:28 <kasei> ... SHOULD may not be the right wording.
... SHOULD may not be the right wording. ←
18:52:43 <kasei> pgearon: was expecting an indication in the service description indicating this.
Paul Gearon: 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.
Sandro Hawke: 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.
... not sure being distributed is a good reason. ←
18:53:29 <AndyS> q+
Andy Seaborne: q+ ←
18:53:36 <LeeF> ack AndyS
Lee Feigenbaum: ack AndyS ←
18:53:58 <sandro> sandro: but, yeah, I guess being distributed is a good reason.
Sandro Hawke: but, yeah, I guess being distributed is a good reason. [ Scribe Assist by Sandro Hawke ] ←
18:54:06 <kasei> AndyS: would like to say SHOULD. two cases. 1: person doing update sees consistent state of the world.
Andy Seaborne: 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.
... 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.
Paul Gearon: 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.
Sandro Hawke: 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.
Andy Seaborne: 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.
Sandro Hawke: implementors might interpret that as shouldn't be doing distributed systems. ←
18:56:20 <kasei> LeeF: hearing concensus. can we close ISSUE-26?
Lee Feigenbaum: 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.
Sandro Hawke: I think we should include some text saying: FOR EXAMPLE, eventually-consistent stores are fine. [ Scribe Assist by Sandro Hawke ] ←
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
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/
Ivan Herman: s/SHOUDL/SHOULD/ ←
18:58:11 <AxelPolleres> +1
Axel Polleres: +1 ←
18:58:15 <ivan> +1
Ivan Herman: +1 ←
18:58:17 <pgearon> +1
Paul Gearon: +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
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
Andy Seaborne: +1 ←
18:58:21 <dcharbon2> +
18:58:23 <dcharbon2> +1
David Charboneau: +1 ←
18:58:28 <Mattperry> +1
Matthew Perry: +1 ←
18:58:31 <sandro> +1
Sandro Hawke: +1 ←
18:58:32 <Souri> +1
Souripriya Das: +1 ←
18:58:38 <bglimm> +1
Birte Glimm: +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
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+
Ivan Herman: q+ ←
18:59:00 <kasei> LeeF: ISSUE-19
18:59:04 <LeeF> ack ivan
Lee Feigenbaum: ack ivan ←
18:59:08 <sandro> issue-19?
18:59:08 <trackbot> ISSUE-19 -- Security issues on SPARQL/UPdate -- OPEN
Trackbot IRC Bot: ISSUE-19 -- Security issues on SPARQL/UPdate -- OPEN ←
18:59:08 <trackbot> http://www.w3.org/2009/sparql/track/issues/19
Trackbot IRC Bot: http://www.w3.org/2009/sparql/track/issues/19 ←
18:59:20 <kasei> ivan: what do we do about HTTP PATCH?
Ivan Herman: what do we do about HTTP PATCH? ←
18:59:33 <kasei> LeeF: need chimezie to be involved in that discussion.
Lee Feigenbaum: need chimezie to be involved in that discussion. ←
18:59:52 <kasei> ivan: spec says must use HTTP POST. might we allow PATCH?
Ivan Herman: 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?
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 .
Trackbot IRC Bot: 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
Ivan Herman: -> http://tinyurl.com/yfjdc3s ←
19:01:15 <sandro> issue-56 : http://tools.ietf.org/html/rfc5789
Sandro Hawke: 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
Trackbot IRC Bot: 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.
Lee Feigenbaum: 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
Ivan Herman: -> http://tools.ietf.org/html/rfc5789 PATCH RFC on Patch ←
19:01:55 <kasei> ... Next: Security in SPARQL Update.
... Next: Security in SPARQL Update. ←
19:02:36 <kasei> SteveH: my concerns is around making the endpoint perform HTTP requests.
Steve Harris: my concerns is around making the endpoint perform HTTP requests. ←
19:02:45 <kasei> LeeF: did we address that in SPARQL 1.0 Query?
Lee Feigenbaum: 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.
Steve Harris: 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
Andy Seaborne: 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.
... we require explicitly saying you want that feature at endpoint startup. ←
19:03:27 <LeeF> ack AndyS
Lee Feigenbaum: ack AndyS ←
19:03:27 <Zakim> AndyS, you wanted to say that covered by any processor can reject a request in query
Zakim IRC Bot: AndyS, you wanted to say that covered by any processor can reject a request in query ←
19:03:28 <AndyS> ack me
Andy Seaborne: ack me ←
19:03:59 <kasei> AndyS: you can just refuse the query if you don't want to make the request.
Andy Seaborne: 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.
... 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.
... 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?
Lee Feigenbaum: 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.
Ivan Herman: 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.
Lee Feigenbaum: 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.
... let's list some of the things we know are important. ←
19:06:06 <LeeF> * loading external data (LOAD <uri>)
Lee Feigenbaum: * loading external data (LOAD <uri>) ←
19:06:24 <LeeF> ** (related: overflowing your internal store with loaded data)
Lee Feigenbaum: ** (related: overflowing your internal store with loaded data) ←
19:06:44 <AxelPolleres> * similar: interpreting FROM/FROM NAMED as HTTP request
Axel Polleres: * similar: interpreting FROM/FROM NAMED as HTTP request ←
19:07:00 <LeeF> * access control
Lee Feigenbaum: * access control ←
19:07:02 <AxelPolleres> ... just as in Query
Axel Polleres: ... just as in Query ←
19:07:02 <SteveH> and multiple LOADs gives an escalation attack
Steve Harris: and multiple LOADs gives an escalation attack ←
19:07:53 <LeeF> * chain authorization to foreign servers?
Lee Feigenbaum: * chain authorization to foreign servers? ←
19:08:14 <SteveH> LOAD is a flexible pivot
Steve Harris: LOAD is a flexible pivot ←
19:08:52 <LeeF> * extension functions (applies to both query and update)
Lee Feigenbaum: * 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.
Lee Feigenbaum: 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
Trackbot IRC Bot: ISSUE-19 Security issues on SPARQL/UPdate notes added ←
19:10:30 <kasei> LeeF: Concurrency (ISSUE-18)
Lee Feigenbaum: Concurrency (ISSUE-18) ←
19:10:46 <AxelPolleres> Appendix A in update doc should be updateded with that list!
Axel Polleres: Appendix A in update doc should be updateded with that list! ←
19:11:12 <SteveH> http://www.w3.org/2009/sparql/track/issues/18
Steve Harris: http://www.w3.org/2009/sparql/track/issues/18 ←
19:11:19 <kasei> ... any proposals for locking or other concurrency facilities?
... any proposals for locking or other concurrency facilities? ←
19:11:42 <kasei> pgearon: I lumped it together with atomicity issues.
Paul Gearon: I lumped it together with atomicity issues. ←
19:12:00 <kasei> LeeF: covered by previous atomicity discussion.
Lee Feigenbaum: 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)
... 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.
David Charboneau: 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
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
Ivan Herman: +1 ←
19:13:25 <bglimm> +1
Birte Glimm: +1 ←
19:13:30 <AxelPolleres> +1
Axel Polleres: +1 ←
19:13:32 <AndyS> +1
Andy Seaborne: +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
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
Paul Gearon: +1 ←
19:14:46 <LeeF> kasei: Consider in protocol making use of HTTP 204 Accepted For Processing ?
Gregory Williams: Consider in protocol making use of HTTP 204 Accepted For Processing ? [ Scribe Assist by Lee Feigenbaum ] ←
19:15:15 <kasei> s/204/202/
s/204/202/ ←
19:15:41 <kasei> pgearon: what happens if you load half a document and run into an error?
Paul Gearon: 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')
Sandro Hawke: 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.
Lee Feigenbaum: now passed the agenda items scheduled through 10:00 this morning. ←
19:17:28 <kasei> LeeF: Moving on to test suite.
Lee Feigenbaum: Moving on to test suite. ←
19:17:37 <kasei> ... sent overview on how tests were done in DAWG.
... 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.
... 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.
... each tests gave info on seting up, running, and evaluating results of the test. ←
19:18:19 <kasei> ... syntax tests were just the query.
... 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.
... 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.
... 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.
... 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.
... 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.
... 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.
Eric Prud'hommeaux: 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.
Lee Feigenbaum: 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.
... 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.
... 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.
... ericP had suggested the use of TriG for serializing quads. ←
19:22:55 <kasei> ... then need to start collecting tests.
... then need to start collecting tests. ←
19:23:03 <ericP> http://swobjects.svn.sourceforge.net/viewvc/swobjects/trunk/tests/sparul/
Eric Prud'hommeaux: http://swobjects.svn.sourceforge.net/viewvc/swobjects/trunk/tests/sparul/ ←
19:23:11 <SteveH> q+
Steve Harris: q+ ←
19:23:18 <ericP> http://swobjects.svn.sourceforge.net/viewvc/swobjects/trunk/tests/sparul/ -> SWObjects SPARUL tests
Eric Prud'hommeaux: http://swobjects.svn.sourceforge.net/viewvc/swobjects/trunk/tests/sparul/ -> SWObjects SPARUL tests ←
19:23:20 <LeeF> ack SteveH
Lee Feigenbaum: ack SteveH ←
19:23:31 <kasei> SteveH: support for using TriG.
Steve Harris: support for using TriG. ←
19:23:50 <kasei> bglimm: don't know how to parse that.
Birte Glimm: don't know how to parse that. ←
19:24:04 <kasei> ... if existing tools can't parse it...
... if existing tools can't parse it... ←
19:25:02 <kasei> ... using OWL API. can parse turtle.
... 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
Andy Seaborne: 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
Steve Harris: could develop framework to turn TriG into HTTP updates ←
19:26:05 <AndyS> q+
Andy Seaborne: 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
Lee Feigenbaum: 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?
SteveH, did I get that right? ←
19:26:29 <SteveH> kasei, not just Trig, the whole thing
Steve Harris: kasei, not just Trig, the whole thing ←
19:26:36 <kasei> bglimm: not able to run dawg tests right now.
Birte Glimm: not able to run dawg tests right now. ←
19:26:56 <kasei> SteveH, could you scribe what you said?
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
Steve Harris: maybe we could colaboratively develop a test harness, which reads the manifests, and judges pass/fail [ Scribe Assist by Steve Harris ] ←
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.
Eric Prud'hommeaux: 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.
Ivan Herman: 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.
Lee Feigenbaum: 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.
... 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.
Eric Prud'hommeaux: 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+
Steve Harris: q+ ←
19:29:44 <LeeF> ack AndyS
Lee Feigenbaum: ack AndyS ←
19:29:45 <AxelPolleres> TriG would be used for dataset and before/after graphstore, yes? anything else?
Axel Polleres: 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?
Sandro Hawke: TriG only brings together the data, though? not the results or other pieces? ←
19:29:59 <kasei> LeeF: correct.
Lee Feigenbaum: correct. ←
19:30:08 <kasei> AndyS: don't see that TriG adds much.
Andy Seaborne: don't see that TriG adds much. ←
19:30:19 <kasei> ... not all toolkits will have support.
... not all toolkits will have support. ←
19:30:19 <AxelPolleres> q+
Axel Polleres: q+ ←
19:31:06 <kasei> ivan: RDFa test suite, you submitted the URLs for different convertors. tool could run whole test suite.
Ivan Herman: 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.
... 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/
Axel Polleres: 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.
... 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.
... worked well, but requirements are much simpler than for SPARQL's case. ←
19:32:17 <kasei> ... setup was very simple.
... 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)
Axel Polleres: but he said to me that it is kinda alpha at the moment (stable mid-end 2010) ←
19:32:24 <LeeF> q?
Lee Feigenbaum: 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.
Ivan Herman: 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
Lee Feigenbaum: ack SteveH ←
19:33:27 <pgearon> +1 on reusing current framework
Paul Gearon: +1 on reusing current framework ←
19:33:52 <kasei> SteveH: agree with ericP that going to TriG is easier.
Steve Harris: agree with ericP that going to TriG is easier. ←
19:33:59 <kasei> ... current manifest is really complicated.
... current manifest is really complicated. ←
19:34:02 <AxelPolleres> q?
Axel Polleres: q? ←
19:34:27 <kasei> AndyS: hearing proposal to flatten manifest files.
Andy Seaborne: 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.
Lee Feigenbaum: 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.
Ivan Herman: 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
Eric Prud'hommeaux: -> http://swobjects.svn.sourceforge.net/viewvc/swobjects/trunk/tests/test_SPARUL.cpp?view=markup SPARUL tests ←
19:36:00 <LeeF> ack AxelPolleres
Lee Feigenbaum: ack AxelPolleres ←
19:36:15 <kasei> ivan: how many implementors are going to be upset at having to make big changes to testing infrastructure?
Ivan Herman: 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.
Axel Polleres: trig sounds like good idea for results of update. ←
19:37:20 <kasei> ... do we need something in protocol to dump the graphstore?
... 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.
Ivan Herman: 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.
Paul Gearon: 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.
... different datastructure for supporting update. will be a major change to test suite to work with that. ←
19:40:25 <LeeF> ack LeeF
Lee Feigenbaum: 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
Zakim IRC Bot: 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.
Lee Feigenbaum: 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.
... until we do that we can't start collecting test cases. ←
19:41:57 <kasei> ... need volunteers.
... need volunteers. ←
19:42:05 <kasei> *crickets*
*crickets* ←
19:42:44 <kasei> ... otherwise will move to CR without any way to tell if features are properly implemented.
... 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.
... 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.
Axel Polleres: 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.
Lee Feigenbaum: 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.
... in ideal world we'd have test editors. ←
19:44:16 <AxelPolleres> I can do a first shot
Axel Polleres: 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
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
Trackbot IRC Bot: 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
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].
Trackbot IRC Bot: 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.
Paul Gearon: 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.
Lee Feigenbaum: 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.
... HTTP Update Protocol testing probably has to be similar to protocol+update testing. ←
19:48:03 <kasei> ... entailment similar to query testing.
... entailment similar to query testing. ←
19:48:17 <kasei> ivan: if we wanted to be formal, entailment would involve the OWL tests.
Ivan Herman: if we wanted to be formal, entailment would involve the OWL tests. ←
19:48:50 <LeeF> q?
Lee Feigenbaum: q? ←
19:48:56 <kasei> bglimm: could manually translate OWL tests into SPARQL queries.
Birte Glimm: could manually translate OWL tests into SPARQL queries. ←
19:49:23 <kasei> ivan: not testing inference engines. SPARQL should consider them correct.
Ivan Herman: not testing inference engines. SPARQL should consider them correct. ←
19:49:34 <kasei> ... have to test relation of those inference engines to SPARQL.
... have to test relation of those inference engines to SPARQL. ←
19:49:46 <kasei> bglimm: you wouldn't get that with the OWL tests.
Birte Glimm: you wouldn't get that with the OWL tests. ←
19:50:03 <kasei> ivan: right. that's not our job.
Ivan Herman: right. that's not our job. ←
19:50:20 <kasei> ... test mechanism should be simple to show that the inference does happen.
... 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.
Birte Glimm: can use same format as query tests. maybe more results. ←
19:51:37 <kasei> AxelPolleres: how are non-deterministic queries treated?
Axel Polleres: 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.
Lee Feigenbaum: 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.
... 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.
Axel Polleres: if results aren't completely ordered, not sure what we do. ←
19:53:10 <kasei> ... small enough test cases could list all possible results.
... small enough test cases could list all possible results. ←
19:54:35 <kasei> LeeF: tomorrow's plan: query issues, not exists vs. minus
Lee Feigenbaum: tomorrow's plan: query issues, not exists vs. minus ←
19:54:41 <kasei> ... propose we go with not exists
... propose we go with not exists ←
19:54:56 <kasei> ... property path issues
... property path issues ←
19:55:02 <kasei> ... entailment issues
... entailment issues ←
19:55:07 <kasei> ... SD issues and testing
... SD issues and testing ←
20:06:50 <LeeF> Adjourned.
(No events recorded for 11 minutes)
Lee Feigenbaum: Adjourned. ←
Formatted by CommonScribe
This revision (#5) generated 2010-03-29 21:04:48 UTC by 'apollere2', comments: 'Applied changes suggested by Souri'