None.
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...
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
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
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
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)
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
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+
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> .
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