edit

Linked Data Platform (LDP) Working Group Teleconference

Minutes of 15 April 2014

Agenda
http://www.w3.org/2012/ldp/wiki/F2F5#Day_1_-_Tuesday_April_15
Present
Alexandre Bertails, Andrei Sambra, Arnaud Le Hors, Ashok Malhotra, Cody Burleson, Eric Prud'hommeaux, John Arwe, Miguel Aragón, Nandana Mihindukulasooriya, Roger Menday, Sandro Hawke, Sergio Fernández, Steve Speicher, Ted Thibodeau
Guests
Tim Berners-Lee (W3C)
Chair
Arnaud Le Hors
Scribe
Alexandre Bertails, Andrei Sambra
IRC Log
Original
Resolutions
  1. We stick with the current null-relative design, and we add a non-normative explanation of how that works, how to do it in some tools, etc, in a footnote, appendix, or (hopefully) BP. link
  2. Add to BP that it follows from the specs that /../ URLs should not be used in POSTed content link
  3. Remove references to named graphs: remove "named" in terminology section, remove paragraph in examples, remove sentence in section 5.2.3.4 and 5.2.4.2 link
  4. We'll use rel=describedby as in the spec currently, for both metadata on binary resources, and expressing constraints during server error messages. These are both descriptions and there may be lots of other kinds in the future, too. link
  5. Copy http://www.w3.org/TR/powder-dr/#appD, more or less, to LDP, so that the link registry can avoid the powder errata situation, pending confirmation from IETF liaison that this is reasonable link
  6. Define exit criteria: Each feature implemented and each test passed by at least two independent implementations link
  7. At a minimum, on paging, we'll provide a way for clients to detect that a triple fell through the cracks during paging. link
  8. We're not going to require use of transactions in order to have paging link
Topics
13:00:19 <RRSAgent> logging to http://www.w3.org/2014/04/15-ldp-irc

RRSAgent IRC Bot: logging to http://www.w3.org/2014/04/15-ldp-irc

13:00:21 <trackbot> RRSAgent, make logs public

Trackbot IRC Bot: RRSAgent, make logs public

13:00:23 <trackbot> Zakim, this will be LDP

Trackbot IRC Bot: Zakim, this will be LDP

13:00:23 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot

Zakim IRC Bot: I do not see a conference matching that name scheduled within the next hour, trackbot

13:00:24 <trackbot> Meeting: Linked Data Platform (LDP) Working Group Teleconference
13:00:24 <trackbot> Date: 15 April 2014
13:00:52 <Arnaud> zakim, room for 10 for 10 hours

Arnaud Le Hors: zakim, room for 10 for 10 hours

13:00:52 <Zakim> I don't understand 'room for 10 for 10 hours', Arnaud

Zakim IRC Bot: I don't understand 'room for 10 for 10 hours', Arnaud

13:01:12 <Arnaud> zakim, room for 10 for 10h

Arnaud Le Hors: zakim, room for 10 for 10h

13:01:12 <Zakim> I don't understand 'room for 10 for 10h', Arnaud

Zakim IRC Bot: I don't understand 'room for 10 for 10h', Arnaud

13:01:58 <Arnaud> zakim, room for 10 for 600 minutes

Arnaud Le Hors: zakim, room for 10 for 600 minutes

13:01:58 <Zakim> I don't understand 'room for 10 for 600 minutes', Arnaud

Zakim IRC Bot: I don't understand 'room for 10 for 600 minutes', Arnaud

13:03:50 <sandro> Zakim, room for 10 people for 600 minutes?

Sandro Hawke: Zakim, room for 10 people for 600 minutes?

13:03:51 <Zakim> ok, sandro; conference Team_(ldp)13:03Z scheduled with code 26631 (CONF1) for 600 minutes until 2303Z

Zakim IRC Bot: ok, sandro; conference Team_(ldp)13:03Z scheduled with code 26631 (CONF1) for 600 minutes until 2303Z

13:04:26 <Zakim> Team_(ldp)13:03Z has now started

Zakim IRC Bot: Team_(ldp)13:03Z has now started

13:04:33 <Zakim> + +1.617.715.aaaa

Zakim IRC Bot: + +1.617.715.aaaa

13:05:20 <sergio> guys, I cannot be all time connected by phone, at least today

Sergio Fernández: guys, I cannot be all time connected by phone, at least today

13:05:26 <sergio> so ping me if you need somethign from me

Sergio Fernández: so ping me if you need somethign from me

13:05:43 <Arnaud> hi everyone

Arnaud Le Hors: hi everyone

13:05:44 <sergio> I'll try to connect for tomorrow and the test cases slot

Sergio Fernández: I'll try to connect for tomorrow and the test cases slot

13:05:50 <Arnaud> we're still getting set up here

Arnaud Le Hors: we're still getting set up here

13:06:23 <sergio> ok

Sergio Fernández: ok

13:07:18 <Arnaud> we forgot to reserve the phone bridge so the code is 26631 instead of the usual ldpwg

Arnaud Le Hors: we forgot to reserve the phone bridge so the code is 26631 instead of the usual ldpwg

13:07:49 <Arnaud> Arnaud has changed the topic to: Teleconference code is 26631 (CONF1)!! LDP WG: http://www.w3.org/2012/ldp - next agenda: https://www.w3.org/2012/ldp/wiki/F2F5#Agenda

Arnaud Le Hors: Arnaud has changed the topic to: Teleconference code is 26631 (CONF1)!! LDP WG: http://www.w3.org/2012/ldp - next agenda: https://www.w3.org/2012/ldp/wiki/F2F5#Agenda

13:14:34 <sandro> video link for meeting -- http://bit.ly/swa-hangout

(No events recorded for 6 minutes)

Sandro Hawke: video link for meeting -- http://bit.ly/swa-hangout

13:16:24 <betehess> scribenick: Alexandre

(Scribe set to Alexandre Bertails)

13:16:31 <betehess> scribenick: betehess
13:16:37 <betehess> scribe: Alexandre
<betehess> guest: Tim (timbl) Berners-Lee, W3C
<betehess> Present: betehess, deiu, arnaud, ashok, cody, ericp, johnarwe, MiguelAraCo, nmihindu, roger, sandro, sergio, steves, tallted
<betehess> agenda: http://www.w3.org/2012/ldp/wiki/F2F5#Day_1_-_Tuesday_April_15
<betehess> chair: Arnaud
<betehess> topic: Welcome, logistics, recap of meeting goals, agenda amendments.

1. Welcome, logistics, recap of meeting goals, agenda amendments.

13:19:46 <betehess> Arnaud: got a request from nandana to move the Primer

Arnaud Le Hors: got a request from nandana to move the Primer

13:20:06 <betehess> ... so I swapped Primer and BP

... so I swapped Primer and BP

13:20:26 <betehess> ... let's get started

... let's get started

13:20:29 <betehess> ... want to talk where we are

... want to talk where we are

13:20:35 <betehess> ... finished 2 LC period

... finished 2 LC period

13:20:41 <betehess> ... few comments, not too many

... few comments, not too many

13:20:48 <betehess> ... we have to dispose of them properly

... we have to dispose of them properly

13:21:09 <betehess> ... be prepared for the review w/ w3c management for later phases

... be prepared for the review w/ w3c management for later phases

13:21:15 <betehess> ... comments are part of the review

... comments are part of the review

13:21:26 <betehess> ... good to  have some comments: people have looked at it!

... good to have some comments: people have looked at it!

13:21:49 <betehess> ... we do best effort to satisfy the comments

... we do best effort to satisfy the comments

13:21:55 <betehess> ... a bit confused with the tracker

... a bit confused with the tracker

13:22:10 <betehess> ... I forward the comments to the list but they don't appear in the tracker

... I forward the comments to the list but they don't appear in the tracker

13:22:47 <betehess> ... need a plan for addressing the comments before leaving the meeting

... need a plan for addressing the comments before leaving the meeting

13:22:55 <betehess> ... I was at WWW last week

... I was at WWW last week

13:23:06 <betehess> ... *many* people came to me to ask me the status of the spec

... *many* people came to me to ask me the status of the spec

13:23:15 <betehess> ... the community is waiting for me

... the community is waiting for it

13:23:26 <betehess> s/for me/for it/
13:23:38 <betehess> ... we split the spec

... we split the spec

13:23:46 <betehess> ... and make sure everybody wants it

... and make sure everybody wants it

13:24:07 <betehess> ... UC&R was republished as a Notee

... UC&R was republished as a Note

13:24:12 <betehess> s/Notee/Note/
13:24:26 <betehess> ... we won't talk about it unless you ask

... we won't talk about it unless you ask

13:24:37 <betehess> ... test suite and validator will be important for CR

... test suite and validator will be important for CR

13:24:42 <betehess> ... so we'll spend time on it

... so we'll spend time on it

13:24:51 <betehess> ... we have to show the spec can be implemented

... we have to show the spec can be implemented

13:25:10 <betehess> ... Access Control WG Note: there will be 1 hour

... Access Control WG Note: there will be 1 hour

13:25:17 <betehess> ... it was part of the Charter

... it was part of the Charter

13:25:27 <betehess> ... we may not do it, just have to explain

... we may not do it, just have to explain

13:25:54 <betehess> ... BP&R was not in charter but we have moved some stuff there

... BP&R was not in charter but we have moved some stuff there

13:26:01 <betehess> ... Primer is important

... Primer is important

13:26:15 <betehess> ... part of the feedback I had was about readibility of spec

... part of the feedback I had was about readibility of spec

13:26:27 <betehess> ... so the Primer is key

... so the Primer is key

13:26:33 <betehess> ... and then, what's next?

... and then, what's next?

13:26:56 <betehess> ... we had a request from W3C to know if we'll meet at TPAC

... we had a request from W3C to know if we'll meet at TPAC

13:27:05 <betehess> ... end of WG supposed to be in June

... end of WG supposed to be in June

13:27:12 <betehess> ... don't we'll be done in June

... don't we'll be done in June

13:27:18 <betehess> ... at best, we're in PR

... at best, we're in PR

13:27:29 <betehess> ... which means we're pretty much done

... which means we're pretty much done

13:27:45 <betehess> ... but we have to stick around, (like 2 months) just in case there are comments

... but we have to stick around, (like 2 months) just in case there are comments

13:27:53 <betehess> ... extension would be under same charter

... extension would be under same charter

13:28:02 <betehess> ... but the group may want to continue the work

... but the group may want to continue the work

13:28:10 <betehess> ... then there would be a _new_ charter

... then there would be a _new_ charter

13:28:32 <betehess> ... we have a page for wishlist for LDP Next

... we have a page for wishlist for LDP Next

13:28:42 <betehess> ... so we'll discuss what we want

... so we'll discuss what we want

13:28:58 <betehess> ... W3C needs to allocate resources, based on what's in the charter

... W3C needs to allocate resources, based on what's in the charter

13:29:12 <betehess> ... succeeding with the first charter is the best way to get another one ;-)

... succeeding with the first charter is the best way to get another one ;-)

13:29:36 <betehess> ... last but not least: Patch format

... last but not least: Patch format

13:29:37 <nmihindu> Zakim, what's the code?

Nandana Mihindukulasooriya: Zakim, what's the code?

13:29:37 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), nmihindu

Zakim IRC Bot: the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), nmihindu

13:29:46 <betehess> ... the spec says you have to use Patch

... the spec says you have to use Patch

13:29:51 <betehess> ... but we don't say how

... but we don't say how

13:30:00 <betehess> ... we created a separate ML

... we created a separate ML

13:30:07 <betehess> ... had some mails, but not much

... had some mails, but not much

13:30:17 <betehess> ... hope we can have a resultion on that

... hope we can have a resultion on that

13:30:28 <Zakim> +??P1

Zakim IRC Bot: +??P1

13:30:38 <nmihindu> Zakim, ??P1 is me

Nandana Mihindukulasooriya: Zakim, ??P1 is me

13:30:38 <Zakim> +nmihindu; got it

Zakim IRC Bot: +nmihindu; got it

13:30:59 <nmihindu> thank you very much

Nandana Mihindukulasooriya: thank you very much

13:31:02 <betehess> SteveS: ericP will participate to the Patch conversation

Steve Speicher: ericP will participate to the Patch conversation

13:31:04 <JohnArwe> if you're speaking nandana, we're not hearing you, fyi

John Arwe: if you're speaking nandana, we're not hearing you, fyi

13:31:12 <SteveS> from F2F5 wiki: “ericP (though I can attend occasionally, possibly for patch)”

Steve Speicher: from F2F5 wiki: “ericP (though I can attend occasionally, possibly for patch)”

13:31:39 <nmihindu> JohnArwe, I am trying to fix the mic, please move on.

Nandana Mihindukulasooriya: JohnArwe, I am trying to fix the mic, please move on.

13:31:42 <betehess> Arnaud: people were interested in interop testing

Arnaud Le Hors: people were interested in interop testing

13:31:50 <betehess> ... don't know how feasible it is

... don't know how feasible it is

13:31:58 <betehess> ... last afternoon is dedicated to doing that

... last afternoon is dedicated to doing that

13:32:08 <betehess> ... not sure how we'll make it happen

... not sure how we'll make it happen

13:32:23 <betehess> ... if there is any prep before we do it, please let me know

... if there is any prep before we do it, please let me know

13:33:26 <betehess> ... based on the discussions we'll have, I won't hesitate to shrink/extend time on some subjects

... based on the discussions we'll have, I won't hesitate to shrink/extend time on some subjects

13:33:56 <betehess> sandro: btw, the catering is provided by @@

Sandro Hawke: btw, the catering is provided by QCRI

13:34:02 <betehess> s/@@/QCRI/
13:34:29 <betehess> Arnaud: thank you

Arnaud Le Hors: thank you

13:34:43 <betehess> ... hard to know how much time we'll need

... hard to know how much time we'll need

13:35:14 <betehess> SteveS: was wondering haw many people we'll have implementations

Steve Speicher: was wondering haw many people we'll have implementations

13:35:26 <betehess> Arnaud: around 4?

Arnaud Le Hors: around 4?

13:35:35 <betehess> TallTed: all servers I guess

Ted Thibodeau: all servers I guess

13:35:58 <betehess> deiu: have a client as well

Andrei Sambra: have a client as well

13:36:09 <betehess> TallTed: curl is test suite, it's not interop

Ted Thibodeau: curl is test suite, it's not interop

13:36:18 <betehess> sandro: it's an alternative

Sandro Hawke: it's an alternative

13:36:25 <betehess> Arnaud: ok I see the point

Arnaud Le Hors: ok I see the point

13:36:53 <betehess> TallTed: I don't consider curl as an LDP client

Ted Thibodeau: I don't consider curl as an LDP client

13:37:14 <betehess> Arnaud: ok, let's just call it "testing"

Arnaud Le Hors: ok, let's just call it "testing"

13:37:33 <betehess> ... interop is reached when you can replace a component with another one

... interop is reached when you can replace a component with another one

13:37:47 <betehess> topic: LDP Specification

2. LDP Specification

13:38:33 <deiu> http://www.w3.org/TR/2014/WD-ldp-20140311/

Andrei Sambra: http://www.w3.org/TR/2014/WD-ldp-20140311/

13:39:49 <TallTed> http://www.w3.org/2006/02/lc-comments-tracker/55082/

Ted Thibodeau: http://www.w3.org/2006/02/lc-comments-tracker/55082/

13:40:02 <TallTed> http://www.w3.org/TR/2014/WD-ldp-20140311/

Ted Thibodeau: http://www.w3.org/TR/2014/WD-ldp-20140311/

13:40:32 <codyburleson> Do we need to engage the teleconference bridge? Right now, +1-617-761-6200, conf. code 53794#, returns "This passcode is not valid."

Cody Burleson: Do we need to engage the teleconference bridge? Right now, +1-617-761-6200, conf. code 53794#, returns "This passcode is not valid."

13:41:00 <sandro> codyburleson...

Sandro Hawke: codyburleson...

13:41:04 <sandro> Zakim, what is the code?

Sandro Hawke: Zakim, what is the code?

13:41:04 <Zakim> the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), sandro

Zakim IRC Bot: the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), sandro

13:41:41 <sandro> codyburleson, code is 26631 for today, and there's a video-only link http://bit.ly/swa-hangout

