IRC log of sparql on 2009-08-04

Timestamps are in UTC.

13:48:13 [RRSAgent]

RRSAgent has joined #sparql

13:48:13 [RRSAgent]

logging to http://www.w3.org/2009/08/04-sparql-irc

13:48:15 [trackbot]

RRSAgent, make logs world

13:48:15 [Zakim]

Zakim has joined #sparql

13:48:17 [trackbot]

Zakim, this will be 77277

13:48:17 [Zakim]

ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 12 minutes

13:48:18 [trackbot]

Meeting: SPARQL Working Group Teleconference

13:48:18 [trackbot]

Date: 04 August 2009

13:48:22 [LeeF]

zakim, this will be SPARQL

13:48:22 [Zakim]

ok, LeeF; I see SW_(SPARQL)10:00AM scheduled to start in 12 minutes

13:48:26 [LeeF]

Chair: LeeF

13:48:35 [LeeF]

Regrets: Axel, EricP, IvanH

13:48:50 [kasei]

scribenick: kasei

13:48:50 [LeeF]

Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2009-08-04

13:49:30 [kasei]

ah, great. didn't realize that was on the agenda today.

13:49:53 [kasei]

would like to start addressing the how and not the what...

13:50:40 [LeeF]

i stuck both parts (what & how) on the agenda

13:50:48 [kasei]

yup

13:51:01 [LeeF]

not really sure which parts of the agenda we (as a group) will be most swapped in on, but the serv. description discovery mechanism always provides for a lively debate :)

13:51:21 [kasei]

yeah. i suspect someone is going to end up really unhappy no matter what we do.

13:51:50 [LeeF]

bengee suggested (on the -comments) list using HTTP conneg on an endpoint URI w/ no query params - think that's a 7th option from the 6 we had before

13:52:24 [kasei]

yes. although I don't particularly care for it...

13:52:36 [kasei]

feels strange

13:53:00 [kasei]

since not everyone even serves content at the endpoint URI without ?query=...

13:53:41 [LeeF]

:)

13:55:13 [LeeF]

have we discussed sitemaps? i guess it's just one version of the "well known location" option, which has the negative fact that you need to control your server's root to do it?

13:55:47 [kasei]

yeah. i think that's how some of the void people do it now... void + semantic sitemaps.

13:56:11 [LeeF]

right - i was browsing http://sw.deri.org/2007/07/sitemapextension/

13:56:30 [Zakim]

SW_(SPARQL)10:00AM has now started

13:56:37 [Zakim]

+??P16

13:56:40 [Zakim]

+??P17

13:56:46 [AlexPassant]

Zakim, ??P17 is me

13:56:46 [Zakim]

+AlexPassant; got it

13:57:00 [kasei]

Zakim, ??P16 is me

13:57:00 [Zakim]

+kasei; got it

13:57:17 [Zakim]

+??P18

13:57:24 [AndyS]

zakim, ??P18 is me

13:57:24 [Zakim]

+AndyS; got it

13:57:54 [AlexPassant]

LeeF, kasei : afaik, sitemaps is just here to say where the endpoint is, not what it serves (void or DARQ can be used here, as you described in your previous action)

13:58:26 [kasei]

right. I thought that's how some people were already doing it.

13:58:44 [pgearon]

pgearon has joined #sparql

13:59:04 [SimonKJ]

SimonKJ has joined #sparql

13:59:20 [Zakim]

+??P22

13:59:51 [SimonS]

SimonS has joined #sparql

13:59:53 [Zakim]

+Lee_Feigenbaum

14:00:08 [AlexPassant]

but since DESCRIBE is implementation specific, it can lead to different answers depending on the endpoint, no ?

14:00:09 [LukeWM]

zakim, ??P22 is Garlik

14:00:12 [Zakim]

+Garlik; got it

14:00:19 [LeeF]

AlexPassant, not DESCRIBE, a new query verb

14:00:22 [Zakim]

+SimonKJ

14:00:32 [kasei]

a verb that happens to be two+ words

