Chatlog 2009-06-02

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