edit

Linked Data Platform (LDP) Working Group Teleconference

Minutes of 03 September 2013

Agenda
http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2013.09.03
Seen
Arnaud Le Hors, Ashok Malhotra, Bart van Leeuwen, David Wood, Eric Prud'hommeaux, Erik Wilde, Henry Story, John Arwe, Nandana Mihindukulasooriya, Pierre-Antoine Champin, Raúl García Castro, Sandro Hawke, Steve Speicher, Tim Berners-Lee (W3C)
Guests
Tim Berners-Lee (W3C)
Chair
Arnaud Le Hors
Scribe
John Arwe
IRC Log
Original
Resolutions

None.

Topics
14:59:03 <RRSAgent> logging to http://www.w3.org/2013/09/03-ldp-irc

RRSAgent IRC Bot: logging to http://www.w3.org/2013/09/03-ldp-irc

14:59:05 <trackbot> RRSAgent, make logs public

Trackbot IRC Bot: RRSAgent, make logs public

14:59:07 <trackbot> Zakim, this will be LDP

Trackbot IRC Bot: Zakim, this will be LDP

14:59:07 <Zakim> ok, trackbot; I see SW_LDP()11:00AM scheduled to start in 1 minute

Zakim IRC Bot: ok, trackbot; I see SW_LDP()11:00AM scheduled to start in 1 minute

14:59:08 <trackbot> Meeting: Linked Data Platform (LDP) Working Group Teleconference
14:59:08 <trackbot> Date: 03 September 2013
14:59:37 <Zakim> SW_LDP()11:00AM has now started

Zakim IRC Bot: SW_LDP()11:00AM has now started

14:59:44 <Zakim> +Arnaud

Zakim IRC Bot: +Arnaud

15:00:16 <Zakim> +[IBM]

Zakim IRC Bot: +[IBM]

15:00:38 <SteveS> Zakim, [IBM] is me

Steve Speicher: Zakim, [IBM] is me

15:00:38 <Zakim> +SteveS; got it

Zakim IRC Bot: +SteveS; got it

15:01:37 <Zakim> +??P19

Zakim IRC Bot: +??P19

15:01:42 <Zakim> +bblfish

Zakim IRC Bot: +bblfish

15:02:00 <bblfish_> hi

Henry Story: hi

15:02:11 <Zakim> +??P20

Zakim IRC Bot: +??P20

15:02:13 <nmihindu> Zakim, ??P19 is me

Nandana Mihindukulasooriya: Zakim, ??P19 is me

15:02:14 <Zakim> +nmihindu; got it

Zakim IRC Bot: +nmihindu; got it

15:02:27 <nmihindu> Zakim, mute me

Nandana Mihindukulasooriya: Zakim, mute me

15:02:27 <Zakim> nmihindu should now be muted

Zakim IRC Bot: nmihindu should now be muted

15:03:04 <Zakim> +JohnArwe

Zakim IRC Bot: +JohnArwe

15:03:22 <Zakim> +??P32

Zakim IRC Bot: +??P32

15:03:27 <pchampin> zakim, ??P20 is me

Pierre-Antoine Champin: zakim, ??P20 is me

15:03:27 <Zakim> +pchampin; got it

Zakim IRC Bot: +pchampin; got it

15:03:28 <BartvanLeeuwen> Zakim, ??p32 is me

Bart van Leeuwen: Zakim, ??p32 is me

15:03:28 <Zakim> +BartvanLeeuwen; got it

Zakim IRC Bot: +BartvanLeeuwen; got it

15:03:35 <pchampin> zakim, mute me

Pierre-Antoine Champin: zakim, mute me

15:03:37 <Zakim> pchampin should now be muted

Zakim IRC Bot: pchampin should now be muted

15:03:41 <Zakim> +Ashok_Malhotra

Zakim IRC Bot: +Ashok_Malhotra

15:04:13 <Zakim> +??P35

Zakim IRC Bot: +??P35

15:04:44 <Zakim> -??P35

Zakim IRC Bot: -??P35

15:04:50 <Zakim> +TimBL

Zakim IRC Bot: +TimBL

15:05:13 <Zakim> +??P44

Zakim IRC Bot: +??P44

15:05:36 <Arnaud> zakim, who's on the phone?

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

15:05:37 <Zakim> On the phone I see Arnaud, SteveS, nmihindu (muted), bblfish, pchampin (muted), JohnArwe, BartvanLeeuwen, Ashok_Malhotra, TimBL, ??P44

Zakim IRC Bot: On the phone I see Arnaud, SteveS, nmihindu (muted), bblfish, pchampin (muted), JohnArwe, BartvanLeeuwen, Ashok_Malhotra, TimBL, ??P44

15:05:45 <rgarcia> zakim, ??P44 is me

Raúl García Castro: zakim, ??P44 is me

15:05:45 <Zakim> +rgarcia; got it

Zakim IRC Bot: +rgarcia; got it

15:06:17 <JohnArwe> sandro, you joining call?

John Arwe: sandro, you joining call?

15:06:34 <JohnArwe> ericP, you joining call?

John Arwe: ericP, you joining call?

15:06:52 <ericP> oops, tx for reminder

Eric Prud'hommeaux: oops, tx for reminder

15:07:16 <JohnArwe> I can scribe...

John Arwe: I can scribe...

15:07:28 <JohnArwe> scribe: JohnArwe

(Scribe set to John Arwe)

<JohnArwe> guest: Tim (timbl) Berners-Lee, W3C
<JohnArwe> agenda: http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2013.09.03
<JohnArwe> chair: Arnaud
<JohnArwe> topic: Introduction

1. Introduction

15:08:19 <JohnArwe> TimBL unable to attend F2F next week, using this call to understand any additional context on comments raised on list

TimBL unable to attend F2F next week, using this call to understand any additional context on comments raised on list

15:08:26 <Zakim> +EricP

Zakim IRC Bot: +EricP

15:08:45 <JohnArwe> ...so WG can have a better chance of resolving them in a way likely to be acceptable to everyone

...so WG can have a better chance of resolving them in a way likely to be acceptable to everyone