14:00:34 [AndyS]

We get the chance to define what DESCRIBE SELF means.

14:00:43 [AlexPassant]

LeeF: ok, cool

14:00:45 [LeeF]

two+ as in twotwotwotwotwo ?

14:00:47 [swh__]

swh__ has joined #sparql

14:00:48 [kasei]

unlike the DESCRIBE <> option

14:00:49 [bglimm]

bglimm has joined #SPARQL

14:01:06 [LeeF]

oh, i see it must be twoooooooooo :-)

14:01:08 [kasei]

LeeF: that would limit our options, but sure.

14:01:10 [LukeWM]

zakim, Garlik has SteveH, LukeWM

14:01:10 [Zakim]

+SteveH, LukeWM; got it

14:01:16 [AndyS]

<> is relative to the base URI of the query ;-)

14:01:17 [Zakim]

+pgearon

14:01:20 [Zakim]

+SimonS

14:01:27 [LeeF]

zakim, who's on the phone?

14:01:27 [Zakim]

On the phone I see kasei, AlexPassant, AndyS, Garlik, Lee_Feigenbaum, SimonKJ, pgearon, SimonS

14:01:27 [LukeWM]

zakim, who is on the phone?

14:01:29 [Zakim]

Garlik has SteveH, LukeWM

14:01:31 [Zakim]

On the phone I see kasei, AlexPassant, AndyS, Garlik, Lee_Feigenbaum, SimonKJ, pgearon, SimonS

14:01:34 [Zakim]

Garlik has SteveH, LukeWM

14:01:37 [Zakim]

+ +8686528aaaa

14:01:55 [bglimm]

Zakim, 8686528aaaa is bglimm

14:01:55 [Zakim]

sorry, bglimm, I do not recognize a party named '8686528aaaa'

14:02:10 [LeeF]

zakim, +8686528aaaa is bglimm

14:02:10 [Zakim]

+bglimm; got it

14:02:11 [bglimm]

Zakim, +8686528aaaa is bglimm

14:02:12 [Zakim]

sorry, bglimm, I do not recognize a party named '+8686528aaaa'

14:02:24 [bglimm]

Zakim, mute me

14:02:24 [Zakim]

bglimm should now be muted

14:02:30 [SimonS]

Zakim, aaaa is bglimm

14:02:30 [Zakim]

sorry, SimonS, I do not recognize a party named 'aaaa'

14:02:39 [SimonS]

was worth trying...

14:02:42 [kasei]

Zakim, mute me

14:02:51 [Zakim]

kasei should now be muted

14:03:08 [LeeF]

zakim, who's in IRC but not yet on the phone?

14:03:08 [Zakim]

I don't understand your question, LeeF.

14:03:17 [chimezie]

chimezie has joined #sparql

14:03:46 [chimezie]

Zakim, what is the passcode?

14:03:46 [Zakim]

the conference code is 77277 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), chimezie

14:03:51 [kasei]

yeah

14:03:59 [LeeF]

topic: Admin

14:04:07 [LeeF]

PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-07-28

14:04:16 [LeeF]

agenda - http://www.w3.org/2009/sparql/wiki/Agenda-2009-08-04

14:04:22 [Zakim]

+Chimezie_Ogbuji

14:04:31 [bglimm]

+1

14:04:42 [LeeF]

RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-07-28

14:05:18 [LeeF]

next mtg Aug-11 SimonS to scribe

14:05:27 [LeeF]

http://www.w3.org/2009/sparql/wiki/Vacation_List

14:05:27 [Zakim]

-kasei

14:05:30 [kasei]

gah

14:06:07 [Zakim]

+[IPcaller]

14:06:12 [kasei]

Zakim, IPcaller is me

14:06:12 [Zakim]

+kasei; got it

14:06:16 [kasei]

Zakim, mute me

14:06:16 [Zakim]

kasei should now be muted

14:06:21 [kasei]

sorry about that

14:06:22 [chimezie]

Zakim, mute me

14:06:22 [Zakim]

