<arnaud> present: Arnaud, Ashok_Malhotra, SteveS, EricP, svillata, pchampin, JohnArwe, Sandro, rgarcia, cody, nmihindu, TallTed, AndyS, Yves
13:50:36 <RRSAgent> logging to http://www.w3.org/2013/04/08-ldp-irc
RRSAgent IRC Bot: logging to http://www.w3.org/2013/04/08-ldp-irc ←
13:50:38 <trackbot> RRSAgent, make logs public
Trackbot IRC Bot: RRSAgent, make logs public ←
13:50:40 <trackbot> Zakim, this will be LDP
Trackbot IRC Bot: Zakim, this will be LDP ←
13:50:40 <Zakim> ok, trackbot; I see SW_LDP()10:00AM scheduled to start in 10 minutes
Zakim IRC Bot: ok, trackbot; I see SW_LDP()10:00AM scheduled to start in 10 minutes ←
13:50:41 <trackbot> Meeting: Linked Data Platform (LDP) Working Group Teleconference
13:50:41 <trackbot> Date: 08 April 2013
13:59:54 <Ashok> zakim, code?
(No events recorded for 9 minutes)
Ashok Malhotra: zakim, code? ←
13:59:54 <Zakim> the conference code is 53794 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), Ashok
Zakim IRC Bot: the conference code is 53794 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), Ashok ←
14:00:10 <Zakim> SW_LDP()10:00AM has now started
Zakim IRC Bot: SW_LDP()10:00AM has now started ←
14:00:14 <Zakim> +Arnaud
Zakim IRC Bot: +Arnaud ←
14:00:29 <Zakim> +[IBM]
Zakim IRC Bot: +[IBM] ←
14:00:31 <Zakim> +Ashok_Malhotra
Zakim IRC Bot: +Ashok_Malhotra ←
14:00:43 <SteveS> zakim, [IBM] is me
Steve Speicher: zakim, [IBM] is me ←
14:00:43 <Zakim> +SteveS; got it
Zakim IRC Bot: +SteveS; got it ←
14:01:00 <Zakim> +??P12
Zakim IRC Bot: +??P12 ←
14:01:07 <Zakim> +EricP
Zakim IRC Bot: +EricP ←
14:01:23 <svillata> Zakim, ??P12 is me
Serena Villata: Zakim, ??P12 is me ←
14:01:23 <Zakim> +svillata; got it
Zakim IRC Bot: +svillata; got it ←
14:01:50 <Zakim> +??P15
Zakim IRC Bot: +??P15 ←
14:02:18 <Zakim> +??P18
Zakim IRC Bot: +??P18 ←
14:02:24 <Zakim> +??P20
Zakim IRC Bot: +??P20 ←
14:02:25 <Zakim> +JohnArwe
Zakim IRC Bot: +JohnArwe ←
14:02:27 <Zakim> +Sandro
Zakim IRC Bot: +Sandro ←
14:02:43 <Zakim> -??P18
Zakim IRC Bot: -??P18 ←
14:02:44 <JohnArwe> regrets: steve battle, sergio
14:03:02 <Zakim> +??P24
Zakim IRC Bot: +??P24 ←
14:03:09 <nmihindu> zakim, ??P18 is me
Nandana Mihindukulasooriya: zakim, ??P18 is me ←
14:03:09 <Zakim> I already had ??P18 as ??P18, nmihindu
Zakim IRC Bot: I already had ??P18 as ??P18, nmihindu ←
14:03:17 <rgarcia> zakim, ??P24 is me
Raúl García Castro: zakim, ??P24 is me ←
14:03:17 <Zakim> +rgarcia; got it
Zakim IRC Bot: +rgarcia; got it ←
14:03:21 <pchampin> scribe: pchampin
(Scribe set to Pierre-Antoine Champin)
14:03:43 <Zakim> +[IPcaller]
Zakim IRC Bot: +[IPcaller] ←
14:04:04 <nmihindu> zakim, ??P20 is me
Nandana Mihindukulasooriya: zakim, ??P20 is me ←
14:04:04 <Zakim> +nmihindu; got it
Zakim IRC Bot: +nmihindu; got it ←
14:04:10 <cody> zakim, +[IPcaller] is me
Cody Burleson: zakim, +[IPcaller] is me ←
14:04:10 <Zakim> sorry, cody, I do not recognize a party named '+[IPcaller]'
Zakim IRC Bot: sorry, cody, I do not recognize a party named '+[IPcaller]' ←
14:04:23 <cody> zakim IPcaller is me
Cody Burleson: zakim IPcaller is me ←
14:04:38 <Zakim> +[OpenLink]
Zakim IRC Bot: +[OpenLink] ←
<pchampin> topic: Admin
14:04:39 <pchampin> subtopic: Announcement
14:04:48 <TallTed> Zakim, [OpenLink] is temporarily me
Ted Thibodeau: Zakim, [OpenLink] is temporarily me ←
14:04:48 <Zakim> +TallTed; got it
Zakim IRC Bot: +TallTed; got it ←
14:05:05 <pchampin> Arnaud: Erik Wilde has renounced chairing this group
Arnaud Le Hors: Erik Wilde has renounced chairing this group ←
14:05:29 <pchampin> ... I've been offered to find a new co-chair, but declined.
... I've been offered to find a new co-chair, but declined. ←
14:05:41 <pchampin> ... I'll chair alone, if that's ok with everyone.
... I'll chair alone, if that's ok with everyone. ←
14:06:00 <pchampin> subtopic: Last week minutes
14:06:32 <pchampin> PROPOSAL: approve minutes of april 1st
PROPOSED: approve minutes of april 1st ←
14:06:40 <pchampin> RESOLVED: approve minutes of april 1st
RESOLVED: approve minutes of april 1st ←
14:07:09 <pchampin> subtopic: next F2F
14:07:25 <SteveS> Zakim, who is here?
Steve Speicher: Zakim, who is here? ←
14:07:25 <Zakim> On the phone I see SteveS, Arnaud, Ashok_Malhotra, svillata, EricP, pchampin, nmihindu, JohnArwe, Sandro, rgarcia, [IPcaller], TallTed
Zakim IRC Bot: On the phone I see SteveS, Arnaud, Ashok_Malhotra, svillata, EricP, pchampin, nmihindu, JohnArwe, Sandro, rgarcia, [IPcaller], TallTed ←
14:07:28 <Zakim> On IRC I see Kalpa, rgarcia, JohnArwe, cody, pchampin, Ashok, svillata, Zakim, nmihindu, RRSAgent, AndyS, cygri, TallTed, stevebattle2, SteveS, oberger, jmvanel, davidwood, Arnaud,
Zakim IRC Bot: On IRC I see Kalpa, rgarcia, JohnArwe, cody, pchampin, Ashok, svillata, Zakim, nmihindu, RRSAgent, AndyS, cygri, TallTed, stevebattle2, SteveS, oberger, jmvanel, davidwood, Arnaud, ←
14:07:28 <Zakim> ... betehess, ericP, thschee, sandro, Yves, trackbot
Zakim IRC Bot: ... betehess, ericP, thschee, sandro, Yves, trackbot ←
14:07:38 <pchampin> Arnaud: Arun proposed to host next F2F in Madrid
Arnaud Le Hors: Raul proposed to host next F2F in Madrid ←
14:07:44 <Zakim> +[IPcaller.a]
Zakim IRC Bot: +[IPcaller.a] ←
14:07:50 <Zakim> +??P39
Zakim IRC Bot: +??P39 ←
14:07:51 <AndyS> zakim, IPCaller.a is me
Andy Seaborne: zakim, IPCaller.a is me ←
14:07:51 <Zakim> +AndyS; got it
Zakim IRC Bot: +AndyS; got it ←
14:08:01 <rgarcia> s/Arun/Raul/
14:08:04 <TallTed> Zakim, mute me
Ted Thibodeau: Zakim, mute me ←
14:08:04 <Zakim> TallTed should now be muted
Zakim IRC Bot: TallTed should now be muted ←
14:09:00 <SteveS> I'm good with proposed dates June 18-20
Steve Speicher: I'm good with proposed dates June 18-20 ←
14:09:08 <pchampin> ... goal is to issue a LC after that F2F if we haven't done so before.
... goal is to issue a LC after that F2F if we haven't done so before. ←
14:09:31 <Arnaud> Proposed: hold our F2F3 on June 18-20, 2013 in Madrid
PROPOSED: hold our F2F3 on June 18-20, 2013 in Madrid ←
14:09:42 <JohnArwe> +1
14:09:44 <rgarcia> +1
Raúl García Castro: +1 ←
14:09:46 <svillata> +1
Serena Villata: +1 ←
14:09:46 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
14:09:46 <SteveS> +1
Steve Speicher: +1 ←
14:09:51 <cody> +1
Cody Burleson: +1 ←
14:09:53 <Ashok> +1
Ashok Malhotra: +1 ←
14:10:01 <sandro> -0 I can't travel for LDP
Sandro Hawke: -0 I can't travel for LDP ←
14:10:16 <ericP> +1
Eric Prud'hommeaux: +1 ←
14:10:26 <pchampin> -0 (unavailable from 19)
-0 (unavailable from 19) ←
14:10:28 <TallTed> -0 I won't be physically present
Ted Thibodeau: -0 I won't be physically present ←
14:11:07 <Arnaud> Resolved: hold our F2F3 on June 18-20, 2013 in Madrid
RESOLVED: hold our F2F3 on June 18-20, 2013 in Madrid ←
14:11:38 <pchampin> Arnaud: I'll update the wiki page http://www.w3.org/2012/ldp/wiki/F2F3
Arnaud Le Hors: I'll update the wiki page http://www.w3.org/2012/ldp/wiki/F2F3 ←
14:11:56 <pchampin> ... Raul can update it as well with info on venue, accommodation, etc.
... Raul can update it as well with info on venue, accommodation, etc. ←
14:12:07 <pchampin> topic: Tracking of actions and issues
14:12:36 <pchampin> Arnaud: anyone claiming victory on open actions?
Arnaud Le Hors: anyone claiming victory on open actions? ←
14:13:27 <Ashok> q+
Ashok Malhotra: q+ ←
14:13:35 <pchampin> ... We are not very strict on setting due dates to actions,
... We are not very strict on setting due dates to actions, ←
14:13:41 <Arnaud> ack ashok
Arnaud Le Hors: ack ashok ←
14:13:50 <pchampin> ... but please complete your actions, as they help us move forward.
... but please complete your actions, as they help us move forward. ←
14:14:03 <ericP> is targeted, public humiliation in order?
Eric Prud'hommeaux: is targeted, public humiliation in order? ←
14:15:05 <pchampin> Ashok: re. ACTION-48, can we talk about it during next telecon?
Ashok Malhotra: re. ACTION-48, can we talk about it during next telecon? ←
14:15:29 <pchampin> ... the question is: how far can we dictate what the engine should/can do.
... the question is: how far can we dictate what the engine should/can do. ←
14:15:40 <pchampin> Arnaud: ok, I'll put it on the agenda for next week.
Arnaud Le Hors: ok, I'll put it on the agenda for next week. ←
14:16:13 <pchampin> EricP: in the meantime, it would be good that Ashok set a low bar and a high bar, to give a starting point to the discussion.
Eric Prud'hommeaux: in the meantime, it would be good that Ashok set a low bar and a high bar, to give a starting point to the discussion. ←
14:16:26 <Arnaud> q?
Arnaud Le Hors: q? ←
<pchampin> topic: Open Issues
<pchampin> subtopic: ISSUE-58: Property for asserting that complete description of members is included in LDPC representation
14:17:21 <pchampin> issue-58?
14:17:21 <trackbot> ISSUE-58 -- Property for asserting that complete description of members is included in LDPC representation -- open
Trackbot IRC Bot: ISSUE-58 -- Property for asserting that complete description of members is included in LDPC representation -- open ←
14:17:21 <trackbot> http://www.w3.org/2012/ldp/track/issues/58
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/58 ←
14:18:31 <pchampin> Arnaud: my method is to put forward a proposal made by someone, and let people comment on it
Arnaud Le Hors: my method is to put forward a proposal made by someone, and let people comment on it ←
14:18:59 <pchampin> ... not meaning that that proposal is what the group should do, but makes a good starting point.
... not meaning that that proposal is what the group should do, but makes a good starting point. ←
14:19:46 <svillata> q?
Serena Villata: q? ←
14:19:48 <SteveS> q+
Steve Speicher: q+ ←
14:19:55 <Arnaud> ack steves
Arnaud Le Hors: ack steves ←
14:20:05 <TallTed> q+
Ted Thibodeau: q+ ←
14:20:06 <TallTed> Zakim, unmute me
Ted Thibodeau: Zakim, unmute me ←
14:20:07 <Zakim> TallTed should no longer be muted
Zakim IRC Bot: TallTed should no longer be muted ←
14:20:29 <pchampin> ISSUE-58 is to prevent people making a useless GET to a resource when they already got complete information from the container
ISSUE-58 is to prevent people making a useless GET to a resource when they already got complete information from the container ←
14:21:06 <Arnaud> yes
Arnaud Le Hors: yes ←
14:21:17 <AndyS> Hard to make a complete judgement without seeing a complete set of properties that we will have. Unclear about whether critical or just useful/nice. Include for now - review in context in complete draft.
Andy Seaborne: Hard to make a complete judgement without seeing a complete set of properties that we will have. Unclear about whether critical or just useful/nice. Include for now - review in context in complete draft. ←
14:21:31 <pchampin> SteveS: I see some value in it, but not sure many would implement it
Steve Speicher: I see some value in it, but not sure many would implement it ←
14:21:57 <Ashok> q+
Ashok Malhotra: q+ ←
14:22:16 <Arnaud> ack tallted
Arnaud Le Hors: ack tallted ←
14:22:25 <pchampin> Arnaud: the property is applied to the container; but it could be applies to each individual resource in the container.
Arnaud Le Hors: the property is applied to the container; but it could be applies to each individual resource in the container. ←
14:22:47 <pchampin> ... Also, not fan of the name of the property: it is not about being inlined, but about being *completely* inlined.
... Also, not fan of the name of the property: it is not about being inlined, but about being *completely* inlined. ←
14:23:02 <Arnaud> ack ashok
Arnaud Le Hors: ack ashok ←
14:23:07 <JohnArwe> @andy, IIRC in the f2f discussion is was ack'd by some as a performance optimization.
John Arwe: @andy, IIRC in the f2f discussion is was ack'd by some as a performance optimization. ←
14:23:10 <pchampin> TallTed: prefer to state this at the resource level; and not fan on the property name either.
Ted Thibodeau: prefer to state this at the resource level; and not fan on the property name either. ←
14:23:34 <AndyS> This touches on layering - what's core (all systems ... MUST provide) and what's on top of that core (optional).
Andy Seaborne: This touches on layering - what's core (all systems ... MUST provide) and what's on top of that core (optional). ←
14:23:51 <pchampin> Ashok: would pagination help solve this?
Ashok Malhotra: would pagination help solve this? ←
14:24:00 <AndyS> JohnArwe - makes sense - is there deployed experience? Caching also plays to this.
Andy Seaborne: JohnArwe - makes sense - is there deployed experience? Caching also plays to this. ←
14:24:13 <pchampin> Arnaud: this is orthogonal to pagination.
Arnaud Le Hors: this is orthogonal to pagination. ←
14:24:51 <JohnArwe> @Andy this is something this WG invented, not part of submission, no impl experience.
John Arwe: @Andy this is something this WG invented, not part of submission, no impl experience. ←
14:25:23 <pchampin> TallTed: sparing GET resources is not only important for the client; it is even more important for the server.
Ted Thibodeau: sparing GET resources is not only important for the client; it is even more important for the server. ←
14:25:52 <AndyS> @john can we treat this as cache control? Are there other such features in that space? (more a rhetorical question)
Andy Seaborne: @john can we treat this as cache control? Are there other such features in that space? (more a rhetorical question) ←
14:26:09 <pchampin> q+
q+ ←
14:26:18 <Arnaud> ack pchampin
Arnaud Le Hors: ack pchampin ←
14:27:24 <JohnArwe> @andy I'm suspecting not directly amenable to cc, since the request-uri for container != request-uri for members. It would take an LDP-aware cache to build a bridge between those two peaks of Mt Kili.
John Arwe: @andy I'm suspecting not directly amenable to cc, since the request-uri for container != request-uri for members. It would take an LDP-aware cache to build a bridge between those two peaks of Mt Kili. ←
14:27:41 <pchampin> pchampin: do we really need extra vocabulary for that
Pierre-Antoine Champin: do we really need extra vocabulary for that ←
14:27:58 <pchampin> ... one way for the server to state that the container items are completely described
... one way for the server to state that the container items are completely described ←
14:28:51 <AndyS> @john good point but I would have though LDP-aware cache is likely (to the point of absolutely necessary :-) in the client impl.
Andy Seaborne: @john good point but I would have though LDP-aware cache is likely (to the point of absolutely necessary :-) in the client impl. ←
14:29:03 <pchampin> ... is to use #-URIs for its items
... is to use #-URIs for its items ←
14:29:37 <ericP> q?
Eric Prud'hommeaux: q? ←
14:29:41 <pchampin> TallTed: this is not a solution; what if the resource description is completely inlined today, but not tomorrow?
Ted Thibodeau: this is not a solution; what if the resource description is completely inlined today, but not tomorrow? ←
14:29:47 <Arnaud> Proposed: Close ISSUE-58: Property for asserting that the complete description of a member resource is included in LDPC representation, adding a property ldp:fullyInlined, values of true/false. The default (if not specified) is false. If true, it means that a complete description of the member resource is inlined with the container document (or page), and therefore clients SHOULD NOT do GET on the member URIs to retrieve additional triples.
PROPOSED: Close ISSUE-58: Property for asserting that the complete description of a member resource is included in LDPC representation, adding a property ldp:fullyInlined, values of true/false. The default (if not specified) is false. If true, it means that a complete description of the member resource is inlined with the container document (or page), and therefore clients SHOULD NOT do GET on the member URIs to retrieve additional triples. ←
14:30:15 <TallTed> suggest s/ldp:fullyInlined/ldp:descriptionComplete/
Ted Thibodeau: suggest s/ldp:fullyInlined/ldp:descriptionComplete/ ←
14:30:19 <pchampin> q+
q+ ←
14:30:27 <Arnaud> ack pchampin
Arnaud Le Hors: ack pchampin ←
14:30:47 <rgarcia> q+
Raúl García Castro: q+ ←
14:30:58 <Arnaud> ack rgarcia
Arnaud Le Hors: ack rgarcia ←
14:31:26 <pchampin> q+
q+ ←
14:31:47 <JohnArwe> @andy: I would not want to Require any caching on the client side (certainly allowed); that would smell like leaving out thin clients, like simple scripts.
John Arwe: @andy: I would not want to Require any caching on the client side (certainly allowed); that would smell like leaving out thin clients, like simple scripts. ←
14:32:06 <SteveS> q+
Steve Speicher: q+ ←
14:32:07 <pchampin> rgarcia: would prefer to state that GET is not required
Raúl García Castro: would prefer to state that GET is not required ←
14:32:21 <pchampin> ericP: or "GET will not provide annotional triples"
Eric Prud'hommeaux: or "GET will not provide annotional triples" ←
14:32:23 <Arnaud> ack pchampin
Arnaud Le Hors: ack pchampin ←
14:32:47 <pchampin> Arnaud: concerns have been expressed about the server getting too many GETs
Arnaud Le Hors: concerns have been expressed about the server getting too many GETs ←
14:33:03 <ericP> pchampin: i'm concearned about the value of the property
Pierre-Antoine Champin: i'm concearned about the value of the property [ Scribe Assist by Eric Prud'hommeaux ] ←
14:33:17 <ericP> ... i don't consider it a property of the resource
Eric Prud'hommeaux: ... i don't consider it a property of the resource ←
14:33:27 <AndyS> @john except thin/slow clients really need caching:-) but yes - not require.
Andy Seaborne: @john except thin/slow clients really need caching:-) but yes - not require. ←
14:33:28 <ericP> ... it's a relationship between the resource and the container
Eric Prud'hommeaux: ... it's a relationship between the resource and the container ←
14:33:32 <AndyS> q+
Andy Seaborne: q+ ←
14:33:57 <pchampin> pchampin: should probably be a relation btw the resource and the container, rather than a boolean property
Pierre-Antoine Champin: should probably be a relation btw the resource and the container, rather than a boolean property ←
14:34:09 <pchampin> ... as this is not something intrinsic to the resource
... as this is not something intrinsic to the resource ←
14:34:51 <pchampin> ... ldp:fullyInlinedBy <container>
... ldp:fullyInlinedBy <container> ←
14:35:13 <TallTed> Zakim, unmute me
Ted Thibodeau: Zakim, unmute me ←
14:35:13 <Zakim> TallTed was not muted, TallTed
Zakim IRC Bot: TallTed was not muted, TallTed ←
14:35:21 <JohnArwe> q+
14:35:43 <AndyS> q-
Andy Seaborne: q- ←
14:35:48 <Arnaud> ack steves
Arnaud Le Hors: ack steves ←
14:35:57 <pchampin> Arnaud: let's not spend too much time on this
Arnaud Le Hors: let's not spend too much time on this ←
14:35:57 <ericP> pchampin: rather than asserting <resource> ldp:descriptionComplete "true", assert <resource> ldp:descriptionComplete <someContainer>,
Pierre-Antoine Champin: rather than asserting <resource> ldp:descriptionComplete "true", assert <resource> ldp:descriptionComplete <someContainer>, [ Scribe Assist by Eric Prud'hommeaux ] ←
14:36:02 <TallTed> resourceURI ldp:descriptionComplete {containerURI, resourceURI}
Ted Thibodeau: resourceURI ldp:descriptionComplete {containerURI, resourceURI} ←
14:36:14 <pchampin> ... let's have somebody make a proposal
... let's have somebody make a proposal ←
14:36:21 <TallTed> "complete description for this resource GOT from container/resource"
Ted Thibodeau: "complete description for this resource GOT from container/resource" ←
14:36:47 <pchampin> SteveS: we should better define what "fully inlined by" means;
Steve Speicher: we should better define what "fully inlined by" means; ←
14:36:53 <TallTed> you could also do a GET on the individual resource -- to *just* get *its* description -- and not the descriptions of the 100 other resources in that container
Ted Thibodeau: you could also do a GET on the individual resource -- to *just* get *its* description -- and not the descriptions of the 100 other resources in that container ←
14:37:22 <pchampin> ... triples can be added very quickly
... triples can be added very quickly ←
14:37:25 <AndyS> Another viewpoint is that this is a statement about the reply (c.f. paging, HTTP header stuff)
Andy Seaborne: Another viewpoint is that this is a statement about the reply (c.f. paging, HTTP header stuff) ←
14:37:33 <Arnaud> ack john
Arnaud Le Hors: ack john ←
14:38:08 <pchampin> JohnArwe: agree with what Andy just wrote on the IRC
John Arwe: agree with what Andy just wrote on the IRC ←
14:38:15 <pchampin> ... should be a property of a specific response
... should be a property of a specific response ←
14:39:01 <JohnArwe> seems debatable to include response properties in any resource's triples
John Arwe: seems debatable to include response properties in any resource's triples ←
14:39:01 <pchampin> Arnaud: any volunteer for making a new proposal?
Arnaud Le Hors: any volunteer for making a new proposal? ←
14:39:41 <pchampin> @JohnArwe: a Link header pointing to all resources that are completely inlined?
@JohnArwe: a Link header pointing to all resources that are completely inlined? ←
14:39:42 <JohnArwe> ... HTTP would use headers for that (and it has named classes of headers for this sort of thing)
John Arwe: ... HTTP would use headers for that (and it has named classes of headers for this sort of thing) ←
14:40:01 <AndyS> @john Should the client be allowed/able to influence the server response? (hmm ... probably over engineering)
Andy Seaborne: @john Should the client be allowed/able to influence the server response? (hmm ... probably over engineering) ←
<pchampin> subtopic: ISSUE-14: Include clarifications about ordering in BPC representations
14:40:19 <SteveS> issue-14?
14:40:20 <trackbot> ISSUE-14 -- Include clarifications about ordering in BPC representations -- open
Trackbot IRC Bot: ISSUE-14 -- Include clarifications about ordering in BPC representations -- open ←
14:40:20 <trackbot> http://www.w3.org/2012/ldp/track/issues/14
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/14 ←
14:40:21 <nmihindu> issue-14?
Nandana Mihindukulasooriya: ISSUE-14? ←
14:40:21 <trackbot> ISSUE-14 -- Include clarifications about ordering in BPC representations -- open
Trackbot IRC Bot: ISSUE-14 -- Include clarifications about ordering in BPC representations -- open ←
14:40:21 <trackbot> http://www.w3.org/2012/ldp/track/issues/14
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/14 ←
14:41:09 <JohnArwe> Actually I did not assert using Link headers. I simply asked if we had agreement that whether or not a member was inlined is really a property of the message response/interaction flow, or not. Ted asserted it must allowed to vary with each request/response pair, and I heard no objections to that.
John Arwe: Actually I did not assert using Link headers. I simply asked if we had agreement that whether or not a member was inlined is really a property of the message response/interaction flow, or not. Ted asserted it must allowed to vary with each request/response pair, and I heard no objections to that. ←
14:41:17 <SteveS> q+
Steve Speicher: q+ ←
14:41:22 <Arnaud> ack steves
Arnaud Le Hors: ack steves ←
14:41:34 <Ashok> q+
Ashok Malhotra: q+ ←
14:41:35 <pchampin> Raul: (described his proposal about ISSUE-14, but scribed didn't get it all)
Raúl García Castro: (described his proposal about ISSUE-14, but scribed didn't get it all) ←
14:41:58 <JohnArwe> @andy: perfect world, sure. clear enough to demand "littering" the spec with it, much less sure (and leaning against that)
John Arwe: @andy: perfect world, sure. clear enough to demand "littering" the spec with it, much less sure (and leaning against that) ←
14:42:05 <nmihindu> yes, that is what I meant.
Nandana Mihindukulasooriya: yes, that is what I meant. ←
14:42:29 <Arnaud> q?
Arnaud Le Hors: q? ←
14:42:34 <Arnaud> ack ashok
Arnaud Le Hors: ack ashok ←
14:43:14 <pchampin> Ashok: someone argued that you have to allow the server to decide on the order, if it is not specified
Ashok Malhotra: Erik argued that you have to allow the server to decide on the order, if it is not specified ←
14:43:49 <pchampin> SteveS: we are only saying how to specify the order
Steve Speicher: we are only saying how to specify the order ←
14:44:20 <pchampin> TallTed: how do we define a container? same Subject-Predicate or only same Subject?
Ted Thibodeau: how do we define a container? same Subject-Predicate or only same Subject? ←
14:44:43 <Ashok> s/someone/Erik/
14:44:47 <cody> a collection of same-subject, same-predicate triples,
Cody Burleson: a collection of same-subject, same-predicate triples, ←
14:45:01 <pchampin> Arnaud: see definition of LDPC
Arnaud Le Hors: see definition of LDPC ←
14:45:13 <pchampin> TallTed: ok, so that's same Subject-Predicate
Ted Thibodeau: ok, so that's same Subject-Predicate ←
14:45:25 <pchampin> SteveS: and if it has no sortPredicate, the order is unspecified
Steve Speicher: and if it has no sortPredicate, the order is unspecified ←
14:45:50 <pchampin> ... If it has a sortPredicate, it should be ordered by the value of that predicate in the items.
... If it has a sortPredicate, it should be ordered by the value of that predicate in the items. ←
14:46:05 <pchampin> ... But there are some problems with locales.
... But there are some problems with locales. ←
14:46:35 <pchampin> Ashok: you can have the ordering specified by the unicode specification.
Ashok Malhotra: you can have the ordering specified by the unicode specification. ←
14:47:23 <pchampin> Arnaud: I agree that we will have to tackle the local/i18n problems at some point,
Arnaud Le Hors: I agree that we will have to tackle the local/i18n problems at some point, ←
14:47:34 <pchampin> ... but would like to see if we get a general agreement on this issue
... but would like to see if we get a general agreement on this issue ←
14:49:06 <pchampin> SteveS: as I understand it, Raul's proposal of an index property is not to add it to the LDP vocabulary,
Steve Speicher: as I understand it, Raul's proposal of an index property is not to add it to the LDP vocabulary, ←
14:49:10 <nmihindu> yes. completely.
Nandana Mihindukulasooriya: yes. completely. ←
14:49:34 <pchampin> ... but an example on how the problem could be solved in a service-specific way.
... but an example on how the problem could be solved in a service-specific way. ←
14:49:36 <nmihindu> I just wanted to show how it can be done in that specific case,
Nandana Mihindukulasooriya: I just wanted to show how it can be done in that specific case, ←
14:52:08 <pchampin> TallTed: this proposal is problematic for me: you can not order by a property that is not present
Ted Thibodeau: this proposal is problematic for me: you can not order by a property that is not present ←
14:52:34 <pchampin> ... so if it is same subject+predicate, you can not sort by anything else than the object.
... so if it is same subject+predicate, you can not sort by anything else than the object. ←
14:53:08 <pchampin> ... Even if that ordering information is something that the server knows in the background.
... Even if that ordering information is something that the server knows in the background. ←
14:53:21 <sandro> q?
Sandro Hawke: q? ←
14:53:42 <sandro> TallTed, the Object is a like a ROW, not a String.
Sandro Hawke: TallTed, the Object is a like a ROW, not a String. ←
14:53:44 <pchampin> ... As inlining is optional, we can not rely on that. It's too complex.
... As inlining is optional, we can not rely on that. It's too complex. ←
14:54:26 <Ashok> Sandro, I think he is saying the value of the object is a string
Ashok Malhotra: Sandro, I think he is saying the value of the object is a string ←
14:54:54 <AndyS> Can include a numeric index (much safer to sort on)
Andy Seaborne: Can include a numeric index (much safer to sort on) ←
14:55:21 <sandro> objects don't have values as strings.
Sandro Hawke: objects don't have values as strings. ←
14:55:39 <sandro> (unless they are literals)
Sandro Hawke: (unless they are literals) ←
14:55:42 <Arnaud> q?
Arnaud Le Hors: q? ←
14:56:21 <pchampin> SteveS: it seems to me that Ted's issue is different from what ISSUE-14 is about.
Steve Speicher: it seems to me that Ted's issue is different from what ISSUE-14 is about. ←
14:56:26 <pchampin> Arnaud: clearly not in a position to close this now. Let's move one
Arnaud Le Hors: clearly not in a position to close this now. Let's move one ←
<pchampin> subtopic: ISSUE-59: Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior
14:56:37 <pchampin> issue-59?
14:56:37 <trackbot> ISSUE-59 -- Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior -- open
Trackbot IRC Bot: ISSUE-59 -- Reconsider usage of Aggregate/Composite construct to get predictable container delete behavior -- open ←
14:56:37 <trackbot> http://www.w3.org/2012/ldp/track/issues/59
Trackbot IRC Bot: http://www.w3.org/2012/ldp/track/issues/59 ←
14:57:13 <pchampin> Arnaud: we have this distinction btw 2 kinds of containers,
Arnaud Le Hors: we have this distinction btw 2 kinds of containers, ←
14:57:17 <pchampin> ... that nobody really likes.
... that nobody really likes. ←
14:57:37 <pchampin> ... SteveS proposed that they emerged because of different need re. DELETE.
... SteveS proposed that they emerged because of different need re. DELETE. ←
14:58:06 <Ashok> q+
Ashok Malhotra: q+ ←
14:58:17 <pchampin> ... Only one type of container, and DELETE only deletes the container, not the members. Leaves recursive delete to a future spec.
... Only one type of container, and DELETE only deletes the container, not the members. Leaves recursive delete to a future spec. ←
14:58:19 <AndyS> +1 to focusing on a single, simple, minimal container proposal.
Andy Seaborne: +1 to focusing on a single, simple, minimal container proposal. ←
14:58:38 <Arnaud> ack ashok
Arnaud Le Hors: ack ashok ←
14:58:38 <pchampin> ... But DELETE should not create dangling resources.
... But DELETE should not create dangling resources. ←
14:58:45 <Ashok> make container management dependent on how resources were added to the container. if they were POSTed to it, they are contained and get DELETEd. if they were linked, they are associated and only the link gets DELETEd.
Ashok Malhotra: make container management dependent on how resources were added to the container. if they were POSTed to it, they are contained and get DELETEd. if they were linked, they are associated and only the link gets DELETEd. ←
14:59:09 <SteveS> q+
Steve Speicher: q+ ←
14:59:36 <Ashok> q+
Ashok Malhotra: q+ ←
14:59:36 <Arnaud> ack steves
Arnaud Le Hors: ack steves ←
14:59:43 <TallTed> q+
Ted Thibodeau: q+ ←
14:59:44 <pchampin> Arnaud: am I right in thinking that the group wants to unify those two kinds of containers?
Arnaud Le Hors: am I right in thinking that the group wants to unify those two kinds of containers? ←
14:59:55 <sandro> +1 single type of container
Sandro Hawke: +1 single type of container ←
15:00:04 <rgarcia> +1
Raúl García Castro: +1 ←
15:00:11 <cody> +1
Cody Burleson: +1 ←
15:00:13 <nmihindu> +1
Nandana Mihindukulasooriya: +1 ←
15:00:54 <pchampin> SteveS: the problem of dangling link exist as long as we delete a resource; it is not limited to the container-member relation.
Steve Speicher: the problem of dangling link exist as long as we delete a resource; it is not limited to the container-member relation. ←
15:01:22 <Arnaud> ack ashok
Arnaud Le Hors: ack ashok ←
15:01:23 <pchampin> ... It should be up to the server to do what they need to do.
... It should be up to the server to do what they need to do. ←
15:01:26 <JohnArwe> +1 single type of container
John Arwe: +1 single type of container ←
15:01:54 <pchampin> Ashok: if we have only one kind of container, do we only have one kind of DELETE?
Ashok Malhotra: if we have only one kind of container, do we only have one kind of DELETE? ←
15:02:14 <pchampin> Arnaud: the idea would be to have one kind of DELETE, and add other kinds later on.
Arnaud Le Hors: the idea would be to have one kind of DELETE, and add other kinds later on. ←
15:02:15 <sandro> How does one add another "type of DELETE" to HTTP?
Sandro Hawke: How does one add another "type of DELETE" to HTTP? ←
15:02:16 <Arnaud> ack tallted
Arnaud Le Hors: ack tallted ←
15:02:47 <JohnArwe> ashok: http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0018.html details under (b) the proposed delete behavior
Ashok Malhotra: http://lists.w3.org/Archives/Public/public-ldp-wg/2013Apr/0018.html details under (b) the proposed delete behavior [ Scribe Assist by John Arwe ] ←
15:03:04 <pchampin> TallTed: aggregation should be the only kind of container
Ted Thibodeau: aggregation should be the only kind of container ←
15:04:26 <Zakim> -Ashok_Malhotra
Zakim IRC Bot: -Ashok_Malhotra ←
15:04:28 <Zakim> -SteveS
Zakim IRC Bot: -SteveS ←
15:04:28 <Zakim> -Sandro
Zakim IRC Bot: -Sandro ←
15:04:29 <Zakim> -TallTed
Zakim IRC Bot: -TallTed ←
15:04:29 <Zakim> -svillata
Zakim IRC Bot: -svillata ←
15:04:31 <Zakim> -Yves
Zakim IRC Bot: -Yves ←
15:04:32 <Zakim> -JohnArwe
Zakim IRC Bot: -JohnArwe ←
15:04:33 <Zakim> -[IPcaller]
Zakim IRC Bot: -[IPcaller] ←
15:04:35 <Zakim> -AndyS
Zakim IRC Bot: -AndyS ←
15:04:36 <Zakim> -EricP
Zakim IRC Bot: -EricP ←
15:04:38 <Zakim> -rgarcia
Zakim IRC Bot: -rgarcia ←
15:04:44 <Arnaud> MEETING ADJOURNED
Arnaud Le Hors: MEETING ADJOURNED ←
15:04:46 <Zakim> -nmihindu
Zakim IRC Bot: -nmihindu ←
15:04:50 <Zakim> -Arnaud
Zakim IRC Bot: -Arnaud ←
15:04:57 <Zakim> -pchampin
Zakim IRC Bot: -pchampin ←
15:04:59 <Zakim> SW_LDP()10:00AM has ended
Zakim IRC Bot: SW_LDP()10:00AM has ended ←
15:04:59 <Zakim> Attendees were Arnaud, Ashok_Malhotra, SteveS, EricP, svillata, pchampin, JohnArwe, Sandro, rgarcia, [IPcaller], nmihindu, TallTed, AndyS, Yves
Zakim IRC Bot: Attendees were Arnaud, Ashok_Malhotra, SteveS, EricP, svillata, pchampin, JohnArwe, Sandro, rgarcia, [IPcaller], nmihindu, TallTed, AndyS, Yves ←
Formatted by CommonScribe