IRC log of sparql on 2009-08-18

Timestamps are in UTC.

13:55:52 [RRSAgent]
RRSAgent has joined #sparql
13:55:52 [RRSAgent]
logging to http://www.w3.org/2009/08/18-sparql-irc
13:55:54 [trackbot]
RRSAgent, make logs world
13:55:54 [Zakim]
Zakim has joined #sparql
13:55:56 [trackbot]
Zakim, this will be 77277
13:55:56 [Zakim]
ok, trackbot; I see SW_(SPARQL)10:00AM scheduled to start in 5 minutes
13:55:57 [trackbot]
Meeting: SPARQL Working Group Teleconference
13:55:57 [trackbot]
Date: 18 August 2009
13:56:00 [LeeF]
zakim, this will be SPARQL
13:56:00 [Zakim]
ok, LeeF; I see SW_(SPARQL)10:00AM scheduled to start in 4 minutes
13:56:04 [LeeF]
Chair: LeeF
13:56:05 [AxelPolleres]
AxelPolleres has joined #sparql
13:56:24 [LeeF]
Regrets: BGlimm, Orri, SteveH, LukeWM, AndyS, Bijan
13:56:27 [kasei]
didn't get an email off, but re: serv. desc. discovery, michael hausenblas pushed us to look at LRDD on #swig the other day.
13:56:47 [kasei]
dunno if anyone here has any experience with it, or how it differs from the Link: header option already discussed.
13:56:47 [LeeF]
LROD?
13:57:05 [kasei]
I was given this link: http://www.hueniverse.com/hueniverse/2009/03/the-discovery-protocol-stack.html
13:57:19 [LeeF]
You know what we clearly need? a wiki page with all of these options
13:57:26 [kasei]
with the belief that we were only discussing the lrdd layer, not the xrd stuff.
13:57:55 [LeeF]
http://tools.ietf.org/html/draft-hammer-discovery-03
13:58:22 [Zakim]
SW_(SPARQL)10:00AM has now started
13:58:29 [Zakim]
+Lee_Feigenbaum
13:58:42 [Zakim]
+??P4
13:58:53 [LeeF]
zakim, Lee_Feigenbaum is m
13:58:53 [Zakim]
+m; got it
13:58:56 [AlexPassant]
Zakim, ??P4 is me
13:58:56 [Zakim]
+AlexPassant; got it
13:58:57 [LeeF]
zakim, m is me
13:58:58 [Zakim]
+LeeF; got it
13:59:21 [Zakim]
+??P7
13:59:30 [ivan]
zakim, dial ivan-voip
13:59:30 [Zakim]
ok, ivan; the call is being made
13:59:31 [SimonS]
zakim, ??P7 is me
13:59:31 [Zakim]
+Ivan
13:59:31 [Zakim]
+SimonS; got it
13:59:48 [SimonS]
zakim, mute me
13:59:48 [Zakim]
SimonS should now be muted
13:59:49 [Zakim]
+kasei
14:00:04 [SimonKJ]
SimonKJ has joined #sparql
14:00:15 [kasei]
Zakim, mute me
14:00:15 [Zakim]
kasei should now be muted
14:00:18 [Zakim]
+AxelPolleres
14:01:03 [kasei]
Zakim, unmute me
14:01:03 [Zakim]
kasei should no longer be muted
14:01:53 [pgearon]
pgearon has joined #sparql
14:01:59 [LeeF]
zakim, who's on the phone?
14:01:59 [Zakim]
On the phone I see LeeF, AlexPassant, SimonS (muted), Ivan, kasei, AxelPolleres
14:02:02 [kasei]
Zakim, mute me
14:02:02 [Zakim]
kasei should now be muted
14:02:26 [Zakim]
+pgearon
14:03:26 [LeeF]
Agenda: http://www.w3.org/2009/sparql/wiki/Agenda-2009-08-18
14:03:48 [LeeF]
Scribenick: pgearon
14:04:00 [LeeF]
topic: Admin
14:04:07 [LeeF]
PROPOSED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-08-11
14:04:35 [Zakim]
+ +1.919.663.aaaa
14:04:37 [pgearon]
Lee: we expect to discuss service descriptions, but won't make any firm decisions due to the limited numbers of attendees
14:04:51 [ericP]
Zakim, please dial ericP-office
14:04:51 [Zakim]
ok, ericP; the call is being made
14:04:52 [LeeF]
RESOLVED: Approve minutes at http://www.w3.org/2009/sparql/meeting/2009-08-11
14:04:53 [Zakim]
+EricP
14:04:59 [SimonKJ]
Zakim, +1.919.663.aaa is SimonKJ
14:04:59 [Zakim]
+SimonKJ; got it
14:05:39 [LeeF]
Next meeting: 2009-08-25 @ 15:00 BST / 10:00 EDT SimonKJ to scribe
14:05:52 [LeeF]
F2f planning - http://www.w3.org/2009/sparql/wiki/F2F2
14:08:01 [LeeF]
topic: Liaisons
14:08:11 [Prateek]
Prateek has joined #sparql
14:08:39 [Zakim]
+cory
14:08:48 [Prateek]
Zakim, cory is Prateek
14:08:48 [Zakim]
+Prateek; got it
14:09:28 [Zakim]
+??P22
14:09:39 [KjetilK]
Zakim, ??P22 is me
14:09:39 [Zakim]
+KjetilK; got it
14:09:47 [KjetilK]
Zakim, mute me
14:09:47 [Zakim]
KjetilK should now be muted
14:09:49 [pgearon]
after the document deadlines, but there is still opportunity to make contributions if quick about it
14:09:56 [LeeF]
(re: RIF)
14:11:56 [pgearon]
RIF work is not a formal working group action that we need to track
14:12:13 [LeeF]
trackbot, close ACTION-71
14:12:13 [trackbot]
ACTION-71 Re-check where to announce F&R (e.g. liaisons) closed
14:14:13 [LeeF]
http://www.w3.org/2009/sparql/wiki/Design:Aggregate
14:14:17 [LeeF]
http://www.w3.org/2009/sparql/wiki/Design:SubSelect
14:14:37 [pgearon]
+q
14:14:47 [LeeF]
ack pgearon
14:15:52 [pgearon]
pgearon: did other forms of assignment (e.g. LET) make the cut?
14:15:58 [pgearon]
LeeF: no
14:16:38 [LeeF]
topic: service description
14:16:42 [ericP]
paul, note whirled peas
14:16:55 [pgearon]
LeeF: understand that some of these issues may come up over time, but unless other features are needed for world peace then they probably won't be revised
14:17:16 [LeeF]
most recent service description discovery thread - http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0187.html
14:18:01 [pgearon]
LeeF: sees 4 main options at the endpoint level. Notes there isn't much support at the query level, except from ericP
14:18:40 [pgearon]
option 1: link header that points to a URI where the service description can be downloaded
14:19:07 [pgearon]
pros: easy to get to, easy to implement. cons: 2 requests
14:19:55 [LeeF]
LRDD http://tools.ietf.org/html/draft-hammer-discovery-03
14:20:19 [pgearon]
LRDD = Link based resource descriptor discovery
14:20:56 [pgearon]
+q
14:21:07 [SimonKJ]
+q
14:21:31 [pgearon]
ericP: P3P have tried to use headers. Notes the deployment of this has been low
14:21:58 [pgearon]
ericP: little development in parsing headers
14:22:30 [LeeF]
ack pgearon
14:22:45 [LeeF]
pgearon: think this is relatively clean but the double call is a real issue
14:23:01 [LeeF]
pgearon: i'd only want to go that way if there was a common URI that the header is likely to point you to so that it's easily guessable
14:24:00 [LeeF]
pgearon: maybe could specify that once you've said the doc will be at a particular URI it will always be there - to minimize double calls
14:24:05 [LeeF]
ack SimonKJ
14:24:08 [KjetilK]
+1 to pgearon
14:25:20 [pgearon]
SimonKJ: could use HEAD for a similar approach, but haven't yet defined what HEAD means
14:26:10 [pgearon]
SimonKJ: other approaches do things like turning the query "on it's head"
14:26:55 [pgearon]
SimonKJ: thinks there's precedent for option 7 (?) which is a GET on the endpoint alone
14:26:57 [LeeF]
q?
14:27:24 [pgearon]
SimonKJ: (These comments are mostly around OpenSearch)
14:27:50 [pgearon]
LeeF: would like to discuss all methods, and we'll finish with a straw poll
14:28:05 [LeeF]
straw poll on HTTP-Header approach
14:28:09 [LeeF]
+1 - i prefer the method
14:28:13 [LeeF]
0 - i could live with the method
14:28:21 [LeeF]
-1 - i'm not too happy with the method
14:28:32 [pgearon]
LeeF: correction, wants to do poll on each option as it is discussed
14:28:52 [pgearon]
+q
14:29:08 [pgearon]
ivan: are the options mutually exclusive?
14:29:18 [pgearon]
LeeF: would rather only agree to one
14:30:34 [pgearon]
LeeF: service description could contain info about how to query for the service description
14:30:51 [LeeF]
ack pgearon
14:31:35 [kasei]
0
14:31:35 [LeeF]
HTTP-Header straw poll:
14:31:38 [ericP]
O
14:31:40 [ivan]
0
14:31:40 [LeeF]
0
14:31:42 [AxelPolleres]
0
14:31:43 [SimonS]
0
14:31:46 [AlexPassant]
0
14:31:46 [Prateek]
0
14:31:47 [SimonKJ]
0
14:31:53 [KjetilK]
-1
14:31:53 [pgearon]
-1
14:32:15 [pgearon]
LeeF: likely to go to more than one option if one of them is for a query and one for HTTP
14:32:50 [pgearon]
option 2 - use the HTTP OPTION verb on the endpoint URI
14:33:07 [pgearon]
pro - nice use of this underused method
14:33:31 [pgearon]
con - spec says you can't cache the results of an OPTION
14:33:41 [AlexPassant]
q+ to ask about the cache mechanism
14:33:48 [LeeF]
ack AlexPassant
14:33:48 [Zakim]
AlexPassant, you wanted to ask about the cache mechanism
14:34:07 [kasei]
i believe it's MUst Not
14:34:16 [KjetilK]
Responses to this method are not cacheable.
14:34:21 [KjetilK]
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
14:34:21 [kasei]
"Responses to this method are not cacheable."
14:34:37 [KjetilK]
q+
14:34:37 [pgearon]
question was - is the inability to cache a "MUST NOT" or "SHOULD NOT"?
14:34:44 [LeeF]
ack kjetil
14:35:41 [KjetilK]
Zakim, mute me
14:35:41 [Zakim]
KjetilK should now be muted
14:35:48 [LeeF]
straw poll on OPTIONS:
14:35:55 [ivan]
-1
14:35:56 [SimonKJ]
-1
14:35:56 [kasei]
-1
14:35:56 [ericP]
o
14:35:56 [KjetilK]
0
14:35:59 [pgearon]
KjetilK: notes that OPTION is easy to implement (contradicting LeeF's concerns earlier), but caching is a major problem here
14:35:59 [LeeF]
-1
14:36:02 [pgearon]
-1
14:36:03 [ericP]
oh
14:36:05 [ericP]
0
14:36:08 [Prateek]
0
14:36:10 [AxelPolleres]
-1 non-chaability seems to be a major problem
14:36:15 [AlexPassant]
-1 (with the cache issue)
14:36:15 [SimonS]
-1 I love the idea, but no caching is a no-go
14:36:31 [AxelPolleres]
s/chaability/cachability/
14:36:32 [pgearon]
+1 SimonS
14:36:44 [KjetilK]
pgearon, actually, what I said was that I'd like to do this (which is the purist view) and 8, which is the pragmatic and easy way
14:38:09 [pgearon]
option 3 - standard query, using content negotiation to get the service description
14:38:18 [ivan]
q+
14:38:19 [kasei]
the "conneg" option might not need actual conneg if the endpoint uri returns RDFa
14:38:40 [pgearon]
correction - this is option 7 (not 3)
14:38:49 [LeeF]
ack ivan
14:39:20 [pgearon]
ivan: agrees with Kendall that we will get all the HTTP purists up in arms, and it's not worth the fight
14:39:38 [kasei]
q+ about http purists
14:39:47 [pgearon]
ivan: if a query with CONSTRUCT then will still get back RDF/XML, how will this work?
14:39:49 [SimonKJ]
+q
14:39:55 [kasei]
q+
14:40:11 [pgearon]
LeeF: this option is uses no query parameter, so you won't have a CONSTRUCT
14:40:32 [LeeF]
q?
14:40:40 [LeeF]
ack SimonKJ
14:40:57 [pgearon]
LeeF: endpoints usually return an HTTP form, and this option would break those sites.
14:41:00 [KjetilK]
q+
14:41:44 [pgearon]
SimonKJ: thinks that the common idea of returning a form is unfortunate. We could be obnoxious and take control of the endpoint
14:42:00 [pgearon]
+1 SimonKJ
14:42:01 [AxelPolleres]
q+ to ask whether pointer to a form can't be simply part of the description returned.
14:42:31 [pgearon]
I think it's the job of this forum to try to standardize common practice, where possible
14:42:32 [kasei]
Zakim, unmute me
14:42:32 [Zakim]
kasei should no longer be muted
14:42:33 [LeeF]
ack kasei
14:43:08 [ivan]
q+
14:43:19 [pgearon]
greg: thinks that HTML at the endpoint SHOULD return a description of the endpoint
14:43:55 [pgearon]
greg: this would be a human friendly version of the description
14:44:04 [LeeF]
ack kjetil
14:44:10 [kasei]
Zakim, mute me
14:44:10 [Zakim]
kasei should now be muted
14:44:37 [AxelPolleres]
q- kjetil was faster :-)
14:44:41 [AxelPolleres]
q-
14:44:44 [pgearon]
KjetilK: service description could point to this HTML form
14:44:45 [SimonKJ]
+q
14:45:46 [LeeF]
q?
14:46:06 [pgearon]
+q
14:46:36 [Zakim]
-LeeF
14:46:37 [KjetilK]
Zakim, mute me
14:46:37 [Zakim]
KjetilK should now be muted
14:46:38 [pgearon]
LeeF excuses himself
14:47:06 [pgearon]
AxelPolleres is now the chair
14:47:47 [ericP]
how do i add Category:Design to http://www.w3.org/2009/sparql/wiki/Design:Project_Expression in a way that the system will recognize?
14:47:49 [pgearon]
ivan: we could have the html containing the additional information about the service description, eg. RDFa or GRDDL
14:47:54 [kasei]
if we use an html link, we're back to a 2-request scenario.
14:48:08 [pgearon]
ivan: or using a link header to request the information
14:48:14 [AxelPolleres]
q?
14:48:22 [AxelPolleres]
ack ivan
14:48:45 [kasei]
I like the option to use just RDFa or GRDDL to allow option 7 to not use conneg at all
14:49:12 [pgearon]
ivan: since most endpoints already return something at the endpoint URI, then this can be useful to provide information
14:49:37 [AxelPolleres]
Option 7': GET would return service description OR an implicit reference in RDFa for instance
14:49:45 [AlexPassant]
+1 for embedding informations in the form, unfortunately some endpoints do not provide HTML forms :-/
14:49:54 [pgearon]
SimonKJ: thinks that only providing RDFa is too big a jump
14:50:20 [pgearon]
SimonKJ: has some sympathy for the idea, but it's too much
14:50:31 [kasei]
q+ to respond to ivan's html link element
14:50:41 [SimonKJ]
-q
14:50:46 [AxelPolleres]
ack SimonKJ
14:51:22 [AxelPolleres]
paul: RDFa (implementations?) still not quite complete at the moment
14:52:23 [AxelPolleres]
q?
14:52:27 [kasei]
Zakim, unmute me
14:52:27 [Zakim]
kasei should no longer be muted
14:52:37 [AlexPassant]
q+ to ask about the minimal requirements for content-negociation
14:52:57 [AxelPolleres]
ack pgearon
14:53:01 [AxelPolleres]
ack kasei
14:53:01 [Zakim]
kasei, you wanted to respond to ivan's html link element
14:53:10 [pgearon]
pgearon: if service description is going to appear in HTML and/or RDFa then I'm no longer opposed to using content negotiation to get an RDF document
14:53:34 [pgearon]
greg: ivan's suggestion of a link takes us back to 2 requests
14:53:37 [AxelPolleres]
kasei: link element would bring us back to Option 1, i.e. 2 requests
14:53:47 [pgearon]
greg = kasei
14:53:47 [ivan]
and setting up content negotiations might require administrator access in some places...
14:53:51 [kasei]
Zakim, mute me
14:53:53 [Zakim]
kasei should now be muted
14:54:12 [AxelPolleres]
q?
14:55:02 [pgearon]
2 straw polls. The first for option 7 pure, with just content negotiation
14:55:09 [ivan]
-1
14:55:10 [pgearon]
-1
14:55:10 [kasei]
+1
14:55:10 [KjetilK]
-1
14:55:13 [SimonS]
-1
14:55:15 [SimonKJ]
+1
14:55:19 [AxelPolleres]
0
14:55:23 [Prateek]
+1
14:55:24 [AlexPassant]
+1
14:55:24 [kasei]
ouch :)
14:55:32 [ericP]
-.5, i guess
14:56:12 [kasei]
I'm not entirely clear on what option7 lite is. just the link element?
14:56:13 [AxelPolleres]
Option 7 light: RDF or "RDF implicit"
14:56:15 [pgearon]
option 7 lite
14:56:27 [pgearon]
Is this - "content negotiation with RDFa and/or human readable form" ?
14:56:33 [ericP]
-1 (should have -1'd the above as well)
14:57:02 [AxelPolleres]
ACTION: Axel to summarize "suboptions" of option 7
14:57:03 [trackbot]
Created ACTION-81 - Summarize "suboptions" of option 7 [on Axel Polleres - due 2009-08-25].
14:57:11 [pgearon]
AlexPolleres: nearly out of time, we should discuss this explicitly on the mailing list
14:58:09 [AxelPolleres]
Option 8 would be in the protocol as an additioonal query parameter.
14:59:43 [pgearon]
option 8 hasn't had major problems raised against it yet. We need to ask the mailing list for opinions on this
14:59:46 [ivan]
bye all
14:59:52 [pgearon]
thanks Alex
14:59:53 [Zakim]
-EricP
14:59:55 [SimonKJ]
SimonKJ has left #sparql
14:59:55 [Zakim]
-SimonKJ
14:59:55 [SimonS]
bye
14:59:57 [Zakim]
-Ivan
14:59:58 [Zakim]
-kasei
14:59:59 [Zakim]
-Prateek
15:00:01 [Zakim]
-SimonS
15:00:02 [Zakim]
-pgearon
15:00:02 [Zakim]
-KjetilK
15:00:08 [Zakim]
-AlexPassant
15:00:14 [SimonS]
SimonS has left #sparql
15:01:01 [AxelPolleres]
Option 8 didn't yet go to strawpoll, not sufficient discussion yet, but doesn't seem to have major opposition on the mailinglist.
15:01:14 [Zakim]
-AxelPolleres
15:01:15 [Zakim]
SW_(SPARQL)10:00AM has ended
15:01:16 [Zakim]
Attendees were AlexPassant, LeeF, Ivan, SimonS, kasei, AxelPolleres, pgearon, +1.919.663.aaaa, EricP, SimonKJ, Prateek, KjetilK
15:02:17 [AxelPolleres]
rrsagent, make records public
15:06:46 [AxelPolleres]
AxelPolleres has left #sparql
15:49:58 [AxelPolleres]
AxelPolleres has joined #sparql
17:14:08 [Zakim]
Zakim has left #sparql
18:09:26 [LeeF]
LeeF has joined #sparql