Chimezie_Ogbuji should now be muted

14:06:34 [kasei]

topic: Liasons

14:06:49 [Zakim]

+Prateek

14:07:02 [kasei]

nothing to report

14:07:09 [LeeF]

topic: TPAC face to face

14:07:33 [kasei]

LeeF: reminder next face to face at TPAC

14:07:58 [kasei]

LeeF: 2 day meeting

14:08:11 [Prateek]

Prateek has joined #sparql

14:08:40 [kasei]

... try to arrange virtual call as well

14:08:47 [kasei]

... comments?

14:09:07 [LeeF]

topic: Actions

14:09:10 [bglimm]

I have to see what the travel budget says...

14:09:12 [kasei]

... will ask on mailing list again who intends to go

14:09:43 [LeeF]

trackbot, close ACTION-55

14:09:43 [trackbot]

ACTION-55 Summarize ISSUE-32 closed

14:10:21 [LeeF]

trackbot, close ACTION-64

14:10:22 [trackbot]

ACTION-64 Draft subqueries in template closed

14:10:42 [chimezie]

Zakim, unmute me

14:10:42 [Zakim]

Chimezie_Ogbuji should no longer be muted

14:11:08 [kasei]

AndyS: trying to work out more formal relationship between not exists and diff

14:11:30 [kasei]

LeeF: will probably turn attention back to that in a few weeks.

14:11:31 [LeeF]

trackbot, close ACTION-67

14:11:31 [trackbot]

ACTION-67 Draft negation closed

14:11:55 [kasei]

chimezie: hope to have something on aggregates later this week

14:12:10 [kasei]

LeeF: hope to have mailing list discussion and discuss aggregates next week

14:12:14 [bglimm]

Zakim, unmute me

14:12:14 [Zakim]

bglimm should no longer be muted

14:12:22 [LeeF]

trackbot, close ACTION-73

14:12:22 [trackbot]

ACTION-73 Kick of BGP entailment TF closed

14:12:31 [LeeF]

trackbot, close ACTION-74

14:12:31 [trackbot]

ACTION-74 Kick off property paths TF closed

14:12:42 [AndyS]

AndyS has joined #sparql

14:12:46 [chimezie]

Zakim, mute me

14:12:46 [Zakim]

Chimezie_Ogbuji should now be muted

14:13:10 [LeeF]

trackbot, close ACTION-76

14:13:11 [trackbot]

ACTION-76 Kick off Basic Federated Query TF closed

14:13:25 [LeeF]

topic: Document editors

14:13:26 [kasei]

SimonS: sent email to kick off basic federated query TF

14:13:30 [kasei]

(that was SimonS?)

14:13:54 [kasei]

LeeF: asked for editors for sparql query and update documents.

14:13:58 [SimonS]

yes, that was me.

14:14:05 [kasei]

... AndyS and SteveH will serve as editors of query

14:14:13 [kasei]

... pgearon and SimonS editors of update

14:14:39 [AndyS]

AndyS has joined #sparql

14:14:43 [bglimm]

Zakim, mute me

14:14:43 [Zakim]

bglimm should now be muted

14:14:59 [kasei]

AndyS: is update for protocol and language?

14:15:07 [kasei]

LeeF: not decided yet.

14:15:32 [kasei]

AndyS: meant REST by "protocol"

14:15:42 [pgearon]

I think that the update protocol will need its own document. I'm prepared to work on both

14:15:59 [kasei]

Zakim, who is speaking?

14:16:09 [Zakim]

kasei, listening for 10 seconds I heard sound from the following: AndyS (9%), Lee_Feigenbaum (34%), pgearon (85%)

14:16:58 [kasei]

topic: Status of SPARQL/Query design template actions

14:17:12 [kasei]

LeeF: any issues worth discussing now?

14:17:20 [LeeF]

http://www.w3.org/2009/sparql/wiki/Design:SubSelect

14:17:29 [kasei]

SteveH: syntax for allowing projected variable renaming

14:17:42 [kasei]