15:09:24 <JohnArwe> Arnaud: need to respond to all comments on list, TimBL's not special in that sense.

Arnaud Le Hors: need to respond to all comments on list, TimBL's not special in that sense.

15:10:08 <JohnArwe> Arnaud: deal with higher level ones on call,  smaller ones via email.  Try to discuss direction, how it got here, what the big animal issues are.

Arnaud Le Hors: deal with higher level ones on call, smaller ones via email. Try to discuss direction, how it got here, what the big animal issues are.

15:10:17 <JohnArwe> Arnaud: more comments coming, per last email?

Arnaud Le Hors: more comments coming, per last email?

15:10:47 <JohnArwe> TimBL: have not found time to type them up, but they have the same ilk

Tim Berners-Lee: have not found time to type them up, but they have the same ilk

15:11:24 <JohnArwe> ... many would change anyway if some of the basic issues were addressed.  e.g. what kind of interop is the goal.

... many would change anyway if some of the basic issues were addressed. e.g. what kind of interop is the goal.

15:11:42 <JohnArwe> ... spec has to require things of clients and servers so they can meet in the middle.

... spec has to require things of clients and servers so they can meet in the middle.

15:11:48 <JohnArwe> ...why so many SHOULDs?

...why so many SHOULDs?

15:12:35 <JohnArwe> ... what's provided above a basic http server?  should we have a separate profile?

... what's provided above a basic http server? should we have a separate profile?

<JohnArwe> topic: Interop / Vanilla vs domain-specific servers

2. Interop / Vanilla vs domain-specific servers

15:13:26 <JohnArwe> Arnaud: history = driven by 2 somewhat conflicting goals; (1) domain-specific servers exist and they want to add an LDP interface to it, like our bug tracker example.

Arnaud Le Hors: history = driven by 2 somewhat conflicting goals; (1) domain-specific servers exist and they want to add an LDP interface to it, like our bug tracker example.

15:13:53 <JohnArwe> ... Those servers are not RDF-based, own internal models, constrain what they store to set fields.

... Those servers are not RDF-based, own internal models, constrain what they store to set fields.

15:14:19 <JohnArwe> ... (2) general RDF store which lacks those constraints on what it stores, so you can demand a lot more from the server

... (2) general RDF store which lacks those constraints on what it stores, so you can demand a lot more from the server

15:15:41 <ericP> i like to exemplify the app-specific LDP app with a controller for a light switch. if you send it triples that don't reflect in a state of the light switch, you'll not see them on a GET

Eric Prud'hommeaux: i like to exemplify the app-specific LDP app with a controller for a light switch. if you send it triples that don't reflect in a state of the light switch, you'll not see them on a GET

15:15:50 <Zakim> -nmihindu

Zakim IRC Bot: -nmihindu

15:16:40 <Zakim> +??P19

Zakim IRC Bot: +??P19

15:17:03 <nmihindu> Zakim, ??P19 is me

Nandana Mihindukulasooriya: Zakim, ??P19 is me

15:17:03 <Zakim> +nmihindu; got it

Zakim IRC Bot: +nmihindu; got it

15:17:20 <nmihindu> Zakim, mute me

Nandana Mihindukulasooriya: Zakim, mute me

15:17:20 <Zakim> nmihindu should now be muted

Zakim IRC Bot: nmihindu should now be muted

15:17:46 <Zakim> + +1.540.898.aaaa

Zakim IRC Bot: + +1.540.898.aaaa

15:17:53 <davidwood> Zakim, aaaa is me

David Wood: Zakim, aaaa is me

15:17:53 <Zakim> +davidwood; got it

Zakim IRC Bot: +davidwood; got it

15:18:23 <JohnArwe> TimBL: domain specific server does not have to implement put/patch; how does client know what to use?  either lots of out of band info required => don't really have a spec.  sounds as if the client lib has to be the kind of thing that iterates through "try X, oh it fails argh, try Y...".  Domain specific doesn't matter there.  I'd like to see the plain vanilla spec first; simpler, allows you to build client apps that are all client-side.

Tim Berners-Lee: domain specific server does not have to implement put/patch; how does client know what to use? either lots of out of band info required => don't really have a spec. sounds as if the client lib has to be the kind of thing that iterates through "try X, oh it fails argh, try Y...". Domain specific doesn't matter there. I'd like to see the plain vanilla spec first; simpler, allows you to build client apps that are all client-side.

15:18:35 <ericP> q+ to say that i was hoping that support libraries for app-specific clients would show us the value of the app-specific profile

Eric Prud'hommeaux: q+ to say that i was hoping that support libraries for app-specific clients would show us the value of the app-specific profile

15:19:24 <JohnArwe> timbl: Vanilla case is really important. Even in case where extra constraints exist, you need ability to specify how to change triples; I need PATCH, and I need a PATCH format.

Tim Berners-Lee: Vanilla case is really important. Even in case where extra constraints exist, you need ability to specify how to change triples; I need PATCH, and I need a PATCH format.

15:19:45 <davidwood> Zakim, mute me

David Wood: Zakim, mute me

15:19:45 <Zakim> davidwood should now be muted

Zakim IRC Bot: davidwood should now be muted

15:20:30 <JohnArwe> Arnaud: everyone in WG *wanted* PATCH, but need at least one patch format for real interop.  since we did not have time to define one, but it on the side and running that discussion in parallel so we can rely on it in next version of LDP.  That's intent.  We can discuss timing.

Arnaud Le Hors: everyone in WG *wanted* PATCH, but need at least one patch format for real interop. since we did not have time to define one, but it on the side and running that discussion in parallel so we can rely on it in next version of LDP. That's intent. We can discuss timing.

15:20:46 <Zakim> -EricP

Zakim IRC Bot: -EricP

15:21:00 <Zakim> +EricP

Zakim IRC Bot: +EricP

15:21:37 <JohnArwe> ... You also said in email LDP is only useful in RW mode, if server is RO then no different than HTTP; want to point out that the notion of containers and paging are counter-examples, things LDP provides not in HTTP.

... You also said in email LDP is only useful in RW mode, if server is RO then no different than HTTP; want to point out that the notion of containers and paging are counter-examples, things LDP provides not in HTTP.

