IRC log of sparql on 2009-06-02

Timestamps are in UTC.

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