... need new syntax because existing syntax doesn't have room for it.

14:18:15 [kasei]

... expressing subselects in obvious way loses internal ordering

14:18:42 [kasei]

... according to current semantics, order isn't preseved in join.

14:18:59 [kasei]

... lots of dependencies between project expressions and aggregates.

14:19:11 [kasei]

LeeF: open issue whether we'll do other types of subqueries

14:19:59 [kasei]

LeeF: summing up, syntax and ordering are issues.

14:20:22 [kasei]

AndyS: big change to existing implementations to address ordering

14:20:57 [kasei]

LeeF: have you had any feedback on ordering?

14:21:06 [kasei]

AndyS: no, but use case for it.

14:21:30 [kasei]

... case for having ORDER BY in subquery

14:21:46 [kasei]

LeeF: need order by and limit to do limit by resource

14:22:02 [kasei]

AndyS: or "top blogger by number of comments"

14:22:40 [pgearon]

no allergic reaction. I might sneeze :-)

14:22:44 [kasei]

LeeF: does anybody find an ORDER BY in subquery with order disappering in outer query problematic?

14:23:17 [kasei]

LeeF: seems to be concensus on keeping ORDER BY in subquery but that order isn't preserved in merging results with main query

14:23:24 [LukeWM_]

LukeWM_ has joined #sparql

14:23:32 [kasei]

... less inclined to move ahead on syntax right now.

14:23:47 [kasei]

... will note that it's an open issue.

14:24:00 [kasei]

SteveH: from logical point of view, straightforward

14:24:09 [chimezie]

Zakim, unmute me

14:24:09 [Zakim]

Chimezie_Ogbuji should no longer be muted

14:24:43 [LeeF]

S,t,e,v,e H,a,r,r,i,s ?

14:24:54 [kasei]

... syntax is a bit off-scope, would like to see if concensus for ways to write rename.

14:25:02 [SteveH]

E1: SELECT (?x+3 AS ?xp3) ?y WHERE ...

14:25:09 [SteveH]

E2: SELECT (?x+3) AS ?xp3 ?y WHERE ...

14:25:16 [SteveH]

E3: SELECT ?x+3 AS ?xp3, ?y WHERE ...

14:25:37 [kasei]

LeeF: 3 ways to express selecting and projecting to a different name.

14:25:58 [AndyS]

I don't like adjacent, unseparated use of variables (the "SELECT (expr) as ?x ?y WHERE" case)

14:25:59 [kasei]

... using an AS keyword in parens, the whole thing in parens, or leaving off parens and adding commas between items.

14:26:11 [kasei]

AndyS++

14:26:27 [kasei]

SteveH: semantically equivalent, just some easier for humans

14:26:40 [chimezie]

E3 +1

14:26:43 [kasei]

LeeF: strawpoll

14:26:48 [LeeF]

poll on E1

14:26:52 [SteveH]

+0

14:26:55 [bglimm]

+0

14:26:56 [LukeWM_]

0

14:26:57 [AndyS]

+1 E1

14:26:58 [LeeF]

+1

14:26:59 [kasei]

+1

14:27:00 [Prateek]

+1

14:27:02 [pgearon]

+1

14:27:02 [AlexPassant]

+1

14:27:05 [chimezie]

0

14:27:14 [LeeF]

poll on E2

14:27:15 [SteveH]

-1

14:27:16 [LukeWM_]

-1

14:27:16 [AndyS]

q+ to ask about E3

14:27:16 [AlexPassant]

-1

14:27:17 [kasei]

can the person breathing into the phone mute themselves please?

14:27:22 [LeeF]

-1

14:27:24 [chimezie]

-1

14:27:24 [pgearon]

-1

14:27:24 [bglimm]

0

14:27:26 [kasei]

-1

14:27:28 [AndyS]

-0.5 E2

14:27:29 [SimonS]

0

14:27:46 [LeeF]

ack AndyS

14:27:46 [Zakim]

AndyS, you wanted to ask about E3

14:28:00 [kasei]