15:21:45 <JohnArwe> TimBL: paging optional?

Tim Berners-Lee: paging optional?

15:21:52 <JohnArwe> SteveS: yes

Steve Speicher: yes

15:23:35 <JohnArwe> TimBL: if can be initiated by server, than mandatory on client.  you need to say that.  b/c you have to meet in the middle, whenever the server has an option, then the client MUST handle it.  and vice versa.  That's how you get interop.  Agree that paging is valuable.

Tim Berners-Lee: if can be initiated by server, than mandatory on client. you need to say that. b/c you have to meet in the middle, whenever the server has an option, then the client MUST handle it. and vice versa. That's how you get interop. Agree that paging is valuable.

15:24:01 <JohnArwe> Earlier question: does current spec say client can initiate paging?  should not.

Earlier question: does current spec say client can initiate paging? should not.

15:24:49 <JohnArwe> Arnaud: can we agree there is still use for LDP in RO case, so we don't have to discuss that further?  I think the problem of interoperability is really the most important point in your comments.

Arnaud Le Hors: can we agree there is still use for LDP in RO case, so we don't have to discuss that further? I think the problem of interoperability is really the most important point in your comments.

15:25:16 <Zakim> -EricP

Zakim IRC Bot: -EricP

15:25:27 <Zakim> +EricP

Zakim IRC Bot: +EricP

15:26:06 <JohnArwe> ... I've been uncomfortable with SHOULDs; Raul ran into that with testing.  So I agree it's an interop problem; how do you think we can improve interop without throwing out the domain-specific server case?  We have a lot of people with those to consider as well/

... I've been uncomfortable with SHOULDs; Raul ran into that with testing. So I agree it's an interop problem; how do you think we can improve interop without throwing out the domain-specific server case? We have a lot of people with those to consider as well/

15:26:18 <ericP> q?

Eric Prud'hommeaux: q?

15:26:41 <davidwood> +1 to Arnaud.  Businesses need domain-specific functionality.  I would love to see an agreement on PATCH, though.

David Wood: +1 to Arnaud. Businesses need domain-specific functionality. I would love to see an agreement on PATCH, though.

15:27:34 <JohnArwe> TimBL: happy to work toward both goals; patch format: code in our RDF lib sends subset of sparql update with MIME type of sparql update, so defining that as simple subset would really help you.

Tim Berners-Lee: happy to work toward both goals; patch format: code in our RDF lib sends subset of sparql update with MIME type of sparql update, so defining that as simple subset would really help you.

15:28:06 <JohnArwe> Arnaud: Sandro helped look at options, after few months he was not comfy moving forward so we had to put it aside.

Arnaud Le Hors: Sandro helped look at options, after few months he was not comfy moving forward so we had to put it aside.

15:29:28 <JohnArwe> TimBL: I can see PATCH is the issue; maybe in spec we put the intent, so people do it.  For PUT/DELETE, say must be supported, but let the Authorization get out jail free card is possible, e.g. a RO server could always respond with 403.

Tim Berners-Lee: I can see PATCH is the issue; maybe in spec we put the intent, so people do it. For PUT/DELETE, say must be supported, but let the Authorization get out jail free card is possible, e.g. a RO server could always respond with 403.

15:29:58 <JohnArwe> ... question: if PUT triples to domain specific server, do I get a 200 back and triples silently discarded?

... question: if PUT triples to domain specific server, do I get a 200 back and triples silently discarded?

15:30:43 <JohnArwe> ... PUT spec says must allow entire thing, so what happens with domain-specific server on PUT?

... PUT spec says must allow entire thing, so what happens with domain-specific server on PUT?

15:30:49 <timbl> "1 If HTTP PUT is performed on an existing resource, LDPR servers MUST replace the entire persistent state of the identified resource with the entity representation in the body of the request."

Tim Berners-Lee: "1 If HTTP PUT is performed on an existing resource, LDPR servers MUST replace the entire persistent state of the identified resource with the entity representation in the body of the request."

15:31:00 <Zakim> -EricP

Zakim IRC Bot: -EricP

15:31:03 <JohnArwe> SteveS: either discards the triples or 4xx.

Steve Speicher: either discards the triples or 4xx.

15:31:07 <Zakim> +EricP

Zakim IRC Bot: +EricP

15:31:12 <JohnArwe> TimBL: 4.5.1

Tim Berners-Lee: 4.5.1

15:31:14 <Zakim> + +1.510.206.aabb

Zakim IRC Bot: + +1.510.206.aabb

15:31:23 <JohnArwe> SteveS: look at MAY

Steve Speicher: look at MAY

15:31:49 <JohnArwe> TimBL: that doesn't cover triples where server does NOT know better (server managed)

Tim Berners-Lee: that doesn't cover triples where server does NOT know better (server managed)

15:31:54 <JohnArwe> SteveS: 4.5 covers that

Steve Speicher: 4.5 covers that

15:32:44 <JohnArwe> TimBL: if server ever can, clients MUST assume (spec says Should) it can happen.  it's not just set of predicates, it's arbitrary constraints on graph.

Tim Berners-Lee: if server ever can, clients MUST assume (spec says Should) it can happen. it's not just set of predicates, it's arbitrary constraints on graph.

15:32:50 <dret> zakim, +1.510.206.aabb is me

Erik Wilde: zakim, +1.510.206.aabb is me

15:32:50 <Zakim> +dret; got it

Zakim IRC Bot: +dret; got it

15:33:08 <JohnArwe> ... parses sentences on client that target the GET/PUT round trip.

... parses sentences on client that target the GET/PUT round trip.

15:33:29 <bblfish>  http://www.w3.org/TR/2013/WD-ldp-20130730/#http-put

Henry Story: http://www.w3.org/TR/2013/WD-ldp-20130730/#http-put

15:33:33 <Zakim> -EricP

Zakim IRC Bot: -EricP

15:33:36 <Zakim> +EricP

Zakim IRC Bot: +EricP

15:33:41 <JohnArwe> ... see that point.  vanilla client has no idea it's talking to a domain-specific server.

... see that point. vanilla client has no idea it's talking to a domain-specific server.