Sandro Hawke: codyburleson, code is 26631 for today, and there's a video-only link http://bit.ly/swa-hangout

13:41:47 <betehess> Arnaud: trying to figure out how the tracker works

Arnaud Le Hors: trying to figure out how the tracker works

13:42:09 <sandro> sandro has changed the topic to: Teleconference code is 26631 (CONF1)!! LDP WG: http://www.w3.org/2012/ldp - next agenda: https://www.w3.org/2012/ldp/wiki/F2F5#Agenda VIDEO: http://bit.ly/swa-hangout

Sandro Hawke: sandro has changed the topic to: Teleconference code is 26631 (CONF1)!! LDP WG: http://www.w3.org/2012/ldp - next agenda: https://www.w3.org/2012/ldp/wiki/F2F5#Agenda VIDEO: http://bit.ly/swa-hangout

13:43:22 <Zakim> +[IPcaller]

Zakim IRC Bot: +[IPcaller]

13:43:32 <codyburleson> Zakim, IPcaller is me.

Cody Burleson: Zakim, IPcaller is me.

13:43:32 <Zakim> +codyburleson; got it

Zakim IRC Bot: +codyburleson; got it

13:47:07 <betehess> Arnaud: there were 2 comments from Reto

Arnaud Le Hors: there were 2 comments from Reto

13:47:15 <betehess> ... one about multiple named graphs

... one about multiple named graphs

13:47:21 <betehess> ... thanks betehess for one!

... thanks betehess for that one!

13:47:28 <betehess> s/one/that one/
13:47:35 <Arnaud> http://lists.w3.org/Archives/Public/public-ldp-comments/2014Mar/

Arnaud Le Hors: http://lists.w3.org/Archives/Public/public-ldp-comments/2014Mar/

13:47:51 <betehess> ... and then the null relative URI "hack"

... and then the null relative URI "hack"

13:48:00 <betehess> ... and then there is an extra one

... and then there is an extra one

13:48:05 <betehess> ... an issue we have to fix

... an issue we have to fix

13:48:14 <betehess> ... brought up by sergio

... brought up by sergio

13:48:29 <betehess> ... there is a problem with the use of the rel=describedBy header

... there is a problem with the use of the rel=describedby header

13:48:34 <betehess> ... for 2 different things

... for 2 different things

13:48:52 <betehess> s/describedBy/describedby/
13:52:14 <Arnaud> http://lists.w3.org/Archives/Public/public-ldp-wg/2014Mar/0037.html

Arnaud Le Hors: http://lists.w3.org/Archives/Public/public-ldp-wg/2014Mar/0037.html

13:52:32 <MiguelAraCo> Zakim, MiguelAraCo is with codyburleson

Miguel Aragón: Zakim, MiguelAraCo is with codyburleson

13:52:32 <Zakim> +MiguelAraCo; got it

Zakim IRC Bot: +MiguelAraCo; got it

13:52:57 <betehess> Arnaud: does anybody have anything to add?

Arnaud Le Hors: does anybody have anything to add?

13:53:15 <betehess> SteveS: had a comment about @@ needing more clarity

Steve Speicher: had a comment about implementation feedback needing more clarity

13:53:39 <betehess> Arnaud: people need to forward comments to the list

Arnaud Le Hors: people need to forward comments to the list

13:53:43 <SteveS> s/@@/implementation feedback/
13:53:43 <betehess> ... so that we can track them

... so that we can track them

13:54:35 <betehess> sandro: external comments are still important for reviews

Sandro Hawke: external comments are still important for reviews

13:54:56 <betehess> Arnaud: let's agree we have 1 issue and 2 comments

Arnaud Le Hors: let's agree we have 1 issue and 2 comments

13:55:10 <betehess> ... and we need to make sure we have done the same for comments from 1st LC

... and we need to make sure we have done the same for comments from 1st LC

13:55:48 <betehess> ... timbl's comments are marked as ?? but we are in an ongoing discussion with him

... timbl's comments are marked as ?? but we are in an ongoing discussion with him

13:56:17 <betehess> ... mark baker said he's fine with the improvements we made

... mark baker said he's fine with the improvements we made

13:57:15 <betehess> ... are we in good share re: comments?  do we need to do more?

... are we in good share re: comments? do we need to do more?

13:58:05 <betehess> ... note that we haven't had a real answer from timbl

... note that we haven't had a real answer from timbl

13:58:26 <betehess> ... and there is a comment not really addressed

... and there is a comment not really addressed

13:58:41 <betehess> sandro: timbl may join us 1 hour, we can ask at this point

Sandro Hawke: timbl may join us 1 hour, we can ask at this point

13:59:07 <betehess> ... in good shape?  would be good to have more feedbacks from implementers

... in good shape? would be good to have more feedbacks from implementers

13:59:14 <betehess> ... having that by email is better

... having that by email is better

13:59:37 <betehess> Arnaud: Q for editors:

Arnaud Le Hors: Q for editors:

13:59:43 <Arnaud> http://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2840

Arnaud Le Hors: http://www.w3.org/2006/02/lc-comments-tracker/55082/ldp/2840

14:00:26 <betehess> [[    4.1 "burden of constraints for resource creation" - I feel that phrase needs more explanation ]]

[[ 4.1 "burden of constraints for resource creation" - I feel that phrase needs more explanation ]]

14:00:40 <betehess> JohnArwe: still part of the spec

John Arwe: still part of the spec

14:01:38 <betehess> TallTed: the question is "what do you mean?"

Ted Thibodeau: the question is "what do you mean?"

14:01:47 <betehess> ... not clear at first read

... not clear at first read

14:02:39 <betehess> [ people discussing possible resolutions ]

[ people discussing possible resolutions ]

14:05:22 <betehess> sandro: how about: how can the server make it easy for the client to create resources?

Sandro Hawke: how about: how can the server make it easy for the client to create resources?

14:05:32 <betehess> Arnaud: sounds nice

Arnaud Le Hors: sounds nice

14:05:40 <betehess> ... do we agree?

... do we agree?

14:05:51 <betehess> ... with editorial change?

... with editorial change?

14:06:14 <betehess> ... would allow us to dispose of that pending comment

... would allow us to dispose of that pending comment

14:06:15 <TallTed> +1

Ted Thibodeau: +1

14:06:19 <betehess> +1

+1

14:06:23 <deiu> +1

Andrei Sambra: +1

14:06:23 <MiguelAraCo> +1

Miguel Aragón: +1

14:06:26 <betehess> ... I don't hear objections

... I don't hear objections

14:06:33 <sandro> +1 :-)

Sandro Hawke: +1 :-)

14:07:31 <codyburleson> +1

Cody Burleson: +1

<betehess> subtopic: Null relative URIs comment

2.1. Null relative URIs comment

14:10:16 <betehess> Arnaud: now we start with the  null relative URIs hack comment

Arnaud Le Hors: now we start with the null relative URIs hack comment

14:10:45 <nmihindu> +1

Nandana Mihindukulasooriya: +1

14:10:56 <betehess> ... let's try restate what the issue is

... let's try restate what the issue is

14:11:01 <betehess> ... when we create a resource

... when we create a resource

14:11:04 <betehess> ... we send some RDF

... we send some RDF

14:11:07 <sandro> action-137?

Sandro Hawke: ACTION-137?

14:11:07 <trackbot> action-137 -- Sandro Hawke to Contact yves and erik to make confirm with them that http-wg is okay with this reading of the link context -- due 2014-04-07 -- OPEN

Trackbot IRC Bot: ACTION-137 -- Sandro Hawke to Contact yves and erik to make confirm with them that http-wg is okay with this reading of the link context -- due 2014-04-07 -- OPEN

14:11:07 <trackbot> http://www.w3.org/2012/ldp/track/actions/137

Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/actions/137

14:11:18 <betehess> ... at that time, we don't know what the url of the resource will be

... at that time, we don't know what the url of the resource will be

14:11:24 <betehess> ... so we use the null relative uri

... so we use the null relative uri

14:11:30 <betehess> ... and everything is relative to it

... and everything is relative to it

14:11:47 <betehess> ... comment says: doesn't exist in RDF

... comment says: doesn't exist in RDF

14:11:57 <betehess> ... as RDF does not support this notion

... as RDF does not support this notion

14:12:10 <betehess> ... alternative is the client know the url before posting

... alternative is the client know the url before posting

14:12:19 <betehess> ... so there are 2 steps

... so there are 2 steps

14:12:33 <betehess> JohnArwe: there are other solutions

John Arwe: there are other solutions

14:12:40 <betehess> ... could have a placeholder

... could have a placeholder

14:12:51 <betehess> ... eg using a header to specify a place holder

... eg using a header to specify a place holder

14:13:16 <betehess> Arnaud: this was presented as an alternative

Arnaud Le Hors: this was presented as an alternative

14:13:58 <betehess> sandro: it's not a bnode, it's a node uri

Sandro Hawke: it's not a bnode, it's a node uri

14:14:08 <betehess> TallTed: it behaves like it

Ted Thibodeau: it behaves like it

14:14:17 <betehess> q+

q+

14:14:51 <betehess> Ashok: RDF does not have the concept, can we fix it?

Ashok Malhotra: RDF does not have the concept, can we fix it?

14:15:05 <betehess> sandro: we can use relative graphs, not rdf graphs

Sandro Hawke: we can use relative graphs, not rdf graphs

14:15:16 <betehess> Arnaud: hold on

Arnaud Le Hors: hold on

14:15:27 <betehess> ... this was proposed as alternatives

... this was proposed as alternatives

14:15:51 <betehess> JohnArwe: you need to specify uri for the placeholder

John Arwe: you need to specify uri for the placeholder

14:16:26 <betehess> betehess: then the graphs are not isomorphic

Alexandre Bertails: then the graphs are not isomorphic

14:17:00 <betehess> Arnaud: issues is coming from people using libraries without relative uris

Arnaud Le Hors: issues is coming from people using libraries without relative uris

14:17:31 <betehess> ... people claim their tools don't support it

... people claim their tools don't support it

14:17:55 <betehess> TallTed: if the problem is the library, go fix the library

Ted Thibodeau: if the problem is the library, go fix the library

14:18:03 <betehess> q+

q+

14:18:06 <ericP> RDF doesn't support it

Eric Prud'hommeaux: RDF doesn't support it

14:18:21 <ericP> i'd like it to, but RDF is all about absolute URIs

Eric Prud'hommeaux: i'd like it to, but RDF is all about absolute URIs

14:18:33 <betehess> Arnaud: RDF does not support it, my tools don't support it, what can I do?

Arnaud Le Hors: RDF does not support it, my tools don't support it, what can I do?

14:19:07 <betehess> ... one possible response: LDP uses Turtle, which support rel uris

... one possible response: LDP uses Turtle, which support rel uris

14:20:05 <Zakim> +ericP

Zakim IRC Bot: +ericP

14:20:12 <Arnaud> ack betehess

Arnaud Le Hors: ack betehess

14:20:41 <deiu> betehess: I reported this issue a long time ago, saying that by changing from RDF mediatypes to something new (eg. application/ld) would help

Alexandre Bertails: I reported this issue a long time ago, saying that by changing from RDF mediatypes to something new (eg. application/ld) would help [ Scribe Assist by Andrei Sambra ]

14:21:07 <deiu> ... we can add something to the recs, telling the RDF processor to use a special namespace for the relative URIs and then you do the interpretation

Andrei Sambra: ... we can add something to the recs, telling the RDF processor to use a special namespace for the relative URIs and then you do the interpretation

14:21:17 <deiu> ... this is a way to deal with libs that don't support relative URIs

Andrei Sambra: ... this is a way to deal with libs that don't support relative URIs

14:21:23 <deiu> sandro: I don't understand

Sandro Hawke: I don't understand [ Scribe Assist by Andrei Sambra ]

14:21:44 <deiu> ... the client has no way to construct a turtle serialization

Andrei Sambra: ... the client has no way to construct a turtle serialization

14:22:03 <ericP> new URI scheme!

Eric Prud'hommeaux: new URI scheme!

14:22:16 <deiu> ... both problems exist, the server has the problem that it cannot properly parse turtle

Andrei Sambra: ... both problems exist, the server has the problem that it cannot properly parse turtle

14:22:24 <ericP> client uses a uri scheme which is understood to be changed by the server

Eric Prud'hommeaux: client uses a uri scheme which is understood to be changed by the server

14:22:39 <ericP> server, in the worst case, parses twice

Eric Prud'hommeaux: server, in the worst case, parses twice

14:23:36 <betehess> Arnaud: several options: either we stick with what we have

Arnaud Le Hors: several options: either we stick with what we have

14:23:37 <ericP> could also say that ldp:foo is the base URI

Eric Prud'hommeaux: could also say that ldp:foo is the base URI

14:23:38 <deiu> betehess: if you want to actually tell people that it's not exactly RDF we're working with

Alexandre Bertails: if you want to actually tell people that it's not exactly RDF we're working with [ Scribe Assist by Andrei Sambra ]

14:23:44 <betehess> ... we can create a note on relative graphs

... we can create a note on relative graphs

14:23:48 <betehess> ... or we just leave it as is

... or we just leave it as is

14:24:06 <betehess> ... or we use some placeholder uris that the server can recognize

... or we use some placeholder uris that the server can recognize

14:24:23 <betehess> ... or we give some control to the client to choose their own rel uri

... or we give some control to the client to choose their own rel uri

14:24:57 <ericP> interesting, we could use the slug for that (or some transform for that)

Eric Prud'hommeaux: interesting, we could use the slug for that (or some transform for that)

14:26:33 <betehess> deiu: can't we use the Slug as the placeholder?

Andrei Sambra: can't we use the Slug as the placeholder?

14:26:37 <sandro> OPTION 1: When the client wants to post a graph including self-reference, it MUST use the null-relative URI as the reference to itself.   We clarify the spec, etc.

Sandro Hawke: OPTION 1: When the client wants to post a graph including self-reference, it MUST use the null-relative URI as the reference to itself. We clarify the spec, etc.

14:26:37 <sandro> OPTION 2: When the client wants to post a graph including self-reference, it MUST use some magic URL we pick, eg http://www.w3.org/ns/ldp#self

Sandro Hawke: OPTION 2: When the client wants to post a graph including self-reference, it MUST use some magic URL we pick, eg http://www.w3.org/ns/ldp#self

14:26:37 <sandro> OPTION 3: When the client wants to post a graph including self-reference, it MUST make up some placeholder URI, and tell the server which one it picked using Link: <placeholder URI> rel=selfReferencePlaceholder

Sandro Hawke: OPTION 3: When the client wants to post a graph including self-reference, it MUST make up some placeholder URI, and tell the server which one it picked using Link: <placeholder URI> rel=selfReferencePlaceholder

14:26:43 <betehess> TallTed: should not be an http uri

Ted Thibodeau: should not be an http uri

14:27:04 <betehess> ... because you don't have control over it, it's a server side thing

... because you don't have control over it, it's a server side thing

14:27:53 <ericP> the only requirement for the placeholder URI is that it have a sufficient number of '/'s

Eric Prud'hommeaux: the only requirement for the placeholder URI is that it have a sufficient number of '/'s