AndyS: is it a change that will affect existing queries (commas)?

14:28:12 [pgearon]

+q

14:28:21 [kasei]

SteveH: named projection would require commas. doesn't change existing queries.

14:28:36 [kasei]

(I didn't catch the "probably yes" point)

14:29:07 [kasei]

SteveH: want impressions on overall look and feel, not details

14:29:19 [LeeF]

ack pgearon

14:30:01 [kasei]

pgearon: if we considering commans in variables in select clause, wouldn't examples 2 and 3 be similar?

14:30:10 [kasei]

s/we/we're/

14:30:14 [kasei]

s/commans/commas/

14:30:22 [kasei]

SteveH: E2 doesn't have commas

14:30:36 [kasei]

pgearon: but if commas were optional and could be put in E2, ...

14:30:56 [kasei]

SteveH: same as AndyS's question, if commas were necessary.

14:30:58 [LeeF]

poll on general feeling of E3

14:31:00 [SteveH]

+1

14:31:00 [chimezie]

Zakim, mute me

14:31:00 [Zakim]

Chimezie_Ogbuji should now be muted

14:31:01 [LukeWM_]

0

14:31:05 [chimezie]

+1

14:31:05 [AlexPassant]

+1 on E3

14:31:08 [kasei]

0

14:31:13 [AndyS]

+0 E3

14:31:27 [LeeF]

+1

14:31:29 [SimonS]

+1

14:31:36 [pgearon]

+1 on E3, but would like a comma-free syntax to be possible as well

14:31:41 [bglimm]

0

14:31:47 [Prateek]

0

14:32:11 [kasei]

SteveH: based on strawpoll, will keep examples.

14:32:26 [kasei]

LeeF: seems to be support for E1 and E3, but will look at reasons to do one or the other.

14:32:39 [LeeF]

topic: Update via SPARQL/Protocol

14:33:14 [kasei]

LeeF: pgearon summarized issues in taking update query strings and using them over SPARQL Query protocol.

14:33:18 [LeeF]

paul's summary is http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0096.html

14:34:13 [kasei]

... take away: sparql update should be issued over HTTP POST only

14:34:33 [kasei]

... consensus over that?

14:35:00 [kasei]

pgearon: approached thinking update protocol would be similar to query protocol. not necessarily the case.

14:35:12 [kasei]

... various options: write an unrelated protocol

14:35:19 [kasei]

... would be nice to have a related protcol

14:35:29 [kasei]

... build on what we already have

14:35:40 [kasei]

... option: all updates go through POST

14:36:11 [kasei]

... PUT is supposed to add data to resource, DELETE deletes, POST is only method that is flexible enough

14:36:21 [kasei]

... query or update can be handled by specifying parameters

14:36:37 [LeeF]

q+ to confirm that this works ok with a WSDL specification + HTTP bindings

14:36:39 [kasei]

... option: PUT and POST. subverts PUT.

14:36:58 [kasei]

... option: use different HTTP methods. requires parsing HTTP methods before intention is clear.

14:37:33 [kasei]

... people seem to like option 2 (all updates through POST)

14:38:11 [chimezie]

Zakim, unmute me

14:38:11 [Zakim]

Chimezie_Ogbuji should no longer be muted

14:38:17 [kasei]

LeeF: if we did this, we could specify abstract WSDL interface, HTTP bindings, etc. correct?

14:38:44 [AndyS]

q+ to ask about WSDL and errors.

14:39:12 [LeeF]

ack LeeF

14:39:12 [Zakim]

LeeF, you wanted to confirm that this works ok with a WSDL specification + HTTP bindings

14:39:14 [kasei]

chimezie: yes.

14:39:17 [LeeF]

ack AndyS

14:39:17 [Zakim]

AndyS, you wanted to ask about WSDL and errors.

14:39:46 [kasei]

AndyS: issue from last time, WSDL is SOAP-centric. have to enumerate error codes.

14:40:01 [kasei]

... does anyone know current state?

14:40:55 [LeeF]

ISSUE: Can we use the correct meaning of the full slate of HTTP errors when specifying the update protocol via WSDL?

14:40:55 [trackbot]

Created ISSUE-33 - Can we use the correct meaning of the full slate of HTTP errors when specifying the update protocol via WSDL? ; please complete additional details at http://www.w3.org/2009/sparql/track/issues/33/edit .

14:40:58 [kasei]

... can we use the correct meaning of all the HTTP errors? will come up with update protocol.

14:41:26 [kasei]

LeeF: any SOAP people on the call?

14:42:05 [kasei]

... will investigate answers.

14:42:24 [LeeF]

ACTION: Lee to investigate ISSUE-33

14:42:24 [trackbot]

Created ACTION-77 - Investigate ISSUE-33 [on Lee Feigenbaum - due 2009-08-11].

14:42:28 [kasei]

... how much desire is there to continue SOAP support?

14:42:52 [AndyS]

q+

14:42:55 [SteveH]

+1 to POST only

14:43:00 [LeeF]

ack AndyS

14:43:03 [kasei]

LeeF: are people happy with making update protocol use POST with ?update=... ?

14:43:31 [pgearon]

+q about single or multiple endpoints

14:43:35 [chimezie]

I'm not sure what the role of the csgi parameter in this scenario

14:43:38 [pgearon]

+q

14:43:44 [SteveH]

+1 to AndyS

14:43:45 [kasei]

AndyS: if everything is on one endpoint, hard to use external security.

14:43:45 [chimezie]

s/in/is in

14:43:53 [LeeF]

ack pgearon

14:44:08 [SimonS]

+1 for allowing both same and different endpoint for update

14:44:16 [kasei]

pgearon: think we need to have a read-only endpoint. useful to do all read operations on read/write endpoint, but seperate issue.

14:44:48 [chimezie]

R+W shouldn't be required, if i understand the question

14:44:55 [kasei]

LeeF: (clarifying) can't be the case that all endpoints must support read and write?

14:45:02 [chimezie]

but it should be *okay* to bind two services to the same network address

14:45:27 [chimezie]

+q about cgi param

14:45:35 [LeeF]

ack chimezie

14:45:50 [AndyS]

I'm OK with read-only endpoint and read-write endpoint. Just care about framing to stress read-only is publishing safely.

14:46:03 [bglimm]

soory, fire alarm here

14:46:06 [bglimm]

I have to leave

14:46:08 [kasei]

chimezie: what did you have in mind with update=?

14:46:14 [Zakim]

-bglimm

14:46:22 [AndyS]

q+ to ask about caching

14:46:50 [kasei]

pgearon: by having update=, only allows update operations. no query operations following update=.

14:47:04 [LukeWM_]

q+

14:47:35 [kasei]

chimezie: address you're POSTing to implies action you want.

14:47:45 [LeeF__]

LeeF__ has joined #sparql

14:47:45 [kasei]

(sorry if i'm missing some of this... getting some static on this end.)

14:48:19 [kasei]

pgearon: want seperation to allow decisions based on security concerns.

14:48:36 [kasei]

... want code that doesn't know how to do any writing to data store.

14:48:37 [LeeF__]

q?

14:48:48 [kasei]

... want to protect write code much more strongly.

14:49:05 [kasei]

... would be nice to read from write endpoint, but not necessary.

14:49:24 [LeeF]

ack LukeWM_

14:50:07 [kasei]

can someone scribe what Luke is saying? I can't make it out.

14:50:26 [chimezie]

I guess you can enforce separation (for security purposes) either at the protocol level or leave it up to the 'query engine' to manage access control (below the level of the protocol)

14:50:32 [LeeF]

ack AndyS

14:50:32 [Zakim]

AndyS, you wanted to ask about caching

14:50:48 [kasei]

AndyS: like the idea of having read/write endpoints. useful.

14:51:08 [kasei]

... if you do GET as read, might see inconsistent views. maybe only allow POST on read/write endpoints.

14:51:36 [kasei]

... want to put security outside the endpoint. implementation choice.

14:52:16 [SteveH]

I like required POST, and update=

14:52:25 [AndyS]

+1

14:52:28 [kasei]

LeeF: consensus in support of HTTP POST. no consensus yet regarding ?query= and ?update= seperation.

14:53:05 [LeeF]

PROPOSED: HTTP version of SPARQL/Protocol for SPARQL/Update statements involves always sending the update statements over HTTP POST

14:53:30 [AndyS]

Seconded

14:53:39 [pgearon]

+1

14:53:49 [LeeF]

RESOLVED: HTTP version of SPARQL/Protocol for SPARQL/Update statements involves always sending the update statements over HTTP POST

14:53:57 [LeeF]

no objections or abstentions

14:54:14 [LukeWM_]

My point before was: although separate read/write and read endpoints seem more convenient, in practice applications will end up simply using read/write for everything.

14:54:21 [kasei]

LeeF: is question of whether parameter is query= or update= something to be continued on mailing list?

14:54:32 [kasei]

chimezie: yes.

14:54:41 [LeeF]

ACTION: chimezie to continue discussion of update= vs. query= on the mailing list

14:54:41 [trackbot]

Created ACTION-78 - Continue discussion of update= vs. query= on the mailing list [on Chimezie Ogbuji - due 2009-08-11].

14:55:12 [kasei]

LeeF: want to allow read only and read/write endpoints.

14:55:22 [SteveH]

if we have read/write endpoints then using query= everywhere will be problematic for some implementations

14:55:32 [kasei]

... punt on service descriptions until next week.

14:55:47 [chimezie]

Zakim, mute me

14:55:47 [Zakim]

Chimezie_Ogbuji should now be muted

14:56:02 [SteveH]

bye

14:56:02 [LeeF]

adjourned

14:56:03 [chimezie]

take care

14:56:08 [Zakim]

-Chimezie_Ogbuji

14:56:10 [Zakim]

-Prateek

14:56:15 [Zakim]

-Garlik

14:56:18 [kasei]

Zakim, unmute me

14:56:18 [Zakim]

kasei should no longer be muted

14:56:20 [SimonKJ]

thanks Lee

14:56:21 [Zakim]

-SimonS

14:56:24 [Zakim]

-AlexPassant

14:56:26 [SimonKJ]

SimonKJ has left #sparql

14:56:26 [Zakim]

-SimonKJ

14:56:32 [SimonS]

SimonS has left #sparql

14:56:56 [Zakim]

-AndyS

14:57:09 [Zakim]

-pgearon

14:57:19 [LeeF]

minutes instructions: http://lists.w3.org/Archives/Public/public-rdf-dawg/2009AprJun/0406.html

14:58:03 [Zakim]

-kasei

14:58:03 [Zakim]

SW_(SPARQL)10:00AM has ended

14:58:04 [Zakim]

Attendees were AlexPassant, kasei, AndyS, Lee_Feigenbaum, SimonKJ, SteveH, LukeWM, pgearon, SimonS, bglimm, Chimezie_Ogbuji, Prateek

15:01:36 [LukeWM]

LukeWM has joined #sparql

15:03:41 [bglimm]

bglimm has joined #SPARQL

15:08:24 [AndyS]

AndyS has joined #sparql

15:14:46 [kasei]

LeeF: the notes don't mention this, but I see last week's chatlog removes a bunch of cruft (people joining, telling Zakim who they are). I should remove that sort of thing?

15:15:30 [LeeF]

i tend to do that

15:15:33 [LeeF]

but it's really up to you

15:15:44 [kasei]

sure, ok.

16:11:10 [AxelPolleres]

AxelPolleres has joined #sparql

16:26:50 [pgearon]

pgearon has joined #sparql

16:59:37 [AxelPolleres]

AxelPolleres has joined #sparql

17:04:16 [Zakim]

Zakim has left #sparql

17:32:47 [LukeWM]

LukeWM has joined #sparql

17:41:39 [AxelPolleres]

AxelPolleres has joined #sparql