15:35:02 <JohnArwe> Arnaud: maybe this is really the problem we have in spec today, "silent failure".  As you know we have RDF validation workshop next week, that's what we've been using to allow clients to discover these server features.  Henry raised that on list.

Arnaud Le Hors: maybe this is really the problem we have in spec today, "silent failure". As you know we have RDF validation workshop next week, that's what we've been using to allow clients to discover these server features. Henry raised that on list.

15:35:32 <JohnArwe> TimBL: one of nice things about defining new spec is you can define new codes.  You can define 20x as I described instead of 303.

Tim Berners-Lee: one of nice things about defining new spec is you can define new codes. You can define 20x as I described instead of 303.

15:36:02 <ericP> 218½: i'm not storing exactly what you PUT

Eric Prud'hommeaux: 218½: i'm not storing exactly what you PUT

15:36:23 <timbl> Important for spam control for example

Tim Berners-Lee: Important for spam control for example

15:36:46 <JohnArwe> ... similarly you could define a 20x to say "I understand what you said, but you didn't get an exact store"... if client wants to know exactly what happened, can look at server capabilities (assuming available via hypermedia etc online)

... similarly you could define a 20x to say "I understand what you said, but you didn't get an exact store"... if client wants to know exactly what happened, can look at server capabilities (assuming available via hypermedia etc online)

15:36:56 <JohnArwe> zakim, who's making noise?

zakim, who's making noise?

15:37:00 <sandro> Zakim, what is the code?

Sandro Hawke: Zakim, what is the code?

15:37:00 <Zakim> the conference code is 53794 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), sandro

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

15:37:07 <Zakim> JohnArwe, listening for 10 seconds I heard sound from the following: Arnaud (54%), SteveS (36%), TimBL (9%), EricP (24%)

Zakim IRC Bot: JohnArwe, listening for 10 seconds I heard sound from the following: Arnaud (54%), SteveS (36%), TimBL (9%), EricP (24%)

15:37:21 <JohnArwe> ericp you might want to mute

ericp you might want to mute

15:37:22 <Zakim> +Sandro

Zakim IRC Bot: +Sandro

15:38:00 <sandro> (sorry, somehow this was in my calendar for the Friday timeslot instead)

Sandro Hawke: (sorry, somehow this was in my calendar for the Friday timeslot instead)

15:38:32 <JohnArwe> TimBL: at the moment, you don't have a way to define all metadata.  client should be able to proceed w/o metadata to update things; if it gets error codes, it can branch off to limited server code or ask human to find more capable server.

Tim Berners-Lee: at the moment, you don't have a way to define all metadata. client should be able to proceed w/o metadata to update things; if it gets error codes, it can branch off to limited server code or ask human to find more capable server.

15:38:39 <JohnArwe> ... silent failure is terrifying.

... silent failure is terrifying.

15:40:30 <JohnArwe> ... With more MUSTs on server, we can write more stuff on client side like [???].  way I'm using it, when you change field in form, the server is updated w/in fraction of second.  you can't afford extra round trip.  if you have to do an OPTIONS/HEAD to find out how to use this thing.  Not going to be able to more than GET.

... With more MUSTs on server, we can write more stuff on client side like [???]. way I'm using it, when you change field in form, the server is updated w/in fraction of second. you can't afford extra round trip. if you have to do an OPTIONS/HEAD to find out how to use this thing. Not going to be able to more than GET.

15:40:42 <JohnArwe> ... was not clear what's in OPTIONS that's not in headers.

... was not clear what's in OPTIONS that's not in headers.

15:41:01 <bblfish> Timbl: a major criteria is that one should reduce the number of connections in the spec. This could be tested by looking at how test suites. Better to create HTTP codes than to have redirects.

Tim Berners-Lee: a major criteria is that one should reduce the number of connections in the spec. This could be tested by looking at how test suites. Better to create HTTP codes than to have redirects. [ Scribe Assist by Henry Story ]

15:41:49 <JohnArwe> Arnaud: OPTIONS added late, allows obtaining same data w/o overhead of calculating some HEAD fields.  People at conferences were happy to see us doing OPTIONS as lighter version of HEAD.

Arnaud Le Hors: OPTIONS added late, allows obtaining same data w/o overhead of calculating some HEAD fields. People at conferences were happy to see us doing OPTIONS as lighter version of HEAD.

15:41:59 <ericP> it's true, content-length is a very expensive header field in a response to a HEAD

Eric Prud'hommeaux: it's true, content-length is a very expensive header field in a response to a HEAD

15:42:11 <davidwood> WebSockets instead? :)

David Wood: WebSockets instead? :)

15:42:15 <JohnArwe> TimBL: oh seemed like OPTIONS was heavier than HEAD

Tim Berners-Lee: oh seemed like OPTIONS was heavier than HEAD

15:42:22 <davidwood> (not really proposing it)

David Wood: (not really proposing it)

15:42:28 <bblfish> Timbl: Doing OPTIONS + GET is more expensive than just GET.

Tim Berners-Lee: Doing OPTIONS + GET is more expensive than just GET. [ Scribe Assist by Henry Story ]

15:42:29 <JohnArwe> ...are all headers on GET?

...are all headers on GET?

15:42:48 <JohnArwe> Arnaud: yes.  anything you see on OPTIONS/HEAD you'll also see on GET response.

Arnaud Le Hors: yes. anything you see on OPTIONS/HEAD you'll also see on GET response.

15:43:28 <bblfish> q+

Henry Story: q+

15:43:56 <JohnArwe> TimBL: protocol is little system, who does what.  quite a bit of text about what server could do, need to (a) must it (b) show more of what client does perhaps as kind of flowchart

Tim Berners-Lee: protocol is little system, who does what. quite a bit of text about what server could do, need to (a) must it (b) show more of what client does perhaps as kind of flowchart

15:44:23 <JohnArwe> ... if flow for vanilla client gets complex, you can see the problem

... if flow for vanilla client gets complex, you can see the problem

15:44:34 <SteveS> q+

Steve Speicher: q+

15:44:44 <Arnaud> ack ericp

Arnaud Le Hors: ack ericp

