edit

SPARQL Working Group Teleconference

Minutes of 02 June 2009

Agenda
http://www.w3.org/2009/sparql/wiki/Agenda-2009-06-02
Present
Lee Feigenbaum, Andy Seaborne, Chimezie Ogbuji, John Clark, Paula Gearon, Gregory Williams, Eric Prud'hommeaux, Orri Erling, Steve Harris, Luke Wilson-Mawer, Prateek Jain, Birte Glimm, Simon Schenk, Ivan Herman, Alexandre Passant, Kjetil Kjernsmo, Axel Polleres
Chair
Lee Feigenbaum
Scribe
Chimezie Ogbuji, Eric Prud'hommeaux
IRC Log
Original
Resolutions
  1. Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-05-26 link
  2. SPARQL WG will pursue a full-featured, multi-graph update language link
  3. SPARQL WG will pursue RESTful operations for updating RDF stores link
  4. 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 link
Topics
<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

Trackbot IRC Bot: Date: 02 June 2009

14:01:09 <LeeF> Chair: LeeF
14:01:14 <LeeF> Scribenick: Chimezie

(Scribe set to Chimezie Ogbuji)

14:07:11 <chimezie> Topic: Admin

(No events recorded for 5 minutes)

1. 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

PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-05-26

14:07:26 <AxelPolleres> +1

Axel Polleres: +1

14:07:42 <LeeF> RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-05-26

RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-05-26

14:08:15 <AlexPassant> indeed :)

Alexandre Passant: indeed :)

14:08:21 <chimezie> LeeF: Others able to make next meeting?

Lee Feigenbaum: Others able to make next meeting?

14:08:35 <kasei> I'll be travelling next week. Will probably make it, but possibly not.

Gregory Williams: I'll be travelling next week. Will probably make it, but possibly not.

14:08:42 <LeeF> regrets next week: ivanh, AlexPassant

Lee Feigenbaum: regrets next week: ivanh, AlexPassant

14:09:09 <LeeF> scribe next week: Yimin (Kjetil on deck)

Lee Feigenbaum: scribe next week: Yimin (Kjetil on deck)

14:09:58 <chimezie> LeeF:  No significant progress on actions/issues to warrant going over

Lee Feigenbaum: No significant progress on actions/issues to warrant going over

14:10:10 <pgearon> +q

Paula Gearon: +q

14:10:11 <chimezie> ... sent an email with outline for progress

... sent an email with outline for progress

14:10:21 <chimezie> ... reach concensus on update and how to scope/phase it

... reach concensus on update and how to scope/phase it

14:10:50 <KjetilK> q+

Kjetil Kjernsmo: q+

14:11:11 <KjetilK> ack pgearon

Kjetil Kjernsmo: ack pgearon

14:11:41 <pgearon> http://www.w3.org/2009/sparql/track/actions/22

Paula Gearon: 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)

Kjetil Kjernsmo: 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

Lee Feigenbaum: 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

Trackbot IRC Bot: 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

... no red flags. Anyone else see issue with this

14:12:32 <LeeF> trackbot, close ACTION-22

Lee Feigenbaum: 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

Trackbot IRC Bot: 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

Lee Feigenbaum: ack kjetilk

14:13:18 <chimezie> Kjetil: It is a bit difficult to write queries for aggregate functions.  Should we discuss this soon?

Kjetil Kjernsmo: 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)

... (which aggregate functions will we do)

14:13:39 <AndyS> q+

Andy Seaborne: q+

14:13:44 <chimezie> LeeF: To early to resolve which aggregates we will use

Lee Feigenbaum: To early to resolve which aggregates we will use

14:13:59 <chimezie> ... best to write a general description of ability in features document

... best to write a general description of ability in features document

14:14:46 <chimezie> Orri: we already have user-specified aggregates

Orri Erling: we already have user-specified aggregates

14:15:14 <LeeF> ack AndyS

Lee Feigenbaum: ack AndyS

14:15:16 <chimezie> AndyS: will it help to pick one we are certain to do?

