13:59:22 RRSAgent has joined #sparql 13:59:22 logging to http://www.w3.org/2012/08/21-sparql-irc 13:59:24 RRSAgent, make logs world 13:59:24 Zakim has joined #sparql 13:59:26 Zakim, this will be 77277 13:59:26 ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 1 minute 13:59:27 Meeting: SPARQL Working Group Teleconference 13:59:28 Date: 21 August 2012 13:59:40 SW_(SPARQL)10:00AM has now started 13:59:47 +MattPerry 13:59:55 agenda: http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JulSep/0122.html 14:00:10 +??P1 14:00:13 zakim, ??P1 is me 14:00:13 +AndyS; got it 14:00:22 LeeF has joined #sparql 14:00:27 zakim, who is on the phone? 14:00:27 On the phone I see MattPerry, AndyS 14:00:37 trackbot, start meeting 14:00:39 +kasei 14:00:39 RRSAgent, make logs world 14:00:41 Zakim, this will be 77277 14:00:41 ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start now 14:00:42 Meeting: SPARQL Working Group Teleconference 14:00:42 Date: 21 August 2012 14:00:43 oops 14:00:45 late to the party 14:00:50 zakim, this is sparql 14:00:50 ok, LeeF; that matches SW_(SPARQL)10:00AM 14:01:12 Zakim, who is on the phone? 14:01:12 On the phone I see MattPerry, AndyS, kasei, AxelPolleres 14:01:15 +LeeF 14:01:25 Chair: LeeF 14:01:46 Agenda: http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JulSep/0122.html 14:01:55 +Arthur_Keen 14:01:56 +sandro 14:02:38 zakim, who's on the phone? 14:02:38 On the phone I see MattPerry, AndyS, kasei, AxelPolleres, LeeF, Arthur_Keen, sandro 14:02:42 cbuilara has joined #sparql 14:03:05 matt, you mentioned you can scribe this week last time? (/me can do otherwise) 14:03:15 sure, I can scribe 14:03:28 scribe: MattPerry 14:03:36 topic: Admin 14:03:36 +??P10 14:03:41 PROPOSED: Approve the minutes from last week at http://www.w3.org/2009/sparql/meeting/2012-08-14 14:03:44 zakim, ??P10 is me 14:03:44 +cbuilara; got it 14:03:47 zakim, mute me 14:03:47 cbuilara should now be muted 14:04:06 +pgearon 14:04:18 +1 to minutes 14:04:27 RESOLVED: Approve the minutes from last week at http://www.w3.org/2009/sparql/meeting/2012-08-14 14:04:41 -cbuilara 14:04:47 LeeF: any comments from RDF WG 14:05:00 AndyS: No, not yet. They are meeting this week 14:06:18 topic: Actions from last week 14:06:55 LeeF: Carlos' Action to look at protocl tests? 14:06:57 cbuilara, have you had a chance yet to look at the protocol tests for completeness? 14:07:13 no, sorry 14:07:20 ok 14:07:45 LeeF: Greg & Sandro, did we get the validator moved? 14:07:46 I tried the tests -- still an issue with the singe endpoint for hosted and web data. 14:07:48 I will look ointo the tests this week 14:07:49 http://www.w3.org/2009/sparql/protocol_validator forwards 14:07:53 ok, great cbuilara 14:08:07 LeeF: anything else on protocol tests 14:08:35 kasei: No, I've made progress on ARQ testing, so I'm willing to open it up 14:08:47 AndyS: what about overloading one endpoint to 2 services 14:09:00 +??P17 14:09:07 zakim, ??P17 is me 14:09:07 +cbuilara; got it 14:09:16 ... some cases require data in the endpoint, some don't 14:09:31 ok 14:09:43 zakim, mute me 14:09:43 cbuilara should now be muted 14:09:51 s/cases/tests 14:10:21 kasei: as written, all of them should work with data in the endpoint, but ARQ doesn't work that way 14:10:37 ... it may be hard to make it work with all implementations 14:11:03 AndyS: can we have 2 endpoints in the tests, one for each case? 14:11:41 kasei: the validator attempts to load the data before running the tests 14:12:06 AndyS: can you point to spec tests to confirm that interpretation 14:12:31 kasei: this is a case where an implementation has some freedom 14:13:21 LeeF: you use SPARQL update to load the data? 14:13:25 kasei: yes 14:13:39 q+ 14:14:03 ... For update tests, it won't work 14:14:19 LeeF: Andy, how would you want to see such a test written? 14:14:41 AndyS: there are two kinds of endpoints: those that host the data and those that get it from the web 14:15:14 ... For fuseki, if it's hosted data you cannot retieve data from the web 14:16:07 ... the update tests run tests for both kinds on the same endpoint 14:16:28 ... doing the update assumes the data is local to the host 14:16:46 ... so specifying protocol parameters don't make sense 14:17:00 LeeF: for systems that pass the tests it makes sense 14:18:05 ... we are trying to test SPARQL update part of the protocol? correct? 14:18:15 kasei: some tests may be for query 14:18:30 ... I don't know of an alternative for testing 14:19:06 AndyS: update is specified using GRAPH URI and NAMED GRAPH URI is referring to local dataset 14:19:25 ... for query, it does not necessarily refer to the local dataset 14:19:34 using-graph-uri= & using-named-uri= 14:21:43 AndyS: you make an update and then you query that dataset. The protocol parameters change the dataset 14:22:10 LeeF: the assumption is that you update the graph store and the dataset is the state of the graph store 14:22:44 ... you update and the the query that follows tests the state of the graph store, 14:23:15 AndyS: the dataset description in the protocol parameters is not the dataset in the graph store 14:23:37 q+ to ask why dataset specification itself in update should update the graph store? 14:23:40 "That is, the GroupGraphPattern in the WHERE clause will be matched against the dataset described by explicit USING or USING NAMED clauses, if specified, and against the Graph Store otherwise." 14:24:45 LeeF: given that configuration of a system, how can you test protocol? 14:25:06 AndyS: you write a query with a GRAPH keyword in it 14:25:38 AexlPolleres: I tend to agree with Andy, we should not use test queries with USING and USING NAMED for protocol 14:26:28 LeeF: if you don't include dataset parameters in the protocol follow up query, the we fall back to what is the default dataset?, which is system-defined 14:26:44 ... because we left the actual meaning of USING/USING NAMED and FROM/FROM NAMED deliberately open, i.e. system-specific 14:28:33 LeeF: if we did update to ARQ, and we followed that up with query via the protocol without dataset specifications, but did have a graph clause that referenced the loaded graph URI, then that would test the state of the graph store? 14:28:36 AndyS: yes 14:28:58 zakim, who's on the phone? 14:28:58 On the phone I see MattPerry, AndyS, kasei, AxelPolleres, LeeF, Arthur_Keen, sandro, pgearon, cbuilara (muted) 14:28:59 LeeF: i don't see anything that will work for all systems 14:30:12 Matt: we do what ARQ/fuseki does 14:30:36 kasei: we do not allow update when cofigured to retrieve data from the web 14:31:01 Arthur_Keen: need to talk it over with our engineers 14:32:02 ... can we get a writeup on this? 14:33:27 no, I do not have a protocol implementation 14:34:23 LeeF: the problem is that different systems use different systems to check the state of the graph store 14:34:59 ... writing a validator for this is thus a problem 14:35:19 q+ to show a tricky case ... 14:35:26 ack AndyS 14:35:26 AndyS, you wanted to show a tricky case ... 14:35:29 ... maybe we should check failures by hand 14:35:59 AndyS: the worst case, the default graph is the UNION of all graphs 14:36:55 ArthurK has joined #sparql 14:37:12 kasei: I agree this is very hard to test. The protocol spec is very accepting 14:38:07 ack me 14:38:11 LeeF: I would like to avoid publishing any document that says implementation X failed these tests, but they were actually conforming 14:39:13 AndyS: in the query suite for 1.0, it wasn't possible to pass, there were tests with 2 anwers 14:39:27 s/anwers/answers 14:40:14 LeeF: how many tests are there 14:40:18 kasei: 30 total 14:40:30 kasei: 9 or 10 have this issue 14:42:04 LeeF: what if we hacked the validator to try each type of state checking query, and pass the test if one of the queries are successful 14:42:16 Update: LOAD at /ds/update Query to /ds/query GRAPH { ... } 14:42:38 kasei: it's possible, but I don't know if there is time to do it 14:42:58 LeeF: I think that is what we should try 14:43:37 AxelPolleres: do you suggest we span the whole possible space of interpretations 14:43:56 LeeF: right now we know of 2 prominent ways, so let's test those 14:45:32 LeeF: I think if we work with fuseki, that will cover a lot of implementations 14:45:39 haven't looked into details but am in general hesitant on testing things which are implementation dependent, rather than spanning up the whole space of possible solutions we should maybe not even eattempt to test those features (e.g. the graph specification parameters) 14:46:19 ok. 14:46:35 LeeF: cbuilara to look at protocol tests, kasei to work on hacking the validator, kasei and LeeF to investigate ARQ query issues 14:47:01 AndyS: I'm happy with this approach 14:47:28 kasei: I'm ok with it but time is short 14:47:47 topic: BIND comments 14:48:04 LeeF: Andy sent a summary email 14:48:16 http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JulSep/0123.html 14:48:54 LeeF: questions about scope issues related to BIND 14:49:44 ... LC3 said BGP is in scope, LG1 and LG2 said GGP is in scope 14:50:23 AndyS: expression side of the BIND is what gets affected 14:50:41 LeeF: are any tests affected by this 14:50:51 AndyS: no 14:51:19 kasei: I didn't change my implementation and the tests still passed 14:51:39 LeeF: does this proposal address the comments 14:51:43 AndyS: yes 14:52:25 q+ 14:52:31 ack AxelPolleres 14:52:31 AxelPolleres, you wanted to ask why dataset specification itself in update should update the graph store? and to 14:52:54 AxelPolleres: Steve said he recalled some issues with BIND and FILTERs 14:53:30 AndyS: what problems are there? 14:53:50 AxelPolleres: the BIND ends the group, does filter go before or after bind? 14:54:12 AndyS: you can always move filters outwards, so there is no issue with scope 14:54:36 AxelPolleres: maybe we should add more tests for this issue 14:55:03 AndyS: easy to make these changes in the spec 14:55:04 -cbuilara 14:55:28 LeeF: we have consensus on Andy's suggested change to BIND 14:56:30 +??P2 14:56:34 zakim, ??2 is me 14:56:34 sorry, cbuilara, I do not recognize a party named '??2' 14:56:36 zakim, mute me 14:56:36 sorry, cbuilara, I do not know which phone connection belongs to you 14:56:53 zakim, ??P2 is me 14:56:53 +cbuilara; got it 14:56:56 zakim, mute me 14:56:56 cbuilara should now be muted 14:57:15 ACTION: Andy to fix the LC3 spec as per the proposal in http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JulSep/0123.html 14:57:15 Created ACTION-673 - Fix the LC3 spec as per the proposal in http://lists.w3.org/Archives/Public/public-rdf-dawg/2012JulSep/0123.html [on Andy Seaborne - due 2012-08-28]. 14:58:00 -LeeF 14:58:01 -MattPerry 14:58:02 -sandro 14:58:02 -pgearon 14:58:04 -AndyS 14:58:06 -Arthur_Keen 14:58:08 -kasei 14:58:11 -cbuilara 14:58:26 I can volunteer to look into whether we want more test cases for BIND+FILTER 14:59:06 (might not get to it in the next 1 or two weeks, but will give myself an action... 14:59:39 ACTION: Axel to look into whether additional BIND+FILTERS test cases are needed 14:59:39 Created ACTION-674 - Look into whether additional BIND+FILTERS test cases are needed [on Axel Polleres - due 2012-08-28]. 15:00:14 rrsagent, make records public 15:04:55 -AxelPolleres 15:04:57 SW_(SPARQL)10:00AM has ended 15:04:57 Attendees were MattPerry, AndyS, kasei, AxelPolleres, LeeF, Arthur_Keen, sandro, cbuilara, pgearon 15:10:42 On first pass: No WG tests fail if I switch back to 2LC semantics for BIND (some of my internal tests do ... which is good really). Checking continues. 15:37:38 kasei - one of the update tests is confusing me. www.w3.org/2009/sparql/docs/tests/data-sparql11/delete/manifest.ttl#dawg-delete-using-02 15:39:07 The test comment is a bit odd : "to make sure the GRAPH clause overrides the USING clause" but it doesn't. USING sets the dataset : GRAPH can't go outside it. 15:40:07 related: #dawg-delete-using-06 15:45:29 As far as I can see, a form like "USING { GRAPH { ... } }" does not match - the USING defines a dataset with no named graph => GRAPH is a miss. 15:50:22 AndyS: I think only the comment in the manifest is wrong. the test looks fine to me. 15:51:00 We agree the comment is wrong ... the test seems to follow the comment though. 15:51:07 I see it as doing: 15:51:20 how? the datasets before and after are identical, no? 15:51:29 the update is a no-op. 15:51:52 Agree it's a no op - Lets look at dawg-delete-using-02 15:52:50 Input dft graph = delete-post-01.ttl != Output dft graph = delete-post-01s.ttl 15:54:00 oh. i missed the default graph in the dataset defn in the manifest. 15:54:03 hrmmmmm 15:54:42 Only these two tests seem to be affected. 15:55:47 how in the world is my impl passing this test!? 15:56:26 everyone seems to be passing it :\ 15:56:54 I don't have time to deal with this right now, but I agree something here is suspicious. 15:59:19 ditto here. I recall rewriting USING handling recently to make it cleaner (and efficient in the common case of no graph merge) but the point was not to address anything related to SPARQL Update tests. We must have both been letting the NGs through. 16:11:10 Shall i commit to email so it does not get lost? 16:53:29 SteveH__ has joined #sparql 17:12:12 AndyS: yes, that seems smart. 17:12:52 Will do. 17:13:18 I'm surprised 4 implementations all got it wrong. 17:13:47 well... surprised that we all got it wrong in the one way that would let the test pass! :) 17:27:19 Zakim has left #sparql 18:28:56 swh has joined #sparql 18:42:55 chimezie has joined #sparql 19:15:53 chimezie_ has joined #sparql 19:23:15 chimezie_ has joined #sparql 19:48:19 chimezie_ has joined #sparql 19:51:56 chimezie has joined #sparql 19:57:48 chimezie has joined #sparql 20:17:47 chimezie has joined #sparql 20:58:21 swh has joined #sparql 21:34:32 chimezie has joined #sparql 21:40:05 AndyS has joined #sparql 21:51:02 chimezie_ has joined #sparql 21:52:01 LeeF has joined #sparql 21:52:30 chimezie has joined #sparql 22:00:52 chimezie has joined #sparql 22:02:10 chimezie has joined #sparql 22:02:54 chimezie has joined #sparql 23:07:53 chimezie has joined #sparql 23:11:42 chimezie has joined #sparql