15:44:44 <Zakim> ericP, you wanted to say that i was hoping that support libraries for app-specific clients would show us the value of the app-specific profile

Zakim IRC Bot: ericP, you wanted to say that i was hoping that support libraries for app-specific clients would show us the value of the app-specific profile

15:46:14 <JohnArwe> ericp: good to try understand spec value; would app-specific show us what should be SHOULDs/MUSTs?  Tim, would you be happy if spec was written for app-specific only, but provided basis for generic (specific is restriction of generic)

Eric Prud'hommeaux: good to try understand spec value; would app-specific show us what should be SHOULDs/MUSTs? Tim, would you be happy if spec was written for app-specific only, but provided basis for generic (specific is restriction of generic)

15:46:34 <JohnArwe> TimBL: no, upside down.  start with clean smooth platform, then express exceptions.

Tim Berners-Lee: no, upside down. start with clean smooth platform, then express exceptions.

15:46:48 <Ashok> +1 to TimBL on Vanilla spec

Ashok Malhotra: +1 to TimBL on Vanilla spec

15:47:33 <JohnArwe> ... MUST support PUT, MUST NOT change client's input.  very basic, testable, invariants.  important for writers, caches.  smaller spec; leave hooks for domain-specific systems.

... MUST support PUT, MUST NOT change client's input. very basic, testable, invariants. important for writers, caches. smaller spec; leave hooks for domain-specific systems.

15:48:20 <JohnArwe> ... we've defined 208.5 code with Link header to more specific sub-protocol.  client can do SOME things from generic, but not all.

... we've defined 208.5 code with Link header to more specific sub-protocol. client can do SOME things from generic, but not all.

15:48:47 <JohnArwe> ericp: I see it other way; generic= MUST preserve, app-specific says MAY throw away triples

Eric Prud'hommeaux: I see it other way; generic= MUST preserve, app-specific says MAY throw away triples

15:49:51 <ericP> i don't see how you base a less restrictive spec on a more restrictive spec.

Eric Prud'hommeaux: i don't see how you base a less restrictive spec on a more restrictive spec.

15:49:51 <JohnArwe> Arnaud: have been trying to figure out how this differs from authorization, security, etc.  even if spec has MUST, it's understood that a single request might fail (due to lack of auth, say) w/o "violating" must.  we accept these things as being beyond the spec.

Arnaud Le Hors: have been trying to figure out how this differs from authorization, security, etc. even if spec has MUST, it's understood that a single request might fail (due to lack of auth, say) w/o "violating" must. we accept these things as being beyond the spec.

15:49:58 <Arnaud> q?

Arnaud Le Hors: q?

15:50:35 <JohnArwe> TimBL: referring to HTTP is a separate issue; all the examples you came up with are covered there.

Tim Berners-Lee: referring to HTTP is a separate issue; all the examples you came up with are covered there.

15:51:12 <bblfish> Timbl: ie access control has an HTTP code that deals with it.

Tim Berners-Lee: ie access control has an HTTP code that deals with it. [ Scribe Assist by Henry Story ]

15:51:16 <Arnaud> ack bblfish

Arnaud Le Hors: ack bblfish

15:51:21 <JohnArwe> Arnaud: point is: there are diff levels of constraint exist.  maybe we should have some way for clients to find out if they're talking to RO/whatever servers.  see value in defining vanilla level that might be much more demanding.

Arnaud Le Hors: point is: there are diff levels of constraint exist. maybe we should have some way for clients to find out if they're talking to RO/whatever servers. see value in defining vanilla level that might be much more demanding.

15:54:10 <JohnArwe> bblfish: +1, need to build explicit things, work out how to move from generic client to specific one.  we added OPTIONS b/c spec had options instead of pushing it off to access control.  email w/in last hour: POST has side effect of creating resource; what is client responsible for on POST?  POST + shopping cart = buy action ==> user responsibility.

Henry Story: +1, need to build explicit things, work out how to move from generic client to specific one. we added OPTIONS b/c spec had options instead of pushing it off to access control. email w/in last hour: POST has side effect of creating resource; what is client responsible for on POST? POST + shopping cart = buy action ==> user responsibility.

15:54:41 <Arnaud> ack steves

Arnaud Le Hors: ack steves

15:54:42 <ericP> bblfish, in what way are the property names and graph patterns insufficient for defining the semantics of the shopping cart POST you described?

Eric Prud'hommeaux: bblfish, in what way are the property names and graph patterns insufficient for defining the semantics of the shopping cart POST you described?

15:55:43 <ericP> i believe that the grounding of terms in the message is exactly why martin nally wanted to use RDF in the first place

Eric Prud'hommeaux: i believe that the grounding of terms in the message is exactly why martin nally wanted to use RDF in the first place

15:55:49 <JohnArwe> SteveS: bug example, going back to flowchart comment... client GETs on bug (no OPTIONS reqd), look at headers.  other alternative is send something on GET response therefore you have some extra verbs available.

Steve Speicher: bug example, going back to flowchart comment... client GETs on bug (no OPTIONS reqd), look at headers. other alternative is send something on GET response therefore you have some extra verbs available.

15:56:57 <JohnArwe> TimBL: one idea, allow 2 types on type header you already have.  one for LDPR, allow others.  client could look up others to find out if subclass of LDPR/etc

Tim Berners-Lee: one idea, allow 2 types on type header you already have. one for LDPR, allow others. client could look up others to find out if subclass of LDPR/etc

15:57:13 <JohnArwe> Arnaud summarizes

Arnaud summarizes

15:57:25 <JohnArwe> - Greater level of interop in RW mode

- Greater level of interop in RW mode

15:57:47 <JohnArwe> - OK if hook exists for client to find other restrictions

- OK if hook exists for client to find other restrictions

<JohnArwe> topic: PATCH

3. PATCH

15:58:01 <JohnArwe> TimBL: patch language is so much more important

Tim Berners-Lee: patch language is so much more important

15:58:40 <JohnArwe> Arnaud: what spec can we point to for what "we" are using today?  Sando: Turtle patch web page, was one input.  Tim, what do you do about blank nodes?  That's where it got hard.

