Chatlog 2009-11-03

See original RRSAgent log and preview nicely formatted version.

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

# workaround for David not being noticed properly by software
<sandro> guest: David Charboneau
16:25:58 <RRSAgent> RRSAgent has joined #sparql
16:25:58 <RRSAgent> logging to http://www.w3.org/2009/11/03-sparql-irc
16:26:00 <trackbot> RRSAgent, make logs world
16:26:00 <Zakim> Zakim has joined #sparql
16:26:02 <trackbot> Zakim, this will be 77277
16:26:02 <Zakim> ok, trackbot; I see SW_SPARQL(TPAC)11:30AM scheduled to start in 4 minutes
16:26:03 <trackbot> Meeting: SPARQL Working Group Teleconference
16:26:03 <trackbot> Date: 03 November 2009
16:26:20 <AxelPolleres> zakim, dial suite_a
16:26:20 <Zakim> ok, AxelPolleres; the call is being made
16:26:21 <Zakim> SW_SPARQL(TPAC)11:30AM has now started
16:26:22 <Zakim> +Suite_a
16:26:36 <AndyS> zakim, what is the conference code?
16:26:36 <Zakim> the conference code is 77277 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), AndyS
16:26:45 <AxelPolleres> zakim, who is on the phone?
16:26:45 <Zakim> On the phone I see Suite_a
16:26:58 <AxelPolleres> zakim, suite_a has kasei, AxelPolleres
16:26:58 <Zakim> +kasei, AxelPolleres; got it
16:27:16 <Zakim> +??P2
16:27:23 <AndyS> zakim, ??P2 is me
16:27:23 <Zakim> +AndyS; got it
16:27:34 <Zakim> +??P3
16:27:41 <bglimm> comming
16:27:43 <LukeWM> LukeWM is ??P3
16:27:55 <Zakim> +bglimm
16:28:02 <LukeWM> zakim,  ??P3 is LukeWM
16:28:02 <Zakim> +LukeWM; got it
16:28:12 <bglimm> Zakim, mute me
16:28:12 <Zakim> bglimm should now be muted
16:28:17 <LukeWM> thanks for getting the phone fixed AxelPolleres 
16:28:32 <bglimm> hi
16:28:43 <LukeWM> hi
16:28:51 <AxelPolleres> paul, are you planning to dial in?
16:29:27 <Zakim> +yolanda
16:29:35 <LeeF> LeeF has joined #sparql
16:30:25 <AndyS> http://www.w3.org/2009/sparql/wiki/F2F2
16:30:39 <AndyS> zakim, mute me
16:30:39 <Zakim> AndyS should now be muted
16:30:54 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/F2F2_Issue_Discussions
16:31:15 <AxelPolleres> scribe: AxelPolleres
16:31:23 <AndyS> Which are the non-contraversail issues that are sort-of closed?
16:31:41 <LeeF> scribenick: LeeF
16:32:09 <LeeF> rrsagent, pointer?
16:32:09 <RRSAgent> See http://www.w3.org/2009/11/03-sparql-irc#T16-32-09
16:32:11 <AndyS> OK.  Will look 
16:32:14 <AxelPolleres> http://www.w3.org/2009/sparql/wiki/Agenda-F2F2#Day_2:_Morning:_Update_and_Remaining_Query_Issues
16:32:14 <Zakim> + +1.919.543.aaaa
16:32:18 <LeeF> zakim, who's here?
16:32:18 <Zakim> On the phone I see Suite_a, AndyS (muted), LukeWM, bglimm (muted), yolanda, +1.919.543.aaaa
16:32:21 <Zakim> Suite_a has kasei, AxelPolleres
16:32:22 <Zakim> On IRC I see LeeF, Zakim, RRSAgent, AxelPolleres, dcharbon2, Prateek, bglimm, LukeWM, AndyS, ivan, pgearon, karl, KjetilK, kasei, iv_an_ru, sandro, kjetil, ericP, trackbot
16:32:33 <AndyS> Hi David!
16:32:38 <LeeF> zakim, aaaa is DavidCharboneau
16:32:38 <Zakim> +DavidCharboneau; got it
16:32:54 <LeeF> dcharbon2: we've been making use of sparql in jazz foundation
16:33:09 <LeeF> ... i've implemented a sparql parser on top of an in house triple store known as ???
16:33:19 <LeeF> ... been working on our query service which is now built on top of Jena TDB
16:33:27 <LeeF> zakim, DavidCharboneau is dcharbon2
16:33:27 <Zakim> +dcharbon2; got it
16:33:49 <AndyS> The minutes aren't there yet?
16:34:04 <LeeF> AndyS, right - just the IRC logs for the moment
16:34:28 <LeeF> zakim, yolanda is Prateek
16:34:28 <Zakim> +Prateek; got it
16:34:53 <LeeF> topic: Update Issues
16:35:01 <LeeF> -> http://www.w3.org/2009/sparql/wiki/UpdateIssues collcetion of update issues
16:35:27 <LeeF> AxelPolleres: first issue is whether to include MODIFY
16:35:43 <LeeF> http://www.w3.org/2009/sparql/track/issues/47
16:36:22 <AndyS> zakim, unmute me
16:36:22 <Zakim> AndyS should no longer be muted
16:36:44 <LeeF> LukeWM: the issue is around the MODIFY keyword is that it's just syntactic sugar
16:36:55 <LeeF> ... it's like putting 2 GRAPH keywords - one for DELETE and one for INSERT
16:37:01 <AndyS> q+
16:37:06 <LeeF> ... not sure there's any strong feelings either way
16:37:25 <LeeF> ... Kjetil and Paul had a debate on what MODIFY actually means - about whether it implies that you're actually changing a triple instead od deleting and inserting
16:37:46 <kjetil_> kjetil_ has joined #sparql
16:37:56 <LeeF> AxelPolleres: is this about having a single atomic operation ?
16:38:08 <AndyS> Request is suggested to be atomic
16:38:09 <LeeF> SteveH: I thought the request was atomic
16:38:21 <kjetil_> Zakim, what is the code?
16:38:21 <Zakim> the conference code is 77277 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), kjetil_
16:38:26 <LukeWM> that was my understanding too
16:38:28 <LeeF> LeeF: ...and the whole HTTP request can have multiple operations
16:38:32 <LukeWM> q?
16:38:49 <LeeF> ack AndyS
16:39:08 <LeeF> AndyS: it is syntactic sugar, but you want to be able to describe triples to remove and inesrt based on the same pattern
16:39:22 <LeeF> ... doing it in 2 steps isn't good because you want to execute the pattern and then do the deletes & inserts
16:39:29 <LeeF> ... that doesn't work with 2 operations
16:39:32 <LeeF> ... also bnodes
16:39:43 <bglimm> q+
16:39:47 <bglimm> Zakim, unmute me
16:39:47 <Zakim> bglimm should no longer be muted
16:39:48 <Zakim> +??P8
16:39:59 <kjetil_> Zakim, ??P8 is me
16:39:59 <Zakim> +kjetil_; got it
16:40:06 <AndyS> s/it is syntactic sugar/it is not syntactic sugar/
16:40:07 <LeeF> ack bglimm
16:40:12 <kjetil_> Zakim, mute me
16:40:12 <Zakim> kjetil_ should now be muted
16:40:50 <LeeF> bglimm: <question about atomicity>
16:41:04 <bglimm> ZAkim, mute me
16:41:04 <Zakim> bglimm should now be muted
16:41:05 <AxelPolleres> q+
16:41:11 <AxelPolleres> q-
16:41:13 <LeeF> AxelPolleres: the understanding from discussions with pgearon is that one HTTP request can have multiple operations which are all atomic
16:41:40 <kjetil_> Zakim, unmute me
16:41:40 <Zakim> kjetil_ should no longer be muted
16:41:56 <AndyS> zakim, mute me please
16:41:56 <Zakim> AndyS should now be muted
16:42:48 <AndyS> The whole blank node & update thing needs sorting out.
16:42:50 <LeeF> kjetil: my main concern has been that things shouldn't be too verbose to write
16:43:39 <LeeF> yesterday we punted some /Query bnode issues over to the editors (*cough*) so I'd be inclined to do the same (for now) for update
16:43:46 <LukeWM> yes
16:43:47 <AndyS> +1 to kjetil's desire for useability
16:44:04 <LukeWM> http://www.w3.org/2009/sparql/docs/update-1.1/gen.html
16:44:10 <LeeF> http://www.w3.org/TR/sparql11-update/ 
16:44:51 <LukeWM> q+
16:44:54 <LeeF> ack LukeWM
16:45:01 <LeeF> LeeF: sounds like consensus for keeping MODIFY
16:45:13 <LeeF> LukeWM: think we should keep it
16:45:46 <kjetil_> q+
16:46:09 <LeeF> PROPOSED: To close ISSUE-47 by noting consensus on keeping MODIFY in the Update language 
16:46:11 <kjetil_> ack me
16:46:28 <AxelPolleres> +1 
16:46:30 <kjetil_> +1
16:46:35 <AndyS> zakim, unmute me
16:46:35 <Zakim> AndyS should no longer be muted
16:46:38 <bglimm> +1
16:47:16 <dcharbon2> +1
16:48:30 <LeeF> AndyS: Hesitant to close issues without an editor present
16:48:48 <LeeF> PROPOSED: To close ISSUE-47 by noting consensus on keeping MODIFY in the Update language, modulo any concerns expressed by Update editors
16:49:08 <AxelPolleres> +1
16:49:13 <AndyS> Good to record the consensus.
16:49:29 <LeeF> RESOLVED: To close ISSUE-47 by noting consensus on keeping MODIFY in the Update language, modulo any concerns expressed by Update editors, no objetions or abstentions
16:49:52 <LukeWM> not sure what that was about
16:50:20 <LeeF> AxelPolleres: next thing is INSERT vs. INSERT DATA
16:50:29 <AndyS> Maybe INSERT DATA is a bad name - too close to INSERT.  ADD ?
16:50:30 <LeeF> LeeF: i thought it was more of a misunderstanding then an issue
16:51:20 <LukeWM> q+
16:51:37 <LeeF> AxelPolleres: next are issues 18 and 19
16:51:45 <LukeWM> ack me
16:52:11 <LeeF> LukeWM: i think the security issues relates to subselects and the way requests are defined
16:52:49 <LeeF> LukeWM: if you are able to do selects or subselects in an update query, is anyone can implement separate endpoints (one for select and one for update) ?
16:52:52 <kjetil_> Zakim, mute me
16:52:52 <Zakim> kjetil_ should now be muted
16:52:55 <LeeF> SteveH: I don't think that's an issue
16:53:30 <LeeF> LukeWM: the idea of having a separate endpoint for select as for update for avoiding sql-injection style attacks
16:53:39 <AndyS> Woudl be issue for INSERT inside SELECT 9as query)?
16:53:41 <LeeF> ... if both can be in one endpoint, i think in the real world people will only implement the one
16:55:25 <LeeF> AndyS: document will have to have a security concerns section
16:55:50 <LeeF> ... it's easy to make mistakes in being setup to accept POSTed queries
16:56:16 <LeeF> zakim, Suite_A has sandro, kasei, AxelPolleres, LeeF, SteveH
16:56:17 <Zakim> kasei was already listed in Suite_a, LeeF
16:56:19 <Zakim> AxelPolleres was already listed in Suite_a, LeeF
16:56:21 <Zakim> +sandro, LeeF, SteveH; got it
16:56:45 <AxelPolleres> q?
16:57:29 <LeeF> SteveH: what concerns me is LOAD, which requires an HTTP request
16:57:41 <LeeF> LeeF: Is that a DOS-type worry?
16:57:49 <LeeF> SteveH: not only that, but also a redirect type attack
16:57:53 <AndyS> AndyS: Might want to discuss/define the case of being able to add triples but not much else.
16:58:34 <LeeF> SteveH: my preferred solution would be some sort of profile which wouldn't implement these features
16:59:03 <LeeF> (in response to LeeF asking whether we're looking at giving advice or doing something more concrete)
16:59:07 <AxelPolleres> "secure profile"
16:59:18 <LeeF> AndyS: it will need to go into the Security section
17:00:10 <AxelPolleres> ... wouldn't have any constructs that need "dereferencing of URIs (LOAF, FROM ...)
17:00:33 <AxelPolleres> ... affects: query, update, servicedescription?
17:00:44 <kjetil_> 403
17:02:02 <LeeF> LeeF: worth noting that FROM doesn't require an HTTP request 
17:02:20 <AxelPolleres> FROM can be ok, if we talk about a local copy in the store, you mean, yes?
17:02:36 <kjetil_> yeah, I think it would be reasonable to use 403 when the server actively refuses a certain query based on the query
17:03:34 <AxelPolleres> steve: protocol also affected: you can do dataset management
17:03:39 <LeeF> LeeF: sounds like the main thing we're talking about is having vocabulary/terminology ro refer to the "safe" parts of Query and Update
17:04:25 <AndyS> q+
17:04:26 <LeeF> SteveH: yes, possibly flag the sections and give a URI in the service description that refers to the parts of the language not flagged
17:04:55 <kjetil_> q+
17:05:06 <LeeF> sandro: "offline operation" ? "two party operation" ?
17:05:06 <AxelPolleres> ack andys
17:05:11 <SteveH> SteveH has joined #sparql
17:05:37 <LeeF> AndyS: finding words and terminology is a lighterweight approach then minting a URI and doing full conformance for profiles
17:05:57 <LeeF> ... good to pull these things out and identify them as things people need to think about
17:06:24 <LeeF> AxelPolleres: maybe we can ask the editors of Query and Update to start with such a security section summarizing the issues and see if it seems to lead to any sort of profile
17:06:29 <LeeF> ack kjetil
17:07:11 <LeeF> kjetil: perhaps instead of flagging, just summarize security issues and allow implementors to return 403 if security implications are too severe
17:07:52 <kjetil_> Zakim, mute me
17:07:52 <Zakim> kjetil_ should now be muted
17:08:46 <LeeF> ACTION: Steve to summarize Query security issues in security section once document has been merged
17:08:46 <trackbot> Created ACTION-135 - Summarize Query security issues in security section once document has been merged [on Steve Harris - due 2009-11-10].
17:09:30 <LeeF> ACTION: Axel to ask Paul to look at security section in Update document 
17:09:30 <trackbot> Created ACTION-136 - Ask Paul to look at security section in Update document  [on Axel Polleres - due 2009-11-10].
17:09:53 <LeeF>  ISSUE-19: see ACTION-135 and ACTION-136
17:09:53 <trackbot> ISSUE-19 Security issues on SPARQL/UPdate notes added
17:10:03 <LeeF>  ACTION-135: this applies to ISSUE-19
17:10:03 <trackbot> ACTION-135 Summarize Query security issues in security section once document has been merged notes added
17:10:06 <LeeF>  ACTION-136: this applies to ISSUE-19
17:10:06 <trackbot> ACTION-136 Ask Paul to look at security section in Update document notes added
17:10:24 <LeeF> AxelPolleres: what can and should we say about concurrency in the spec?
17:10:36 <LeeF> http://www.w3.org/2009/sparql/track/issues/18
17:10:40 <AxelPolleres> q?
17:12:48 <AxelPolleres> that realtes ISUE-26
17:12:51 <LeeF>  ISSUE-18: see also ISSUE-26
17:12:51 <trackbot> ISSUE-18 Concurrency in SPARQL/update notes added
17:13:55 <LeeF> LeeF: steve's conversation with pgearon seemed to say that pgearon intended multiple operations within an update request to be atomic
17:14:07 <LeeF> SteveH: would like an opt out clause from this requirement
17:14:15 <LeeF> ... could always issue a "can't be bothered error"
17:14:47 <LeeF> AndyS: if the store has transactions then the whole request gets wrapped in a transaction
17:15:25 <LeeF> ... if the underlying store doesn't support transactions, then you can't do it
17:15:47 <bglimm> +1 to have a choice of supporting transactions or not
17:16:13 <kjetil_> +1 for a service description about it
17:16:14 <LeeF> SteveH: have a small implementation of parts of update and it's not atomic
17:17:08 <LeeF> LeeF: sounds like requiring atomicity might be a big burden on implementors
17:17:19 <AndyS> Can't require it - no very web-like - even SD is rather detaisl - more an SLA thing.
17:17:26 <LeeF> ... and whether or not i can expect that changes a user/application writer's perspective dramatically
17:19:39 <kjetil_> +1 to default that you don't have it, SD statement that you have it
17:20:31 <LeeF> kasei: this would be a partial answer to people looking at why there isn't full transaction support
17:20:40 <LeeF> SteveH: what about a protocol feature where you can request atomicity?
17:20:56 <LeeF> kasei: what if you're using a command line?
17:21:12 <LeeF> SteveH: other systems can implement it other way (like a command line argument)
17:21:16 <LeeF> Sandro: what about a keyword?
17:21:46 <LeeF> SteveH: Possible option, though some choices might raise expectations of transactions
17:21:56 <LeeF> AxelPolleres: what's the difference from full transactoinality?
17:22:20 <LeeF> SteveH: you don't get read barriers, you don't get rollback 
<sandro> guest: Dave (dajobe) Beckett, Yahoo
17:22:39 <LeeF> zakim, Suite_a also has dajobe
17:22:39 <Zakim> +dajobe; got it
17:23:04 <LeeF> sandro: also support across multiple requests with read/write consistency 
17:24:00 <LeeF> <discussion of what happens when someone trips over the power cord in the middle of an update request>
17:24:21 <AndyS> IMHO not worth defining a formal mechanism with all the details.  Unbounded, relates to other work going on (why not distributed transactions? etc?)  Not REST :-)
17:25:03 <LeeF> sandro: issue of whether a conformant Update impl can not do atomic requests is separate from whether there is a flag in the protocol
17:25:42 <LeeF> steveh: distinction between atomicity and durability
17:26:05 <LeeF> sandro: isolation is that no one else can see it while it's happening
17:26:41 <SteveH> http://en.wikipedia.org/wiki/ACID
17:27:06 <dajobe> dajobe has joined #sparql
17:27:10 <LeeF> AxelPolleres: one option is to make atomicity a requirement - seems to be an overkill
17:27:21 <LeeF> ... second option is that atomicity is an optional feature 
17:27:28 <LeeF> ... then need to clarify if it's per implementation or per request
17:28:14 <LeeF> SteveH: I think we should require it and let systems that don't implement it raise an error
17:28:39 <AndyS> q+
17:29:45 <LeeF> <discussion of how one would word conformance requirements>
17:31:50 <LeeF> SteveH: simple implementations of atomicity are easy
17:32:13 <AndyS> q?
17:32:27 <LeeF> SteveH: "if atomic=1 is in the protocol, then you must guarnatee atomicity"
17:32:46 <sandro> "protocol conformant" is to return an error when you're supposed to.   
17:34:31 <LeeF> AxelPolleres: do people agree that a request for atomicity belongs in the protocol?
17:34:35 <AndyS> no
17:34:53 <LeeF> AndyS: i don't think it's that clear cut
17:35:04 <LeeF> AxelPolleres: what would be an alternative?
17:35:13 <LeeF> AndyS: Make sure we do the same style as other Web application frameworks
17:35:17 <LeeF> ... take the same approach as other people
17:35:25 <LeeF> ... the word atomic is confusing here
17:35:27 <sandro> q+
17:35:31 <LeeF> ack AndyS
17:35:49 <LeeF> AndyS: i'm not sure you can always tell what atomicity you're going to give when you get a request
17:36:38 <LeeF> AxelPolleres: I think we need to say something; people expect something
17:36:44 <LeeF> AndyS: not saying something does not mean banning it
17:36:50 <LeeF> ack sandro
17:37:14 <LeeF> sandro: this is no harder to implement -- put it in the language like in SQL -- "begin transaction" and "commit" 
17:37:27 <LeeF> ... doesn't span HTTP requests so no harder then what we're talking about now
17:37:29 <AndyS> WebAPI has gone a different way to SQL.
17:37:52 <LeeF> SteveH: i think putting it in the request is a sensible approach
17:38:05 <LeeF> ... perhaps with other terms that don't imply ACID
17:38:47 <LeeF> AndyS: WebAPI only has "commit" and "abort" - no explicit "begin"
17:39:22 <LeeF> AxelPolleres: Agreed, there are several possibilities - shouldn't we give advice to the editors, put something in, and get feedback?
17:39:42 <bglimm> So everything is one transaction automatically that runs until I say commit or abort and at that point, I start a new transaction?
17:39:48 <LeeF> AndyS: I'd suggest not putting anything in the protocol or language and put a discussion point in saying services should consider and may offer atomicity
17:40:18 <kjetil_> ...and state so in the SD?
17:40:33 <kjetil_> q+
17:40:48 <LeeF> ack kjetil
17:41:05 <LeeF> kjetil: if it is implemented, it should be stated in the service description?
17:41:40 <LeeF> AndyS: goes back to issue of having exact meaning in the service description 
17:41:50 <LeeF> s/in the service description/tied to terms in the service description
17:42:00 <LeeF> AxelPolleres: two things - do we want to do something, if so, what do we want to do?
17:42:11 <AndyS> As an impl issue then we need to ask the impls :-) which is chicken and egg - so define in a later WG after experience
17:42:12 <kjetil_> Zakim, mute me
17:42:12 <Zakim> kjetil_ should now be muted
17:42:25 <LeeF> AxelPolleres: Straw poll: who thinks either Protocol or Update should take a stand about atomicity - wherever it's located, that if you request it, it should be executed atomically
17:42:30 <SteveH> +1
17:42:32 <kasei> 0
17:42:35 <sandro> +1
17:42:38 <LukeWM> 0
17:42:51 <kjetil_> +1
17:43:03 <LeeF> LeeF: By "take a stand" I mean define an actual mechanism 
17:43:18 <bglimm> -1 (too complicated to get right in a web setting I think)
17:44:22 <sandro> (Hey, bglimm ....    I'm curious how the web setting makes it harder.)
17:44:45 <bglimm> well, you have less control
17:44:46 <AndyS> -1 (too complicated to get right this time round : also need query+update to do some changes)
17:44:57 <LeeF> LeeF: 0
17:45:02 <AxelPolleres> 0 (it can be still a part of the sd: extnsibility, if �we don't support it)
17:45:17 <bglimm> the web is like a distributed database in a sense
17:45:58 <LeeF> LeeF: no consensus - safer route seems to be not to put an explicit mechanism in, but we should probably continue discussion when editor ispresent
17:46:10 <kjetil_> AxelPolleres, I understood it so that it wouldn't be a part of the SD, that's why I voted +1
17:46:16 <bglimm> I think such a spec is non-trivial, there is nothing really worked out on the table and not much of agreement, which makes me think better not
17:46:18 <LeeF> SteveH: there is a risk of certain people being very upset if we don't address this 
17:46:21 <AndyS> If the editors (or other WG) can propose something in the timescale then great but not critical path.
17:46:29 <LeeF> kasei: more than a risk
17:46:52 <bglimm> +1 to Andy
17:47:00 <sandro> but sparql update operates against some conceptually unified triplestore, not the web....   it seems to me.
17:47:36 <kasei> http codes 202 and 409 interesting at protocol level for this stuff
17:47:51 <sandro> sandro: if SPARQL doesn't say anything about transactions, it will be derided by at least the database commuity.
17:48:05 <bglimm> well, but w
17:48:14 <LeeF> http://www.w3.org/2009/sparql/track/issues/20
17:48:15 <bglimm> ups, didn't mean to send that
17:49:14 <LeeF> SteveH: my experience of implementing this and using it in anger is that it's very annoying to have to explicitly create graphs before writing to them
17:49:58 <LeeF> ... currently in the update spec graphs must be explicitly created before they are used 
17:50:33 <AxelPolleres> SELECT ?G { GRAPH ?G {}}
17:51:03 <AndyS> +1 to SteveH - may not have been a good design choice in hindsight.
17:52:01 <LukeWM> q+
17:52:03 <LeeF> LeeF: is it important to be able to create an empty graph?
17:52:05 <LeeF> ack LukeWM
17:52:07 <AndyS> Flip to "test if exists else error"
17:52:29 <LeeF> LukeWM: someone might want to check for existence of graph, which might mean something even if it's empty
17:52:38 <AndyS> DROP <graph> ; INSERT DATA <graph> {...}
17:52:52 <LeeF> good test, Andy
17:53:04 <kjetil_> +1 to that
17:53:08 <AndyS> CLEAR <graph> ; INSERT DATA <graph> {...} -- so empty graphs exist albeit temporarily
17:54:07 <LeeF> SteveH: 4store supports empty graphs, our internal store doesn't support it
17:54:51 <LeeF> dajobe: empty graphs need to be supported
17:54:56 <LeeF> LeeF: empty graphs need to be supported
17:55:43 <AndyS> How are you going to do locking across operations? :-)
17:56:13 <LeeF> Consensus at F2F2 is that the Update langauge & semantics should support the notion of a graph that exists but is empty
17:56:29 <LeeF>  ISSUE-20: Consensus at F2F2 is that the Update langauge & semantics should support the notion of a graph that exists but is empty
17:56:29 <trackbot> ISSUE-20 Graphs aware stores vs. quad stores for SPARQL/update (empty graphs) notes added
17:56:35 <AndyS> q+
17:56:44 <LeeF> ack AndyS
17:57:08 <LeeF> AndyS: Consequence of this is can you test whether a graph exists and then use that to decide whether to perform further operations
17:57:35 <LeeF> ... such as loading data into a graph only if it exists and is empty
17:57:45 <dajobe> I asked how do you test if a graph does not exist?
17:57:49 <dajobe> or whether it is empty?
17:58:14 <LeeF> AndyS: currently, issuing CREATE is an unintended way of asking if a graph exists
17:58:44 <LeeF> SteveH: can keep CREATE if it's helpful, just not if it's required to insert data
17:59:33 <AndyS> q+ to note it conflicts with INSERT { GRAPH ?g { ... } } 
17:59:58 <dajobe> where is CREATE from? I don't see it in sparql 1.1 update.
18:00:06 <dajobe> oh never mind
18:00:15 <LeeF> dajobe: http://www.w3.org/TR/sparql11-update/#t521
18:00:20 <LeeF> s/dajobe:/dajobe,
18:00:27 <LeeF> ack AndyS
18:00:29 <Zakim> AndyS, you wanted to note it conflicts with INSERT { GRAPH ?g { ... } }
18:01:24 <AndyS> Maybe needs a systematic use case analysis
18:01:33 <SteveH> +1 to AndyS 
18:01:55 <LeeF> ISSUE-21 - http://www.w3.org/2009/sparql/track/issues/21
18:02:16 <LukeWM> I don't know where that issue came from
18:02:19 <LeeF> http://www.w3.org/2009/sparql/meeting/2009-05-07 is the source of many of these issues (F2F1)
18:02:30 <Zakim> -Prateek
18:05:48 <LeeF> PROPOSED: Close ISSUE-21 noting that there are no proposals for additional operations at this time
18:06:14 <LeeF> RESOLVED: Close ISSUE-21 noting that there are no proposals for additional operations at this time
18:06:15 <AxelPolleres> �+1
18:06:48 <LeeF>  ISSUE-21: day 2 of F2F2 had  RESOLVED: Close ISSUE-21 noting that there are no proposals for additional operations at this time
18:06:48 <trackbot> ISSUE-21 More complex update operations, e.g. CHANGE objects notes added
18:06:52 <LeeF> trackbot, close ISSUE-21
18:06:52 <trackbot> ISSUE-21 More complex update operations, e.g. CHANGE objects closed
18:08:20 <LukeWM> MODIFY is just for 1 graph as far as I knew
18:08:48 <AndyS> +1 to Leef: Can't do it with MODIFY - INSERT and DELETE are on the same graph
18:09:03 <AndyS> ... only WHERE can do it.
18:09:16 <kjetil_> We could use that: http://www.w3.org/2009/sparql/wiki/ResourceTopicPortals#Move_data_between_graphs
18:09:44 <LukeWM> q+
18:09:46 <kjetil_> currently, we insert into a temp graph and rename or something, IIRC...
18:10:25 <AndyS> Copy graph?  Rename graph?
18:10:29 <LukeWM> ack me
18:11:55 <kjetil_> GRAPH vs. INSERT INTO
18:14:32 <AxelPolleres> What is the dataset of UPDATE queries, i.e. do we need clauses for specifying the graphstore... is that an issue which is missing? Or, resp. further clarification of what is a graphstore ,as opposed to the dataset. 
18:16:03 <LeeF> LeeF: My question is how does / can someone define the RDF Dataset that the pattern matching in a MODIFY proceeds against, a la FROM/FROM NAMED in SPARQL Query
18:17:08 <AndyS> AndyS: different service endpoints can do this (but clunky?)
18:18:27 <AxelPolleres> Issue seems to be whether or not ther graphstore and the dataset for the WHERE part should be decoupled or not? 
18:18:48 <AxelPolleres> q?
18:19:02 <sandro> sandro: there are obviously multiple graph stores in the universe, so the question is whether you can have multiple graph stores behind one endpoint?      [ Lee: Yes. ]
18:19:43 <LeeF> INSERT INTO <g1> { template } FROM g2 FROM g3 FROM NAMED g4 FROM NAMED g5 WHERE { pattern }
18:22:58 <sandro> lee:  we've never had something like "FROM *" and that's been a source of consternation.   I'm concerned that UPDATE seems to be doing it the other way.
18:23:28 <AxelPolleres> q+
18:23:31 <LeeF> INSERT INTO <g1> { template } FROM g2 FROM g3 FROM NAMED g4 FROM NAMED g5 WHERE { GRAPH ?g { ?s ?p ?o } }
18:25:53 <AxelPolleres> I suggest to raise and issue... ISSUE: shall dataset clauses be allowed in SPARQL/update?
18:26:09 <AxelPolleres> q?
18:27:03 <AxelPolleres> ack me
18:27:19 <AxelPolleres> ISSUE: shall dataset clauses be allowed in SPARQL/update?
18:27:20 <trackbot> Created ISSUE-51 - Shall dataset clauses be allowed in SPARQL/update? ; please complete additional details at http://www.w3.org/2009/sparql/track/issues/51/edit .
18:27:48 <AndyS> bigger issue is the overall abstraction.
18:28:12 <AndyS> +1 to dajobe
18:29:04 <AxelPolleres> q?
18:29:22 <SteveH> overall abstraction is definitely the problem
18:29:27 <dajobe> be brave: change the graph management model to be clear, if necessary do not use FROM
18:29:58 <bglimm> Zakim, unmute me
18:29:58 <Zakim> bglimm should no longer be muted
18:30:01 <LeeF> LeeF: I'd find it very hard to teach & think about the situation if they have different graph management models - also, we find the current graph model _useful_, though I realize that's contrary to others' expectations
18:31:14 <AndyS> What is now after the break?
18:31:53 <bglimm> I'll now disappear for a while and check in late tonight UK time to see what is still going on. 
18:32:20 <LeeF> thanks, bglimm
18:35:10 <pgearon> what time are you back from the break?
18:35:21 <pgearon> because I should be available to dial in then
18:35:58 <bglimm> ok, see you later
18:36:05 <Zakim> -bglimm
18:37:00 <Zakim> -LukeWM
18:52:50 <Zakim> -kjetil_
18:56:36 <AndyS> So if it were BIND(?x := lang(?y) ) is that OK?
18:57:22 <AndyS> I don't care about the syntax word.
18:59:35 <AndyS> DECLARE(?x := ?y+3) :-)
19:07:34 <AxelPolleres> Zakim, who is on the phone?
19:07:34 <Zakim> On the phone I see Suite_a, AndyS, dcharbon2
19:07:35 <Zakim> Suite_a has sandro, LeeF, SteveH, dajobe
19:07:54 <AxelPolleres> Zakim, suite_a has kasei
19:07:54 <Zakim> +kasei; got it
19:08:24 <AxelPolleres> Zakim, suite_a has axelpolleres
19:08:24 <Zakim> +axelpolleres; got it
19:08:36 <AxelPolleres> zakim, sho is on the phone?
19:08:36 <Zakim> I don't understand your question, AxelPolleres.
19:09:37 <AxelPolleres> zakim, who is on the phone?
19:09:37 <Zakim> On the phone I see Suite_a, AndyS, dcharbon2
19:09:38 <Zakim> Suite_a has axelpolleres
19:09:58 <AxelPolleres> zakim, you don't get it, doya?
19:09:58 <Zakim> I don't understand your question, AxelPolleres.
19:10:31 <AxelPolleres> zakim, suite_a has leef, axelpolleres, steveh, sandro, dajobe, kasei
19:10:31 <Zakim> axelpolleres was already listed in Suite_a, AxelPolleres
19:10:32 <Zakim> +leef, steveh, sandro, dajobe, kasei; got it
19:10:54 <Zakim> +??P4
19:11:08 <LukeWM> zakim, ??P4 is me
19:11:08 <Zakim> +LukeWM; got it
19:11:26 <sandro> scribe: sandro
19:11:31 <LeeF> scribenick: sandro
19:11:40 <LeeF> pgearon, we are restarting now
19:11:58 <sandro> axel: issue-24 do we need a move operation?
19:12:01 <sandro> issue-24?
19:12:01 <trackbot> ISSUE-24 -- Move data between graphs (select on one graph and insert into another... copy from/to) -- OPEN
19:12:01 <trackbot> http://www.w3.org/2009/sparql/track/issues/24
19:12:04 <pgearon> OK, still on DuraSpace call. I'll dial in the moment I'm off
19:12:36 <sandro> axel: current example in updates document, with move as delete-from plus insert-into.   The question is whether we want a more convenient syntax.
19:12:46 <AxelPolleres> q?
19:13:39 <sandro> axel: modify only affects a single graph, but maybe it could be stretched....
19:14:06 <sandro> strawpoll: do we need a nice syntax for moving data between graphs?
19:14:10 <AndyS> q+
19:14:13 <sandro> -0.5
19:14:38 <AndyS> q-
19:14:39 <LukeWM> q+
19:15:08 <sandro> Lee: you can do it with modify
19:16:03 <sandro> lee: since the WHERE is always against your entire your graph store, and the URI only applies to insert/delete, UPDATE can be used for Move.
19:16:22 <sandro> LukeWM: (unintelligible).
19:16:23 <kjetil_> kjetil_ has joined #sparql
19:16:33 <sandro> axel: I can't delete from one graph and insert into another, in one statement.
19:16:59 <sandro> axel: is example 3e good enough?
19:17:30 <sandro> a combiination LukeWM -- loud fan, bad phone, and I didn't understand the subject.  :-)
19:17:44 <LukeWM> ok
19:18:07 <sandro> lee: Let's not run around and add too many premature simplifications.
19:18:14 <sandro> lee: Syntactic sugar can come later
19:18:16 <sandro> +1 Lee
19:19:03 <sandro> PROPOSED: Close issue-24, saying example 3e in the current draft is sufficient
19:20:07 <sandro> PROPOSED: Close issue-24, saying example 3e in the current draft is sufficient (subject to approval from editors absent from this meeting)
19:20:29 <sandro> PROPOSED: Close issue-24, saying example 3e in the current draft is sufficient (subject to approval from update editor, who are absent from this meeting)
19:20:35 <sandro> PROPOSED: Close issue-24, saying example 3e in the current draft is sufficient (subject to approval from update editors, who are absent from this meeting)
19:20:40 <sandro> +1
19:20:42 <AxelPolleres> +!
19:20:46 <AxelPolleres> +1
19:20:48 <sandro> RESOLVED: Close issue-24, saying example 3e in the current draft is sufficient (subject to approval from update editors, who are absent from this meeting)
19:21:03 <sandro> issue-25?
19:21:03 <trackbot> ISSUE-25 -- Dynamic graph (variable) for INTO graph to update/modify -- OPEN
19:21:03 <trackbot> http://www.w3.org/2009/sparql/track/issues/25
19:21:11 <sandro> topic: issue-25
19:21:31 <sandro> steve: into vs graph  
19:22:05 <sandro> steve: I think it's important.   there are lots of big graphs you want to card up into little graphs by, eg, subject URI.
19:22:09 <LeeF> +1 to steve, this is the most intriguing part of update to me
19:22:32 <sandro> greg: The note from Paul describes this issue as "fraught"  :-)
19:22:45 <sandro> axel: insert and modify
19:22:51 <sandro> axel: and probably delete from
19:22:53 <AndyS> This (INSERT { GRAPH ...}) is a good change.  
19:23:23 <sandro> steve: There are times where you want to delete certain triples from all named graphs.  If you can't use a variable, theres no way to write that down.
19:23:40 <sandro> steve: More than one graph per query.
19:24:01 <sandro> steve: There was also a clarify issue, someone posted about.
19:24:39 <AxelPolleres> sub-issue 1: insert/modify/delete from variable graph yes/no? sub-issue2: concrete syntax (GRAPH vs. INTO/FROM)
19:25:20 <sandro> lee: It sounds good, but I'd like to understand what it's fraught with.
19:25:28 <sandro> steve: some complexity.
19:25:52 <sandro> steve: we'd be re-using some semantics from the WHERE part, so a little simplifying
19:26:16 <sandro> steve: We'd have to talk about some error cases.    eg G binds to a literal.
19:26:42 <sandro> steve: There are probably some nasty corner cases; I haven't implemented it.
19:27:07 <sandro> dajobe: How far has this gone to an arbitrary graph manilpulation language?
19:27:22 <sandro> steve: I think it's clearer if we use graph in both parts.
19:27:38 <sandro> steve: RELATED do we allow things other than graphs to appear?
19:28:10 <sandro> axel: If we used the GRAPH keyword, then it would be weird to disallow variables.
19:28:51 <sandro> steve: the INTO thing poses a number of problems.
19:29:10 <sandro> axel: Should we throw these together?
19:29:18 <sandro> steve: Hard to talk about them separately.
19:29:37 <AxelPolleres> axel: i don't think we can but they affect each other
19:29:43 <sandro> steve: If there no enthusiasm for using GRAPH in INSERT, then we probably shouldn't go with variables.
19:30:26 <sandro> axel: Does anyone see a problem with allowing variables in identifying graphs in INSERT and DELETE?
19:30:36 <sandro> lee: I think we should totally do this.
19:30:51 <sandro> lee: I would use it all the time, to break a giant triples file into quads.
19:30:59 <sandro> lee: I do this all the time.
19:31:04 <sandro> steve: Me too!
19:32:00 <sandro> dajobe: This reminds me of a Map-Reduce.   A new, complex, thing
19:32:14 <sandro> steve: the Graph keyword seems more important to me.
19:32:16 <AxelPolleres> q?
19:32:34 <sandro> dajobe: I'm worried about complexity from many angles.
19:32:47 <AxelPolleres> Luke... is your staring on the q  still current?
19:32:57 <sandro> Lee: The points that stop short are MORE complicated, because they are arbitrary.
19:33:18 <sandro> Dajobe: SPARQL UPDATE == RDF Graph Manipulation Language.
19:33:24 <LukeWM> ack me
19:33:44 <sandro> lee: My own angle is that this is the thing I'd want from update.
19:34:10 <sandro> dajobe: My only advice is to make clear that you're taking on this big peice.
19:34:33 <sandro> lee: As Andy said, we keep adding things to update....
19:34:40 <sandro> dajobe: What would be a step too far?
19:34:48 <sandro> Lee: personally or as chair?
19:35:11 <sandro> Lee: WHERE part when inserting data?    we talked about this, and decided it was important.   That we want a "full featured update language"
19:35:30 <sandro> dajobe: So you're positioning SPARQL updates as diferent from SPARQL Query?
19:35:52 <sandro> dajobe: It looks like SPARQL UPdate is a superset of SPARQL Query.   Or nearly superset.
19:36:30 <sandro> steve: We still want a way to provide a simple flag about whether updates are allowed
19:36:39 <sandro> sandro: a read-only flag isn't that complicated
19:36:54 <sandro> Axel: I'm not sure whether this bit adds problems.
19:37:00 <SteveH> not a flag really, different endpoints
19:37:16 <LeeF> zakim, who's here?
19:37:16 <Zakim> On the phone I see Suite_a, AndyS, dcharbon2, LukeWM
19:37:17 <Zakim> Suite_a has leef, steveh, sandro, dajobe, kasei
19:37:19 <Zakim> On IRC I see kjetil_, dajobe, SteveH, LeeF, Zakim, RRSAgent, AxelPolleres, dcharbon2, Prateek, LukeWM, AndyS, pgearon, karl, KjetilK, kasei, iv_an_ru, sandro, kjetil, ericP,
19:37:21 <Zakim> ... trackbot
19:38:00 <sandro> PROPOSED: SPARQL Update will allow insert/modify/delete on graphs identified by variables (subject to review by Update editors)
19:38:26 <sandro> (who is talking?)
19:39:14 <sandro> dcharbon2: (scribe didn't quite follow)
19:39:30 <sandro> AndyS: I'm worried that this is a peice of a bigger thing.
19:39:59 <sandro> AndyS: View of graph store as a large collection is quad is kind of natural.       Thus variables as quads.
19:40:03 <AndyS> Consequence is GRAPH ?g in templates
19:40:35 <AndyS> q+
19:40:38 <sandro> steve: I'm only in favor of this if it's in the form with GRAPH ?g in templates.
19:40:54 <LeeF> ack AndyS
19:41:10 <AndyS> q-
19:41:29 <sandro> andy: what if you insert/delete into multiple graphs, putting graph in a template.
19:41:40 <sandro> steve: Right -- I want to delete some triple from all named graphs.
19:42:12 <AndyS>  Example: INSERT { GRAPH ?g1 {} GRAPH ?g2 {} } WHERE { ... ?g1 ... ?g2 ... }
19:42:13 <sandro> sandro: where the graphs deleted-from could be determined by a whole spaql query?
19:42:15 <sandro> steve: yes
19:43:05 <sandro> PROPOSED: use GRAPH inside insert/delete templates instead of FROM/INTO (subject to approval from Update Editors.)
19:43:30 <Zakim> -AndyS
19:43:31 <LukeWM> bye
19:43:34 <sandro> lee: thanks andy...
19:43:45 <LukeWM> q+ to ask about how this affects modify
19:44:22 <Zakim> +pgearon
19:44:36 <sandro> sandro: insert into    is soooo nice and simple, and this feels a little down-the-rabit-hole.
19:45:49 <sandro> steve: insert into <a> { ?x ?y ?z } WHERE { ?x ?y ?z } 
19:46:07 <sandro> dajobe: copy from default graph into <a>  ?
19:46:28 <sandro> steve: seems like it might match in <a>, instead of in default graph
19:46:48 <sandro> steve: DELETE FROM <a> { ?x ?y ?z } WHERE { ?x ?y ?z }
19:47:06 <sandro> steve: actually, confusingly, subtracts default from from <a>
19:48:00 <AxelPolleres> ack LukeWM
19:48:00 <Zakim> LukeWM, you wanted to ask about how this affects modify
19:48:25 <sandro> steve: DELETE { GRAPH <A> { ?x ?y ?z } } WHERE { ?x ?y ?z }       # subtract default graph from A 
19:48:41 <sandro> steve: DELETE { GRAPH <A> { ?x ?y ?z } } WHERE { GRAPH <A> {?x ?y ?z }}       # clear A
19:49:24 <sandro> axel: Is a separate syntax for MODIFY necessary, or do INSERT ... DELETE ... WHERE ...   as one statement.
19:50:06 <LukeWM> ack me
19:50:39 <sandro> axel: If we're making things more uniform this way, then modify not longer makes sense, being on one graph.
19:52:51 <sandro> sandro: maybe I want ON GRAPH <g> INSERT ... DELETE ... WHERE ...   
19:53:11 <sandro> dajobe: Yeah, this feels like you're grabbing bits; it's not clear how you they compose.
19:53:17 <sandro> (who?)
19:54:18 <sandro> how about DELETE ... THEN INSERT ... WHERE
19:54:23 <LukeWM> q+
19:54:44 <sandro> axel: it seems simpler to have one statement
19:55:00 <sandro> pgearon: I like WITH or USING, as a way to override the default graph
19:55:14 <AxelPolleres> GRAPGH g { INSERT ... DELETE ... } WHERE ...
19:55:25 <sandro> pgearon: most of the time you're probably operating on a single graph, so putting it in one place.
19:55:26 <dajobe> if WITH omitted, defaults to default graph?
19:55:31 <sandro> (who?)
19:55:42 <sandro> ?: can we just use MODIFY?
19:55:42 <AxelPolleres>  INSERT ...  GRAPGH g {DELETE ...  WHERE ... }
19:56:04 <LukeWM> yes
19:56:04 <sandro> (axel, DELETEs happen before INSERTs, which is why I want it first.)
19:57:05 <sandro> someone: insert into one named graph, delete from another, query on a 'general' one, ....   MODIFY X doesnt make much sense.
19:57:14 <sandro> someone-else: good point.
19:57:19 <pgearon> sandro, that's me
19:57:20 <LukeWM> sandro, LukeWM
19:57:28 <AxelPolleres> DELETEpart|INSERTpart|(DELETEpart INSERTpart)  DATASETclause? WHEREpart?
19:57:28 <LukeWM> (the good point bit)
19:58:45 <sandro> axel: if we allow GRAPH in templates everywhere, then the uniform statement probably makes sense, but it might be nice to have syntax sugar like USING.
19:59:40 <sandro> steve: it's not syntactic sugar, because you might nest graph stmts
19:59:59 <pgearon> can someone please type a counter example showing nested graph statements?
20:01:38 <sandro> sandro: my sense is USING or ON would set a lexical-scope temporary default graph.
20:01:43 <sandro> steve: that might work
20:02:25 <sandro> axel:    GRAPH g { INSERT .... { } }
20:02:33 <sandro> steve: a bit weird.
20:02:57 <sandro> paul: nested graphs?
20:03:20 <sandro> axel:  INSERT { GRAPH g { a b c } }       
20:03:32 <sandro> axel: instead of INSERT INTO G { a b c }
20:03:41 <sandro> axel: people here seemed to like this.
20:04:02 <sandro> paul: I want to insert and delete with multiple graphs at once.
20:04:41 <AxelPolleres>  INSERT { GRAPH g { a b c  GRAPH g2 { d e f} } }     
20:05:02 <AxelPolleres> INSERT { GRAPH g { a b c } GRAPH g2 { d e f} }   
20:05:05 <pgearon> INSERT { GRAPH g { a b c } GRAPH g�2 { d e f } }  
20:05:42 <sandro> paul: There's no context to bring in, with the nesting.
20:05:55 <sandro> lee: it's the same in QUERY, and it also has no effect.
20:06:14 <sandro> greg: it's NEVER made sense to me.   it's just to make it easier on parser.
20:06:33 <sandro> lee: there's a notion of active graph or something
20:06:46 <sandro> axel: so it's equally redundant in query
20:06:53 <sandro> paul: Are filters kept inside scope?
20:07:01 <sandro> lee: I don't think it has any effect
20:07:23 <sandro> lee: in GRAPH X, there's never a semantic difference from being ...     unless it's GRAPH ?g
20:07:58 <sandro> paul: I just don't like nesting, because it adds complexity for no gain
20:08:07 <sandro> paul: if someone else writes the JavaCC
20:08:36 <sandro> axel: leaving out grammar issues, are we okay with this...
20:08:49 <AxelPolleres> DELETEpart|INSERTpart|(DELETEpart INSERTpart)  DATASETclause? WHEREpart?
20:10:57 <sandro> sandro: what about a THEN connective between DELETE and INSERT
20:11:13 <LukeWM> AxelPolleres, there could be two WHERE clauses above.
20:11:53 <sandro> LukeWM: there could  be different WHERE clauses for the DELETE and the INSERT
20:11:56 <sandro> axel: I don't get that.
20:12:14 <sandro> axel: Just do two separate queries.
20:12:47 <sandro> Paul: It's an atomic operation.
20:13:35 <sandro> axel: one approach was several statements in one HTTP request, and treat those atomically.
20:14:02 <sandro> paul: as ISWC we were being grilled on this lack of transactions.    
20:14:33 <sandro> paul: So a seperate where clause of insert and delete might help with that.
20:14:34 <AxelPolleres> (DELETEpart|INSERTpart|(DELETEpart INSERTpart)  DATASETclause? WHEREpart?)+
20:15:40 <AxelPolleres> probably needs separator ';'?
20:15:51 <sandro> steve: grammar allows multiple statements in one blob?    no...
20:16:50 <sandro> Paul:  roughly: [DELETE ...  [WHERE ...]] [INSERT ... [ WHERE ... ]]
20:17:12 <sandro> paul: where if theres no WHERE on DELETE, it uses the INSERT's
20:17:20 <pgearon> (DELETE...[WHERE...])* (INSERT...[WHERE...])* WHERE...
20:17:39 <sandro> axel: I don't see the difference.
20:18:47 <sandro> paul: you can do your delete and your insert each with their WHERE, and then a default WHERE at the end.
20:19:22 <sandro> axel: If you can put multiple operations in one request, then this isn't necessary.
20:19:28 <sandro> paul: how do we package them up>?
20:19:41 <sandro> steve: all in one string with a seperator character.
20:19:46 <sandro> Paul: works for me.
20:19:51 <sandro> steve: semi-colon
20:19:57 <AxelPolleres> steve: separator charcter ';' 
20:20:15 <sandro> paul: hard to pre-parse, since semi-colon is used inside braces
20:20:47 <sandro> steve: it's always going to need a real parser anyone because of escaping.
20:24:04 <sandro> PROPOSED:  we'll have one update statement,   DELETE ... INSERT ... WHERE ..., where one of DELETE or INSERT may be ommitted, and WHERE is optional, and multiple of these may be combined in a string using ";" as the separator. 
20:24:32 <sandro> (and we'll talk about having ON or USING separately.)
20:24:47 <LukeWM> q+ to mention multiple wheres
20:25:03 <Zakim> -dcharbon2
20:25:04 <LukeWM> ack me
20:25:05 <Zakim> LukeWM, you wanted to mention multiple wheres
20:25:26 <AxelPolleres> +1
20:25:28 <pgearon> +1
20:25:35 <sandro> +1
20:25:55 <sandro> RESOLVED:  we'll have one update statement,   DELETE ... INSERT ... WHERE ..., where one of DELETE or INSERT may be ommitted, and WHERE is optional, and multiple of these may be combined in a string using ";" as the separator. 
20:25:58 <LukeWM> q+
20:27:04 <sandro> luke; there might be some issue with the WHERE applying *after* the delete has happened?
20:28:29 <pgearon> doesn't the WHERE clause have to be done first?
20:29:44 <AxelPolleres> sandro... simple testcase  DELETE {?s ?p ?o } INSERT  {?s ?p ?o } WHERE  {?s ?p ?o } should have no effect 
20:30:18 <sandro> sandro: so you do the WHERE, then the DELETE, then the INSERT, (both using the results of the WHERE)
20:30:22 <sandro> steve: Yes.
20:30:44 <LukeWM> +1 to USING
20:31:09 <pgearon> +1 to WITH or USING. Happy to discuss which
20:31:11 <SteveH> +0
20:32:02 <sandro> steve: Paul, as editor, feel free to go ahead and put it in the document for now.
20:32:06 <pgearon> :-D
20:32:11 <sandro> Lee: Yeah, that's the best way to make progress.
20:32:28 <sandro> I wonder about calling it DEFAULT
20:33:03 <SteveH> not DEFAULT :)
20:33:19 <sandro> okay  :-)   I forgot.
20:33:48 <sandro> steve: Paul, about atomicity -- did you want one HTTP request to be dispatched atomically?
20:34:00 <sandro> Paul: yes.
20:35:06 <LeeF> issue-26?
20:35:06 <trackbot> ISSUE-26 -- Conjunction of operation vs atomocity, transactions -- OPEN
20:35:06 <trackbot> http://www.w3.org/2009/sparql/track/issues/26
20:35:20 <sandro> topic: issue-26
20:35:34 <sandro> axel: we've broadly discussed a lot of these.
20:35:47 <sandro> axel: do we have another issue about atomicity?   are they linked?
20:36:03 <sandro> topic: issue-27
20:36:05 <sandro> issue-27?
20:36:05 <trackbot> ISSUE-27 -- Subqueries in Update operations, full expressivity -- OPEN
20:36:05 <trackbot> http://www.w3.org/2009/sparql/track/issues/27
20:37:03 <sandro> axel: in Update document?
20:37:48 <sandro> axel: We dropped subqueries yesterday, we only have subselects.
20:38:00 <sandro> axel: allow full query syntax in WHERE part?
20:38:05 <sandro> paul: I think so
20:38:33 <sandro> Steve: yeah, there's a risk that someone does UPDATE only, eg to add to SPARQL server.
20:38:38 <AxelPolleres> issue-27 boils down to... do we allow full SPARQL1.1/query  WHERE parts?
20:38:43 <sandro> paul: So they'll have crippled where clauses.
20:39:19 <AxelPolleres> what if someone wants to add UPDATE on top of SPARQL/Query 1.0?
20:39:20 <sandro> steve: They might implement UPDATE only, not QUERY.
20:39:34 <sandro> steve: it's a corner case that doesn't bother me.
20:40:25 <sandro> paul: in Service Description, you can say you can only do trivial updates.
20:40:54 <sandro> Greg: I've been very hesistant to include way of describing that you fall short of conformance.
20:40:58 <LukeWM> q+ to ask about SELECTS in update queries.
20:41:22 <sandro> Greg: Should we have a way to say: I do 1.1 update but only 1.0 query?
20:41:29 <sandro> steve: No, let's avoid profiles.
20:42:21 <sandro> greg: Are we telling them they can never be a conformant sparql imnplementation?
20:42:42 <sandro> paul: If your where clause is not complete, ... that's fine.
20:43:00 <sandro> Greg: Someone else can define that language.
20:45:13 <sandro> sandro: some sort of AT RISK bit with profiles, to give ourselves flexibility as the market develops.
20:45:51 <sandro> steve: fallback is SPARQL UPDATE with the WHERE clause being beyond 1.1 being AT RISK.
20:46:00 <AxelPolleres> q?
20:46:39 <sandro> luke: I thought we had consensus that we'd have multiple selects inside updates
20:47:42 <sandro> steve: I don't think we can handle a single request which does both an update and a query, BUT we will allow one endpoint to handle both.
20:48:02 <sandro> steve: the format can't allow it 
20:48:07 <sandro> luke: no problem.
20:49:32 <sandro> PROPOSED: SPARQL Update WHERE clauses will be at least SPARQL 1.0 QUERY, with SPARQL 1.1 Query being AT RISK for this.  This closes ISSUE-27.
20:53:14 <sandro> sandro: related is the idea of profiles.
20:53:55 <sandro> PROPOSED: SPARQL Update WHERE clauses will be at least SPARQL 1.0 QUERY, with each feature 1.1 adds to SPARQL Query being AT RISK for this.  This closes ISSUE-27.
20:54:02 <SteveH> this doesn't rule out profiles, just doesn't mention them explictly
20:54:48 <sandro> greg: this rules out the case of update endpoints that doesn't even do 1.0
20:55:02 <SteveH> seconded
20:55:04 <sandro> +1
20:55:08 <AxelPolleres> +1
20:55:30 <sandro> RESOLVED: SPARQL Update WHERE clauses will be at least SPARQL 1.0 QUERY, with each feature 1.1 adds to SPARQL Query being AT RISK for this.  This closes ISSUE-27.
20:55:57 <sandro> steve: this may be overly paranoid
20:56:00 <sandro> (yeah)
20:56:30 <sandro> topic: issue-46
20:56:33 <sandro> issue-46?
20:56:33 <trackbot> ISSUE-46 -- Can INSERTS, DELETES, and other 'subupdates' be nested inside update language queries? -- OPEN
20:56:33 <trackbot> http://www.w3.org/2009/sparql/track/issues/46
20:57:19 <sandro> axel: where updates can somehow be nested?    Ummmm NO.
20:57:33 <sandro> PROPOSED: Close issue-46, no action required.
20:57:37 <sandro> +1
20:57:43 <AxelPolleres> +1
20:57:46 <sandro> RESOLVED: Close issue-46, no action required.
20:57:46 <pgearon> +1
20:58:05 <LukeWM> Right, I'm off home, bye 
20:58:10 <AxelPolleres> Lunch break! thanks all the brave phone participants
20:58:20 <sandro> RRSAgent, make log public
20:58:21 <Zakim> -pgearon
20:59:07 <Zakim> -LukeWM
21:25:57 <AxelPolleres> AxelPolleres has joined #sparql
21:48:21 <SteveH> SteveH has joined #sparql
21:49:08 <kjetil_> kjetil_ has joined #sparql
21:53:04 <LukeWM> LukeWM has joined #sparql
21:57:11 <LeeF> LeeF has joined #sparql
21:59:21 <AxelPolleres> AxelPolleres has joined #sparql
21:59:51 <AxelPolleres> Zakim, who is on the phone?
21:59:51 <Zakim> On the phone I see Suite_a
21:59:52 <Zakim> Suite_a has leef, steveh, sandro, dajobe, kasei
22:00:10 <AxelPolleres> Zakim, Suite_a also has axelpolleres
22:00:10 <Zakim> +axelpolleres; got it
22:00:31 <dajobe> dajobe has joined #sparql
22:00:32 <AxelPolleres> Zakim, who is on the phone?
22:00:32 <Zakim> On the phone I see Suite_a
22:00:33 <Zakim> Suite_a has leef, steveh, sandro, dajobe, kasei, axelpolleres
22:01:06 <LukeWM> LukeWM has joined #sparql
22:06:31 <sandro> pgearon, you calling in?
22:06:49 <SteveH> AxelPolleres: "is delete too verbose?"
22:07:19 <SteveH> AxelPolleres: put it in telecon to see if it's still an issue
22:07:39 <AxelPolleres> ACTION: Axel to put ISSUE-48 on the table in one of the next TCs and ask whether it is still an issue
22:07:39 <trackbot> Created ACTION-137 - Put ISSUE-48 on the table in one of the next TCs and ask whether it is still an issue [on Axel Polleres - due 2009-11-10].
22:08:05 <SteveH> kasei: 3 things... (service desc)
22:08:21 <SteveH> ... punting on dataset hoping void or similar will cover it
22:08:46 <SteveH> ... void won't cover the default graph, would like property to link named graph to default graph
22:09:09 <SteveH> ... we have a single property that points to something that describes the dataset
22:10:14 <AxelPolleres>   sd:dataset --> sd:hasDefaultGraph --> void ;   
22:10:31 <AxelPolleres>  sd:dataset --> sd:hasNamedGraph --> void ; 
22:10:49 <AxelPolleres> sd:dataset rdfs:range sd:Dataset ?
22:11:19 <SteveH> kasei: we were going to have a note saying how to use it, but it seems core to SPARQL
22:12:06 <SteveH> AxelPolleres: datasets in void are more than one graph, collections of graphs at the same domain
22:12:35 <SteveH> kasei: they're clarifying for the next iteration, [something about requirements]
22:13:07 <AxelPolleres> ... e.g. dppedia is a graph.
22:13:14 <AxelPolleres> s/graph/dataset/
22:14:32 <SteveH> kasei: default graph is fundamental to SPARQL but not in other things
22:15:26 <SteveH> ... we have a predicate that says "this is the description"
22:15:47 <SteveH> AxelPolleres: I would assume you want to give some description, stats etc
22:17:00 <SteveH> AxelPolleres: do we want to have a different predicate
22:17:12 <SteveH> kasei: that's what we'd looked at punting
22:17:30 <sandro> so the defaultGraph of an endpoint ...    maybe be bnode.
22:17:51 <sandro> endpoint hasDefaultGraph ...
22:17:52 <SteveH> AxelPolleres: might need two seperate descriptions
22:19:18 <SteveH> sandro: you could also have the inverse relation, graph-has-proxy or so
22:19:32 <SteveH> sandro: you could do it either way
22:20:40 <sandro> endpoint has dataset, dataset has namedGraph
22:21:52 <SteveH> AxelPolleres: two descriptive properties which describe the dataset in terms that SPARQL cares about
22:23:20 <SteveH> dajobe: if you've got 10M graphs could you not put up SPARQL endpoint to describe them
22:23:37 <SteveH> AxelPolleres: we don't make this obligator
22:23:39 <SteveH> y
22:23:52 <SteveH> ... you could do it by asking a query about the graph names
22:24:05 <SteveH> kasei: I don't think you can always do that
22:24:14 <sandro> So sparql:Dataset is a subset of Dataset, where one of the graph is the default graph, and any others have names.
22:24:33 <SteveH> kasei: some impls. require you to enumerate graphs with FROM NAMED
22:25:10 <SteveH> kasei: what if the store doesn't provide a default dataset, but it describes the URIs it could use
22:27:21 <SteveH> LeeF: describing the dataset that's used if nothing else is defined - I think that's very usefulk
22:27:39 <SteveH> AxelPolleres: we have sd:dataset already
22:27:55 <SteveH> AxelPolleres: lets add two more properties
22:28:42 <SteveH> kasei: we don't want to nail it down too much
22:29:47 <SteveH> kasei: we only need the default graph on because that's unique to SPARQL, void does named graphs
22:33:28 <SteveH> [ LeeF drawing on flipchart ]
22:53:29 <LeeF> [ LeeF drawing beautiful pictures of turtles ]
22:55:30 <SteveH> discussion about sparql:feature <feature> v's rdf:type <EndpointWithFeature>
22:57:56 <sandro> "from-able universe" instead of "available universe" ?
23:08:23 <SteveH> descriptions like:
23:09:22 <SteveH> <EP> :defaultDataset _;ds . _:ds defaultGraph <dg> . <EP> :availableUniverse _:u .
23:09:34 <SteveH> [ see photos ]
23:11:51 <SteveH> discussion of :feature predicate
23:12:08 <SteveH> kasei: OWL people will like it to be subclasses
23:12:19 <SteveH> kasei: subclass of service for each feature
23:14:45 <SteveH> kasei: for now I will create a class for range, and delay deciding if it should be modelled in some other way
23:15:20 <SteveH> ... property functions - a lot of impl. use them, want some say to describe it
23:15:32 <SteveH> ... here are the functions it supports
23:17:05 <SteveH> SteveH: they're not part of the language, and have issues, so we can't really describe them
23:18:56 <SteveH> dajobe: leave property functions off the agenda unless you've got a lot of time
23:19:49 <SteveH> LeeF: testcases
23:22:09 <SteveH> LeeF: the impl. report generator was a bit slow
23:23:24 <SteveH> sandro: OWL2 had two people overseeing testcases
23:24:09 <dajobe> http://owl.semanticweb.org/page/OWL_2_Test_Cases
23:28:02 <SteveH> [ discussion of how testcases should be maintained ]
23:28:44 <bglimm> bglimm has joined #sparql
23:30:15 <Zakim> + +0186598aabb
23:30:21 <SteveH> LeeF: lets try maintaining collaborativly, responsibility of chairs to assign actions when things are contentious
23:30:54 <bglimm> Zakim, +0186598aabb is bglimm
23:30:54 <Zakim> +bglimm; got it
23:31:42 <kasei> ...coffee time...
23:32:46 <Zakim> -bglimm
23:38:21 <LeeF> see http://thefigtrees.net/lee/dl/sparql-IMG00009-20091103-1508.jpg for picture
23:50:53 <LeeF> the unlabeled blue arc should be "default graph"
23:54:52 <LeeF> RRSAgent, pointer?
23:54:52 <RRSAgent> See http://www.w3.org/2009/11/03-sparql-irc#T23-54-52
23:58:45 <SteveH> SteveH has joined #sparql
23:59:27 <AxelPolleres> AxelPolleres has joined #sparql
00:00:10 <LeeF> consensus that we need a formal model (an algebra probably) for what all of the update operations mean, probably including what a dataset is/means
00:00:20 <LeeF> ...or a graph store
00:00:24 <LeeF> ...and/or a graph store
00:00:55 <dajobe> dajobe has joined #sparql
00:02:17 <AxelPolleres> scribe: Axel Polleres
00:02:26 <AxelPolleres> scribe: Axel Polleres
00:02:51 <AxelPolleres> LeeF: what did we miss in the Agenda?
00:03:21 <AxelPolleres> Dajobe: How will you do propertypaths?
00:03:46 <AxelPolleres> ... seems that HCLS will need it
00:04:11 <AxelPolleres> ... will be substantial work for implementers
00:04:47 <AxelPolleres> other time allowed features:
00:05:28 <AxelPolleres> entailment, basic federated queries, function library
00:06:19 <AxelPolleres> BETWEEN would be sugar, IN probably not
00:06:28 <AxelPolleres> steve: I'd like IN
00:07:17 <AxelPolleres> axel: what about list accessors... we had them in property paths?
00:07:37 <AxelPolleres> LeeF: we probably should adjourn
00:08:24 <AxelPolleres> Dajobe: scope of function library?
00:09:03 <Zakim> +bglimm
00:09:15 <AxelPolleres> LeeF: mainly xpath string and math functions
00:09:31 <AxelPolleres> ... IF THEN, COALESCE, maybe
00:09:45 <AxelPolleres> SteveH: group-concat 
00:10:19 <AxelPolleres> LeeF: Birte? anything on entailment?
00:11:12 <AxelPolleres> Birte: Entailment-telecon on Friday
00:11:29 <AxelPolleres> ... we could quickly discuss entailment URIs
00:13:16 <AxelPolleres> Birte: RIF, OWL RL, RDFS don't have owl:imports 
00:14:12 <AxelPolleres> Sandro: Axel and I will go back to RIF and will probably suggest them to add something like rif:imports
00:14:32 <AxelPolleres> ... alternative would be a RIF->RDF serialisation, prbably more difficult
00:14:51 <AxelPolleres> Birte: there is RDF/XML for SWRL rules
00:15:56 <AxelPolleres> Sandro: needed talking to some people (Pat, Peter...) 
00:17:01 <AxelPolleres> Sandro: Does the client have an option to define the entailment?
00:18:37 <AxelPolleres> Axel: So far, we have only said that Entailment doc will define what X-Entailment means, but not how to request/advertise it. 
00:19:19 <bglimm> So far the client cannot choose or define its own entailment
00:19:21 <AxelPolleres> ... Service Description has so far minimal means for it, but we had discussions of different use cases (Andy brought up that there might be a need for different entailments on different graphs)
00:19:39 <AxelPolleres> ... so far, nothing in protocol
00:20:37 <AxelPolleres> Greg: doesn't that mean that you'd need to do all possible entailments (in case you have fwd-chaining) 
00:23:00 <AxelPolleres> Birte: sandro said at the moment you can't say you are an incomplete OWL/RDFS implementation. 
00:23:20 <AxelPolleres> ... not sure whether we want to go that way.
00:23:32 <AxelPolleres> ... at the moment we can't describe that.
00:25:22 <AxelPolleres> ... e.g. OWL2RL supporting inference engine can still do reasoning, but incomplete on OWL DL
00:26:31 <AxelPolleres> Sandro: OWL2RL doesn't do all it can (example by Paul)
00:27:18 <AxelPolleres> Birte: OWL2RL is not really an entailment regime.
00:29:36 <AxelPolleres> Axel: that was the whole idea of RIF-based entailment regime from my side.
00:31:28 <AxelPolleres> Sandro: Don't see much sense in advertising entailment regime
00:31:49 <AxelPolleres> Axel: It makes sense to know which work is "already done" inside the query engine.
00:33:09 <AxelPolleres> ... but that's not trivial.  
00:35:31 <AxelPolleres> Axel: I would personally like a way to request entailment, but that's personal opinion and at this point, I don't see it happen in the standard (more important things).
00:36:25 <AxelPolleres> Sandro: is SPARQL extensible in the way that you can add such a request for entailment?
00:36:26 <pgearon> I figured that I could shoehorn this approach into anything the working group comes up with :-)
00:36:47 <bglimm> Some people do that, materialise inferences
00:37:06 <AxelPolleres> LeeF: in the language it would be a syntax error, in the protocol it would be ignored.
00:38:02 <AxelPolleres> Steve: I have reservations on putting it in the language.
00:38:33 <pgearon> I've been considering creating graphs based on original data that contains only entailments. So for a graph named foo:bar, then entailed data might exist in foo:bar_entailed. By default, queries will be applied to their union.
00:38:42 <pgearon> I figured that I could shoehorn this approach into anything the working group comes up with
00:39:20 <AxelPolleres> sandro: that would indicate the need for something like pragmas
00:39:35 <pgearon> bglimm, yes, this id for materializing inferences. This appears to be the best approach for rules. Though the entailed graph can be in RAM
00:39:45 <pgearon> s/id/is/
00:39:59 <kasei> Zakim, who is on the phone?
#00:39:59 <Zakim> On the phone I see Suite_a, bglimm
#00:40:01 <Zakim> Suite_a has leef, steveh, sandro, dajobe, kasei, axelpolleres
00:40:01 <sandro> zakim, who is on the call?
00:40:02 <Zakim> On the phone I see Suite_a, bglimm
00:40:03 <Zakim> Suite_a has leef, steveh, sandro, dajobe, kasei, axelpolleres
00:40:17 <sandro> pgearon, are you available to call in, if we want to talk about something interesing?
00:40:35 <pgearon> yes, though LeeF told me out of band that you were wrapping up
00:41:07 <pgearon> so I stayed out
00:41:35 <Zakim> +pgearon
00:42:27 <AxelPolleres> probably defining entailment-request as part of the protocol too much of a burden in this stage, even if a simple proposal was made.
00:42:34 <pgearon> Hector Perez-Urbina had a very interesting paper at ISWC
00:42:39 <sandro> sandro: I think it's okay to leave out client-server negotiation about entailment regimes from SPARQL 1.1    Folks can easily experiment for now now, and add it later.
00:42:57 <AxelPolleres> defninitly, not normative.
00:43:19 <AxelPolleres> paul: was looking at rules for entailment, cover most of what people wanna do.
00:44:00 <AxelPolleres> </chairhat>http://axel.deri.ie/~axepol/presentations/20091029iann-etal-ISWC2009_GiaBATA.pptx<chairhat>
00:44:33 <AxelPolleres> sandro: is this part of service description?
00:45:09 <AxelPolleres> paul: we can put it there, but not per graph, probably, that's difficult with many graphs.
00:45:20 <AxelPolleres> ... not standard, at least
00:45:55 <AxelPolleres> kasei: pointing to the non-mandatory parts of service-descriptions discussed earlier.
00:46:44 <bglimm> so a graph/resource has a description that also says which entailments have been/will be applied to that graph?
00:47:38 <AxelPolleres> Axel: by the rdfs:domain of sd:supportedEntailment we prohibit that the same property is used for describing graphs
00:48:26 <AxelPolleres> discussion whether we need description whether one graph entails the other in SD.
00:48:43 <bglimm> but that is not what Andy wanted
00:49:56 <pgearon> bglimm, I'm describing a system where graph resources (ie. the name for a graph) has a description which says where entailments for it have been generated
00:49:59 <AxelPolleres> sandro: <g1> <..../entailment/RDFS> <g2>
00:50:19 <AxelPolleres> axel: uuuuh, sounds scary to reuse entailment URIs as predicates.
00:50:23 <bglimm> ah, ok, sound quality is quite bad, so I can not understand everything
00:51:22 <sandro> sorry, Birte, we're all tentative, so we're speaking more softly.
00:51:27 <AxelPolleres> discussion whether this should be in mandatory part of SD... probably not.
00:51:58 <AxelPolleres> Birte: use case of Andy, was querying for subclasses and/or direct-subclasses.
00:52:24 <AxelPolleres> ... andy models this by having two graphs, one with simple only, one with RDFS closure
00:55:21 <AxelPolleres> Axel: Question is: Do we want SD to cover that? Do we want existing properties such as sd:supportedEntailment to be usable that way (i.e. describing Graphs in the dataset, insead of services) ... I personally think we may want to start small. 
00:55:35 <AxelPolleres> ... in terms of what we put in the core part of SD.
00:56:03 <AxelPolleres> Axel: propose to adjourn
00:56:29 <AxelPolleres> Thanks everybody!
00:56:43 <AxelPolleres> rrsagent, make record public
00:57:32 <Zakim> -bglimm
00:59:19 <bglimm> bglimm has joined #sparql
01:02:23 <dajobe> I was refering to http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt
01:02:40 <dajobe> e.g. Link: <http://example.com/TheBook/chapter2>; rel="previous";
01:02:40 <dajobe>          title="previous chapter"
01:12:35 <kasei> Zakim, who is on the phone?
01:12:35 <Zakim> On the phone I see Suite_a, pgearon
01:12:36 <Zakim> Suite_a has leef, steveh, sandro, dajobe, kasei, axelpolleres
01:12:49 <Zakim> -pgearon
#01:12:56 <Zakim> -Suite_a
01:12:58 <Zakim> SW_SPARQL(TPAC)11:30AM has ended
01:12:59 <Zakim> Attendees were kasei, AxelPolleres, AndyS, bglimm, LukeWM, +1.919.543.aaaa, dcharbon2, Prateek, kjetil_, sandro, LeeF, SteveH, dajobe, pgearon
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00000793