14:28:04 <betehess> [discussing sandro's options]

[discussing sandro's options]

14:30:23 <betehess> sandro: the client doesn't know the future "this" uri, that's the issue

Sandro Hawke: the client doesn't know the future "this" uri, that's the issue

14:30:30 <betehess> ... option 1 is what we have in LC right now

... option 1 is what we have in LC right now

14:30:47 <betehess> Arnaud: then we'd say "sorry, you have to make it work"

Arnaud Le Hors: then we'd say "sorry, you have to make it work"

14:30:58 <betehess> ... other options would require to change the spec

... other options would require to change the spec

14:31:23 <betehess> sandro: well processing is different

Sandro Hawke: well processing is different

14:32:39 <betehess> ... we'd need to ask every lib to fix that

... we'd need to ask every lib to fix that

14:34:04 <betehess> TallTed: which side we're putting the burden on: client or server

Ted Thibodeau: which side we're putting the burden on: client or server

14:34:24 <ericP> POST /containers/PeopleAndMovies << { ../foo a foaf:Person }

Eric Prud'hommeaux: POST /containers/PeopleAndMovies << { ../foo a foaf:Person }

14:34:38 <betehess> sandro: we may need a Relative Graph Note

Sandro Hawke: we may need a Relative Graph Note

14:34:48 <betehess> Ashok: would it be helpful to other people?

Ashok Malhotra: would it be helpful to other people?

14:35:02 <ericP> OPTION 1 is probably the easiest to optimize because the server doesn't ever have to crack potentially normalized IRIs

Eric Prud'hommeaux: OPTION 1 is probably the easiest to optimize because the server doesn't ever have to crack potentially normalized IRIs

14:35:38 <betehess> Arnaud: honestly, I am not really in favor in making new documents: too much effort

Arnaud Le Hors: honestly, I am not really in favor in making new documents: too much effort

14:35:40 <sandro> A "Relative RDF Graph" is hereby defined as being just like an RDF Graph except that IRIs are allowed to be Relative IRIs, not just Absolute IRIs.

Sandro Hawke: A "Relative RDF Graph" is hereby defined as being just like an RDF Graph except that IRIs are allowed to be Relative IRIs, not just Absolute IRIs.

14:36:45 <betehess> SteveS: there is always a base

Steve Speicher: there is always a base

14:37:01 <betehess> ... meaning the client can communicate the base it wanted

... meaning the client can communicate the base it wanted

14:37:11 <betehess> ... there is always some base

... there is always some base

14:37:30 <betehess> sandro: what you want is the Turtle serializer to make the graph relative to my own base

Sandro Hawke: what you want is the Turtle serializer to make the graph relative to my own base

14:38:05 <sandro> And then we suggest tool makers include this concept in their APIs.    EG Turtle serializers should have a way to serialize relative graphs.

Sandro Hawke: And then we suggest tool makers include this concept in their APIs. EG Turtle serializers should have a way to serialize relative graphs.

14:38:37 <sandro> sandro: OR, lets just say RDF serializers SHOULD include a base parameter

Sandro Hawke: OR, lets just say RDF serializers SHOULD include a base parameter [ Scribe Assist by Sandro Hawke ]

14:40:26 <betehess> ericP: betehess and I tried to use Jena back then, had to do some hack

Eric Prud'hommeaux: betehess and I tried to use Jena back then, had to do some hack

14:40:46 <betehess> betehess: situation is much better now, a few lines of code to have a proper serializer

Alexandre Bertails: situation is much better now, a few lines of code to have a proper serializer

14:41:18 <betehess> sandro: may not speak about the relative graph, just say that we don't know the base

Sandro Hawke: may not speak about the relative graph, just say that we don't know the base

14:41:21 <ericP> "The POST or PATCH body may have relative IRIs. These IRIs are relative to the final document location. Note: Systems which parse the input document in order to determine the final document location may need to provide a temporary BASE (RFC3896) for parsing, determine the final document location, and parse the input again with that as the BASE

Eric Prud'hommeaux: "The POST or PATCH body may have relative IRIs. These IRIs are relative to the final document location. Note: Systems which parse the input document in order to determine the final document location may need to provide a temporary BASE (RFC3896) for parsing, determine the final document location, and parse the input again with that as the BASE

14:41:27 <ericP> ."

Eric Prud'hommeaux: ."

14:41:28 <sandro> Sandro: Let's NOT use "Relative RDF Graph", but instead use "Deferred-Base RDF Graph Serialization".

Sandro Hawke: Let's NOT use "Relative RDF Graph", but instead use "Deferred-Base RDF Graph Serialization". [ Scribe Assist by Sandro Hawke ]

14:41:39 <betehess> q+

q+

14:42:00 <sandro> ericP, what are you quoting?

Sandro Hawke: ericP, what are you quoting?

14:42:06 <ericP> just proposing

Eric Prud'hommeaux: just proposing

14:42:06 <Arnaud> ack bete

Arnaud Le Hors: ack bete

14:42:16 <betehess> Arnaud: if we didn't have the LC already, I would push for option 3

Arnaud Le Hors: if we didn't have the LC already, I would push for option 3

14:42:26 <ericP> but you probably have better text already, sandro

Eric Prud'hommeaux: but you probably have better text already, sandro

14:42:28 <deiu> betehess: I think we're just trying to make Reto happy

Alexandre Bertails: I think we're just trying to make Reto happy [ Scribe Assist by Andrei Sambra ]

14:42:37 <deiu> ... I've always been thinking of relative graphs

Andrei Sambra: ... I've always been thinking of relative graphs

14:42:53 <deiu> ... there is a time when we don't know the URI of the graph

Andrei Sambra: ... there is a time when we don't know the URI of the graph

14:43:12 <deiu> ... the LDP spec says the base URI will be chosen by the LDP container, so I don't see any issue

Andrei Sambra: ... the LDP spec says the base URI will be chosen by the LDP container, so I don't see any issue

14:43:27 <sergio> guys, not sure if you are still dicussing the issue, but rdflib (python has the base for serilizers: http://rdflib.readthedocs.org/en/latest/apidocs/rdflib.plugins.serializers.html, and probably sesame (java) too:

Sergio Fernández: guys, not sure if you are still dicussing the issue, but rdflib (python has the base for serilizers: http://rdflib.readthedocs.org/en/latest/apidocs/rdflib.plugins.serializers.html, and probably sesame (java) too:

14:43:37 <betehess> sandro: problem with rel graph as a concept, it means we have something new to be handled by libraries

Sandro Hawke: problem with rel graph as a concept, it means we have something new to be handled by libraries

14:44:15 <JohnArwe> @sergio are you unsure b/c you're having trouble hearing us/

John Arwe: @sergio are you unsure b/c you're having trouble hearing us/

14:44:30 <deiu> betehess: libraries can be fixed today, and we stand to gain a lot more from using relative URIs

Alexandre Bertails: libraries can be fixed today, and we stand to gain a lot more from using relative URIs [ Scribe Assist by Andrei Sambra ]

14:44:39 <sergio> JohnArwe: I'm not connected by phone, sorry

John Arwe: I'm not connected by phone, sorry [ Scribe Assist by Sergio Fernández ]

14:44:51 <ericP> i wouldn't call that "fixed". i'd call it "extended".

Eric Prud'hommeaux: i wouldn't call that "fixed". i'd call it "extended".

14:45:09 <ericP> pretending otherwise will irk the ire of RDF hackers

Eric Prud'hommeaux: pretending otherwise will irk the ire of RDF hackers

14:45:46 <JohnArwe> ah no worries - yes lots of discussion back and forth about value/not of "relative graph" definitions

John Arwe: ah no worries - yes lots of discussion back and forth about value/not of "relative graph" definitions

14:46:38 <betehess> sandro: the real question is being able to make a serialization to a certain base

Sandro Hawke: the real question is being able to make a serialization relative to a certain base

14:46:43 <sandro> sandro: I don't think defining Relative Graph is a good idea, because it will make Jena, etc, think they should define serializers and parsers for this, would be be a waste.

Sandro Hawke: I don't think defining Relative Graph is a good idea, because it will make Jena, etc, think they should define serializers and parsers for this, would be be a waste. [ Scribe Assist by Sandro Hawke ]

14:46:49 <betehess> s/to a/relative to a/
14:47:02 <sandro> sandro: We want serializers to have a MakeRelativeToThis IRI parameter.

Sandro Hawke: We want serializers to have a MakeRelativeToThis IRI parameter. [ Scribe Assist by Sandro Hawke ]

14:47:56 <sandro> serialize(outputStream, graph, makeRelativeToThis)

Sandro Hawke: serialize(outputStream, graph, makeRelativeToThis)

14:48:23 <sandro> and note that servers may need to parse zero, one, or two times, depending on their design.

Sandro Hawke: and note that servers may need to parse zero, one, or two times, depending on their design.

14:48:24 <betehess> Arnaud: we have to acknowledge the problem

Arnaud Le Hors: we have to acknowledge the problem

14:48:32 <sandro> ... for very reasonable designs.

Sandro Hawke: ... for very reasonable designs.

14:48:54 <betehess> ... other people said this is a practical way to handle this situation (cygri, dwoods)

... other people said this is a practical way to handle this situation (cygri, dwoods)

14:49:02 <TallTed> TallTed: or rather, we need to be able to tell serializers to make serializations with relative IRIs which refer to that serialization...  so s/makeRelativeToThis/makeRelative[ToOutputStream]/

Ted Thibodeau: or rather, we need to be able to tell serializers to make serializations with relative IRIs which refer to that serialization... so s/makeRelativeToThis/makeRelative[ToOutputStream]/ [ Scribe Assist by Ted Thibodeau ]

14:49:49 <betehess> sandro: we can add the MakeRelativeToThis thing in best practices

Sandro Hawke: we can add the MakeRelativeToThis thing in best practices

14:50:00 <betehess> Arnaud: then we don't do anything in the spec?

Arnaud Le Hors: then we don't do anything in the spec?

14:50:13 <betehess> ... would be reasonable to add something

... would be reasonable to add something

14:51:10 <betehess> ... the remark was based on how tools work, based on RDF is defined

... the remark was based on how tools work, based on RDF is defined

14:51:29 <betehess> sandro: we could link from the spec to uc&r

Sandro Hawke: we could link from the spec to uc&r

14:51:46 <JohnArwe> not to uc&r, to best practices

John Arwe: not to uc&r, to best practices

14:51:47 <betehess> Ashok: best practices is not normative

Ashok Malhotra: best practices is not normative

14:52:00 <betehess> Arnaud: sounds like we're getting to an agreement

Arnaud Le Hors: sounds like we're getting to an agreement

14:52:10 <sandro> "For a discussion of implementation issues around the use of relative IRIs during POST operations, see [BP]"

Sandro Hawke: "For a discussion of implementation issues around the use of relative IRIs during POST operations, see [BP]"

14:52:19 <sergio> +1

Sergio Fernández: +1

14:52:33 <sergio> I'll try to provide some practical examples of different libs

Sergio Fernández: I'll try to provide some practical examples of different libs

14:52:47 <sandro> great, sergio

Sandro Hawke: great, sergio

14:52:53 <betehess> PROPOSAL: we stick with the spec, add a pointer to Best Practices, and add an implementation issues relative to this

PROPOSED: we stick with the spec, add a pointer to Best Practices, and add an implementation issues relative to this

14:53:19 <betehess> sandro: it'd be an informative dependency

Sandro Hawke: it'd be an informative dependency

14:54:04 <SteveS> BP https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html

Steve Speicher: BP https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html

14:54:25 <betehess> Arnaud: errr, BP not published yet

Arnaud Le Hors: errr, BP not published yet

14:54:44 <betehess> sandro: or we can have a non-normative appendix in main LDP spec

Sandro Hawke: or we can have a non-normative appendix in main LDP spec

14:55:26 <sandro> PROPOSAL: We stick with the current null-relative design, and we add a non-normative explanation of how that works, how to do it in some tools, etc, in a footnote, appendix, or (hopefully) BP.

PROPOSED: We stick with the current null-relative design, and we add a non-normative explanation of how that works, how to do it in some tools, etc, in a footnote, appendix, or (hopefully) BP.

14:55:43 <deiu> +1

Andrei Sambra: +1

14:55:45 <TallTed> +1

Ted Thibodeau: +1

14:55:45 <betehess> +1

+1

14:55:47 <sandro> +1

Sandro Hawke: +1

14:55:48 <nmihindu> +1

Nandana Mihindukulasooriya: +1

14:55:50 <JohnArwe> +1

John Arwe: +1

14:55:51 <MiguelAraCo> +1

Miguel Aragón: +1

14:55:53 <codyburleson> +1

Cody Burleson: +1

14:55:56 <Ashok> +1

Ashok Malhotra: +1

14:55:59 <roger> +1

Roger Menday: +1

14:55:59 <ericP> +1 (hope it works)

Eric Prud'hommeaux: +1 (hope it works)

14:56:10 <sandro> RESOLVED: We stick with the current null-relative design, and we add a non-normative explanation of how that works, how to do it in some tools, etc, in a footnote, appendix, or (hopefully) BP.

RESOLVED: We stick with the current null-relative design, and we add a non-normative explanation of how that works, how to do it in some tools, etc, in a footnote, appendix, or (hopefully) BP.

14:56:12 <sergio> +1

Sergio Fernández: +1

14:56:17 <sergio> (late xD)

Sergio Fernández: (late xD)

14:56:32 <sandro> :-)

Sandro Hawke: :-)

14:56:33 <JohnArwe> @ericp, what part do you think might not work?

John Arwe: @ericp, what part do you think might not work?

14:57:11 <ericP> @JohnArwe, can we claim a media type of text/turtle if we don't know the base at the time of transmission?

Eric Prud'hommeaux: @JohnArwe, can we claim a media type of text/turtle if we don't know the base at the time of transmission?

14:57:39 <ericP> i.e. should the client or an intermediary be able to know what graph was actually transmitted?

Eric Prud'hommeaux: i.e. should the client or an intermediary be able to know what graph was actually transmitted?

14:57:45 <sandro> So using .. is a Wrost-Practice, UNLESS you know how the Server is assiging URIs.

Sandro Hawke: So using .. is a Wrost-Practice, UNLESS you know how the Server is assiging URIs.

14:59:02 <ericP> JohnArwe, you see my issue?

Eric Prud'hommeaux: JohnArwe, you see my issue?

14:59:41 <ericP> could i, as a client, have an automagically filled cache of stuff-i've-told-the-world?

Eric Prud'hommeaux: could i, as a client, have an automagically filled cache of stuff-i've-told-the-world?

15:00:09 <ericP> (probably not a show stopper use case, but does illustrate what goes wrong when you cheat on specs)

Eric Prud'hommeaux: (probably not a show stopper use case, but does illustrate what goes wrong when you cheat on specs)

15:00:17 <Zakim> -ericP

Zakim IRC Bot: -ericP

<betehess> subtopic: Meaning of "../" in relative URIs

2.2. Meaning of "../" in relative URIs

15:11:07 <betehess> Arnaud: resuming

(No events recorded for 10 minutes)

Arnaud Le Hors: resuming

15:11:33 <betehess> ... during the discussion, somebody brought the ../ "problem"

... during the discussion, somebody brought the ../ "problem"

15:11:42 <betehess> ... do we want to allow it? prevent it?

... do we want to allow it? prevent it?

15:12:17 <betehess> ... what does it know? you don't know where the document will be

... what does it know? you don't know where the document will be

15:12:28 <betehess> q+

q+

15:13:08 <betehess> JohnArwe: it cannot be a reliable way to reference the container

John Arwe: it cannot be a reliable way to reference the container

15:13:18 <betehess> Arnaud: or even another resource eg. a sibling

Arnaud Le Hors: or even another resource eg. a sibling

15:13:35 <betehess> TallTed: sure

Ted Thibodeau: sure

15:13:42 <betehess> ... not necesseraly an issue

... not necesseraly an issue

15:14:00 <betehess> ... can have multiple container having multiple paths

... can have multiple container having multiple paths

15:16:02 <Arnaud> zakim, who's talking?

Arnaud Le Hors: zakim, who's talking?

15:16:14 <Zakim> Arnaud, listening for 10 seconds I heard sound from the following: nmihindu (45%), +1.617.715.aaaa (20%)

Zakim IRC Bot: Arnaud, listening for 10 seconds I heard sound from the following: nmihindu (45%), +1.617.715.aaaa (20%)

15:16:23 <Arnaud> zakim, mute nmihindu

Arnaud Le Hors: zakim, mute nmihindu

15:16:23 <Zakim> nmihindu should now be muted

Zakim IRC Bot: nmihindu should now be muted

15:16:51 <nmihindu> Sorry. I thought I was already muted.

Nandana Mihindukulasooriya: Sorry. I thought I was already muted.

15:18:09 <betehess> JohnArwe: interop could be limited

John Arwe: interop could be limited

15:18:45 <betehess> sandro: the ../ semantics is implied because of other specs

Sandro Hawke: the ../ semantics is implied because of other specs

15:19:39 <betehess> Arnaud: do we want to say something about it in the spec?

Arnaud Le Hors: do we want to say something about it in the spec?

15:20:05 <betehess> ... oh, the ../ issue was brought by cygri

... oh, the ../ issue was brought by cygri

15:20:16 <Arnaud> http://lists.w3.org/Archives/Public/public-ldp/2014Mar/0051.html

Arnaud Le Hors: http://lists.w3.org/Archives/Public/public-ldp/2014Mar/0051.html

15:20:47 <betehess> ... (may be discussed elsewhere as well)

... (may be discussed elsewhere as well)

15:21:00 <betehess> [[

[[

15:21:00 <betehess> Because otherwise, it’ll be even less clear what “/“ or “/foo” or “..” refer to, as it’s unclear whether they will be resolved against your hack URI, or the container URI, or the new item URI.

Because otherwise, it’ll be even less clear what “/“ or “/foo” or “..” refer to, as it’s unclear whether they will be resolved against your hack URI, or the container URI, or the new item URI.

15:21:00 <betehess>  ]]

]]

15:23:02 <betehess> JohnArwe: rel uris is application specific

John Arwe: rel uris is application specific

15:24:04 <betehess> sandro: so the question is about base uri, not just null uri

Sandro Hawke: so the question is about base uri, not just null uri

15:24:11 <betehess> ... the spec is already good

... the spec is already good

15:24:27 <sandro> 4.2.1.5 LDP servers MUST assign the default base-URI for [RFC3987] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource.

Sandro Hawke: 4.2.1.5 LDP servers MUST assign the default base-URI for [RFC3987] relative-URI resolution to be the HTTP Request-URI when the resource already exists, and to the URI of the created resource when the request results in the creation of a new resource.

15:24:46 <betehess> SteveS: the spec is clear

Steve Speicher: the spec is clear

15:24:54 <betehess> ... BP might help explaining further

... BP might help explaining further

15:25:07 <betehess> Arnaud: so what are we doing? nothing to do?

Arnaud Le Hors: so what are we doing? nothing to do?

15:25:15 <betehess> ... add something in BP?

... add something in BP?

15:25:47 <sandro> "It follows from this definition that use of /../ and other non-null relative URI constructs during POST has application-dependent results"

Sandro Hawke: "It follows from this definition that use of /../ and other non-null relative URI constructs during POST has application-dependent results"

15:26:25 <betehess> JohnArwe: it's not ill-defined but it may limit interop

John Arwe: it's not ill-defined but it may limit interop

15:26:32 <betehess> betehess: I'd need an example where it limits interop

Alexandre Bertails: I'd need an example where it limits interop

15:29:27 <betehess> betehess: it's not application or implementation specific. the spec already says it's relative to the base uri, always defined in LDP, even during POST

Alexandre Bertails: it's not application or implementation specific. the spec already says it's relative to the base uri, always defined in LDP, even during POST

15:29:29 <sandro> "It follows from this definition that use of /../ and other non-null relative URI constructs during POST will cause the content to be referring to resources in a manner the client will not, in general, be able to predict."

Sandro Hawke: "It follows from this definition that use of /../ and other non-null relative URI constructs during POST will cause the content to be referring to resources in a manner the client will not, in general, be able to predict."

15:29:42 <betehess> ... but nobody can rely on it to refer to a parent or sibling

... but nobody can rely on it to refer to a parent or sibling

15:31:10 <betehess> Arnaud: people presumed to know where the resource is going to land in a POST and may use ../ in consequence

Arnaud Le Hors: people presumed to know where the resource is going to land in a POST and may use ../ in consequence

15:31:19 <betehess> TallTed: why do we presume people will do that?

Ted Thibodeau: why do we presume people will do that?

15:31:29 <betehess> SteveS: we may handled that in BP

Steve Speicher: we may handled that in BP

15:31:54 <betehess> Arnaud: it's just somebody referred to that, would like to be able to point people at a good answer

Arnaud Le Hors: it's just somebody referred to that, would like to be able to point people at a good answer

15:32:02 <betehess> q?

q?

15:32:03 <betehess> q-

q-

15:32:49 <betehess> roger: people will want to speak about hierarchy and may want to use ../ and stuff like that

Roger Menday: people will want to speak about hierarchy and may want to use ../ and stuff like that

15:32:57 <TallTed> "Other non-null relative URI constructs may not refer to the user's anticipated resource, due to variability in implementation and/or deployment. Tread with caution. Here be dragons."

Ted Thibodeau: "Other non-null relative URI constructs may not refer to the user's anticipated resource, due to variability in implementation and/or deployment. Tread with caution. Here be dragons."

15:33:00 <betehess> Arnaud: let me make a proposal

Arnaud Le Hors: let me make a proposal

15:33:13 <SteveS> roger, yes https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html#represent-container-membership-with-hierarchical-uris

Steve Speicher: roger, yes https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html#represent-container-membership-with-hierarchical-uris

15:33:25 <sandro> "It follows from this definition /../ URLs should not be used in POSTed content unless the client has additional information about IRIs are assigned."

Sandro Hawke: "It follows from this definition /../ URLs should not be used in POSTed content unless the client has additional information about IRIs are assigned."

15:33:45 <betehess> ... we should agree to add something in the BP doc about the danger of POSTing docs using rel uris

... we should agree to add something in the BP doc about the danger of POSTing docs using rel uris

15:35:37 <sandro> Add it BP that it follows from the specs that /../ URLs should not be used in POSTed content unless the client has additional information about IRIs are assigned.

Sandro Hawke: Add it BP that it follows from the specs that /../ URLs should not be used in POSTed content unless the client has additional information about IRIs are assigned.

15:35:50 <betehess> deiu: you should never try to refer to a uri that will exist later

Andrei Sambra: you should never try to refer to a uri that will exist later

15:36:10 <betehess> JohnArwe: we had a proposal to handle that in the BP doc

John Arwe: we had a proposal to handle that in the BP doc

15:36:34 <sandro> PROPOSED: Add it BP that it follows from the specs that /../ URLs should not be used in POSTed content unless the client has additional information about IRIs are assigned.

PROPOSED: Add it BP that it follows from the specs that /../ URLs should not be used in POSTed content unless the client has additional information about IRIs are assigned.

15:36:42 <betehess> ... and we nail down the document

... and we nail down the document

15:36:48 <sandro> PROPOSED: Add it BP that it follows from the specs that /../ URLs should not be used in POSTed content unless the client has additional information about how IRIs are assigned.

PROPOSED: Add to BP that it follows from the specs that /../ URLs should not be used in POSTed content unless the client has additional information about how IRIs are assigned.

15:37:06 <TallTed> s/Add it BP/Add to BP/
15:37:06 <sandro> PROPOSED: Add it BP that it follows from the specs that /../ URLs should not be used in POSTed content unless the client has additional information about how IRIs are assigned (by that particular server).

PROPOSED: Add it BP that it follows from the specs that /../ URLs should not be used in POSTed content unless the client has additional information about how IRIs are assigned (by that particular server).

15:37:10 <JohnArwe> +1

John Arwe: +1

15:37:12 <SteveS> +../1

Steve Speicher: +../1

15:37:17 <MiguelAraCo> +1

Miguel Aragón: +1

15:37:18 <sandro> +1

Sandro Hawke: +1

15:37:27 <nmihindu> +1

Nandana Mihindukulasooriya: +1

15:38:17 <betehess> sandro: we can have an LDP extension using information that uris will be right under the container

Sandro Hawke: we can have an LDP extension using information that uris will be right under the container

15:39:24 <deiu> +0

Andrei Sambra: +0

15:39:33 <betehess> -1

-1

15:39:39 <sandro> betehess: i don't want people to consider the possibility that they MIGHT know more about how URIs are assigned by servers.

Alexandre Bertails: i don't want people to consider the possibility that they MIGHT know more about how URIs are assigned by servers. [ Scribe Assist by Sandro Hawke ]

15:40:07 <TallTed> PROPOSED: Add to BP that it follows from the specs that using /../ URLs in POSTed content may have unpredictable results.

PROPOSED: Add to BP that it follows from the specs that using /../ URLs in POSTed content may have unpredictable results.

15:40:22 <sandro> PROPOSED: Add to BP that it follows from the specs that /../ URLs should not be used in POSTed content

PROPOSED: Add to BP that it follows from the specs that /../ URLs should not be used in POSTed content

15:41:09 <sandro> +1

Sandro Hawke: +1

15:41:10 <TallTed> +0

Ted Thibodeau: +0

15:41:14 <JohnArwe> voting on sandro's...

John Arwe: voting on sandro's...

15:41:21 <deiu> +0

Andrei Sambra: +0

15:41:28 <betehess> +0 (can leave with it, strongly prefer TallTed's wording)

+0 (can leave with it, strongly prefer TallTed's wording)

15:41:33 <JohnArwe> +0.5

John Arwe: +0.5

15:41:34 <codyburleson> +1

Cody Burleson: +1

15:41:38 <roger> +0

Roger Menday: +0

15:41:44 <nmihindu> +0.5

Nandana Mihindukulasooriya: +0.5

15:41:53 <betehess> (we're currently voting on sandro's proposal)

(we're currently voting on sandro's proposal)

15:42:19 <Ashok> 0

Ashok Malhotra: 0

15:42:20 <SteveS> +0.5 (think a general section and discussion in BP on this general topic is good)

Steve Speicher: +0.5 (think a general section and discussion in BP on this general topic is good)

15:42:33 <Arnaud> PROPOSED: Add to BP that it follows from the specs that using /../ URLs in POSTed content may have unpredictable results.

PROPOSED: Add to BP that it follows from the specs that using /../ URLs in POSTed content may have unpredictable results.

15:42:41 <roger> +1

Roger Menday: +1

15:42:44 <betehess> +1

+1

15:42:45 <deiu> +1

Andrei Sambra: +1

15:42:45 <JohnArwe> +0.5

John Arwe: +0.5

15:42:49 <sandro> +0

Sandro Hawke: +0

15:42:51 <TallTed> +1

Ted Thibodeau: +1

15:42:56 <codyburleson> -1

Cody Burleson: -1

15:42:57 <nmihindu> +1

Nandana Mihindukulasooriya: +1

15:43:06 <MiguelAraCo> +0

Miguel Aragón: +0

15:43:26 <SteveS> +0.5 (think a general section and discussion in BP on this general topic is good)

Steve Speicher: +0.5 (think a general section and discussion in BP on this general topic is good)

15:43:33 <TallTed> codyburleson - can you explain the -1?

Ted Thibodeau: codyburleson - can you explain the -1?

15:43:50 <codyburleson> I just am uncomfortable with ../ in graphs

Cody Burleson: I just am uncomfortable with ../ in graphs

15:43:50 <Arnaud> zakim, who's on the phone?

Arnaud Le Hors: zakim, who's on the phone?

15:43:50 <Zakim> On the phone I see +1.617.715.aaaa, nmihindu (muted), codyburleson

Zakim IRC Bot: On the phone I see +1.617.715.aaaa, nmihindu (muted), codyburleson

15:43:51 <Zakim> codyburleson has codyburleson, MiguelAraCo

Zakim IRC Bot: codyburleson has codyburleson, MiguelAraCo

15:43:52 <codyburleson> period

Cody Burleson: period

15:44:11 <Arnaud> ok, thanks

Arnaud Le Hors: ok, thanks

15:44:11 <betehess> Arnaud: then I think we'll go with sandro's proposal

Arnaud Le Hors: then I think we'll go with sandro's proposal

15:44:16 <Arnaud> RESOLVED: Add to BP that it follows from the specs that /../ URLs should not be used in POSTed content

RESOLVED: Add to BP that it follows from the specs that /../ URLs should not be used in POSTed content

15:44:18 <betehess> ... resolved!

... resolved!

15:44:38 <codyburleson> +q

Cody Burleson: +q

15:44:39 <betehess> ... should take care of all relative uris

... should take care of all relative uris

15:45:04 <Arnaud> ack codyburleson

Arnaud Le Hors: ack codyburleson

15:45:54 <betehess> Arnaud: that's the power you have: -1 is blocking

Arnaud Le Hors: that's the power you have: -1 is blocking

15:47:31 <betehess> ... that's how concensus should work!

... that's how concensus should work!

15:47:42 <betehess> ... let's move to next topic: named graphs

... let's move to next topic: named graphs

<betehess> subtopic: Named graphs comment

2.3. Named graphs comment

15:47:53 <TallTed> http://lists.w3.org/Archives/Public/public-ldp-comments/2014Mar/0000.html

Ted Thibodeau: http://lists.w3.org/Archives/Public/public-ldp-comments/2014Mar/0000.html

15:48:13 <betehess> ... we added the sentence in the spec lately

... we added the sentence in the spec lately

15:48:49 <betehess> .. in 5.2.3.4 [[ The created resource can be thought of as an RDF named graph ]]

.. in 5.2.3.4 [[ The created resource can be thought of as an RDF named graph ]]

15:49:10 <betehess> ... some people thought it was a great improvement

... some people thought it was a great improvement

15:49:25 <betehess> ... but other didn't like it, prefer to have one big graph

... but other didn't like it, prefer to have one big graph

15:49:42 <codyburleson> -q

Cody Burleson: -q

15:50:30 <betehess> betehess: has anybody said anything about the default graph as union of named graphs?

Alexandre Bertails: has anybody said anything about the default graph as union of named graphs?

15:50:35 <betehess> sandro: don't think so

Sandro Hawke: don't think so

15:51:20 <betehess> Arnaud: that's where I think the sparql store protocol does a good job

Arnaud Le Hors: the sparql protocol does make use of named graphs

15:52:34 <betehess> s/that's where I think the sparql store protocol does a good job/the sparql protocol does make use of named graphs/
15:53:00 <betehess> sandro: named graphs should rely on defining a dataset, which is not defiend

Sandro Hawke: named graphs should rely on defining a dataset, which is not defiend

15:54:23 <betehess> TallTed: the spec speaks about a preference to use a syntax supporting named graphs

Ted Thibodeau: the spec speaks about a preference to use a syntax supporting named graphs when `providing [a] resource and supporting containers in a single response representation.`

15:54:24 <betehess> q+

q+

15:55:04 <betehess> Arnaud: also related to inlining

Arnaud Le Hors: also related to inlining

15:55:15 <Arnaud> ack betehess

Arnaud Le Hors: ack betehess

15:55:56 <deiu> betehess: the reason I introduced the named graph discussion is that there are two things to consider: inlining and named graphs are very related

Alexandre Bertails: the reason I introduced the named graph discussion is that there are two things to consider: inlining and named graphs are very related [ Scribe Assist by Andrei Sambra ]

15:56:00 <JohnArwe> TimBL: historically lots of discussion about named graphs, what they should be, etc.  when you bring in that term you tend to raise a lot of questions

Tim Berners-Lee: historically lots of discussion about named graphs, what they should be, etc. when you bring in that term you tend to raise a lot of questions [ Scribe Assist by John Arwe ]

15:56:06 <deiu> ... where can I look for info if I don't know where it is

Andrei Sambra: ... where can I look for info if I don't know where it is

15:56:39 <deiu> ... if I want to enable SPARQL for an LDPC, then how do I know which resources are members of a container

Andrei Sambra: ... if I want to enable SPARQL for an LDPC, then how do I know which resources are members of a container

15:57:00 <deiu> sandro: that can be part of an extension

Sandro Hawke: that can be part of an extension [ Scribe Assist by Andrei Sambra ]

15:57:27 <deiu> betehess: the triple in question is ldpContains

Alexandre Bertails: the triple in question is ldpContains [ Scribe Assist by Andrei Sambra ]

15:57:50 <deiu> ... basically, you are able to point to the named graphs so therefore you can explore the container

Andrei Sambra: ... basically, you are able to point to the named graphs so therefore you can explore the container

15:58:14 <deiu> sandro: you can't backhand into SPARQL, LDP doesn't say that LDP is a dataset

Sandro Hawke: you can't backhand into SPARQL, LDP doesn't say that LDP is a dataset [ Scribe Assist by Andrei Sambra ]

15:58:25 <deiu> ... there is no way to get to SPARQL from LDP

Andrei Sambra: ... there is no way to get to SPARQL from LDP

15:58:40 <deiu> betehess: how do you define dataset?

Alexandre Bertails: how do you define dataset? [ Scribe Assist by Andrei Sambra ]

15:58:41 <TallTed> s/TallTed: the spec speaks about a preference to use a syntax supporting named graphs/TallTed: the spec speaks about a preference to use a syntax supporting named graphs when `providing [a] resource and supporting containers in a single response representation.`/
15:58:53 <deiu> sandro: it's what you have in your SPARQL database

Sandro Hawke: it's what you have in your SPARQL database [ Scribe Assist by Andrei Sambra ]

16:00:23 <deiu> ... LDP doesn't care about SPARQL, so it's out of scope

Andrei Sambra: ... LDP doesn't care about SPARQL, so it's out of scope

16:00:34 <deiu> betehess: nothing tells me today where the triples live

Alexandre Bertails: nothing tells me today where the triples live [ Scribe Assist by Andrei Sambra ]

16:04:51 <betehess> JohnArwe: we never said that implementations had to rely on named graphs

John Arwe: we never said that implementations had to rely on named graphs

16:05:13 <betehess> sandro: just saying that the specification is not properly done when it comes to named graphs

Sandro Hawke: just saying that the specification is not properly done when it comes to named graphs

16:05:34 <betehess> ... I'd like to be able to do a GET with trig

... I'd like to be able to do a GET with trig

16:05:53 <betehess> sandro: 2 options:

Sandro Hawke: 2 options:

16:06:09 <betehess> ... 1. keep spec as is, and say we don't prevent him to have a one graph implementation

... 1. keep spec as is, and say we don't prevent him to have a one graph implementation

16:06:24 <betehess> ... 2. we remove mentions of named graphs in the spec, and make him happy

... 2. we remove mentions of named graphs in the spec, and make him happy

16:06:31 <sandro> sandro: Let's remove all usage of "Named Graphs" terminology in the spec, since we're not fully defining how it's all supposed to work.

Sandro Hawke: Let's remove all usage of "Named Graphs" terminology in the spec, since we're not fully defining how it's all supposed to work. [ Scribe Assist by Sandro Hawke ]

16:06:40 <betehess> TallTed: not forbidden use of trig, it's still possible to return it

Ted Thibodeau: not forbidden use of trig, it's still possible to return it

16:06:47 <timbl> q+

Tim Berners-Lee: q+

16:06:49 <betehess> ... if not supported, just return Turtle

... if not supported, just return Turtle

16:06:57 <betehess> ... options are still there

... options are still there

16:07:05 <Arnaud> ack timbl

Arnaud Le Hors: ack timbl

16:07:07 <betehess> Arnaud: are you saying you're speaking spec as is?

Arnaud Le Hors: are you saying you're speaking spec as is?

16:07:39 <betehess> timbl: conneg must be used for things that are the same

Tim Berners-Lee: conneg must be used for things that are the same

16:07:57 <betehess> ... so Turtle is not enough to return named graphs

... so Turtle is not enough to return named graphs

16:08:25 <betehess> TallTed: we said the server can return more than you ask for

Ted Thibodeau: we said the server can return more than you ask for

16:08:30 <betehess> ... so if you ask for trig, you just get more informations

... so if you ask for trig, you just get more informations

16:10:07 <betehess> timbl: would be a bad idea to return trig without saying it's not a full representation of the resource

Tim Berners-Lee: would be a bad idea to return trig without saying it's not a full representation of the resource

16:10:14 <betehess> ... maybe a different http code?

... maybe a different http code?

16:10:30 <betehess> ... in LDP thing, the conceptual thing is a graph

... in LDP thing, the conceptual thing is a graph

16:10:58 <betehess> sandro: in http, caching allows to use headers for variance

Sandro Hawke: in http, caching allows to use headers for variance

16:11:34 <betehess> ... could use link headers, like Prefer

... could use link headers, like Prefer

16:12:24 <betehess> ... meta point is: it's interesting work outside of this WG

... meta point is: it's interesting work outside of this WG

16:12:34 <betehess> ... let's not prejudge what the issue is

... let's not prejudge what the issue is

16:13:28 <betehess> Arnaud: maybe we can remove it?

Arnaud Le Hors: maybe we can remove it?

16:14:15 <betehess> ... in terminology section, we have LDP-RS

... in terminology section, we have LDP-RS

16:14:34 <betehess> sandro: can say it's a pair or IRI and graph in some dataset, but dataset is not defined

Sandro Hawke: can say it's a pair or IRI and graph in some dataset, but dataset is not defined

16:16:10 <TallTed> from RDF 1.1 Concepts -- "We informally use the term RDF source to refer to a persistent yet mutable source or container of RDF graphs. An RDF source is a resource that may be said to have a state that can change over time. A snapshot of the state can be expressed as an RDF graph. For example, any web document that has an RDF-bearing representation may be considered an RDF source. Like all resources, RDF sources may be named with

Ted Thibodeau: from RDF 1.1 Concepts -- "We informally use the term RDF source to refer to a persistent yet mutable source or container of RDF graphs. An RDF source is a resource that may be said to have a state that can change over time. A snapshot of the state can be expressed as an RDF graph. For example, any web document that has an RDF-bearing representation may be considered an RDF source. Like all resources, RDF sources may be named with

16:16:10 <TallTed>  IRIs and therefore described in other RDF graphs."

Ted Thibodeau: IRIs and therefore described in other RDF graphs."

16:16:25 <betehess> ... was brought up by betehess saying that we have to clarify the spec

... was brought up by betehess saying that we have to clarify the spec

16:16:49 <betehess> SteveS: timbl said we could just remove "named" from "named graph" because it is what it is

Steve Speicher: timbl said we could just remove "named" from "named graph" because it is what it is

16:17:26 <betehess> sandro: the problem is that it contradicts the RDF spec

Sandro Hawke: the problem is that it contradicts the RDF spec

16:17:33 <betehess> Arnaud: yeah, it's a G-Box

Arnaud Le Hors: yeah, it's a G-Box

16:18:44 <betehess> timbl: the state of the resource is graph

Tim Berners-Lee: the state of the resource is a graph

16:18:50 <betehess> s/graph/a graph/
16:18:59 <betehess> Arnaud: so removing "named" would work then

Arnaud Le Hors: so removing "named" would work then

16:19:05 <sandro> The State of the Resource is a Graph, but the Resource itself is not a Graph.

Sandro Hawke: The State of the Resource is a Graph, but the Resource itself is not a Graph.

16:19:19 <timbl> yes

Tim Berners-Lee: yes

16:19:34 <betehess> ... the spec already speaks about spec

... the state already speaks about state

16:19:38 <betehess> s/spec/state/
16:19:54 <betehess> ... the spec already speaks about state

... the spec already speaks about state

16:20:15 <sandro> +1 An LDPR whose state is fully represented by an RDF Graph.

Sandro Hawke: +1 An LDPR whose state is fully represented by an RDF Graph.

16:20:19 <betehess> ... then let's go to Examples

... then let's go to Examples

16:20:56 <betehess> ... we may remove the paragraph about syntax and multiple named graphs

... we may remove the paragraph about syntax and multiple named graphs

16:21:29 <betehess> timbl: what's nice about LDP spec is that it defines solid things

Tim Berners-Lee: what's nice about LDP spec is that it defines solid things

16:22:08 <timbl> An LDPR’s state is an RDF Graph and is fully represented in RDF.  See also the term RDF Source from [rdf11-concepts].

Tim Berners-Lee: An LDPR’s state is an RDF Graph and is fully represented in RDF. See also the term RDF Source from [rdf11-concepts].

16:23:25 <betehess> Arnaud: so the question from SteveS was to consider moving that paragraph to BP

Arnaud Le Hors: so the question from SteveS was to consider moving that paragraph to BP

16:23:30 <betehess> ... I think it's fine

... I think it's fine

16:24:00 <betehess> ... we can remove the mention from 5.2.3.4

... we can remove the mention from 5.2.3.4

16:24:05 <betehess> ... just a hint here

... just a hint here

16:24:12 <betehess> ... same for 5.2.4.2

... same for 5.2.4.2

16:24:15 <betehess> ... and that's it

... and that's it

16:25:50 <Arnaud> PROPOSED: remove references to named graphs: remove "named" in terminology section, remove paragraph in examples, remove sentence in section 5.2.3.4 and 5.2.4.2

PROPOSED: remove references to named graphs: remove "named" in terminology section, remove paragraph in examples, remove sentence in section 5.2.3.4 and 5.2.4.2

16:25:54 <sandro> +1

Sandro Hawke: +1

16:26:01 <TallTed> +1

Ted Thibodeau: +1

16:26:03 <betehess> +0.99

+0.99

16:26:03 <deiu> +1

Andrei Sambra: +1

16:26:07 <roger> +1

Roger Menday: +1

16:26:08 <SteveS> +1

Steve Speicher: +1

16:26:15 <MiguelAraCo> +1

Miguel Aragón: +1

16:26:17 <codyburleson> +1

Cody Burleson: +1

16:26:30 <JohnArwe> +1

John Arwe: +1

16:26:41 <Arnaud> RESOLVED: Remove references to named graphs: remove "named" in terminology section, remove paragraph in examples, remove sentence in section 5.2.3.4 and 5.2.4.2

RESOLVED: Remove references to named graphs: remove "named" in terminology section, remove paragraph in examples, remove sentence in section 5.2.3.4 and 5.2.4.2

16:27:13 <sandro> break until 1:15

Sandro Hawke: break until 1:15

16:27:25 <Zakim> -codyburleson

Zakim IRC Bot: -codyburleson

16:27:27 <Zakim> -nmihindu

Zakim IRC Bot: -nmihindu

17:19:23 <deiu> scribenick: deiu

(No events recorded for 51 minutes)

(Scribe set to Andrei Sambra)

17:19:23 <Arnaud> http://lists.w3.org/Archives/Public/public-ldp-wg/2014Mar/0037.html

Arnaud Le Hors: http://lists.w3.org/Archives/Public/public-ldp-wg/2014Mar/0037.html

17:19:24 <deiu> scribe: Andrei
17:19:51 <deiu> subtopic: describedby

2.4. describedby

17:20:26 <deiu> Arnaud: when we POST a non-RDF source, the server may create an additional RDF source (with the meta data for the non-RDF source)

Arnaud Le Hors: when we POST a non-RDF source, the server may create an additional RDF source (with the meta data for the non-RDF source)

17:20:43 <deiu> ... to do that, we use describedBy

... to do that, we use rel=describedby

17:21:30 <deiu> s/describedBy/rel=describedby
17:22:05 <deiu> ... Sergio raised the question about a possible conflict with describedBy

... Sergio raised the question about a possible conflict with describedBy

17:22:41 <deiu> sandro: we should say what happens when there are two headers

Sandro Hawke: we should say what happens when there are two headers

17:22:56 <deiu> Arnaud: there is more than one thing that describes the resource, there's nothing wrong with that

Arnaud Le Hors: there is more than one thing that describes the resource, there's nothing wrong with that

17:23:30 <deiu> sandro: basically they are all true, so the best practice would be to merge

Sandro Hawke: basically they are all true, so the best practice would be to merge

17:23:53 <deiu> Arnaud: for a non-RDF you wouldn't have a shape

Arnaud Le Hors: for a non-RDF you wouldn't have a shape

17:24:06 <deiu> ... you have a piece of XML, meta data and a schema

... you have a piece of XML, meta data and a schema

17:24:23 <deiu> ... you need to follow the link to find what kind of information resource it is

... you need to follow the link to find what kind of information resource it is

17:24:54 <deiu> ... there is no way to guarantee that there will only be one

... there is no way to guarantee that there will only be one

17:25:16 <deiu> sandro: if it's something very specific, then you should sub-type the property

Sandro Hawke: if it's something very specific, then you should sub-type the property

17:25:51 <deiu> sandro: we can change rel=describedby to rel=serverconstraints

Sandro Hawke: we can change rel=describedby to rel=serverconstraints

17:26:26 <deiu> Arnaud: resource shape was submitted to W3C

Arnaud Le Hors: resource shape was submitted to W3C

17:26:36 <deiu> ... I expect discussion to start soon

... I expect discussion to start soon

17:27:07 <deiu> ... if I have a shape, I MUST use the rel=describedby link

... if I have a shape, I MUST use the rel=describedby link

17:27:37 <deiu> sandro: I would like to take this out

Sandro Hawke: I would like to take this out

17:27:52 <deiu> ... 4.2.1.6 that is

... 4.2.1.6 that is

17:28:11 <deiu> ... if the resource shape spec says something about this, then we don't need to have it in the LDP spec

... if the resource shape spec says something about this, then we don't need to have it in the LDP spec

17:29:29 <deiu> Arnaud: your client can figure out the constraints by following the link

Arnaud Le Hors: your client can figure out the constraints by following the link

17:29:50 <deiu> sandro: I agree it works to follow the link and do conneg

Sandro Hawke: I agree it works to follow the link and do conneg

17:30:37 <Zakim> +[IPcaller]

Zakim IRC Bot: +[IPcaller]

17:30:49 <codyburleson> Zakim, IPcaller is me.

Cody Burleson: Zakim, IPcaller is me.

17:30:49 <Zakim> +codyburleson; got it

Zakim IRC Bot: +codyburleson; got it

17:30:56 <deiu> Arnaud: you might end up using two Link headers, it's not a big deal

Arnaud Le Hors: you might end up using two Link headers, it's not a big deal

17:31:08 <deiu> ... one Link might become deprecated at some point

... one Link might become deprecated at some point

17:31:54 <deiu> TallTed: if you fail and don't say anything about the reason, then it's bad (as Timbl said)

Ted Thibodeau: if you fail and don't say anything about the reason, then it's bad (as Timbl said)

17:32:42 <deiu> sandro: unless there is something a client could do, why have the server provide the reason to the client

Sandro Hawke: unless there is something a client could do, why have the server provide the reason to the client

17:33:43 <deiu> Arnaud: we can either drop or keep the Link, but if we keep it, what rel value are we going to use?

Arnaud Le Hors: we can either drop or keep the Link, but if we keep it, what rel value are we going to use?

17:34:54 <sandro> OPTION 1: Use rel=describedby for as many things at once as needed; they are all types of description

Sandro Hawke: OPTION 1: Use rel=describedby for as many things at once as needed; they are all types of description

17:34:54 <sandro> OPTION 2: Use different rel= arguments for each different type of description the client might find useful

Sandro Hawke: OPTION 2: Use different rel= arguments for each different type of description the client might find useful

17:35:35 <deiu> Arnaud: Sergio said the "possible" conflict, when he referred to rel=describedby, and the one that is linking the binary resource to the RDF meta resource

Arnaud Le Hors: Sergio said the "possible" conflict, when he referred to rel=describedby, and the one that is linking the binary resource to the RDF meta resource

17:36:16 <deiu> JohnArwe: if you read the spec carefully, then you would see there is no conflict

John Arwe: if you read the spec carefully, then you would see there is no conflict

17:36:28 <deiu> ... some people may have a problem, others may not

... some people may have a problem, others may not

17:36:38 <deiu> sandro: how do you decide what is meta data and what is data?

Sandro Hawke: how do you decide what is meta data and what is data?

17:37:27 <deiu> ... these are the most important bits of the data, I don't want to have another request to get the meta data

... these are the most important bits of the data, I don't want to have another request to get the meta data

17:38:31 <deiu> Arnaud: there's a tradeoff of reusing existing terms, but sometimes those terms are used to refer to different things

Arnaud Le Hors: there's a tradeoff of reusing existing terms, but sometimes those terms are used to refer to different things

17:39:07 <deiu> sandro: the resource shape will say "this kind of shape is allowed here"

Sandro Hawke: the resource shape will say "this kind of shape is allowed here"

17:39:18 <TallTed> { :thing  rel=describedby  :a  .  :a  a  ldp:resourceShape  }

Ted Thibodeau: { :thing rel=describedby :a . :a a ldp:resourceShape }

17:39:57 <deiu> Arnaud: the spec is not really broken, we can live with the way it is so

Arnaud Le Hors: the spec is not really broken, we can live with the way it is so

17:40:03 <sandro> I kind of think OPTION 2 is better, long term, but OPTION 1 is fine, and in the spec already.

Sandro Hawke: I kind of think OPTION 2 is better, long term, but OPTION 1 is fine, and in the spec already.

17:40:46 <deiu> Arnaud: the only downside is that if we come up with a better way, we still have to support the old rel=describedby link

Arnaud Le Hors: the only downside is that if we come up with a better way, we still have to support the old rel=describedby link

17:40:49 <sandro> Arnaud: worst case, we need to send around extra describedby links

Arnaud Le Hors: worst case, we need to send around extra describedby links [ Scribe Assist by Sandro Hawke ]

17:40:53 <deiu> ... it's not a big problem

... it's not a big problem

17:42:37 <sandro> PROPOSED: we'll use rel=describedby as in the spec currently, for both metadata on binary resources, and expressing constraints during server error messages.   These are both descriptions and there may be lots of other kinds in the future, too.

PROPOSED: we'll use rel=describedby as in the spec currently, for both metadata on binary resources, and expressing constraints during server error messages. These are both descriptions and there may be lots of other kinds in the future, too.

17:43:02 <JohnArwe> +0 (don't care/fine either way)

John Arwe: +0 (don't care/fine either way)

17:43:03 <TallTed> +1

Ted Thibodeau: +1

17:43:04 <sandro> +0.9

Sandro Hawke: +0.9

17:43:07 <deiu> +0

+0

17:43:08 <roger> +1

Roger Menday: +1

17:43:10 <betehess> +0

Alexandre Bertails: +0

17:43:11 <SteveS> +1

Steve Speicher: +1

17:43:27 <MiguelAraCo> +0

Miguel Aragón: +0

17:43:52 <Arnaud> RESOLVED: We'll use rel=describedby as in the spec currently, for both metadata on binary resources, and expressing constraints during server error messages.   These are both descriptions and there may be lots of other kinds in the future, too.

RESOLVED: We'll use rel=describedby as in the spec currently, for both metadata on binary resources, and expressing constraints during server error messages. These are both descriptions and there may be lots of other kinds in the future, too.

17:44:11 <sandro> http://www.w3.org/TR/powder-dr/#assoc-linking

Sandro Hawke: http://www.w3.org/TR/powder-dr/#assoc-linking

17:45:18 <JohnArwe> http://www.w3.org/2007/powder/powder-errata

John Arwe: http://www.w3.org/2007/powder/powder-errata

17:45:48 <JohnArwe> within errata, search on: Misalignment of definition of wdrs:describedby cf. @rel describedby

John Arwe: within errata, search on: Misalignment of definition of wdrs:describedby cf. @rel describedby

17:46:00 <TallTed> better -- http://www.w3.org/2007/powder/powder-errata#describedby

Ted Thibodeau: better -- http://www.w3.org/2007/powder/powder-errata#describedby

17:48:32 <deiu> [people talking about defining describedby or linking to the right definition]

[people talking about defining describedby or linking to the right definition]

17:49:30 <sandro> Do we keep this:     We define the RDF property wdrs:describedby, the meaning of which is identical to the describedby link relationship type defined above so that:

Sandro Hawke: Do we keep this: We define the RDF property wdrs:describedby, the meaning of which is identical to the describedby link relationship type defined above so that:

17:49:51 <sandro> ... if we're defining a spec for rel=describedby.

Sandro Hawke: ... if we're defining a spec for rel=describedby.

17:50:21 <deiu> sandro: I'm suggesting we change anything that would affect implementations, just editorially

Sandro Hawke: I'm suggesting we change anything that would affect implementations, just editorially

17:51:19 <deiu> ... we can defined describedby the way we want it, and still keep the link header definition from powder

... we can define describedby the way we want it, and still keep the link header definition from powder

17:51:26 <deiu> s/defined/define
17:52:03 <Zakim> +??P0

Zakim IRC Bot: +??P0

17:52:17 <JohnArwe> The relationship A 'describedby' B asserts that resource B provides a description of resource A.

John Arwe: The relationship A 'describedby' B asserts that resource B provides a description of resource A.

17:52:17 <nmihindu> Zakim, ??P0 is me

Nandana Mihindukulasooriya: Zakim, ??P0 is me

17:52:17 <Zakim> +nmihindu; got it

Zakim IRC Bot: +nmihindu; got it

17:52:28 <nmihindu> Zakim, mute me

Nandana Mihindukulasooriya: Zakim, mute me

17:52:28 <Zakim> nmihindu should now be muted

Zakim IRC Bot: nmihindu should now be muted

17:52:58 <JohnArwe> ...that's the normative definition of it based on the content of the errata linked to above

John Arwe: ...that's the normative definition of it based on the content of the errata linked to above

17:53:13 <deiu> sandro: the reference points to the powder spec which has a bad definition

Sandro Hawke: the reference points to the powder spec which has a bad definition

17:53:26 <deiu> sandro: the textual definition from Appendix D is fine

Sandro Hawke: the textual definition from Appendix D is fine

17:53:55 <deiu> ... unfortunately iana links to a different part of the spec

... unfortunately iana links to a different part of the spec

17:54:22 <JohnArwe> http://www.w3.org/2007/05/powder-s.rdf#describedby

John Arwe: http://www.w3.org/2007/05/powder-s.rdf#describedby

17:54:31 <sandro> sandro: Basically, http://www.w3.org/TR/powder-dr/#appD is fine.

Sandro Hawke: Basically, http://www.w3.org/TR/powder-dr/#appD is fine. [ Scribe Assist by Sandro Hawke ]

17:54:31 <sandro>     http://www.w3.org/TR/powder-dr/#assoc-linking

Sandro Hawke: http://www.w3.org/TR/powder-dr/#assoc-linking

17:54:39 <sandro> http://www.w3.org/TR/powder-dr/#semlink

Sandro Hawke: http://www.w3.org/TR/powder-dr/#semlink

17:54:43 <JohnArwe> ...that's the link from the erratum to the RDF Schema document

John Arwe: ...that's the link from the erratum to the RDF Schema document

17:54:48 <deiu> Arnaud: so we are good from an LDP perspective, it's just the references that need to be fixed

Arnaud Le Hors: so we are good from an LDP perspective, it's just the references that need to be fixed

17:56:19 <TallTed> http://www.w3.org/2010/08/26-maintenance.html

Ted Thibodeau: http://www.w3.org/2010/08/26-maintenance.html

17:56:57 <deiu> sandro: can't we have LDP just repeat the same definition, instead of using the link from iana to powder

Sandro Hawke: can't we have LDP just repeat the same definition, instead of using the link from iana to powder

17:58:40 <deiu> ... basically copy the definition from Appendix D into LDP

... basically copy the definition from Appendix D into LDP

17:59:30 <sandro> PROPOSED: Copy http://www.w3.org/TR/powder-dr/#appD, more or less, to LDP, so that the link registry can avoid the powder errata situation, pending confirmation from IETF liaison that this is reasonable

PROPOSED: Copy http://www.w3.org/TR/powder-dr/#appD, more or less, to LDP, so that the link registry can avoid the powder errata situation, pending confirmation from IETF liaison that this is reasonable

18:00:00 <sandro> +1

Sandro Hawke: +1

18:00:02 <deiu> +1

+1

18:00:06 <SteveS> +0.5

Steve Speicher: +0.5

18:00:10 <betehess> +0

Alexandre Bertails: +0

18:00:11 <TallTed> +1

Ted Thibodeau: +1

18:00:12 <nmihindu> +0

Nandana Mihindukulasooriya: +0

18:00:23 <JohnArwe> +0.5

John Arwe: +0.5

18:00:24 <Ashok> 1

Ashok Malhotra: 1

18:00:37 <Arnaud> RESOLVED: Copy http://www.w3.org/TR/powder-dr/#appD, more or less, to LDP, so that the link registry can avoid the powder errata situation, pending confirmation from IETF liaison that this is reasonable

RESOLVED: Copy http://www.w3.org/TR/powder-dr/#appD, more or less, to LDP, so that the link registry can avoid the powder errata situation, pending confirmation from IETF liaison that this is reasonable

18:00:39 <sandro> (the "more or less" is meant to cover the fact that the link will of course be different., as will the description of the process.)

Sandro Hawke: (the "more or less" is meant to cover the fact that the link will of course be different., as will the description of the process.)

18:00:54 <sandro> action: sandro follow up on resolution about moving rel=describedby text

ACTION: sandro follow up on resolution about moving rel=describedby text

18:01:00 <trackbot> Created ACTION-138 - Follow up on resolution about moving rel=describedby text [on Sandro Hawke - due 2014-04-22].

Trackbot IRC Bot: Created ACTION-138 - Follow up on resolution about moving rel=describedby text [on Sandro Hawke - due 2014-04-22].

<deiu> subtopic: Moving to CR

2.5. Moving to CR

18:03:06 <deiu> Arnaud: let's talk about the LDP spec now, what do we need to move forward

Arnaud Le Hors: let's talk about the LDP spec now, what do we need to move forward

18:03:14 <deiu> ... what does it mean to go to CR?

... what does it mean to go to CR?

18:03:25 <deiu> ... it's an explicit call for feedback

... it's an explicit call for feedback

18:03:30 <SteveS> Process stuff http://www.w3.org/2005/10/Process-20051014/tr#transition-reqs

Steve Speicher: Process stuff http://www.w3.org/2005/10/Process-20051014/tr#transition-reqs

18:03:59 <deiu> ... as part of the process we have to define our exit criteria for CR

... as part of the process we have to define our exit criteria for CR

18:04:24 <deiu> Ashok: you want to go to CR on the spec (and only on the spec), no paging spec

Ashok Malhotra: you want to go to CR on the spec (and only on the spec), no paging spec

18:04:47 <deiu> ... paging is really important, so is patch

... paging is really important, so is patch

18:05:28 <deiu> Arnaud: at this point the spec is what it is, but as soon as we make progress on paging/patch we can update the spec and/or point to those documents

Arnaud Le Hors: at this point the spec is what it is, but as soon as we make progress on paging/patch we can update the spec and/or point to those documents

18:05:46 <deiu> Ashok: paging is a fundamental part of our scope

Ashok Malhotra: paging is a fundamental part of our scope

18:06:10 <deiu> ... it is one of the two big questions, so can we go to CR with only half the work?

... it is one of the two big questions, so can we go to CR with only half the work?

18:06:25 <deiu> Arnaud: we made a decision to move paging to the side for now

Arnaud Le Hors: we made a decision to move paging to the side for now

18:06:41 <deiu> ... I agree that is is on the charter and we will dedicate time to it

... I agree that is is on the charter and we will dedicate time to it

18:07:42 <deiu> timbl: paging is useful but patch is more vital

Tim Berners-Lee: paging is useful but patch is more vital

18:08:14 <deiu> Arnaud: paging is still on the table, we're not dropping it

Arnaud Le Hors: paging is still on the table, we're not dropping it

18:08:58 <SteveS> q+ ask about current “features at risk” in draft

Steve Speicher: q+ ask about current “features at risk” in draft

18:09:16 <Arnaud> ack SteveS

Arnaud Le Hors: ack SteveS

18:09:37 <deiu> Arnaud: it would be better to have something (LDP) even without paging, as opposed to not making it to CR at all due to paging

Arnaud Le Hors: it would be better to have something (LDP) even without paging, as opposed to not making it to CR at all due to paging

18:10:41 <deiu> Arnaud: we can delay Accept-Post

Arnaud Le Hors: we can delay Accept-Post

18:10:54 <deiu> ... we're waiting on progress from the IETF

... we're waiting on progress from the IETF

18:11:25 <deiu> ... we'll carry both features to CR for now

... we'll carry both features to CR for now

18:11:42 <deiu> ... CR is open-ended, we don't exit until we meet the criteria

... CR is open-ended, we don't exit until we meet the criteria

18:12:25 <deiu> ... going back to the CR discussion now

... going back to the CR discussion now

18:12:49 <deiu> sandro: the exit criteria is about either having two implementations that pass every test, or every test is passed by at least two implementations

Sandro Hawke: the exit criteria could be about either having two implementations that pass every test, or every test could be passed by at least two implementations

18:13:46 <Arnaud> s/is/could be/
18:16:25 <deiu> Arnaud: some parts of the spec are difficult to test (i.e. MUST vs SHOULD)

Arnaud Le Hors: some parts of the spec are difficult to test (i.e. MUST vs SHOULD)

18:17:40 <deiu> sandro: those are useful tests but they are not required for CR exit

Sandro Hawke: those are useful tests but they are not required for CR exit

18:18:31 <nmihindu> related section on non-testable parts in test suite document -> https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html#test-suite-coverage

Nandana Mihindukulasooriya: related section on non-testable parts in test suite document -> https://dvcs.w3.org/hg/ldpwg/raw-file/tip/Test%20Cases/LDP%20Test%20Cases.html#test-suite-coverage

18:18:48 <deiu> timbl: test suits should be public, even though W3C does trust the spec implementors

Tim Berners-Lee: test suits should be public, even though W3C does trust the spec implementors

18:19:49 <codyburleson> We are implementing - with goal for Q3. So, we will have a lot of the internals within a month or two.

Cody Burleson: We are implementing - with goal for Q3. So, we will have a lot of the internals within a month or two.

18:19:50 <nmihindu> Arnaud, every test is passed by at least two implementations seems to be the better criteria

Nandana Mihindukulasooriya: Arnaud, every test is passed by at least two implementations seems to be the better criteria

18:19:53 <sandro> sandro: Are your implementations expecting to be feature-complete for LDP?

Sandro Hawke: Are your implementations expecting to be feature-complete for LDP? [ Scribe Assist by Sandro Hawke ]

18:20:10 <deiu> Arnaud: let's go around the table to see who plans on implementing it

Arnaud Le Hors: let's go around the table to see who plans on implementing it

18:21:00 <deiu> [around 4-5 people]

[around 4-5 people]

18:21:16 <sandro> raised hands from: roger, steve, andrei, alexandre

Sandro Hawke: raised hands from: roger, steve, andrei, alexandre, TallTed

18:21:43 <Ashok> ... and Oracle

Ashok Malhotra: ... and Oracle

18:21:49 <sandro> roger: server and client library, focus on direct and indirect containers, written in Scala, not open source

Roger Menday: server and client library, focus on direct and indirect containers, written in Scala, not open source [ Scribe Assist by Sandro Hawke ]

18:22:16 <TallTed> s/alexandre/alexandre, TallTed/
18:23:30 <deiu> SteveS: a simple reference server, a thin layer to prove the entire spec (in java)

Steve Speicher: a simple reference server, a thin layer to prove the entire spec (in java)

18:23:46 <sandro> SteveS: a number of impls, including a simple reference server (jaxrs + jena), supporting everything in LDP, Open Source (Eclipse)

Steve Speicher: a number of impls, including a simple reference server (jaxrs + jena), supporting everything in LDP, Open Source (Eclipse) [ Scribe Assist by Sandro Hawke ]

18:23:46 <nmihindu> nmihindu: we will have one implementation for the ALM iStack project from UPM http://www.centeropenmiddleware.com/news/overviewofthefirstyearofthealmistackproject and a variant of that combined with  R2RML http://oeg-dev.dia.fi.upm.es/morph-ldp/. We plan to open source our implementation as soon as we figure out some bureaucratic stuff.

Nandana Mihindukulasooriya: we will have one implementation for the ALM iStack project from UPM http://www.centeropenmiddleware.com/news/overviewofthefirstyearofthealmistackproject and a variant of that combined with R2RML http://oeg-dev.dia.fi.upm.es/morph-ldp/. We plan to open source our implementation as soon as we figure out some bureaucratic stuff. [ Scribe Assist by Nandana Mihindukulasooriya ]

18:24:31 <sandro> SteveS: products at their own pace

Steve Speicher: products at their own pace [ Scribe Assist by Sandro Hawke ]

18:25:37 <sandro> andrei: open source server, personal data store, in PHP; working on another one in go.

Andrei Sambra: open source server, personal data store, in PHP; working on another one in go. [ Scribe Assist by Sandro Hawke ]

18:25:59 <sandro> andrei: only basic containers.

Andrei Sambra: only basic containers. [ Scribe Assist by Sandro Hawke ]

18:26:27 <sandro> andrei: also client (cimba), uses basic containers

Andrei Sambra: also client (cimba), uses basic containers [ Scribe Assist by Sandro Hawke ]

18:26:40 <nmihindu> nmihindu: in ALM iStack, we might not support all the features in the spec thought for the first version.

Nandana Mihindukulasooriya: in ALM iStack, we might not support all the features in the spec thought for the first version. [ Scribe Assist by Nandana Mihindukulasooriya ]

18:26:41 <sandro> betehess: Scala, supports basic containers

Alexandre Bertails: Scala, supports basic containers [ Scribe Assist by Sandro Hawke ]

18:28:18 <sandro> SteveS: indirectContainers is planned, but not done

Steve Speicher: indirectContainers is planned, but not done [ Scribe Assist by Sandro Hawke ]

18:28:34 <sandro> sandro: Don't implement it just for CR.  Implement it if your users want it.

Sandro Hawke: Don't implement it just for CR. Implement it if your users want it. [ Scribe Assist by Sandro Hawke ]

18:29:07 <deiu> TallTed: we are working on an implementation (full featured) but we don't have an ETA

Ted Thibodeau: we are working on an implementation (full featured) but we don't have an ETA

18:29:38 <sandro> TallTed: Working on an implementation.   I don't have ETA.  Probably full features, client and servers.        At least virtuoso engine able to act as client and server.

Ted Thibodeau: Working on an implementation. I don't have ETA. Probably full features, client and servers. At least virtuoso engine able to act as client and server. [ Scribe Assist by Sandro Hawke ]

18:30:02 <deiu> Ashok: we've started working on an implementation

Ashok Malhotra: we've started working on an implementation

18:30:11 <sandro> Ashok: We might have two.    Just starting, probably not ready in the 2-3 month timeframe.

Ashok Malhotra: We might have two. Just starting, probably not ready in the 3-6 month timeframe. [ Scribe Assist by Sandro Hawke ]

18:31:24 <sandro> zakim, who is on the call?

Sandro Hawke: zakim, who is on the call?

18:31:24 <Zakim> On the phone I see +1.617.715.aaaa, codyburleson, nmihindu (muted)

Zakim IRC Bot: On the phone I see +1.617.715.aaaa, codyburleson, nmihindu (muted)

18:31:33 <Ashok> s/2-3/3-6/
18:31:44 <nmihindu> Apache Marmotta which Sergio et al. are working on.

Nandana Mihindukulasooriya: Apache Marmotta which Sergio et al. are working on.

18:32:28 <SteveS> http://wiki.apache.org/marmotta/LDPImplementationReport/2014-03-11

Steve Speicher: http://wiki.apache.org/marmotta/LDPImplementationReport/2014-03-11

18:38:21 <sandro> sandro: I think at some point we'll have a much better, elegant thing for what DirectContainer and IndirectContainer do.    But I'm okay with us proceeding with including them, since we don't have those elegant things yet.

(No events recorded for 5 minutes)

Sandro Hawke: I think at some point we'll have a much better, elegant thing for what DirectContainer and IndirectContainer do. But I'm okay with us proceeding with including them, since we don't have those elegant things yet. [ Scribe Assist by Sandro Hawke ]

18:41:35 <deiu> Arnaud: let's get back to the exit criteria

Arnaud Le Hors: let's get back to the exit criteria

18:41:48 <sandro> arnaud: I think we're in a fairly healthy situation on implementations

Arnaud Le Hors: I think we're in a fairly healthy situation on implementations [ Scribe Assist by Sandro Hawke ]

18:42:57 <deiu> Arnaud: each feature of LDP must be implemented by at least 2 implementations

Arnaud Le Hors: each feature of LDP must be implemented by at least 2 implementations

18:43:15 <deiu> ... we rely on people making a statement about it, say whether or not they have implemented it

... we rely on people making a statement about it, say whether or not they have implemented it

18:43:39 <sandro> Each Feature and Test has been implementation by at least two independent implementations

Sandro Hawke: Each Feature and Test has been implemented by at least two independent implementations

18:43:57 <TallTed> s/been implementation/been implemented/
18:44:14 <Arnaud> PROPOSED: define exit criteria as: Each Feature and Test has been implementation by at least two independent implementations

PROPOSED: define exit criteria as: Each Feature and Test has been implementation by at least two independent implementations

18:45:21 <codyburleson> Wouldn't 3 be better than 2, so that there can be a majority on one side of any issue rather than just 1 vs 1?

Cody Burleson: Wouldn't 3 be better than 2, so that there can be a majority on one side of any issue rather than just 1 vs 1?

18:45:47 <sandro> PROPOSED: Define exit criteria: Each feature implemented and each test passed by at least two independent implementations

PROPOSED: Define exit criteria: Each feature implemented and each test passed by at least two independent implementations

18:46:12 <codyburleson> OK

Cody Burleson: OK

18:46:33 <sandro> Arnaud: codyburleson we don't do majority -- if there's a disagreement we work it out, and come to consensus.

Arnaud Le Hors: codyburleson we don't do majority -- if there's a disagreement we work it out, and come to consensus. [ Scribe Assist by Sandro Hawke ]

18:46:53 <betehess> +1 sounds good

Alexandre Bertails: +1 sounds good

18:46:59 <nmihindu> +1

Nandana Mihindukulasooriya: +1

18:47:00 <codyburleson> +1

Cody Burleson: +1

18:47:03 <deiu> +1

+1

18:47:13 <Ashok> +1

Ashok Malhotra: +1

18:47:35 <sandro> +1 but of course the details depend on the checklist of fatures and the test suite

Sandro Hawke: +1 but of course the details depend on the checklist of fatures and the test suite

18:48:12 <sandro> RESOLVED: Define exit criteria: Each feature implemented and each test passed by at least two independent implementations

RESOLVED: Define exit criteria: Each feature implemented and each test passed by at least two independent implementations

18:48:55 <deiu> Arnaud: let's talk about the BP&G

Arnaud Le Hors: let's talk about the BP&G

18:49:17 <sandro> topic: Best Practices & Guidelines document

3. Best Practices & Guidelines document

18:49:08 <codyburleson>  Status:

Cody Burleson: Status:

18:49:30 <codyburleson> All BPs in original wiki doc have been added (and words refined).

Cody Burleson: All BPs in original wiki doc have been added (and words refined).

18:49:47 <codyburleson> TO DO: Update to reflect new revisions in spec; specifically: containe rtypes and code examples

Cody Burleson: TO DO: Update to reflect new revisions in spec; specifically: containe rtypes and code examples

18:50:06 <Ashok> Pl. paste URL

Ashok Malhotra: Pl. paste URL

18:50:12 <deiu> Arnaud: cody, as the editor for the BP&G document, can you please give us an update

Arnaud Le Hors: cody, as the editor for the BP&G document, can you please give us an update

18:50:55 <deiu> codyburleson: now that the spec has changed, the document needs to be updated to reflect the changes (e.g. container type)

Cody Burleson: now that the spec has changed, the document needs to be updated to reflect the changes (e.g. container type)

18:51:04 <deiu> ... at least two things from today also need to be added

... at least two things from today also need to be added

18:51:33 <sandro> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html

Sandro Hawke: https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html

18:51:34 <deiu> ... I could update the document to catch up with the spec in the next couple of days, but I think the document also needs a team review

... I could update the document to catch up with the spec in the next couple of days, but I think the document also needs a team review

18:51:46 <deiu> Arnaud: I'd rather ask people to review the spec when you think you're done

Arnaud Le Hors: I'd rather ask people to review the spec when you think you're done

18:52:06 <deiu> ... reviewing the document after every change is not efficient

... reviewing the document after every change is not efficient

18:52:13 <deiu> ... do you need people to review it *now*?

... do you need people to review it *now*?

18:52:19 <deiu> ... is there an immediate benefit?

... is there an immediate benefit?

18:52:28 <deiu> codyburleson: not really, I need to add today's items

Cody Burleson: not really, I need to add today's items

18:52:48 <deiu> ... after this meeting, I could use a few days to update the spec and present it for review

... after this meeting, I could use a few days to update the spec and present it for review

18:53:20 <deiu> ... I don't know if I have the right words for the changes right now, so I might need to talk to people

... I don't know if I have the right words for the changes right now, so I might need to talk to people

18:53:47 <deiu> Arnaud: if you're not sure, you could put some placeholders in the document and then signal when you're done so we can assign 2 people to review it

Arnaud Le Hors: if you're not sure, you could put some placeholders in the document and then signal when you're done so we can assign 2 people to review it

18:54:06 <deiu> ... this doc has never been officially published, and we need to get to that stage since this will be a WG note

... this doc has never been officially published, and we need to get to that stage since this will be a WG note

18:54:17 <Ashok> q

Ashok Malhotra: q

18:54:28 <deiu> ... we need to refer to it in the main spec, so it needs publishing

... we need to refer to it in the main spec, so it needs publishing

18:54:34 <Ashok> q+

Ashok Malhotra: q+

18:54:53 <deiu> codyburleson: I can notify the team by 28th to review the doc

Cody Burleson: I can notify the team by 28th to review the doc

18:55:13 <deiu> Arnaud: on the 21st we'll have a formal call, so 28th would be good

Arnaud Le Hors: on the 21st we'll have a formal call, so 28th would be good

18:55:30 <deiu> ... we can assign two people to look at it then and then hopefully publish it

... we can assign two people to look at it then and then hopefully publish it

18:55:49 <Arnaud> ack Ashok

Arnaud Le Hors: ack Ashok

18:56:47 <sandro> sandro; Section 2.3 "Use Relative URIs" obviously needs to be updated with a big EXCEPT ON POST.

Sandro Hawke: sandro; Section 2.3 "Use Relative URIs" obviously needs to be updated with a big EXCEPT ON POST.

18:56:47 <deiu> Ashok: as we've gone to the spec, we have said that some things need to be clarified and added to the BP&G so I want to be sure they've been caught and they'll be added to the doc

Ashok Malhotra: as we've gone to the spec, we have said that some things need to be clarified and added to the BP&G so I want to be sure they've been caught and they'll be added to the doc

18:56:52 <sandro> sandro: Section 2.3 "Use Relative URIs" obviously needs to be updated with a big EXCEPT ON POST.

Sandro Hawke: Section 2.3 "Use Relative URIs" obviously needs to be updated with a big EXCEPT ON POST. [ Scribe Assist by Sandro Hawke ]

18:57:48 <deiu> codyburleson: I'll track people down and talk to them if I don't understand what's in the minutes

Cody Burleson: I'll track people down and talk to them if I don't understand what's in the minutes

18:59:57 <deiu> Arnaud: we've volunteered to do all these deliverables and we need to keep moving, because I feel that we're not really working on these documents

Arnaud Le Hors: we've volunteered to do all these deliverables and we need to keep moving, because I feel that we're not really working on these documents

19:00:26 <deiu> ... once we're done with the LDP spec I'll start hunting you! (fair warning)

... once we're done with the LDP spec I'll start hunting you! (fair warning)

19:00:38 <deiu> ... and haunting too!

... and haunting too!

19:02:42 <betehess> http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0625.html

Alexandre Bertails: http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0625.html

19:03:02 <betehess> [[

Alexandre Bertails: [[

19:03:02 <betehess> The most relevant proposals were:

Alexandre Bertails: The most relevant proposals were:

19:03:02 <betehess> A. Opportunistic encryption for http:// URIs without server authentication -- a.k.a. "TLS Relaxed" as per draft-nottingham-http2-encryption.

Alexandre Bertails: A. Opportunistic encryption for http:// URIs without server authentication -- a.k.a. "TLS Relaxed" as per draft-nottingham-http2-encryption.

19:03:02 <betehess> B. Opportunistic encryption for http:// URIs with server authentication -- the same mechanism, but not "relaxed", along with some form of downgrade protection.

Alexandre Bertails: B. Opportunistic encryption for http:// URIs with server authentication -- the same mechanism, but not "relaxed", along with some form of downgrade protection.

19:03:04 <betehess> ]]

Alexandre Bertails: ]]

19:03:31 <deiu> Arnaud: in terms of timing, we need to look at the charter and the expiration date and see when and much of an extension we need to request

Arnaud Le Hors: in terms of timing, we need to look at the charter and the expiration date and see when and much of an extension we need to request

19:03:36 <deiu> sandro: "expires June 1st"

Sandro Hawke: "expires June 1st"

19:06:45 <deiu> [people discussing the W3C technical aspects of charter extension]

[people discussing the W3C technical aspects of charter extension]

19:07:37 <deiu> [break for 10-15 mins]

[break for 10-15 mins]

19:31:09 <deiu> [resuming meeting]

(No events recorded for 23 minutes)

[resuming meeting]

19:33:35 <deiu> Topic: Paging specification

4. Paging specification

19:35:17 <deiu> Ashok: we're trying to make the Web R/W

Ashok Malhotra: we're trying to make the Web R/W

19:35:27 <deiu> [Ashok presents slides]

[Ashok presents slides]

19:36:13 <deiu> ...databases have stuff that we haven't got on the Web, such as locking, transactions, etc.

...databases have stuff that we haven't got on the Web, such as locking, transactions, etc.

19:37:07 <Zakim> +??P1

Zakim IRC Bot: +??P1

19:37:16 <nmihindu> Zakim, ??P1 is me

Nandana Mihindukulasooriya: Zakim, ??P1 is me

19:37:16 <Zakim> +nmihindu; got it

Zakim IRC Bot: +nmihindu; got it

19:37:22 <nmihindu> Zakim, mute me

Nandana Mihindukulasooriya: Zakim, mute me

19:37:22 <Zakim> nmihindu was already muted, nmihindu

Zakim IRC Bot: nmihindu was already muted, nmihindu

19:37:32 <deiu> ... you can have data in the databases that has not yet been computed

... you can have data in the databases that has not yet been computed

19:37:53 <deiu> ... what are we going to do about the http limitations

... what are we going to do about the http limitations

19:38:42 <deiu> ... some possible solutions are to have clients page through collections/graph knowing that it may change during this time

... some possible solutions are to have clients page through collections/graph knowing that it may change during this time

19:38:55 <deiu> ... the client may use ETags to check if the collection has changed

... the client may use ETags to check if the collection has changed

19:39:16 <deiu> ... client pages through snapshot of collection

... client pages through snapshot of collection

19:40:24 <deiu> ... the feedback we got was about snapshots and the fact that they cost almost nothing

... the feedback we got was about snapshots and the fact that they cost almost nothing

19:40:40 <deiu> ... the database guys are used to this system

... the database guys are used to this system

19:41:16 <deiu> ... the problem with snapshots is that we don't know when the snapshots are created and deleted

... the problem with snapshots is that we don't know when the snapshots are created and deleted

19:41:34 <deiu> ... the solution is to use locking and transactions instead

... the solution is to use locking and transactions instead

19:43:04 <deiu> Arnaud: we have no guarantee that as you walk the pages, you have seen all the resources in their current state

Arnaud Le Hors: we have no guarantee that as you walk the pages, you have seen all the resources in their current state

19:43:22 <deiu> ... with http there is no guarantee that a change has not been produced during this time

... with http there is no guarantee that a change has not been produced during this time

19:43:42 <deiu> ... Sandro requires guarantees that resources have not been missed

... Sandro requires guarantees that resources have not been missed

19:44:06 <deiu> ... it is a reasonable argument, but a difficult one to address

... it is a reasonable argument, but a difficult one to address

19:44:49 <deiu> Ashok: what happened to Sandro's variable page size proposal?

Ashok Malhotra: what happened to Sandro's variable page size proposal?

19:45:40 <sandro> http://lists.w3.org/Archives/Public/public-ldp-wg/2014Mar/0063.html

Sandro Hawke: http://lists.w3.org/Archives/Public/public-ldp-wg/2014Mar/0063.html

19:45:44 <deiu> Arnaud: that proposal is guaranteeing that you're not going to miss triples, even through there might be new tripes, but between the time you started and the time you have finished the traversal, you know you won't miss triples from that range

Arnaud Le Hors: that proposal is guaranteeing that you're not going to miss triples, even through there might be new tripes, but between the time you started and the time you have finished the traversal, you know you won't miss triples from that range

19:46:02 <deiu> ... I still this this proposal is on the table

... I still this this proposal is on the table

19:46:13 <deiu> ... we got pushed back from Ted

... we got pushed back from Ted

19:46:49 <deiu> ... the question is: can we find something that is better than what we have now in the spec, which addresses Sandro's proposal

... the question is: can we find something that is better than what we have now in the spec, which addresses Sandro's proposal

19:49:33 <deiu> [debate over snapshots are expensive or not]

[debate over snapshots are expensive or not]

19:49:41 <betehess> also cost is not only in size, it's also computing power

Alexandre Bertails: also cost is not only in size, it's also computing power

19:49:59 <deiu> [Ashok is defending his take that they are not expensive]

[Ashok is defending his take that they are not expensive]

19:52:34 <betehess> scribenick: betehess

(Scribe set to Alexandre Bertails)

19:52:51 <betehess> Arnaud: if there was a snapshot feature, of course that'd solve the problem

Arnaud Le Hors: if there was a snapshot feature, of course that'd solve the problem

19:53:01 <betehess> ... not sure we want to do that

... not sure we want to do that

19:53:35 <betehess> ... there could be an LDP Snapshot spec

... there could be an LDP Snapshot spec

19:53:48 <betehess> sandro: do we want paging to depend on snapshot?

Sandro Hawke: do we want paging to depend on snapshot?

19:54:04 <betehess> Arnaud: or we can have paging like it is today, with its flaws

Arnaud Le Hors: or we can have paging like it is today, with its flaws

19:54:17 <betehess> TallTed: it's a best effort

Ted Thibodeau: it's a best effort

19:54:52 <betehess> ... when we start having snapshot, just advertise it

... when we start having snapshot, just advertise it

19:55:25 <betehess> Arnaud: at WWW last weeek, somebody presented how to do transactions with 2 phase commit, in a restful way

Arnaud Le Hors: at WWW last weeek, somebody presented how to do transactions with 2 phase commit, in a restful way

19:55:30 <betehess> ... including timeouts

... including timeouts

19:55:35 <betehess> ... clients can cancel

... clients can cancel

19:55:42 <betehess> ... so there are ways to do it

... so there are ways to do it

19:56:06 <betehess> ... totally doable

... totally doable

19:57:30 <betehess> TallTed: we need to study the database history

Ted Thibodeau: we need to study the database history

19:57:34 <betehess> ... to learn from it

... to learn from it

19:57:45 <deiu> scribenick: deiu

(Scribe set to Andrei Sambra)

19:57:52 <nmihindu> We identified at least 8 different transaction models proposed for REST including TCC which Arnaud mentioned http://ws-rest.org/2014/sites/default/files/wsrest2014_submission_4.pdf

Nandana Mihindukulasooriya: We identified at least 8 different transaction models proposed for REST including TCC which Arnaud mentioned http://ws-rest.org/2014/sites/default/files/wsrest2014_submission_4.pdf

19:58:03 <deiu> Arnaud: isn't option 2 what we have already

Arnaud Le Hors: isn't option 2 what we have already

19:58:26 <deiu> sandro: not really, we need another header

Sandro Hawke: not really, we need another header

19:59:06 <deiu> Arnaud: the same comments from 2 also apply to 1

Arnaud Le Hors: the same comments from 2 also apply to 1

20:00:13 <deiu> sandro: snapshot is a way to implement lossless paging

Sandro Hawke: snapshot is a way to implement lossless paging

20:01:34 <deiu> TallTed: all are viable options with different costs and tradeoffs

Ted Thibodeau: all are viable options with different costs and tradeoffs

20:01:46 <deiu> ... we should not force clients to choose one over another

... we should not force clients to choose one over another

20:01:56 <deiu> ... the negotiation is really important

... the negotiation is really important

20:02:15 <nmihindu> +1 TallTed, it is important if the client can negotiate that based on its needs

Nandana Mihindukulasooriya: +1 TallTed, it is important if the client can negotiate that based on its needs

20:02:43 <deiu> Arnaud: I think we should do option 2, to give the client a fair warning

Arnaud Le Hors: I think we should do option 2, to give the client a fair warning

20:03:33 <deiu> sandro: we just need another header (similar to ETag) but for the main resource that we apply paging to

Sandro Hawke: we just need another header (similar to ETag) but for the main resource that we apply paging to

20:03:37 <betehess> q+

Alexandre Bertails: q+

20:04:21 <Arnaud> ack betehess

Arnaud Le Hors: ack betehess

20:04:52 <deiu> betehess: what about caching? if you add new headers that are not supported by proxies?

Alexandre Bertails: what about caching? if you add new headers that are not supported by proxies?

20:05:09 <deiu> sandro: it shouldn't be a problem if we expose that header in the Vary header

Sandro Hawke: it shouldn't be a problem if we expose that header in the Vary header

20:06:03 <sandro> OPTION 1: Undetectable Lossy

Sandro Hawke: OPTION 1: Undetectable Lossy

20:06:03 <sandro> OPTION 2: Detectable Lossy

Sandro Hawke: OPTION 2: Detectable Lossy

20:06:03 <sandro> OPTION 3: Lossless Paging (Sandro's)

Sandro Hawke: OPTION 3: Lossless Paging (Sandro's)

20:06:03 <sandro> OPTION 4: Use Snapshots

Sandro Hawke: OPTION 4: Use Snapshots

20:06:23 <sandro> OPTION 5: Transactions

Sandro Hawke: OPTION 5: Transactions

20:06:45 <roger> http://ws-rest.org/2014/sites/default/files/wsrest2014_submission_7.pdf

Roger Menday: http://ws-rest.org/2014/sites/default/files/wsrest2014_submission_7.pdf

20:06:47 <roger> ?

Roger Menday: ?

20:06:54 <nmihindu> The presentation that Arnaud mentioned TCC - http://ws-rest.org/2014/sites/default/files/wsrest2014_submission_7.pdf

Nandana Mihindukulasooriya: The presentation that Arnaud mentioned TCC - http://ws-rest.org/2014/sites/default/files/wsrest2014_submission_7.pdf

20:08:26 <TallTed> thanks, nmihindu!

Ted Thibodeau: thanks, nmihindu!

20:09:25 <deiu> sandro: my sense is that 2&3 are the only practical options

Sandro Hawke: my sense is that 2&3 are the only practical options

20:09:51 <deiu> ... people should be able to do paging without snapshots

... people should be able to do paging without snapshots

20:10:59 <sandro> sandro: I want snapshots, but I want paging even on servers that don't support snapshots.   So -1 on 4.

Sandro Hawke: I want snapshots, but I want paging even on servers that don't support snapshots. So -1 on 4. [ Scribe Assist by Sandro Hawke ]

20:11:06 <deiu> TallTed: we need to use common terminology instead of snapshots, so we do not alienate people

Ted Thibodeau: we need to use common terminology instead of snapshots, so we do not alienate people

20:11:46 <deiu> sandro: you actually want the state of the resource (of the members) not of the container

Sandro Hawke: you actually want the state of the resource (of the members) not of the container

20:12:35 <deiu> TallTed: the best thing to do now is to document what we have

Ted Thibodeau: the best thing to do now is to document what we have

20:13:38 <deiu> ... option 2 is fine with me

... option 2 is fine with me

20:13:56 <deiu> Arnaud: I would like to raise the bar and say that we should agree to do option 2

Arnaud Le Hors: I would like to raise the bar and say that we should agree to do option 2

20:14:12 <deiu> ... and also to agree to eliminate option 1

... and also to agree to eliminate option 1

20:14:36 <sandro> PROPOSED: At a minimum, on paging, we'll provide a way for clients to detect that a triple fell through the cracks during paging.

PROPOSED: At a minimum, on paging, we'll provide a way for clients to detect that a triple fell through the cracks during paging.

20:14:49 <sandro> (ie OPTION 2 as a minumum)

Sandro Hawke: (ie OPTION 2 as a minumum)

20:15:04 <TallTed> +1

Ted Thibodeau: +1

20:15:05 <sandro> +1

Sandro Hawke: +1

20:15:13 <deiu> +1

+1

20:15:18 <MiguelAraCo> +1

Miguel Aragón: +1

20:15:19 <nmihindu> +1

Nandana Mihindukulasooriya: +1

20:15:20 <roger> +1

Roger Menday: +1

20:15:42 <SteveS> +1

Steve Speicher: +1

20:15:49 <codyburleson> +1

Cody Burleson: +1

20:17:02 <roger> +q

Roger Menday: +q

20:17:17 <sandro> RESOLVED: At a minimum, on paging, we'll provide a way for clients to detect that a triple fell through the cracks during paging.

RESOLVED: At a minimum, on paging, we'll provide a way for clients to detect that a triple fell through the cracks during paging.

20:19:25 <TallTed> PROPOSED: Any server claiming paging support must provide a way for clients to know that the resource/collection/whatever being paged has changed during the paging.

PROPOSED: Any server claiming paging support must provide a way for clients to know that the resource/collection/whatever being paged has changed during the paging.

20:19:38 <Arnaud> ack roger

Arnaud Le Hors: ack roger

20:20:16 <sandro> TallTed, that's the right spirit, but....

Sandro Hawke: TallTed, that's the right spirit, but....

20:20:42 <deiu> roger: if the ETag header is not there, then the client falls back to option 1

Roger Menday: if the ETag header is not there, then the client falls back to option 1

20:21:13 <deiu> ... it's the same as how ETags are used now, clients use it if it's there

... it's the same as how ETags are used now, clients use it if it's there

20:23:58 <deiu> Arnaud: we're starting to converge, so let's see if we can eliminate the transactions

Arnaud Le Hors: we're starting to converge, so let's see if we can eliminate the transactions

20:24:23 <nmihindu> we would like to have transaction but we have happy to do it outside the LDP spec

Nandana Mihindukulasooriya: we would like to have transaction but we are happy to do it outside the LDP spec

20:24:40 <nmihindu> s/we have happy/we are happy/
20:24:50 <deiu> Arnaud: the LDP does not _require_ you to do transactions for paging

Arnaud Le Hors: the LDP does not _require_ you to do transactions for paging

20:24:58 <sandro> PROPOSED:  We're not going to require use of transactions in order to have paging

PROPOSED: We're not going to require use of transactions in order to have paging

20:25:06 <SteveS> +1

Steve Speicher: +1

20:25:07 <JohnArwe> +1

John Arwe: +1

20:25:08 <sandro> +1

Sandro Hawke: +1

20:25:08 <deiu> +1

+1

20:25:19 <roger> +1

Roger Menday: +1

20:25:24 <TallTed> +1

Ted Thibodeau: +1

20:26:16 <nmihindu> +0

Nandana Mihindukulasooriya: +0

20:26:41 <Ashok> 1

Ashok Malhotra: 1

20:26:46 <sandro> RESOLVED:  We're not going to require use of transactions in order to have paging

RESOLVED: We're not going to require use of transactions in order to have paging

20:28:44 <sandro> PROPOSED: We're not going to require snapshots in order to have (better-than-undetectably-lossy) paging.

PROPOSED: We're not going to require snapshots in order to have (better-than-undetectably-lossy) paging.

20:29:26 <sandro> PROPOSED: We're not going to require snapshots in order to have paging.

PROPOSED: We're not going to require snapshots in order to have paging.

20:29:30 <JohnArwe> +1

John Arwe: +1

20:29:37 <deiu> +1

+1

20:29:38 <roger> +1

Roger Menday: +1

20:29:48 <Ashok> -1

Ashok Malhotra: -1

20:29:58 <TallTed> +0.5

Ted Thibodeau: +0.5

20:30:04 <SteveS> +1

Steve Speicher: +1

20:30:05 <MiguelAraCo> +0

Miguel Aragón: +0

20:30:42 <sandro> sandro: Possible design for snapshots:    server can include a Link <> rel=snapshot

Sandro Hawke: Possible design for snapshots: server can include a Link <> rel=snapshot [ Scribe Assist by Sandro Hawke ]

20:36:25 <deiu> Arnaud: from what I understand the TAG is divided on the 209 code

(No events recorded for 5 minutes)

Arnaud Le Hors: from what I understand the TAG is divided on the 209 code

20:36:46 <deiu> ... http2.0 support won't happen soon either

... http2.0 support won't happen soon either

20:42:26 <sandro> JohnArwe: you can use Link with an Context (Anchor) to say this is a snapshot of the PagedResource

(No events recorded for 5 minutes)

John Arwe: you can use Link with an Context (Anchor) to say this is a snapshot of the PagedResource [ Scribe Assist by Sandro Hawke ]

20:42:31 <sandro> +1 nice!

Sandro Hawke: +1 nice!

20:44:53 <sandro> deiu: Servers should not initiate paging.    Sometimes you want the 2G resource and dont know how to do paging.

Andrei Sambra: Servers should not initiate paging. Sometimes you want the 2G resource and dont know how to do paging. [ Scribe Assist by Sandro Hawke ]

20:46:28 <sandro> client Prefer: maxPageSize=20m

Sandro Hawke: client Prefer: maxPageSize=20m

20:49:44 <TallTed> PROPOSED: An LDP server claiming paging support MAY offer snapshots for paging, but snapshots are not required for paging compliance.

PROPOSED: An LDP server claiming paging support MAY offer snapshots for paging, but snapshots are not required for paging compliance.

20:50:57 <deiu> Arnaud: I wonder if we have to specify the 3 options and define mechanisms for each of them

Arnaud Le Hors: I wonder if we have to specify the 3 options and define mechanisms for each of them

20:51:56 <deiu> sandro: we can make it a note

Sandro Hawke: we can make it a note

20:52:25 <deiu> Ashok: you can also point to a set of best practices

Ashok Malhotra: you can also point to a set of best practices

20:54:15 <deiu> TallTed: the availability of having that option (3) is key to having paging support

Ted Thibodeau: the availability of having that option (3) is key to having paging support

20:54:49 <deiu> Arnaud: how does the client figure out which options are available?

Arnaud Le Hors: how does the client figure out which options are available?

20:55:23 <deiu> ... I'm trying to understand how simple/complicated things will be

... I'm trying to understand how simple/complicated things will be

20:55:44 <deiu> sandro: option 2 can be done with an extra header; the client doesn't need to request anything

Sandro Hawke: option 2 can be done with an extra header; the client doesn't need to request anything

20:56:33 <deiu> ... Link rels can be used for 3 and 4

... Link rels can be used for 3 and 4

20:57:00 <TallTed> http://mementoweb.org/

Ted Thibodeau: http://mementoweb.org/

20:57:06 <JohnArwe> http://www.rfc-editor.org/info/rfc7089

John Arwe: http://www.rfc-editor.org/info/rfc7089

21:06:13 <TallTed> just noticed possibly useful... -- http://tools.ietf.org/html/rfc6585 -- "428 Precondition Required"

(No events recorded for 9 minutes)

Ted Thibodeau: just noticed possibly useful... -- http://tools.ietf.org/html/rfc6585 -- "428 Precondition Required"

21:11:56 <deiu> Arnaud: we should call it a day

(No events recorded for 5 minutes)

Arnaud Le Hors: we should call it a day

21:15:18 <TallTed> complete current HTTP status code list - http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

Ted Thibodeau: complete current HTTP status code list - http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml

21:18:11 <Arnaud> meeting adjourned

Arnaud Le Hors: meeting adjourned

21:18:17 <codyburleson> Thanks!

Cody Burleson: Thanks!

21:18:32 <codyburleson> G'night.

Cody Burleson: G'night.

21:18:47 <Arnaud> bye

Arnaud Le Hors: bye

21:19:48 <Zakim> -codyburleson

Zakim IRC Bot: -codyburleson

21:21:30 <Arnaud> trackbot, end meeting

Arnaud Le Hors: trackbot, end meeting

21:21:30 <trackbot> Zakim, list attendees

Trackbot IRC Bot: Zakim, list attendees

21:21:30 <Zakim> As of this point the attendees have been +1.617.715.aaaa, nmihindu, codyburleson, MiguelAraCo, ericP

Zakim IRC Bot: As of this point the attendees have been +1.617.715.aaaa, nmihindu, codyburleson, MiguelAraCo, ericP

21:21:38 <trackbot> RRSAgent, please draft minutes

Trackbot IRC Bot: RRSAgent, please draft minutes

21:21:38 <RRSAgent> I have made the request to generate http://www.w3.org/2014/04/15-ldp-minutes.html trackbot

RRSAgent IRC Bot: I have made the request to generate http://www.w3.org/2014/04/15-ldp-minutes.html trackbot

21:21:39 <trackbot> RRSAgent, bye

Trackbot IRC Bot: RRSAgent, bye

21:21:39 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2014/04/15-ldp-actions.rdf :

RRSAgent IRC Bot: I see 1 open action item saved in http://www.w3.org/2014/04/15-ldp-actions.rdf :

21:21:39 <RRSAgent> ACTION: sandro follow up on resolution about moving rel=describedby text [1]

ACTION: sandro follow up on resolution about moving rel=describedby text [1]

21:21:39 <RRSAgent>   recorded in http://www.w3.org/2014/04/15-ldp-irc#T18-00-54

RRSAgent IRC Bot: recorded in http://www.w3.org/2014/04/15-ldp-irc#T18-00-54



Formatted by CommonScribe