Arnaud Le Hors: what spec can we point to for what "we" are using today? Sandro: Turtle patch web page, was one input. Tim, what do you do about blank nodes? That's where it got hard.

15:58:49 <JohnArwe> s/Sando/Sandro/
15:58:57 <timbl> For blank node id, there is a WHERE

Tim Berners-Lee: For blank node id, there is a WHERE

15:59:09 <JohnArwe> Sandro: Tim, you and I can help move the task force forward

Sandro Hawke: Tim, you and I can help move the task force forward

15:59:31 <JohnArwe> TimBL: just want to modify RDF graph; need Where clause for Bnodes

Tim Berners-Lee: just want to modify RDF graph; need Where clause for Bnodes

15:59:44 <JohnArwe> ... took 2 lines of JS

... took 2 lines of JS

15:59:57 <JohnArwe> Sandro: still NP complete, can take forever to run

Sandro Hawke: still NP complete, can take forever to run

16:00:00 <bblfish> while ( true ) print "hello"

Henry Story: while ( true ) print "hello"

16:00:02 <JohnArwe> ...scares people

...scares people

16:00:12 <bblfish> oh dear! a p[iece of code that is np complete.

Henry Story: oh dear! a p[iece of code that is np complete.

16:00:40 <JohnArwe> ... spirited discussion of why, in practice, theory != reality

... spirited discussion of why, in practice, theory != reality

16:00:40 <bblfish> JS is NP Complete. Everybody uses it :-)

Henry Story: JS is NP Complete. Everybody uses it :-)

16:01:03 <bblfish> ( sorry )

Henry Story: ( sorry )

16:01:20 <JohnArwe> Arnaud: wrapping up

Arnaud Le Hors: wrapping up

16:01:32 <JohnArwe>  Several: continue... Tim available into part of lunch

Several: continue... Tim available into part of lunch

16:02:33 <JohnArwe> Arnaud: so you're saying a limited solution is better than none, for patch format?

Arnaud Le Hors: so you're saying a limited solution is better than none, for patch format?

16:03:09 <JohnArwe> TimBL: write examples/BNF, point out subset... yeah everyone really wants it, let's push on it.

Tim Berners-Lee: write examples/BNF, point out subset... yeah everyone really wants it, let's push on it.

16:03:13 <timbl> a test suite

Tim Berners-Lee: a test suite

16:04:20 <Zakim> -davidwood

Zakim IRC Bot: -davidwood

16:04:39 <JohnArwe> Sandro: works fine in good cases, for right datasets.  for wrong datasets, e.g. with list containing few hundred elements, takes much longer.  people used to that in sparql.  but in patch, is making a simple operation hard worth it?  if we had round-trippable bnode labels it would be linear.

Sandro Hawke: works fine in good cases, for right datasets. for wrong datasets, e.g. with list containing few hundred elements, takes much longer. people used to that in sparql. but in patch, is making a simple operation hard worth it? if we had round-trippable bnode labels it would be linear.

16:04:45 <Arnaud> q?

Arnaud Le Hors: q?

16:05:35 <ericP> SPARQL WG spent a while talking about "told BNodes" and gave up

Eric Prud'hommeaux: SPARQL WG spent a while talking about "told BNodes" and gave up

16:06:04 <ericP> i'd not expect to constrain systems to remember the BNode labels they invented when serializing

Eric Prud'hommeaux: i'd not expect to constrain systems to remember the BNode labels they invented when serializing

16:06:32 <JohnArwe> Discussion of patch format issues/ideas

Discussion of patch format issues/ideas

16:06:52 <Zakim> -BartvanLeeuwen

Zakim IRC Bot: -BartvanLeeuwen

16:10:26 <JohnArwe> Arnaud: if you can come up with something in reasonable time window, everyone would love to have it.

Arnaud Le Hors: if you can come up with something in reasonable time window, everyone would love to have it.

<JohnArwe> topic: Interop (continues)

4. Interop (continues)

16:10:53 <JohnArwe> TimBL: would things go better/faster if spec introduced notion of a vanilla server?

Tim Berners-Lee: would things go better/faster if spec introduced notion of a vanilla server?

16:11:33 <bblfish> seems good to me to make the distinction between two servers

Henry Story: seems good to me to make the distinction between two servers

16:11:36 <JohnArwe> ... spec constraints can then be associated with one class vs others

... spec constraints can then be associated with one class vs others

16:11:43 <JohnArwe> ... still needs a lot more MUSTs

... still needs a lot more MUSTs

16:12:28 <JohnArwe> Arnaud: WG needs to figure out which SHOULDs can become MUSTs, and how to accomodate both types of server.

Arnaud Le Hors: WG needs to figure out which SHOULDs can become MUSTs, and how to accomodate both types of server.

16:12:29 <SteveS> it would be a good exercise to see if we can tag our reqs/scenario with which type of server they are

Steve Speicher: it would be a good exercise to see if we can tag our reqs/scenario with which type of server they are

16:12:58 <JohnArwe> TimBL: if it's a bit, you can put in headers.  if more complicated, you need a richer language.

Tim Berners-Lee: if it's a bit, you can put in headers. if more complicated, you need a richer language.

16:13:34 <JohnArwe> Arnaud: I am just saying that figuring out which constraints apply to vanilla (as MUST) vs domain is a WG activity

Arnaud Le Hors: I am just saying that figuring out which constraints apply to vanilla (as MUST) vs domain is a WG activity

<JohnArwe> topic: Paging

5. Paging

16:14:20 <JohnArwe> Arnaud: another comment I wanted to ask about is the Page resource; right now all done in RDF level, you wanted to move it header.  in general where do you draw the line where to put it?  WG had LOTS of discussion on placement.

Arnaud Le Hors: another comment I wanted to ask about is the Page resource; right now all done in RDF level, you wanted to move it header. in general where do you draw the line where to put it? WG had LOTS of discussion on placement.

16:16:15 <JohnArwe> TimBL: for me, a data store is a store of quads: subj, predicate, object, resource ID.  you can just send a patch to a resource for update.  great model for building apps.  do hit problem that app works fine, then you run into scaling issue.  most bits of generic sw need something like paging.  to me it seemed clear part of http layer, and valuable there.

