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