Chatlog 2009-08-18

See original RRSAgent log and preview nicely formatted version.

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