Tim Berners-Lee: for me, a data store is a store of quads: subj, predicate, object, resource ID. you can just send a patch to a resource for update. great model for building apps. do hit problem that app works fine, then you run into scaling issue. most bits of generic sw need something like paging. to me it seemed clear part of http layer, and valuable there.

16:17:13 <JohnArwe> ... Want client to be able to say LIMIT(10K) like on cell phone/constrained env.

... Want client to be able to say LIMIT(10K) like on cell phone/constrained env.

16:17:27 <JohnArwe> ericp: problem is hard to apply that to generic triple store.

Eric Prud'hommeaux: problem is hard to apply that to generic triple store.

16:17:30 <bblfish> Timbl: headers that would allow one to limit the triples you get.

Tim Berners-Lee: headers that would allow one to limit the triples you get. [ Scribe Assist by Henry Story ]

16:18:15 <JohnArwe> EricP: ...discussion

Eric Prud'hommeaux: ...discussion

16:18:48 <bblfish> ... allowing the triple store to break it all up into chunks.

Henry Story: ... allowing the triple store to break it all up into chunks.

16:19:04 <JohnArwe> TimBL: triple store could arbitrarily break up data into chunks... talking about reasons for doing things in http instead

Tim Berners-Lee: triple store could arbitrarily break up data into chunks... talking about reasons for doing things in http instead

16:19:05 <bblfish> ... by moving it to the HTTP layer

Henry Story: ... by moving it to the HTTP layer

16:19:56 <JohnArwe> TimBL: you'd know if someone wanted to do a SPARQL query over the logical resource (that gets paged at the http resource level)

Tim Berners-Lee: you'd know if someone wanted to do a SPARQL query over the logical resource (that gets paged at the http resource level)

16:20:18 <JohnArwe> ericp: do this as named graphs in trig

Eric Prud'hommeaux: do this as named graphs in trig

16:21:18 <JohnArwe> TimBL: maybe I'm wrong, but when I looked at paging stuff the only crucial bits were the links between pages.  rel=next/prev/part

Tim Berners-Lee: maybe I'm wrong, but when I looked at paging stuff the only crucial bits were the links between pages. rel=next/prev/part

16:21:33 <timbl> rel = page:{partOf,next,prev}

Tim Berners-Lee: rel = page:{partOf,next,prev}

16:21:46 <JohnArwe> ericp: makes sense; possible that's in existing client libs

Eric Prud'hommeaux: makes sense; possible that's in existing client libs

16:21:55 <bblfish> q?

Henry Story: q?

16:21:57 <JohnArwe> ... UK example given

... UK example given

16:21:58 <bblfish> q+

Henry Story: q+

16:22:29 <JohnArwe> Arnaud: Tim in camp that prefers HTTP headers, but ok if left as is?

Arnaud Le Hors: Tim in camp that prefers HTTP headers, but ok if left as is?

16:23:04 <timbl> (s,p,o,r)

Tim Berners-Lee: (s,p,o,r)

16:23:08 <JohnArwe> TimBL: I wouldn't use it; can't have magic triples appear in payload if the axiom is that server does not modify the triples sent by clients except in response to client requests

Tim Berners-Lee: I wouldn't use it; can't have magic triples appear in payload if the axiom is that server does not modify the triples sent by clients except in response to client requests

16:23:27 <timbl> In a vanilla server,

Tim Berners-Lee: In a vanilla server,

16:23:30 <JohnArwe> Arnaud: sounds like vanilla httpd server

Arnaud Le Hors: sounds like vanilla httpd server

16:24:17 <JohnArwe> TimBL: no, vanilla LDP server.  invariant: if client writes (s,p,o,r) into server, then resource r will contain triple (s,p,o).  extension of webdav model, if you like.

Tim Berners-Lee: no, vanilla LDP server. invariant: if client writes (s,p,o,r) into server, then resource r will contain triple (s,p,o). extension of webdav model, if you like.

16:25:21 <JohnArwe> ... similar to what happens with servers that accept "any" media type and then, once you put them in there, it will serve them faithfully

... similar to what happens with servers that accept "any" media type and then, once you put them in there, it will serve them faithfully

16:25:37 <JohnArwe> ...easy to test, build clean stuff on top of that

...easy to test, build clean stuff on top of that

16:26:42 <JohnArwe> Arnaud: clarify - you want client to be in full control.  even in that case, ex client just adds triples daily, after 2 years GEts, you're expecting one 200 response?

Arnaud Le Hors: clarify - you want client to be in full control. even in that case, ex client just adds triples daily, after 2 years GEts, you're expecting one 200 response?

16:26:43 <pchampin> q+

Pierre-Antoine Champin: q+

16:27:25 <ericP> GET /bigLog

Eric Prud'hommeaux: GET /bigLog

16:27:25 <JohnArwe> TimBL: no, 208.5 response "I gave you part of it", Location tells you URI, and link headers give you the next/part of headers

Tim Berners-Lee: no, 208.5 response "I gave you part of it", Location tells you URI, and link headers give you the next/part of the resource

16:27:43 <JohnArwe> s/of headers/of the resource/
16:27:45 <ericP> HTTP/1.1 208½ try this instead

Eric Prud'hommeaux: HTTP/1.1 208½ try this instead

16:28:14 <ericP>  firstPage: /bigLog/p1

Eric Prud'hommeaux: firstPage: /bigLog/p1

16:28:22 <Arnaud> ack bblfish

Arnaud Le Hors: ack bblfish

16:28:24 <ericP>  nextPage: /bigLog/p2

Eric Prud'hommeaux: nextPage: /bigLog/p2

16:28:27 <ericP> .

Eric Prud'hommeaux: .

16:28:39 <JohnArwe> TimBL: pagination is great to build in, want at low level so libs will build it in, so clients get it for free.  alternative would be apps grow to certain pt then have to rework things later.

Tim Berners-Lee: pagination is great to build in, want at low level so libs will build it in, so clients get it for free. alternative would be apps grow to certain pt then have to rework things later.

16:29:03 <JohnArwe> bblfish: you said before different clients get different size responses?

