SPARQL Working Group Teleconference

Minutes of 25 March 2010

Agenda
http://www.w3.org/2009/sparql/wiki/F2F3_Agenda
Present
Birte Glimm, Axel Polleres, Andy Seaborne, Steve Harris, Paul Gearon, Lee Feigenbaum, David Charboneau, Alexandre Passant, Souripriya Das, Matthew Perry, Sandro Hawke, Gregory Williams, Ivan Herman, Eric Prud'hommeaux
Guests
Alexandre Bertails (W3C)
Chair
Lee Feigenbaum
Scribe
Birte Glimm, Paul Gearon, Andy Seaborne, Gregory Williams
IRC Log
Original and Editable Wiki Version
Resolutions
  1. The working group will intends to take the time-permitting feature "Entailment" through to Rec link
  2. The working group will intends to take the time-permitting feature "PropertyPaths" through to Rec link
  3. 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 link
  4. semicolons are a required separator for update operations, and either ";" or <EOF> terminates (and empty-string is an acceptable command) link
  5. SPARQL Update requests return either success or failure only, no abstentions or objections link
  6. 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 link
  7. 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 link
Topics
<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

1. 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

2. 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

David Charboneau: 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

Gregory Williams: 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

2.1. 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

2.2. 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

Alexandre Passant: 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

2.3. 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> +

David Charboneau: +

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

Lee Feigenbaum: ISSUE-19

18:59:04 <LeeF> ack ivan

Lee Feigenbaum: ack ivan

18:59:08 <sandro> issue-19?

Sandro Hawke: 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

3. 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'