Andy Seaborne: will it help to pick one we are certain to do?

14:15:27 <chimezie> kjetil: That would be helpful, yes

Kjetil Kjernsmo: That would be helpful, yes

14:16:03 <AndyS> If we don't do COUNT(*), I will be very surprised.

Andy Seaborne: 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

Axel Polleres: 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

Lee Feigenbaum: Features & rational document goal is still to have a first draft by next week

14:17:55 <chimezie> ... WD is a necessary first step

... 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.

Lee Feigenbaum: FPWD of F&R is a necessary step in the ongoing re-chartering process. [ Scribe Assist by Axel Polleres ]

14:18:48 <chimezie> Kjetil: First working draft should be bad enough to 'scare' out comments

Kjetil Kjernsmo: First working draft should be bad enough to 'scare' out comments

14:19:56 <chimezie> Topic: Update

2. Update

14:20:27 <chimezie> LeeF: Last week was focused on usecases, this week we should go over concrete proposals

Lee Feigenbaum: 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

... spectrum from update language (proper) - with and without WHERE clause

14:21:15 <chimezie> ... to usecases that are aware of a proper RDF dataset

... 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..)

... 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

... support for protocol take update query strings via various HTTP verbs

14:23:38 <AndyS> Good summary

Andy Seaborne: Good summary

14:23:57 <chimezie> LeeF: rough consensus on doing these things, but worrysome if we do all

Lee Feigenbaum: rough consensus on doing these things, but worrysome if we do all

14:24:27 <SteveH> q+ to talk about +/- WHERE

Steve Harris: q+ to talk about +/- WHERE

14:24:50 <AndyS> ack SteveH

Andy Seaborne: ack SteveH

14:24:50 <Zakim> SteveH, you wanted to talk about +/- WHERE

Zakim IRC Bot: 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

Steve Harris: although usecases require WHERE, this is something we can drop using ASK queries initially prior to an update operation

14:25:25 <AndyS> (bnodes)

Andy Seaborne: (bnodes)

14:25:41 <chimezie> LeeF: Including WHERE in UL gives ability determine conditions on update

Lee Feigenbaum: Including WHERE in UL gives ability determine conditions on update

14:25:50 <KjetilK> q+ to ask about DELETE

Kjetil Kjernsmo: q+ to ask about DELETE

14:26:02 <LukeWM> q+ to ask about doing less in language & more in protocol

Luke Wilson-Mawer: q+ to ask about doing less in language & more in protocol

14:26:38 <LeeF> ack kjetil

Lee Feigenbaum: ack kjetil

14:26:38 <Zakim> KjetilK, you wanted to ask about DELETE

Zakim IRC Bot: KjetilK, you wanted to ask about DELETE

14:26:41 <chimezie> AndyS: Might end up codifying weird URI schemes to handle BnNodes

Andy Seaborne: 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)

Kjetil Kjernsmo: 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?

Axel Polleres: 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

... 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

Andy Seaborne: CONSTRUCT can be used prior to DELETE initially

14:28:08 <chimezie> PATCH?

PATCH?

14:28:09 <SteveH> what would DELETE FROM <a> { ?x a foaf:Person } mean?

Steve Harris: what would DELETE FROM <a> { ?x a foaf:Person } mean?

14:28:11 <LeeF> ack LukeWM

Lee Feigenbaum: ack LukeWM

14:28:11 <Zakim> LukeWM, you wanted to ask about doing less in language & more in protocol

Zakim IRC Bot: 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

Luke Wilson-Mawer: 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?

Andy Seaborne: How commonly supported is PATCH?

14:28:40 <chimezie> Not very, I don't think (unfortunately)

Not very, I don't think (unfortunately)

14:28:47 <AxelPolleres> q-

Axel Polleres: q-

14:28:52 <SteveH> Suported by HTTP libraries, or servers?

Steve Harris: Suported by HTTP libraries, or servers?

14:28:52 <KjetilK> q+

Kjetil Kjernsmo: q+

14:29:00 <chimezie> LeeF: Gut reaction is that it is same amount of work