Henry Story: you said before different clients get different size responses?

16:29:39 <JohnArwe> TimBL: search engine wants to stream in large data; tabulator style web app should always be putting limits on their requests

Tim Berners-Lee: search engine wants to stream in large data; tabulator style web app should always be putting limits on their requests

16:29:50 <JohnArwe> ... sorting makes sense

... sorting makes sense

16:30:15 <JohnArwe> ... no point in sending data app can't cope with, cell phone/slow links

... no point in sending data app can't cope with, cell phone/slow links

16:30:19 <timbl>  Limit: 10000

Tim Berners-Lee: Limit: 10000

16:30:26 <JohnArwe> ... at the moment done by bytes

... at the moment done by bytes

16:30:32 <JohnArwe> ... hint from client

... hint from client

16:30:43 <bblfish> thanks

Henry Story: thanks

16:30:47 <JohnArwe> ... suggesting page size client could handle

... suggesting page size client could handle

16:30:54 <pchampin>  zakim, unmute me

Pierre-Antoine Champin: zakim, unmute me

16:30:54 <Zakim> pchampin should no longer be muted

Zakim IRC Bot: pchampin should no longer be muted

16:30:55 <Arnaud> ack pchampin

Arnaud Le Hors: ack pchampin

16:31:28 <ericP> note that client-selected size is slightly at odds with persistent URIs for the pages

Eric Prud'hommeaux: note that client-selected size is slightly at odds with persistent URIs for the pages

16:31:38 <JohnArwe> Pierre: reaction to "no magic triples".  Magic triples not added to resource, they're a separate resource that explains how it relates to original.  Is that as bad?

Pierre-Antoine Champin: reaction to "no magic triples". Magic triples not added to resource, they're a separate resource that explains how it relates to original. Is that as bad?

16:31:45 <pchampin> zakim, mute me

Pierre-Antoine Champin: zakim, mute me

16:31:45 <Zakim> pchampin should now be muted

Zakim IRC Bot: pchampin should now be muted

16:31:55 <ericP> so far, the paging has no need to be dynamic. you can statically store the pages

Eric Prud'hommeaux: so far, the paging has no need to be dynamic. you can statically store the pages

16:32:24 <JohnArwe> TimBL: don't think so, my app already has lots of magic triples.  under the covers there's a whole bunch of data about the http request.

Tim Berners-Lee: don't think so, my app already has lots of magic triples. under the covers there's a whole bunch of data about the http request.

16:32:57 <pchampin> ok, thx

Pierre-Antoine Champin: ok, thx

16:33:12 <JohnArwe> ... from that I can conclude it's type, from MIME type, so I'm already used to 2 layers, and if HTTP is already doing metadata I'm happy to let the next/prev links be there too.

... from that I can conclude it's type, from MIME type, so I'm already used to 2 layers, and if HTTP is already doing metadata I'm happy to let the next/prev links be there too.

16:33:23 <JohnArwe> Arnaud: anything you want to hit before we stop?

Arnaud Le Hors: anything you want to hit before we stop?

16:33:27 <SteveS> Hopefully timbl can get the other comments in by next week

Steve Speicher: Hopefully timbl can get the other comments in by next week

16:33:59 <JohnArwe> TimBL: have not talked about conneg; hopefully no need to discuss that.

Tim Berners-Lee: have not talked about conneg; hopefully no need to discuss that.

16:34:39 <Zakim> -EricP

Zakim IRC Bot: -EricP

16:35:01 <Zakim> -bblfish

Zakim IRC Bot: -bblfish

16:35:08 <Zakim> -dret

Zakim IRC Bot: -dret

16:35:17 <Zakim> -Ashok_Malhotra

Zakim IRC Bot: -Ashok_Malhotra

16:35:18 <Zakim> -TimBL

Zakim IRC Bot: -TimBL

16:35:19 <Zakim> -SteveS

Zakim IRC Bot: -SteveS

16:35:20 <pchampin> bye bye

Pierre-Antoine Champin: bye bye

16:35:21 <Zakim> -Sandro

Zakim IRC Bot: -Sandro

16:35:22 <Zakim> -JohnArwe

Zakim IRC Bot: -JohnArwe

16:35:23 <Zakim> -rgarcia

Zakim IRC Bot: -rgarcia

16:35:26 <Zakim> -Arnaud

Zakim IRC Bot: -Arnaud

16:35:30 <Zakim> -pchampin

Zakim IRC Bot: -pchampin

16:35:39 <Arnaud> timbl, Bon Appetit! :-)

Arnaud Le Hors: timbl, Bon Appetit! :-)

16:40:30 <Zakim> disconnecting the lone participant, nmihindu, in SW_LDP()11:00AM

Zakim IRC Bot: disconnecting the lone participant, nmihindu, in SW_LDP()11:00AM

16:40:31 <Zakim> SW_LDP()11:00AM has ended

Zakim IRC Bot: SW_LDP()11:00AM has ended

16:40:31 <Zakim> Attendees were Arnaud, SteveS, bblfish, nmihindu, JohnArwe, pchampin, BartvanLeeuwen, Ashok_Malhotra, TimBL, rgarcia, EricP, +1.540.898.aaaa, davidwood, dret, Sandro

Zakim IRC Bot: Attendees were Arnaud, SteveS, bblfish, nmihindu, JohnArwe, pchampin, BartvanLeeuwen, Ashok_Malhotra, TimBL, rgarcia, EricP, +1.540.898.aaaa, davidwood, dret, Sandro

18:44:01 <Ashok> zakim, pointer?

(No events recorded for 123 minutes)

Ashok Malhotra: zakim, pointer?

18:44:01 <Zakim> I don't understand your question, Ashok.

Zakim IRC Bot: I don't understand your question, Ashok.

18:45:23 <Ashok> rrsagent, pointer?

Ashok Malhotra: rrsagent, pointer?

18:45:23 <RRSAgent> See http://www.w3.org/2013/09/03-ldp-irc#T18-45-23

RRSAgent IRC Bot: See http://www.w3.org/2013/09/03-ldp-irc#T18-45-23



Formatted by CommonScribe