From SPARQL Working Group
Please justify/explain all edits to this page, in your "edit summary" text.
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 herman> 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 herman: 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 herman> 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 herman> -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 herman> 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 herman: 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 herman: 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 herman> 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 herman: 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 herman: 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 herman: 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 herman> 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 herman> -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> AxelPolleres: 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 herman> 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 Herman 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 # SPECIAL MARKER FOR CHATSYNC. DO NOT EDIT THIS LINE OR BELOW. SRCLINESUSED=00000277