Lee Feigenbaum: 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

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.

Andy Seaborne: Quick google suggests it's new and not supported much. Draft expired July 2008.

14:30:43 <SteveH> major echo

Steve Harris: major echo

14:31:39 <chimezie> LeeF: does an UL w/out a WHERE language save us much?

Lee Feigenbaum: does an UL w/out a WHERE language save us much?

14:31:47 <chimezie> AndyS: Not much , but it does save *some* effort

Andy Seaborne: Not much , but it does save *some* effort

14:31:48 <ericP> i'd say it saves very little work

Eric Prud'hommeaux: i'd say it saves very little work

14:32:06 <chimezie> ... but marginal.

... but marginal.

14:32:31 <chimezie> ... biggest work area is a formalization of a model of multiple graphs (where does that fit in REST?)

... 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

Andy Seaborne: 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

Eric Prud'hommeaux: 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?

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

... 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

Andy Seaborne: 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

... 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?

Lee Feigenbaum: q?

14:35:16 <KjetilK> ack me

Kjetil Kjernsmo: ack me

14:35:17 <SteveH> PUT http://endpoint/rest/?graph=http://foo.com

Steve Harris: PUT http://endpoint/rest/?graph=http://foo.com

14:35:32 <AxelPolleres> q+

Axel Polleres: q+

14:35:57 <chimezie> Generally? plenty of precedent.

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?

Paula Gearon: 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

Andy Seaborne: 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

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

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

Steve Harris: 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

Andy Seaborne: Perhaps we simply describe a mapping from the UL to the protocol

14:39:05 <chimezie> ... an informative mapping

... an informative mapping

14:39:42 <ericP> chimezie: if you can't address part of the resource you're trying to update, ...

Chimezie Ogbuji: if you can't address part of the resource you're trying to update, ... [ Scribe Assist by Eric Prud'hommeaux ]

14:39:54 <ericP> ... i makes more sense in the language

Eric Prud'hommeaux: ... 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?

Andy Seaborne: 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?

Steve Harris: 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?

Steve Harris: 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.

Andy Seaborne: 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 :)

Steve Harris: ok, sorry AndyS :)

14:42:55 <chimezie> AxelPolleres: Should we identify restrictions up front ?

Axel Polleres: 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

Lee Feigenbaum: 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.

Axel Polleres: 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

... but are there things that can be done RESTfully but not easily in UL

14:45:11 <AndyS> q+ to express REST hopes

Andy Seaborne: q+ to express REST hopes

14:45:21 <AxelPolleres> q-

Axel Polleres: q-

14:45:34 <LukeWM> q+

Luke Wilson-Mawer: q+

14:45:48 <LeeF> ack AndyS

Lee Feigenbaum: ack AndyS

14:45:48 <Zakim> AndyS, you wanted to express REST hopes

Zakim IRC Bot: AndyS, you wanted to express REST hopes

14:45:57 <chimezie> AndyS: Nice thing about REST is deployability on standard servers

Andy Seaborne: Nice thing about REST is deployability on standard servers

14:46:16 <chimezie> q+

q+

14:46:25 <KjetilK> +1 to AndyS point

Kjetil Kjernsmo: +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

Luke Wilson-Mawer: No clear usecase of where you can do one via REST but not via the update language -- i think?

14:47:02 <LeeF> s/via the protocol/via the update language -- i think?
14:47:37 <LeeF> ack chimezie

Lee Feigenbaum: ack chimezie

14:47:40 <LeeF> ack LukeWM

Lee Feigenbaum: ack LukeWM

14:47:41 <SteveH> the curl as a sparql client usecase

Steve Harris: 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

Chimezie Ogbuji: 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 [ Scribe Assist by Lee Feigenbaum ]

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

Chimezie Ogbuji: start with the language and then have a look of which patr of it can fit in the RESTful approach [ Scribe Assist by Axel Polleres ]

14:48:53 <AxelPolleres> (+1 to chime on that)

