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