Warning:
This wiki has been archived and is now read-only.
Chatlog 2009-06-02
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.
<LeeF> Present: LeeF, AndyS, Chimezie, john-l, pgearon, kasei, EricP, Orri, SteveH, LukeWM, Prateek, Birte, SimonS, ivanh, Alex, Kjetil, Axel 13:56:15 <trackbot> Meeting: SPARQL Working Group Teleconference 13:56:16 <trackbot> Date: 02 June 2009 14:01:09 <LeeF> Chair: LeeF 14:01:14 <LeeF> Scribenick: Chimezie 14:07:11 <chimezie> Topic: Admin 14:06:54 <LeeF> Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2009-06-02 14:07:15 <LeeF> PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-05-26 14:07:26 <AxelPolleres> +1 14:07:42 <LeeF> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-05-26 14:08:15 <AlexPassant> indeed :) 14:08:21 <chimezie> LeeF: Others able to make next meeting? 14:08:35 <kasei> I'll be travelling next week. Will probably make it, but possibly not. 14:08:42 <LeeF> regrets next week: ivanh, AlexPassant 14:09:09 <LeeF> scribe next week: Yimin (Kjetil on deck) 14:09:58 <chimezie> LeeF: No significant progress on actions/issues to warrant going over 14:10:10 <pgearon> +q 14:10:11 <chimezie> ... sent an email with outline for progress 14:10:21 <chimezie> ... reach concensus on update and how to scope/phase it 14:10:50 <KjetilK> q+ 14:11:11 <KjetilK> ack pgearon 14:11:41 <pgearon> http://www.w3.org/2009/sparql/track/actions/22 14:11:49 <chimezie> KjetilK: Nothing written up for ACTION item #22 (issues with subqueries and ??HAVING?? clause) 14:12:04 <LeeF> ACTION-22: pgearon unable to find any queries with an issue 14:12:04 <trackbot> ACTION-22 Write a subquery to be executed in a having clause that causes execution order problems for the list notes added 14:12:05 <chimezie> ... no red flags. Anyone else see issue with this 14:12:32 <LeeF> trackbot, close ACTION-22 14:12:33 <trackbot> ACTION-22 Write a subquery to be executed in a having clause that causes execution order problems for the list closed 14:12:52 <LeeF> ack kjetilk 14:13:04 <AxelPolleres> AxelPolleres has joined #sparql 14:13:18 <chimezie> Kjetil: It is a bit difficult to write queries for aggregate functions. Should we discuss this soon? 14:13:25 <chimezie> ... (which aggregate functions will we do) 14:13:39 <AndyS> q+ 14:13:44 <chimezie> LeeF: To early to resolve which aggregates we will use 14:13:59 <chimezie> ... best to write a general description of ability in features document 14:14:46 <chimezie> Orri: we already have user-specified aggregates 14:15:14 <LeeF> ack AndyS 14:15:16 <chimezie> AndyS: will it help to pick one we are certain to do? 14:15:27 <chimezie> kjetil: That would be helpful, yes 14:16:03 <AndyS> If we don't do COUNT(*), I will be very surprised. 14:16:07 <AxelPolleres> I agree that "count" is safe enough and we just mention that this is just one example 14:17:15 <chimezie> LeeF: Features & rational document goal is still to have a first draft by next week 14:17:55 <chimezie> ... WD is a necessary first step 14:18:28 <AxelPolleres> LeeF: FPWD of F&R is a necessary step in the ongoing re-chartering process. 14:18:48 <chimezie> Kjetil: First working draft should be bad enough to 'scare' out comments 14:19:56 <chimezie> Topic: Update 14:20:27 <chimezie> LeeF: Last week was focused on usecases, this week we should go over concrete proposals 14:21:03 <chimezie> ... spectrum from update language (proper) - with and without WHERE clause 14:21:15 <chimezie> ... to usecases that are aware of a proper RDF dataset 14:21:49 <chimezie> ... not much support for single-graph update language. Support for direct HTTP interaction with SPARQL service (PUT/POST, etc..) 14:22:43 <chimezie> ... support for protocol take update query strings via various HTTP verbs 14:23:38 <AndyS> Good summary 14:23:57 <chimezie> LeeF: rough consensus on doing these things, but worrysome if we do all 14:24:27 <SteveH> q+ to talk about +/- WHERE 14:24:50 <AndyS> ack SteveH 14:24:50 <Zakim> SteveH, you wanted to talk about +/- WHERE 14:25:15 <chimezie> SteveH: although usecases require WHERE, this is something we can drop using ASK queries initially prior to an update operation 14:25:25 <AndyS> (bnodes) 14:25:41 <chimezie> LeeF: Including WHERE in UL gives ability determine conditions on update 14:25:50 <KjetilK> q+ to ask about DELETE 14:26:02 <LukeWM> q+ to ask about doing less in language & more in protocol 14:26:38 <LeeF> ack kjetil 14:26:38 <Zakim> KjetilK, you wanted to ask about DELETE 14:26:41 <chimezie> AndyS: Might end up codifying weird URI schemes to handle BnNodes 14:26:54 <chimezie> kjetil: we can do most of what we need now w/out WHERE support in UL (update language) 14:27:01 <AxelPolleres> q+to ask whether steve meant with intermediate COSNTRUCTing temporary graphs? 14:27:06 <chimezie> ... not sure how we can do w/out it in a DELETE operation 14:27:57 <chimezie> AndyS: CONSTRUCT can be used prior to DELETE initially 14:28:08 <chimezie> PATCH? 14:28:09 <SteveH> what would DELETE FROM <a> { ?x a foaf:Person } mean? 14:28:11 <LeeF> ack LukeWM 14:28:11 <Zakim> LukeWM, you wanted to ask about doing less in language & more in protocol 14:28:27 <chimezie> LukeWM: How much time will be saved by doing less in UL and more in the protocol 14:28:28 <AndyS> How commonly supported is PATCH? 14:28:40 <chimezie> Not very, I don't think (unfortunately) 14:28:47 <AxelPolleres> q- 14:28:52 <SteveH> Suported by HTTP libraries, or servers? 14:28:52 <KjetilK> q+ 14:29:00 <chimezie> LeeF: Gut reaction is that it is same amount of work 14:29:35 <chimezie> I'm not so sure it is the same amount of work, since in one case (in the protocol) you have precedent for the semantics of operations 14:29:48 <AndyS> Quick google suggests it's new and not supported much. Draft expired July 2008. 14:30:43 <SteveH> major echo 14:31:39 <chimezie> LeeF: does an UL w/out a WHERE language save us much? 14:31:47 <chimezie> AndyS: Not much , but it does save *some* effort 14:31:48 <ericP> i'd say it saves very little work 14:32:06 <chimezie> ... but marginal. 14:32:31 <chimezie> ... biggest work area is a formalization of a model of multiple graphs (where does that fit in REST?) 14:33:05 <chimezie> AndyS: Perhaps best to at least try to start early 14:33:12 <ericP> i propose that we do SPARQUL first, and call UL protocol at risk 14:33:30 <chimezie> I'm not so sure I understand the relationship between datasets and REST perhaps some elaboration? 14:34:02 <chimezie> ... There are definately usecases that are not covered by protocol. Concerned about putting all effort in protocol 14:34:41 <chimezie> AndyS: A lot of REST relies on particular ways of using URIs for addressing sub-resources 14:35:07 <chimezie> ... how can a service expose itself such that its components can be acted upon. Don't have a way of naming subgraphs 14:35:09 <LeeF> q? 14:35:16 <KjetilK> ack me 14:35:17 <SteveH> PUT http://endpoint/rest/?graph=http://foo.com 14:35:32 <AxelPolleres> q+ 14:35:57 <chimezie> Generally? plenty of precedent. 14:36:23 <pgearon> I agree with ericP that it might make sense to put the protocol "at risk", but there still seems to be a number of people interested in the protocol. Maybe those who are interested should get together for a note? 14:37:03 <chimezie> AndyS: Can PUT/DELETE graphs but still have problem with parts of graphs 14:37:17 <chimezie> Certainly addresdsing subgraphs is problematic for a 'pure' protocol approach 14:37:45 <chimezie> but this is an example of an area where the UL takes care of what the protocol can't do intuitively, but these considerations should be considered 14:38:42 <chimezie> SteveH: We may get more comments if we don't desribe a RESTful approach 14:38:59 <chimezie> AndyS: Perhaps we simply describe a mapping from the UL to the protocol 14:39:05 <chimezie> ... an informative mapping 14:39:42 <ericP> chimezie: if you can't address part of the resource you're trying to update, ... 14:39:54 <ericP> ... i makes more sense in the language 14:40:34 <chimezie> AndyS: perhaps create the UL first and come abgck to this issue? Or create 2 task forces? 14:40:41 <SteveH> how about define what datasets are, then have two taskforces? 14:41:25 <chimezie> SteveH: Share issues with timescales and divergence. We avoided definition of *what* a dataset is. If we define this perhaps this is the starting point for two efforts? 14:42:21 <AndyS> SPARQL/Update very carefully talks about a graph store, not dataset to allow them to be subtly different. 14:42:34 <SteveH> ok, sorry AndyS :) 14:42:55 <chimezie> AxelPolleres: Should we identify restrictions up front ? 14:43:59 <chimezie> LeeF: consensus to do SPARUL w/out limitations upfront and then take a protocol approach as well. Not clear that these are mutually exclusive paradigms or how we coordinate these two approaches 14:44:35 <AxelPolleres> We seem to guess where we can cut/whereas any of the proposed phasing doesn't seem to work for all use cases mentioned so far. 14:45:09 <chimezie> ... but are there things that can be done RESTfully but not easily in UL 14:45:11 <AndyS> q+ to express REST hopes 14:45:21 <AxelPolleres> q- 14:45:34 <LukeWM> q+ 14:45:48 <LeeF> ack AndyS 14:45:48 <Zakim> AndyS, you wanted to express REST hopes 14:45:57 <chimezie> AndyS: Nice thing about REST is deployability on standard servers 14:46:16 <chimezie> q+ 14:46:25 <KjetilK> +1 to AndyS point 14:46:40 <chimezie> LukeWM: No clear usecase of where you can do one via REST but not via the protocol 14:47:02 <LeeF> s/via the protocol/via the update language -- i think? 14:47:37 <LeeF> ack chimezie 14:47:40 <LeeF> ack LukeWM 14:47:41 <SteveH> the curl as a sparql client usecase 14:48:17 <LeeF> chimezie: as we develop SPARQL/Update language, take a look at HTTP and see if there's precedent and specifications that give us a way to do it RESTfully - make sure there's harmony between SPARQL/Update & HTTP 14:48:38 <AxelPolleres> chime: start with the language and then have a look of which patr of it can fit in the RESTful approach 14:48:53 <AxelPolleres> (+1 to chime on that) 14:49:22 <chimezie> LeeF: General consensus - Want to start with SPARUL submission then exploit operations that can be done RESTfully over HTTP 14:49:28 <pgearon_> pgearon_ has joined #sparql 14:49:37 <KjetilK> +1 14:49:47 <AxelPolleres> LeeF: general agreement with that? 14:49:52 <AxelPolleres> +1 14:49:54 <Prateek> +1 14:49:59 <SimonS> +1 14:50:06 <chimezie> LeeF: quick straw poll on this point of consensus 14:50:17 <AndyS> +1 with caution 14:50:26 <john-l> +1 14:50:36 <bglimm> +1 14:50:41 <LeeF> -> http://www.w3.org/2009/sparql/track/issues/17 14:51:09 <AlexPassant> +1 14:51:10 <LukeWM> 0 14:51:10 <pgearon> +1 14:51:13 <ivanh> +1 14:51:38 <chimezie> LeeF: proposal is to resolve this issue (17) 14:52:11 <LeeF> PROPOSAL: Resolve ISSUE-17 in favor of doing a full-featured, multi-graph update language and to define corresponding RESTful operations where possible 14:52:44 <chimezie> AndyS: .. and to define .. where possible 14:52:56 <chimezie> ... I read as doing UL and seeing where REST fits in 14:52:58 <SteveH> I don't really like that wording 14:53:57 <chimezie> SteveH: suggested wording: Support the natural REST operations 14:54:20 <chimezie> ... current wording risks ending up with a disconnect from REST 14:54:48 <SteveH> SteveH has joined #sparql 14:54:59 <pgearon_> pgearon_ has left #sparql 14:55:06 <chimezie> how about instead of 'where possible' , 'where there is clear guidance from web architecture' 14:55:21 <SteveH> still don't see why way want to align them 14:55:36 <LeeF> PROPOSAL: Resolve ISSUE-17 in favor of doing a full-featured, multi-graph update language and to define corresponding RESTful operations where there is clear guidance from web architecture 14:56:19 <AndyS> One key issue coudl be investigated -- the use of query string/PUT and how widespread is the consensus of use. Given the state of the world, we can be more comfortable with the connection to language 14:56:23 <chimezie> SteveH: agree to do trivial REST operations at least 14:57:30 <SteveH> or maybe the new issue should be "how do we support RESTful inferfaces" 14:57:39 <LeeF> PROPOSAL: SPARQL WG will pursue a full-featured, multi-graph update language 14:58:06 <LeeF> PROPOSAL: SPARQL WG will define RESTful operations for updating RDF stores 14:58:11 <SteveH> +1 14:58:12 <KjetilK> +1 14:58:37 <chimezie> SteveH: We don't have to tie them 14:58:41 <SteveH> they /might/ turn out to be harmonised, but also they might not 14:58:48 <chimezie> AndyS: agree (about not tying them) 14:59:12 <chimezie> LeeF: do these 2 proposals at least 14:59:40 <LeeF> PROPOSAL: SPARQL WG will pursue a full-featured, multi-graph update language 14:59:48 <KjetilK> +1 14:59:52 <ericP> scribenick: ericP 15:00:03 <AxelPolleres> +1 15:00:07 <LeeF> RESOLVED: SPARQL WG will pursue a full-featured, multi-graph update language 15:00:11 <LeeF> no objections or abstentions 15:00:17 <LeeF> PROPOSAL: SPARQL WG will define RESTful operations for updating RDF stores 15:00:25 <AxelPolleres> +1 15:00:26 <KjetilK> +1 15:00:36 <ericP> abstain 15:00:49 <LeeF> PROPOSAL: SPARQL WG will pursue RESTful operations for updating RDF stores 15:00:54 <SteveH> +1 15:00:57 <ericP> +1 15:00:58 <KjetilK> +1 15:00:59 <bglimm> +1 15:01:01 <SimonS> +1 15:01:02 <AlexPassant> +1 15:01:05 <pgearon> +1 15:01:06 <Prateek> +1 15:01:21 <SteveH> don't you need a 2nd 15:01:59 <LeeF> RESOLVED: SPARQL WG will pursue RESTful operations for updating RDF stores 15:02:10 <ivanh> q+ 15:02:14 <AxelPolleres> +1 (agreeing that pursue is better than define) 15:02:33 <LeeF> ISSUE: What RESTful update operations should be defined? 15:02:33 <trackbot> Created ISSUE-30 - What RESTful update operations should be defined? ; please complete additional details at http://www.w3.org/2009/sparql/track/issues/30/edit . 15:03:08 <ericP> LeeF: anyone believe these close issue 17? 15:03:38 <AndyS> I believe they do 15:04:08 <ericP> ivanh: [adminstrative] make it clear what protocol stuff is in the requirements document, and ergo, SPARQL-b charter <LeeF> topic: rdf:PlainLiteral (nee rdf:text) 15:04:19 <AndyS> rdf:text -> rdf:PlainLiteral 15:05:01 <ericP> AndyS: i am tolerant of the current text in the document 15:05:06 <LukeWM> LukeWM has joined #SPARQL 15:05:22 <ericP> ... explicitly refs SPARQL BGP mapping 15:05:40 <ericP> ... i didn't believe arguments that it was already said in the spec 15:06:14 <ericP> ... covers requirement if there are no changes to SPARQL 15:06:32 <ericP> q+ to say that rdf-interpretation covers "extended" BGP matching 15:06:59 <LeeF> ack ivanh 15:07:07 <LeeF> ack ericP 15:07:07 <Zakim> ericP, you wanted to say that rdf-interpretation covers "extended" BGP matching 15:07:15 <ericP> http://www.w3.org/2007/OWL/wiki/PlainLiteral#Syntax_for_rdf:PlainLiteral_Literals 15:07:21 <AxelPolleres> dropped again... thanks to Andy for the summary. 15:07:48 <AxelPolleres> apologies, but have to join the RIF conf now. 15:08:03 <SimonS> SimonS has left #sparql 15:11:31 <LeeF> PROPOSAL: SPARQL WG is satisfied with how http://www.w3.org/2007/OWL/wiki/PlainLiteral as of 11:11EDT on 2009-06-02 addresses our LC comments on rdf:text 15:11:37 <ericP> second 15:11:52 <AndyS> seconded 15:12:15 <ivanh> +1 15:12:19 <bglimm> +1 15:12:21 <AndyS> RESOLVED 15:11:31 <LeeF> RESOLVED: SPARQL WG is satisfied with how http://www.w3.org/2007/OWL/wiki/PlainLiteral as of 11:11EDT on 2009-06-02 addresses our LC comments on rdf:text 15:12:29 <LeeF> ericP, do you want to communicate this? 15:12:40 <ericP> sure 15:12:48 <SteveH> bye 15:13:16 <ericP> ACTION: eric to tell OWL/RIF that SPARQL is content with http://www.w3.org/2007/OWL/wiki/PlainLiteral 15:13:16 <trackbot> Created ACTION-35 - Tell OWL/RIF that SPARQL is content with http://www.w3.org/2007/OWL/wiki/PlainLiteral [on Eric Prud'hommeaux - due 2009-06-09]. 15:13:30 <AndyS> ADJOURNED # SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000322