Axel Polleres: (+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

Lee Feigenbaum: General consensus - Want to start with SPARUL submission then exploit operations that can be done RESTfully over HTTP

14:49:37 <KjetilK> +1

Kjetil Kjernsmo: +1

14:49:47 <AxelPolleres> LeeF: general agreement with that?

Lee Feigenbaum: general agreement with that? [ Scribe Assist by Axel Polleres ]

14:49:52 <AxelPolleres> +1

Axel Polleres: +1

14:49:54 <Prateek> +1

Prateek Jain: +1

14:49:59 <SimonS> +1

Simon Schenk: +1

14:50:06 <chimezie> LeeF: quick straw poll on this point of consensus

Lee Feigenbaum: quick straw poll on this point of consensus

14:50:17 <AndyS> +1 with caution

Andy Seaborne: +1 with caution

14:50:26 <john-l> +1

John Clark: +1

14:50:36 <bglimm> +1

Birte Glimm: +1

14:50:41 <LeeF> -> http://www.w3.org/2009/sparql/track/issues/17

Lee Feigenbaum: -> http://www.w3.org/2009/sparql/track/issues/17

14:51:09 <AlexPassant> +1

Alexandre Passant: +1

14:51:10 <LukeWM> 0

Luke Wilson-Mawer: 0

14:51:10 <pgearon> +1

Paula Gearon: +1

14:51:13 <ivanh> +1

Ivan Herman: +1

14:51:38 <chimezie> LeeF: proposal is to resolve this issue (17)

Lee Feigenbaum: 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

PROPOSED: 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

Andy Seaborne: .. and to define .. where possible

14:52:56 <chimezie> ... I read as doing UL and seeing where REST fits in

... I read as doing UL and seeing where REST fits in

14:52:58 <SteveH> I don't really like that wording

Steve Harris: I don't really like that wording

14:53:57 <chimezie> SteveH: suggested wording:  Support the natural REST operations

Steve Harris: suggested wording: Support the natural REST operations

14:54:20 <chimezie> ... current wording risks ending up with a disconnect from REST

... current wording risks ending up with a disconnect from REST

14:55:06 <chimezie> how about instead of 'where possible' , 'where there is clear guidance from web architecture'

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

Steve Harris: 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

PROPOSED: 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

Andy Seaborne: 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

Steve Harris: 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"

Steve Harris: 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

PROPOSED: 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

PROPOSED: SPARQL WG will define RESTful operations for updating RDF stores

14:58:11 <SteveH> +1

Steve Harris: +1

14:58:12 <KjetilK> +1

Kjetil Kjernsmo: +1

14:58:37 <chimezie> SteveH: We don't have to tie them

Steve Harris: We don't have to tie them

14:58:41 <SteveH> they /might/ turn out to be harmonised, but also they might not

Steve Harris: they /might/ turn out to be harmonised, but also they might not

14:58:48 <chimezie> AndyS: agree (about not tying them)

Andy Seaborne: agree (about not tying them)

14:59:12 <chimezie> LeeF: do these 2 proposals at least

Lee Feigenbaum: do these 2 proposals at least

14:59:40 <LeeF> PROPOSAL: SPARQL WG will pursue a full-featured, multi-graph update language

PROPOSED: SPARQL WG will pursue a full-featured, multi-graph update language

14:59:48 <KjetilK> +1

Kjetil Kjernsmo: +1

14:59:52 <ericP> scribenick: ericP

(Scribe set to Eric Prud'hommeaux)

15:00:03 <AxelPolleres> +1

Axel Polleres: +1

15:00:07 <LeeF> RESOLVED: SPARQL WG will pursue a full-featured, multi-graph update language

RESOLVED: SPARQL WG will pursue a full-featured, multi-graph update language

15:00:11 <LeeF> no objections or abstentions

Lee Feigenbaum: no objections or abstentions

15:00:17 <LeeF>  PROPOSAL: SPARQL WG will define RESTful operations for updating RDF stores

Lee Feigenbaum: PROPOSAL: SPARQL WG will define RESTful operations for updating RDF stores

15:00:25 <AxelPolleres> +1

Axel Polleres: +1

15:00:26 <KjetilK> +1

Kjetil Kjernsmo: +1

15:00:36 <ericP> abstain

abstain

15:00:49 <LeeF> PROPOSAL: SPARQL WG will pursue RESTful operations for updating RDF stores

PROPOSED: SPARQL WG will pursue RESTful operations for updating RDF stores

15:00:54 <SteveH> +1

Steve Harris: +1

15:00:57 <ericP> +1

+1

15:00:58 <KjetilK> +1

Kjetil Kjernsmo: +1

15:00:59 <bglimm> +1

Birte Glimm: +1

15:01:01 <SimonS> +1

Simon Schenk: +1

15:01:02 <AlexPassant> +1

Alexandre Passant: +1

15:01:05 <pgearon> +1

Paula Gearon: +1

15:01:06 <Prateek> +1

Prateek Jain: +1

15:01:21 <SteveH> don't you need a 2nd

Steve Harris: don't you need a 2nd

15:01:59 <LeeF> RESOLVED: SPARQL WG will pursue RESTful operations for updating RDF stores

RESOLVED: SPARQL WG will pursue RESTful operations for updating RDF stores

15:02:10 <ivanh> q+

Ivan Herman: q+

15:02:14 <AxelPolleres> +1 (agreeing that pursue is better than define)

Axel Polleres: +1 (agreeing that pursue is better than define)

15:02:33 <LeeF> ISSUE: What RESTful update operations should be defined?

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 .

Trackbot IRC Bot: 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?

Lee Feigenbaum: anyone believe these close ISSUE-17?

15:03:38 <AndyS> I believe they do

Andy Seaborne: 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

Ivan Herman: [adminstrative] make it clear what protocol stuff is in the requirements document, and ergo, SPARQL-b charter

<LeeF> topic: rdf:PlainLiteral (nee rdf:text)

3. rdf:PlainLiteral (nee rdf:text)

15:04:19 <AndyS>  rdf:text -> rdf:PlainLiteral

Andy Seaborne: rdf:text -> rdf:PlainLiteral

15:05:01 <ericP> AndyS: i am tolerant of the current text in the document

Andy Seaborne: i am tolerant of the current text in the document

15:05:22 <ericP> ... explicitly refs SPARQL BGP mapping

... explicitly refs SPARQL BGP mapping

15:05:40 <ericP> ... i didn't believe arguments that it was already said in the spec

... 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

... covers requirement if there are no changes to SPARQL

15:06:32 <ericP> q+ to say that rdf-interpretation covers "extended" BGP matching

q+ to say that rdf-interpretation covers "extended" BGP matching

15:06:59 <LeeF> ack ivanh

Lee Feigenbaum: ack ivanh

15:07:07 <LeeF> ack ericP

Lee Feigenbaum: ack ericP

15:07:07 <Zakim> ericP, you wanted to say that rdf-interpretation covers "extended" BGP matching

Zakim IRC Bot: 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

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.

Axel Polleres: dropped again... thanks to Andy for the summary.

15:07:48 <AxelPolleres> apologies, but have to join the RIF conf now.

Axel Polleres: apologies, but have to join the RIF conf now.

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

PROPOSED: 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

second

15:11:52 <AndyS> seconded

Andy Seaborne: seconded

15:12:15 <ivanh> +1

Ivan Herman: +1

15:12:19 <bglimm> +1

Birte Glimm: +1

15:12:21 <AndyS> RESOLVED

Andy Seaborne: 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

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?

Lee Feigenbaum: ericP, do you want to communicate this?

15:12:40 <ericP> sure

sure

15:12:48 <SteveH> bye

Steve Harris: bye

15:13:16 <ericP> ACTION: eric to tell OWL/RIF that SPARQL is content with http://www.w3.org/2007/OWL/wiki/PlainLiteral

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].

Trackbot IRC Bot: 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

Andy Seaborne: ADJOURNED



Formatted by CommonScribe