Warning:
This wiki has been archived and is now read-only.
Chatlog 2009-08-11
From SPARQL Working Group
See original RRSAgent log and preview nicely formatted version.
Please justify/explain all edits to this page, in your "edit summary" text.
13:47:31 <RRSAgent> RRSAgent has joined #sparql 13:47:31 <RRSAgent> logging to http://www.w3.org/2009/08/11-sparql-irc 13:47:33 <trackbot> RRSAgent, make logs world 13:47:33 <Zakim> Zakim has joined #sparql 13:47:35 <trackbot> Zakim, this will be 77277 13:47:35 <Zakim> ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 13 minutes 13:47:36 <trackbot> Meeting: SPARQL Working Group Teleconference 13:47:36 <trackbot> Date: 11 August 2009 13:47:40 <LeeF> Zakim, this will be sparql 13:47:40 <Zakim> ok, LeeF; I see SW_(SPARQL)10:00AM scheduled to start in 13 minutes 13:47:42 <LeeF> Chair: LeeF 13:47:45 <LeeF> Scribe: SimonS 13:47:47 <KjetilK> KjetilK has joined #sparql 13:47:47 <LeeF> Scribenick: SimonS 13:48:01 <LeeF> Regrets: IvanH, pgearon, AndyS 13:48:24 <LeeF> Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2009-08-11 13:48:30 <LeeF> LeeF has changed the topic to: Agenda - http://www.w3.org/2009/sparql/wiki/Agenda-2009-08-11 14:06:23 <LeeF> zakim, who's here? 14:06:23 <Zakim> On the phone I see kasei (muted), LeeF, SteveH, AlexPassant, john-l, AxelPolleres, kjetilk (muted), Orri, LukeWM, bglimm, Chimezie_Ogbuji (muted), SimonS, Prateek, iv_an_ru, EricP 14:06:26 <Zakim> On IRC I see Prateek, chimezie, bglimm, SimonS, KjetilK, Zakim, RRSAgent, LukeWM, AxelPolleres, SteveH, LeeF, karl, john-l, iv_an_ru, kjetil, AlexPassant, trackbot, kasei, ericP 14:07:00 <SimonS> LeeF: Topics for today are Aggregate design and discovering service descriptions 14:07:23 <LeeF> topic: admin 14:07:30 <LeeF> PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-08-04 14:07:53 <bglimm> +1 14:08:07 <LeeF> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-08-04 14:08:27 <LeeF> Next meeting: 2009-08-18 @ 15:00 BST / 10:00 EDT, SimonKJ to scribe 14:08:34 <bglimm> Next week I am on holiday 14:08:41 <LeeF> http://www.w3.org/2009/sparql/wiki/Vacation_List 14:08:51 <LeeF> regrets next week: bglimm, orri 14:09:42 <LeeF> wiki page for next F2F http://www.w3.org/2009/sparql/wiki/F2F2 14:10:08 <SimonS> LeeF: F2F 1st week of November in Santa Clara. 14:10:09 <SteveH> $50/day 14:10:52 <SimonS> ... Please indicate your attendance on the Wiki 14:11:10 <chimezie> Zakim, unmute me 14:11:10 <Zakim> Chimezie_Ogbuji should no longer be muted 14:11:29 <KjetilK> q+ 14:11:29 <chimezie> Good question, I don't know off head (will need to chew on that). 14:11:37 <chimezie> whoops 14:11:50 <SimonS> LeeF: SPARQL group meeting Monday and Tuesday. 14:12:06 <KjetilK> ack me 14:12:12 <LeeF> ack kjetilk 14:12:31 <SimonS> KjetilK: how about a split meeting with video conferencing? 14:12:36 <bglimm> +1 to KjetilK 14:12:39 <ericP> q+ to talk about challenges 14:12:44 <ericP> q- 14:12:53 <ericP> q+ to talk about tech challenges re: vid conf 14:13:05 <SimonS> LeeF: might be possible, but huge time difference, European side needs to host night owls. 14:13:36 <bglimm> I would fly just for the 2 days and the jet-lag would kill me, I rather stay up late here 14:13:45 <KjetilK> Zakim, mute me 14:13:45 <Zakim> kjetilk should now be muted 14:13:53 <bglimm> I could probably organize some video conferencing here 14:14:47 <SimonS> EricP: point of the meeting also is to interact with other groups, which means we need video conferencing on site, which is prohibitively expensive. 14:15:05 <SimonS> LeeF: Unlikely that we will have video conferencing. 14:15:19 <SimonS> ... phone will be available, though. 14:15:57 <SteveH> can we chivvy people to say whether they're going or not? 14:16:03 <SteveH> I have to decide soon 14:16:09 <iv_an_ru> Which Ivan? 14:16:13 <ericP> nothing new from HCLS or XQuery 14:16:15 <SimonS> topic: Liaisons 14:17:01 <SimonS> Orri: nothing new from RDB2RDF 14:17:14 <AxelPolleres> no news from RIF (teleconfs irregular, there is one today, so I will know more next week) 14:17:35 <SimonS> Orri: talk about it at the F2F. 14:17:42 <SimonS> topic: actions 14:17:39 <LeeF> open actions - http://www.w3.org/2009/sparql/track/actions/open 14:17:52 <LeeF> trackbot, close ACTION-66 14:17:52 <trackbot> ACTION-66 Draft aggregates closed 14:20:09 <AxelPolleres> 71 is done from my side in the sense that rif and rdb2rdf are informed. 14:20:07 <LeeF> topic: Aggregates 14:20:24 <LeeF> draft of aggregate design at http://www.w3.org/2009/sparql/wiki/Design:Aggregate 14:21:29 <SimonS> chimezie: First draft, some issues regarding sets vs multi-sets 14:21:39 <SimonS> ... do we need specific restrictions? 14:21:48 <SimonS> ... how to deal with DISTINCT? 14:21:55 <LeeF> open issues at http://www.w3.org/2009/sparql/wiki/Design:Aggregate#Status 14:22:22 <SimonS> ... seems we want to have variables associated with result of aggregates, so we always need AS 14:22:44 <SimonS> ... tried to describe algebra extension. 14:23:20 <SimonS> ... Start with groups function 14:23:56 <SimonS> ... starting with grouped variables. 14:24:39 <SimonS> ... function partitions takes solution set and extracts unique n-tuples, which are partitions of the solution set 14:24:51 <AxelPolleres> q+ to ask about whether bnodes should be considered nasty or not 14:25:15 <LeeF> ack ericp 14:25:16 <Zakim> ericP, you wanted to talk about tech challenges re: vid conf 14:25:20 <SimonS> ... Aggregation then computes the actual aggregate. 14:25:29 <SimonS> ... now need test cases 14:26:21 <AxelPolleres> ack me 14:26:21 <Zakim> AxelPolleres, you wanted to ask about whether bnodes should be considered nasty or not 14:26:59 <ericP> q+ to propose we stay with a graph semantics 14:27:02 <SimonS> AxelPolleres: Are BNodes in the solution set an issue? e.g. count is difficult, if BNodes are treated as existentials 14:27:13 <SimonS> ... most implementations treat them as constants, though. 14:27:56 <bglimm> I agrre in that blank nodes in our reasoner (OWL direct semantics) are not the same as constants 14:28:00 <SimonS> Orri: We treat them as constants, sometimes owl:sameAs semantics is applied 14:28:06 <LeeF> ack ericP 14:28:06 <Zakim> ericP, you wanted to propose we stay with a graph semantics 14:28:26 <SimonS> EricP: Language should stay a graph based language. 14:28:31 <AxelPolleres> similar with "!=" which is currently "not known to be equal" 14:29:14 <SimonS> LeeF: treat as in equals in filters 14:29:25 <SimonS> ... might need to look at this again for entailment regimes. 14:29:38 <LeeF> ISSUE: How do other entailment regimes interact with aggregate grouping vis a vis blank nodes? 14:29:38 <trackbot> Created ISSUE-34 - How do other entailment regimes interact with aggregate grouping vis a vis blank nodes? ; please complete additional details at http://www.w3.org/2009/sparql/track/issues/34/edit . 14:30:25 <SimonS> Orri: Guess, you can do expressions of aggregates 14:31:46 <LeeF> for the record, extensibility of aggregate functions is an open issue http://www.w3.org/2009/sparql/track/issues/15 14:31:48 <SimonS> ... are user defined aggregates in scope, but we might need syntax restrictions? 14:32:18 <SimonS> LeeF: we already have issue for extensions in aggregate functions 14:32:22 <ericP> am fiddling with grammar (has S/R errors) -- http://www.w3.org/2005/01/yacker/uploads/SPARQL_Aggregate?lang=perl 14:32:22 <Zakim> -SimonS 14:32:59 <Zakim> +??P30 14:33:08 <SimonS> Zakim, ??P30 is me 14:33:08 <Zakim> +SimonS; got it 14:33:46 <LeeF> LeeF: can aggregate functions take multiple arguments? 14:34:00 <LeeF> Chimezie: As long as all variables are part of gorup keys, should be ok, not sure if SQL aggregate functions do this at all 14:34:05 <LeeF> Orri: there are a few like diverse_regression 14:34:37 <ericP> ok, no S/Rs in http://www.w3.org/2005/01/yacker?name=SPARQL_Aggregate&replace=1&lang=perl 14:35:11 <SimonS> chimezie; issues with multi sets. Do not require uniqueness. however, Aggregates do for partitioning. 14:35:49 <SimonS> EricP: Algebra does not have ordering, but aggregates need them. Current algebra should work. 14:35:58 <SimonS> Orri: Why do aggregates require ordering? 14:36:09 <SimonS> EricP: Not always, but might make sense. 14:36:28 <chimezie> SteveH did have an example on the SubSelect design wiki asking about ordering and aggregation (working together) 14:36:35 <SimonS> Orri: For user defined aggregates we have a flag for that, but usually it is not neccessary. 14:36:58 <SimonS> ... should not be an issue, if we do not specify extension syntax 14:37:18 <LeeF> q? 14:37:35 <SimonS> iv_an_ru: also benefits for parallelization then. 14:37:51 <chimezie> Zakim, who is here? 14:37:51 <Zakim> On the phone I see kasei (muted), LeeF, SteveH, AlexPassant, john-l, AxelPolleres, kjetilk (muted), Orri, LukeWM, bglimm, Chimezie_Ogbuji, Prateek, iv_an_ru, EricP, SimonS 14:37:55 <Zakim> On IRC I see Prateek, chimezie, bglimm, SimonS, KjetilK, Zakim, RRSAgent, LukeWM, AxelPolleres, SteveH, LeeF, karl, john-l, iv_an_ru, kjetil, AlexPassant, trackbot, kasei, ericP 14:38:20 <SimonS> LeeF: do we need test case, that needs ordering? 14:38:30 <SimonS> EricP: same as for SubSelect. 14:38:48 <SimonS> LeeF: Last week we had consensus to discard ordering for subqueries. 14:39:12 <SimonS> Orri: ORDER BY allowed? 14:39:37 <SimonS> LeeF: yes, needed for slicing for example, but when combined with parent query, order is lost. 14:40:07 <SimonS> LeeF: what specific aggregate functions to include? 14:40:10 <AxelPolleres> any slicing in subqueries potentially introduces non-determinism, but well, I guess that was discussed? 14:40:17 <SimonS> ... discuss tios on the mailing list. 14:40:19 <ericP> chimezie, do you know of a grammar proposal for SELECT ?foo AS ?bar which i could inject tinot the SPARQL_Aggregate grammar? 14:40:46 <SimonS> LeeF: How to apply REDUCED / DISTINCT? Afterwards? 14:41:04 <SimonS> chimezie: if done afterwards, everything should be fine. 14:41:05 <ericP> ahh, it was in your proposal 14:41:14 <SimonS> Orri: grouped columns are distinct anyway. 14:42:01 <SimonS> Orri: Can we have DISTINCT in aggregate expressions? 14:42:16 <SimonS> ... e.g. SELECT COUNT(DISTINCT ?X) 14:42:33 <LeeF> ISSUE: Can aggregate functions take DISTINCT as an argument a la SELECT COUNT(DISTINCT ?X)? 14:42:33 <trackbot> Created ISSUE-35 - Can aggregate functions take DISTINCT as an argument a la SELECT COUNT(DISTINCT ?X)? ; please complete additional details at http://www.w3.org/2009/sparql/track/issues/35/edit . 14:42:55 <LukeWM> q+ to ask about HAVING 14:43:13 <LeeF> ack LukeWM 14:43:13 <Zakim> LukeWM, you wanted to ask about HAVING 14:43:34 <SimonS> LukeWM: does HAVING cause issues? 14:43:43 <SimonS> Orri: HAVING is save. 14:44:02 <SimonS> ... can be done in nested query. 14:44:06 <LeeF> q? 14:44:43 <kasei> we had talked earlier about using FILTER instead of HAVING (not introducing new terms for roughly the same thing) 14:44:53 <SteveH> yes, reusing FILTER would makesense 14:45:06 <SimonS> chimezie: should be easy to add to the proposal for completeness' sake. 14:45:46 <LeeF> ACTION: Chimezie to continue forward with aggregates w.r.t test cases, HAVING/FILTER clause, ISSUE-35, ... 14:45:46 <trackbot> Created ACTION-79 - Continue forward with aggregates w.r.t test cases, HAVING/FILTER clause, ISSUE-35, ... [on Chimezie Ogbuji - due 2009-08-18]. 14:46:23 <LeeF> topic: service description 14:47:22 <LeeF> -> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0139.html 14:47:26 <SimonS> LeeF: Most important question is discovery mechanism. We have >= 8 proposals. 14:48:54 <SimonS> ... drop proposal 3 - Well known location. 14:49:02 <SimonS> ... general agreement on this. 14:49:23 <SimonS> ... drop 5 - Query as well. 14:49:31 <AxelPolleres> is "DESCRIBE <.>" also meant as a suboption of Opt 4? 14:49:42 <SimonS> ... EricP likes it, but noone else. 14:50:32 <SimonS> ... some objections to 6: prefer discovery via the endpoint instead of via the query. 14:52:07 <ericP> chimezie, http://tinyurl.com/SPARQL-sum shows that your example query works with the grammar you supplied (modulo AggregateFunc which I added) 14:52:16 <SimonS> ... issue with option 7 without conneg is that existing implementations might have webpages at endpoint URI 14:52:38 <SimonS> ... proposal 8: do get with some special operation 14:52:43 <chimezie> ericP: thanks 14:53:00 <ericP> feel free to fiddle with the grammar 14:53:10 <ericP> (note [Edit this grammar]) 14:53:11 <SimonS> ... is anyone NOT happy with using an approach based on the endpoint rather than the query? 14:53:18 <kasei> eh 14:53:56 <kasei> Zakim, unmute me 14:53:56 <Zakim> kasei should no longer be muted 14:54:10 <SimonS> EricP: might be nice to be able to query endpoint descriptions, but could solve that differently. 14:54:46 <AxelPolleres> q+ 14:54:47 <SimonS> kasei: favors conneg 14:55:08 <LukeWM> np 14:55:17 <kasei> Zakim, mute me 14:55:17 <Zakim> kasei should now be muted 14:55:21 <LeeF> ack AxelPolleres 14:55:34 <SimonS> AxelPolleres: What was objection to option 4? 14:55:53 <SimonS> LeeF: restricts possible datasets and URIs 14:55:59 <kasei> and that describe doesn't always return the same things... 14:56:02 <ericP> q+ to ask how i find for instance, what VoID description it has in opt 4 14:56:21 <SimonS> LeeF: same for DESCRIBE <> as it is just a shortcut 14:56:28 <LeeF> ack ericP 14:56:28 <Zakim> ericP, you wanted to ask how i find for instance, what VoID description it has in opt 4 14:57:12 <SteveH> you can still do FROM <endpoint> .... on stores that support it 14:57:13 <SimonS> EricP: that also means optimization becomes more difficult than just serving a void description. 14:57:39 <SimonS> Orri: You would usually ask for the whole graph once. 14:58:20 <SimonS> EricP: imagine void, void* etc, so guessing the best representation is a burden on the endpoint 14:59:36 <SimonS> Orri: don't want to do many round trips with lots of short queries. Retrieve full description once, then do postprocessing locally. 14:59:59 <SimonS> EricP: But we might be interested in certain aspects of the description only. 15:00:09 <AxelPolleres> q+ to ask about the relative or absolute description in the protocol based options 15:00:22 <kasei> ericP's point, I think, supports conneg or a simple GET mechanism so that you *could* point a SPARQL query at the SD if you wanted. 15:00:24 <LeeF> zakim, close the queue 15:00:24 <Zakim> ok, LeeF, the speaker queue is closed 15:01:01 <SimonS> Orri: We might say in the void description that the description is queryable, and where. 15:01:24 <LeeF> ack AxelPolleres 15:01:24 <Zakim> AxelPolleres, you wanted to ask about the relative or absolute description in the protocol based options 15:02:07 <SimonS> AxelPolleres: option 1 is just about returning a link to the service description, i.e. two GETs are neccessary, while the others are one GET only. 15:02:13 <SimonS> LeeF: that is right. 15:02:32 <AxelPolleres> 2 GETs for getting to the service description seems a bit awkward to me, personally. 15:02:59 <LeeF> PROPOSED: Service description discovery should be based on an operation performed against a SPARQL endpoint, ruling out options 3,4,5,6 in http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0139.html 15:03:51 <AxelPolleres> need to get something clear: does it mean we agree that QUERYING the service description should NOT necessarily be allowed on the very endpoint? 15:04:02 <Zakim> -iv_an_ru 15:04:22 <SimonS> I'd say not required. 15:04:43 <SteveH> to be convinced I'd need to be shown that it works, not that it meets some usecases 15:05:03 <SimonS> EricP: Could do use cases for querying. Would that be worth while? 15:05:13 <SteveH> you can still do FROM <endpoint> .... on stores that support it 15:05:30 <SimonS> Orri: Propose to include in the endpoint based description link to the queryable version 15:06:18 <kasei> option 7 gives you queryability for free with a FROM clause. 15:07:03 <SimonS> LeeF: discussion closed, please continue on the mailing list. Continue discussion next week 15:07:10 <LeeF> ACTION: Orri to send a compromise proposal to the mailing list 15:07:11 <trackbot> Created ACTION-80 - Send a compromise proposal to the mailing list [on Orri Erling - due 2009-08-18]. 15:07:44 <Zakim> -Chimezie_Ogbuji 15:07:44 <LeeF> Adjourned. # SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000325