13:56:10 <RRSAgent> RRSAgent has joined #sparql
13:56:11 <RRSAgent> logging to http://www.w3.org/2009/06/02-sparql-irc
13:56:12 <trackbot> RRSAgent, make logs world
13:56:13 <Zakim> Zakim has joined #sparql
13:56:14 <trackbot> Zakim, this will be 77277
13:56:14 <Zakim> ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 4 minutes
13:56:15 <trackbot> Meeting: SPARQL Working Group Teleconference
13:56:16 <trackbot> Date: 02 June 2009
13:56:55 <Zakim> SW_(SPARQL)10:00AM has now started
13:57:18 <SimonS> SimonS has joined #sparql
13:57:43 <AndyS> zakim, who is on the phone?
13:57:43 <Zakim> On the phone I see no one
13:57:44 <LeeF> zakim, this is sparql
13:57:44 <Zakim> LeeF, this was already SW_(SPARQL)10:00AM
13:57:46 <Zakim> ok, LeeF; that matches SW_(SPARQL)10:00AM
13:58:02 <kasei> kasei has joined #sparql
13:58:13 <LeeF> zakim, who's on the phone?
13:58:13 <Zakim> On the phone I see no one
13:58:22 <SteveH> SteveH has joined #sparql
13:58:28 <chimezie> I'm on the scribe list already?
13:58:29 <chimezie> i should be
13:58:34 <LukeWM> LukeWM has joined #SPARQL
13:58:42 <chimezie> Zakim passcode?
13:59:02 <AndyS> 77277
13:59:16 <ericP> Zakim, please dial ericP-office
13:59:16 <Zakim> ok, ericP; the call is being made
13:59:16 <LeeF> zakim, why do you hate us?
13:59:18 <Zakim> I don't understand your question, LeeF.
14:00:11 <SteveH> Zakim, who's on the phone?
14:00:11 <Zakim> On the phone I see no one
14:00:18 <SteveH> that's a bad sign :)
14:00:21 <kasei> heh
14:00:27 <bglimm> bglimm has joined #SPARQL
14:00:30 <chimezie> Zakim on strike?
14:01:09 <LeeF> Chair: Lee Feigenbaum
14:01:14 <LeeF> Scribenick: Chimezie
14:01:28 <LeeF> +LeeF
14:01:37 <LeeF> . +LeeF
14:01:47 <ericP> . + ericP
14:01:51 <chimezie> +Chimezie
14:01:53 <SteveH> . +SteveH 
14:01:55 <SimonS> +SimonS
14:01:56 <AlexPassant> i just joined on the phone
14:01:57 <KjetilK> Zakim, what is the code
14:01:57 <Zakim> I don't understand 'what is the code', KjetilK
14:01:58 <LukeWM> + LukeWM
14:01:59 <AndyS> . +AndyS
14:02:01 <KjetilK> Zakim, what is the code?
14:02:01 <Zakim> the conference code is 77277 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), KjetilK
14:02:05 <kasei> . +kasei
14:02:13 <SimonS> Zakim, I am here.
14:02:13 <Zakim> sorry, SimonS, I do not see a party named 'here'
14:02:14 <ivan> zakim, dial ivan-voip
14:02:14 <Zakim> ok, ivan; the call is being made
14:02:24 <chimezie> . +Chimezie
14:02:25 <AlexPassant> . +AlexPassant
14:02:41 <SimonS> . +SimonS
14:02:57 <LeeF> . +ivan
14:03:12 <LeeF> . +orri
14:03:38 <LeeF> . +kjetil
14:03:55 <john-l> . +john-l
14:03:56 <AndyS> zakim is not registering the phone side
14:04:00 <ericP> . +baby
14:04:05 <KjetilK> Zakim, mute me
14:04:05 <Zakim> sorry, KjetilK, I do not know which phone connection belongs to you
14:04:09 <LeeF> Leef, who's on the phone?
14:04:29 <kasei> 61# to mute, I think
14:04:37 <AxelPolleres> AxelPolleres has joined #sparql
14:04:40 <Prateek> Prateek has joined #sparql
14:05:25 <LeeF> . + bglimm
14:05:30 <bglimm> zakim, mute me
14:05:30 <Zakim> sorry, bglimm, I do not know which phone connection belongs to you
14:05:35 <LeeF> . + prateek
14:05:48 <LeeF> . +pgearon
14:05:59 <pag> pag has joined #sparql
14:06:14 <LeeF> . +Axel
14:06:54 <LeeF> Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2009-06-02
14:07:11 <chimezie> Topic: Agenda
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> RESOVLED: 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: ivan, 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> ???: 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:29 <chimezie> s/???/kjetil
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:16:19 <Zakim> irc bot restart will be required to re-connect with bridge for participant info.  Restart will NOT be done immediately unless there is a consensus (tell #sysreq on irc) to do so. 
14:17:08 <Zakim> ... Irc bot restart does not affect the actual telecon
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> AlexPassant: First working draft should be bad enough to 'scare' out comments
14:19:04 <AlexPassant> s/AlexPassant/kjetil
14:19:04 <KjetilK> s/AlexPassant/kjetil/
14:19:05 <AxelPolleres> s/AlexPassant/Kjetil/
14:19:56 <chimezie> Topic: Update
14:20:08 <iv_an_ru> iv_an_ru has joined #sparql
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 reuqire 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 formalizing a model of multiple graphs (where does that fit in REST?)
14:32:40 <chimezie> s/formalizing/formalization of
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: Alot 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 it's 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:31 <chimezie> s/it's/its
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:30 <KjetilK> q+
14:48:33 <KjetilK> q-
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 <ivan> +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:28 <LeeF> PROPOSAL: Resolve ISSUE-17 in favor of doing a full-featured, multi-graph update language and to define corresponding RESTful operations where these is clear guidance from web architecture
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:33 <ericP> absain
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:48 <LeeF> RESOLVED: SPARQL WG will pursue RESTful operations for updating RDF stores, ericP abstaining
15:01:59 <LeeF> RESOLVED: SPARQL WG will pursue RESTful operations for updating RDF stores
15:02:10 <ivan> 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 it does
15:03:52 <AndyS> s/it does/they do/
15:04:08 <ericP> ivan: [adminstrative] make it clear what protocol stuff is in the requirements document, and ergo, SPARQL-b charter
15:04:19 <AndyS> rdf:text -> rdf:PlainLiteral 
15:05:01 <ericP> AndyS: i am tollerant 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 ivan
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 <ivan> +1
15:12:19 <bglimm> +1
15:12:21 <AndyS> RESOLVED 
15:12:29 <LeeF> ericP, do you want to communicate this?
15:12:40 <ericP> sure
15:12:48 <SteveH> bye
15:13:06 <ericP> ACTION: ericP to tell OWL/RIF that SPARQL is content with http://www.w3.org/2007/OWL/wiki/PlainLiteral
15:13:06 <trackbot> Sorry, couldn't find user - ericP
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:23 <AndyS> ADJOURED
15:13:30 <AndyS> ADJOURNED
15:13:44 <SteveH> SteveH has joined #sparql
15:14:13 <Zakim> SW_(SPARQL)10:00AM has ended
15:14:14 <Zakim> Attendees were 
15:16:41 <LeeF> yeah, thanks a lot Zakim.
15:16:44 <LeeF> thanks for nothing
15:18:22 <KjetilK> kjefte means scolding in Norwegian, so perhaps I should be chair so I can do that ;-)
15:24:29 <LeeF> :-)
15:31:43 <Zakim> irc bot will restart shortly; reinvite a minute or two after departure
16:40:47 <LeeF> LeeF has joined #sparql
18:17:52 <kasei> kasei has left #sparql
19:15:57 <AxelPolleres_> AxelPolleres_ has joined #sparql
19:17:48 <AxelPolleres> AxelPolleres has joined #sparql
20:07:09 <LeeF> LeeF has joined #sparql
20:23:18 <LeeF__> LeeF__ has joined #sparql
22:07:58 <LeeF> LeeF has joined #sparql