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
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]
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]
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]
14:01:37 [LeeF]
. +LeeF
14:01:47 [ericP]
. + ericP
14:01:51 [chimezie]
14:01:53 [SteveH]
. +SteveH
14:01:55 [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:+ 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]
14:07:11 [chimezie]
Topic: Agenda
14:07:15 [LeeF]
PROPOSED: Approve minutes at
14:07:26 [AxelPolleres]
14:07:42 [LeeF]
RESOVLED: Approve minutes at
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]
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]
14:11:11 [KjetilK]
ack pgearon
14:11:41 [pgearon]
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]
14:13:39 [AndyS]
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]
14:19:04 [KjetilK]
14:19:05 [AxelPolleres]
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]
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]
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]
14:28:52 [SteveH]
Suported by HTTP libraries, or servers?
14:28:52 [KjetilK]
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]
14:35:16 [KjetilK]
ack me
14:35:17 [SteveH]
PUT http://endpoint/rest/?graph=
14:35:31 [chimezie]
14:35:32 [AxelPolleres]
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]
14:45:34 [LukeWM]
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]
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]
14:48:33 [KjetilK]
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]
14:49:47 [AxelPolleres]
LeeF: general agreement with that?
14:49:52 [AxelPolleres]
14:49:54 [Prateek]
14:49:59 [SimonS]
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]
14:50:36 [bglimm]
14:50:41 [LeeF]
14:51:09 [AlexPassant]
14:51:10 [LukeWM]
14:51:10 [pgearon]
14:51:13 [ivan]
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]
14:58:12 [KjetilK]
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]
14:59:52 [ericP]
scribenick: ericP
15:00:03 [AxelPolleres]
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]
15:00:26 [KjetilK]
15:00:33 [ericP]
15:00:36 [ericP]
15:00:49 [LeeF]
PROPOSAL: SPARQL WG will pursue RESTful operations for updating RDF stores
15:00:54 [SteveH]
15:00:57 [ericP]
15:00:58 [KjetilK]
15:00:59 [bglimm]
15:01:01 [SimonS]
15:01:02 [AlexPassant]
15:01:05 [pgearon]
15:01:06 [Prateek]
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]
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 .
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]
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 as of 11:11EDT on 2009-06-02 addresses our LC comments on rdf:text
15:11:37 [ericP]
15:11:52 [AndyS]
15:12:15 [ivan]
15:12:19 [bglimm]
15:12:21 [AndyS]
15:12:29 [LeeF]
ericP, do you want to communicate this?
15:12:40 [ericP]
15:12:48 [SteveH]
15:13:06 [ericP]
ACTION: ericP to tell OWL/RIF that SPARQL is content with
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
15:13:16 [trackbot]
Created ACTION-35 - Tell OWL/RIF that SPARQL is content with [on Eric Prud'hommeaux - due 2009-06-09].
15:13:23 [AndyS]
15:13:30 [AndyS]
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