Chatlog 2012-08-21

From SPARQL Working Group
Jump to: navigation, search

See original RRSAgent log and preview nicely formatted version.

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

13:59:22 <RRSAgent> RRSAgent has joined #sparql
13:59:22 <RRSAgent> logging to
13:59:24 <trackbot> RRSAgent, make logs world
13:59:24 <Zakim> Zakim has joined #sparql
13:59:26 <trackbot> Zakim, this will be 77277
13:59:26 <Zakim> ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 1 minute
13:59:27 <trackbot> Meeting: SPARQL Working Group Teleconference
13:59:28 <trackbot> Date: 21 August 2012
13:59:40 <Zakim> SW_(SPARQL)10:00AM has now started
13:59:47 <Zakim> +MattPerry
13:59:55 <AxelPolleres> agenda:
14:00:10 <Zakim> +??P1
14:00:13 <AndyS> zakim, ??P1 is me
14:00:13 <Zakim> +AndyS; got it
14:00:22 <LeeF> LeeF has joined #sparql
14:00:27 <AndyS> zakim, who is on the phone?
14:00:27 <Zakim> On the phone I see MattPerry, AndyS
14:00:37 <LeeF> trackbot, start meeting
14:00:39 <Zakim> +kasei
14:00:39 <trackbot> RRSAgent, make logs world
14:00:41 <trackbot> Zakim, this will be 77277
14:00:41 <Zakim> ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start now
14:00:42 <trackbot> Meeting: SPARQL Working Group Teleconference
14:00:42 <trackbot> Date: 21 August 2012
14:00:43 <LeeF> oops
14:00:45 <LeeF> late to the party
14:00:50 <LeeF> zakim, this is sparql
14:00:50 <Zakim> ok, LeeF; that matches SW_(SPARQL)10:00AM
14:01:12 <AxelPolleres> Zakim, who is on the phone?
14:01:12 <Zakim> On the phone I see MattPerry, AndyS, kasei, AxelPolleres
14:01:15 <Zakim> +LeeF
14:01:25 <LeeF> Chair: LeeF
14:01:46 <LeeF> Agenda:
14:01:55 <Zakim> +Arthur_Keen
14:01:56 <Zakim> +sandro
14:02:38 <LeeF> zakim, who's on the phone?
14:02:38 <Zakim> On the phone I see MattPerry, AndyS, kasei, AxelPolleres, LeeF, Arthur_Keen, sandro
14:02:42 <cbuilara> cbuilara has joined #sparql
14:03:05 <AxelPolleres> matt, you mentioned you can scribe this week last time? (/me can do otherwise)
14:03:15 <MattPerry> sure, I can scribe
14:03:28 <AxelPolleres> scribe: MattPerry
14:03:36 <LeeF> topic: Admin
14:03:36 <Zakim> +??P10
14:03:41 <LeeF> PROPOSED: Approve the minutes from last week at
14:03:44 <cbuilara> zakim, ??P10 is me
14:03:44 <Zakim> +cbuilara; got it
14:03:47 <cbuilara> zakim, mute me
14:03:47 <Zakim> cbuilara should now be muted
14:04:06 <Zakim> +pgearon
14:04:18 <AndyS> +1 to minutes
14:04:27 <LeeF> RESOLVED: Approve the minutes from last week at
14:04:41 <Zakim> -cbuilara
14:04:47 <MattPerry> LeeF: any comments from RDF WG
14:05:00 <MattPerry> AndyS: No, not yet. They are meeting this week
14:06:18 <MattPerry> topic: Actions from last week
14:06:55 <MattPerry> LeeF: Carlos' Action to look at protocl tests?
14:06:57 <LeeF> cbuilara, have you had a chance yet to look at the protocol tests for completeness?
14:07:13 <cbuilara> no, sorry
14:07:20 <LeeF> ok
14:07:45 <MattPerry> LeeF: Greg & Sandro, did we get the validator moved?
14:07:46 <AndyS> I tried the tests -- still an issue with the singe endpoint for hosted and web data.
14:07:48 <cbuilara> I will look ointo the tests this week
14:07:49 <LeeF> forwards
14:07:53 <LeeF> ok, great cbuilara
14:08:07 <MattPerry> LeeF: anything else on protocol tests
14:08:35 <MattPerry> kasei: No, I've made progress on ARQ testing, so I'm willing to open it up
14:08:47 <MattPerry> AndyS: what about overloading one endpoint to 2 services
14:09:00 <Zakim> +??P17
14:09:07 <cbuilara> zakim, ??P17 is me
14:09:07 <Zakim> +cbuilara; got it
14:09:16 <MattPerry> ... some cases require data in the endpoint, some don't
14:09:31 <cbuilara> ok
14:09:43 <cbuilara> zakim, mute me
14:09:43 <Zakim> cbuilara should now be muted
14:09:51 <MattPerry> s/cases/tests
14:10:21 <MattPerry> kasei: as written, all of them should work with data in the endpoint, but ARQ doesn't work that way
14:10:37 <MattPerry> ... it may be hard to make it work with all implementations
14:11:03 <MattPerry> AndyS: can we have 2 endpoints in the tests, one for each case?
14:11:41 <MattPerry> kasei: the validator attempts to load the data before running the tests
14:12:06 <MattPerry> AndyS: can you point to spec tests to confirm that interpretation
14:12:31 <MattPerry> kasei: this is a case where an implementation has some freedom
14:13:21 <MattPerry> LeeF: you use SPARQL update to load the data?
14:13:25 <MattPerry> kasei: yes
14:13:39 <AndyS> q+
14:14:03 <MattPerry> ... For update tests, it won't work
14:14:19 <MattPerry> LeeF: Andy, how would you want to see such a test written?
14:14:41 <MattPerry> AndyS: there are two kinds of endpoints: those that host the data and those that get it from the web
14:15:14 <MattPerry> ... For fuseki, if it's hosted data you cannot retieve data from the web
14:16:07 <MattPerry> ... the update tests run tests for both kinds on the same endpoint
14:16:28 <MattPerry> ... doing the update assumes the data is local to the host
14:16:46 <MattPerry> ... so specifying protocol parameters don't make sense
14:17:00 <MattPerry> LeeF: for systems that pass the tests it makes sense
14:18:05 <MattPerry> ... we are trying to test SPARQL update part of the protocol? correct?
14:18:15 <MattPerry> kasei: some tests may be for query
14:18:30 <MattPerry> ... I don't know of an alternative for testing
14:19:06 <MattPerry> AndyS: update is specified using GRAPH URI and NAMED GRAPH URI is referring to local dataset
14:19:25 <MattPerry> ... for query, it does not necessarily refer to the local dataset
14:19:34 <AndyS> using-graph-uri=  &  using-named-uri=
14:21:43 <MattPerry> AndyS: you make an update and then you query that dataset. The protocol parameters change the dataset
14:22:10 <MattPerry> LeeF: the assumption is that you update the graph store and the dataset is the state of the graph store
14:22:44 <MattPerry> ... you update and the the query that follows tests the state of the graph store,
14:23:15 <MattPerry> AndyS: the dataset description in the protocol parameters is not the dataset in the graph store
14:23:37 <AxelPolleres> q+ to ask why dataset specification itself in update should update the graph store?
14:23:40 <AxelPolleres> "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 <MattPerry> LeeF: given that configuration of a system, how can you test protocol?
14:25:06 <MattPerry> AndyS: you write a query with a GRAPH keyword in it
14:25:38 <MattPerry> AxelPolleres: I tend to agree with Andy, we should not use test queries with USING and USING NAMED for protocol
14:26:28 <MattPerry> 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 <AxelPolleres> ... because we left the actual meaning of USING/USING NAMED and FROM/FROM NAMED deliberately open, i.e. system-specific
14:28:33 <MattPerry> 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 <MattPerry> AndyS: yes
14:28:58 <LeeF> zakim, who's on the phone?
14:28:58 <Zakim> On the phone I see MattPerry, AndyS, kasei, AxelPolleres, LeeF, Arthur_Keen, sandro, pgearon, cbuilara (muted)
14:28:59 <MattPerry> LeeF: i don't see anything that will work for all systems
14:30:12 <MattPerry> Matt: we do what ARQ/fuseki does
14:30:36 <MattPerry> kasei: we do not allow update when cofigured to retrieve data from the web
14:31:01 <MattPerry> Arthur_Keen: need to talk it over with our engineers
14:32:02 <MattPerry> ... can we get a writeup on this?
14:33:27 <cbuilara> no, I do not have a protocol implementation
14:34:23 <MattPerry> LeeF: the problem is that different systems use different systems to check the state of the graph store
14:34:59 <MattPerry> ... writing a validator for this is thus a problem
14:35:19 <AndyS> q+ to show a tricky case ...
14:35:26 <LeeF> ack AndyS
14:35:26 <Zakim> AndyS, you wanted to show a tricky case ...
14:35:29 <MattPerry> ... maybe we should check failures by hand
14:35:59 <MattPerry> AndyS: the worst case, the default graph is the UNION of all graphs
14:36:55 <ArthurK> ArthurK has joined #sparql
14:37:12 <MattPerry> kasei: I agree this is very hard to test. The protocol spec is very accepting
14:38:07 <AndyS> ack me
14:38:11 <MattPerry> LeeF: I would like to avoid publishing any document that says implementation X failed these tests, but they were actually conforming
14:39:13 <MattPerry> AndyS: in the query suite for 1.0, it wasn't possible to pass, there were tests with 2 anwers
14:39:27 <MattPerry> s/anwers/answers
14:40:14 <MattPerry> LeeF: how many tests are there
14:40:18 <MattPerry> kasei: 30 total
14:40:30 <MattPerry> kasei: 9 or 10 have this issue
14:42:04 <MattPerry> 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 <AndyS> Update, LOAD <foo> at /ds/update    Query to /ds/query  GRAPH <foo> { ... }
14:42:38 <MattPerry> kasei: it's possible, but I don't know if there is time to do it
14:42:58 <MattPerry> LeeF: I think that is what we should try
14:43:37 <MattPerry> AxelPolleres: do you suggest we span the whole possible space of interpretations
14:43:56 <MattPerry> LeeF: right now we know of 2 prominent ways, so let's test those
14:45:32 <MattPerry> LeeF: I think if we work with fuseki, that will cover a lot of implementations
14:45:39 <AxelPolleres> 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 <AxelPolleres> ok.
14:46:35 <MattPerry> 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 <MattPerry> AndyS: I'm happy with this approach
14:47:28 <MattPerry> kasei: I'm ok with it but time is short
14:47:47 <MattPerry> topic: BIND comments
14:48:04 <MattPerry> LeeF: Andy sent a summary email
14:48:16 <LeeF>
14:48:54 <MattPerry> LeeF: questions about scope issues related to BIND
14:49:44 <MattPerry> ... LC3 said BGP is in scope, LG1 and LG2 said GGP is in scope
14:50:23 <MattPerry> AndyS: expression side of the BIND is what gets affected
14:50:41 <MattPerry> LeeF: are any tests affected by this
14:50:51 <MattPerry> AndyS: no
14:51:19 <MattPerry> kasei: I didn't change my implementation and the tests still passed
14:51:39 <MattPerry> LeeF: does this proposal address the comments
14:51:43 <MattPerry> AndyS: yes
14:52:25 <AxelPolleres> q+
14:52:31 <LeeF> ack AxelPolleres
14:52:31 <Zakim> AxelPolleres, you wanted to ask why dataset specification itself in update should update the graph store? and to 
14:52:54 <MattPerry> AxelPolleres: Steve said he recalled some issues with BIND and FILTERs
14:53:30 <MattPerry> AndyS: what problems are there?
14:53:50 <MattPerry> AxelPolleres: the BIND ends the group, does filter go before or after bind?
14:54:12 <MattPerry> AndyS: you can always move filters outwards, so there is no issue with scope
14:54:36 <MattPerry> AxelPolleres: maybe we should add more tests for this issue
14:55:03 <MattPerry> AndyS: easy to make these changes in the spec
14:55:04 <Zakim> -cbuilara
14:55:28 <MattPerry> LeeF: we have consensus on Andy's suggested change to BIND
14:56:30 <Zakim> +??P2
14:56:34 <cbuilara> zakim, ??2 is me
14:56:34 <Zakim> sorry, cbuilara, I do not recognize a party named '??2'
14:56:36 <cbuilara> zakim, mute me
14:56:36 <Zakim> sorry, cbuilara, I do not know which phone connection belongs to you
14:56:53 <cbuilara> zakim, ??P2 is me
14:56:53 <Zakim> +cbuilara; got it
14:56:56 <cbuilara> zakim, mute me
14:56:56 <Zakim> cbuilara should now be muted
14:57:15 <LeeF> ACTION: Andy to fix the LC3 spec as per the proposal in
14:57:15 <trackbot> Created ACTION-673 - Fix the LC3 spec as per the proposal in [on Andy Seaborne - due 2012-08-28].
14:58:00 <Zakim> -LeeF
14:58:01 <Zakim> -MattPerry
14:58:02 <Zakim> -sandro
14:58:02 <Zakim> -pgearon
14:58:04 <Zakim> -AndyS
14:58:06 <Zakim> -Arthur_Keen
14:58:08 <Zakim> -kasei
14:58:11 <Zakim> -cbuilara
14:58:26 <AxelPolleres> I can volunteer to look into whether we want more test cases for BIND+FILTER
14:59:06 <AxelPolleres> (might not get to it in the next 1 or two weeks, but will give myself an action...
14:59:39 <AxelPolleres> ACTION: Axel to look into whether additional BIND+FILTERS test cases are needed
14:59:39 <trackbot> Created ACTION-674 - Look into whether additional BIND+FILTERS test cases are needed [on Axel Polleres - due 2012-08-28].
15:00:14 <AxelPolleres> rrsagent, make records public