14:56:01 <RRSAgent> RRSAgent has joined #ldp
14:56:01 <RRSAgent> logging to http://www.w3.org/2013/12/02-ldp-irc
14:56:03 <trackbot> RRSAgent, make logs public
14:56:03 <Zakim> Zakim has joined #ldp
14:56:05 <trackbot> Zakim, this will be LDP
14:56:05 <Zakim> ok, trackbot; I see SW_LDP()10:00AM scheduled to start in 4 minutes
14:56:06 <trackbot> Meeting: Linked Data Platform (LDP) Working Group Teleconference
14:56:06 <trackbot> Date: 02 December 2013
14:58:01 <SteveS> SteveS has joined #ldp
15:00:54 <Zakim> SW_LDP()10:00AM has now started
15:01:01 <Zakim> +Arnaud
15:01:13 <Ashok> Ashok has joined #ldp
15:02:01 <Zakim> +Ashok_Malhotra
15:02:21 <Zakim> +Steve_Speicher
15:02:56 <Zakim> +OpenLink_Software
15:03:08 <Zakim> +ericP
15:03:30 <SteveS> Zakim, Steve_Speicher is me
15:03:30 <Zakim> +SteveS; got it
15:03:47 <TallTed> Zakim, OpenLink_Software is temporarily me
15:03:47 <Zakim> +TallTed; got it
15:03:48 <TallTed> Zakim, mute me
15:03:48 <Zakim> TallTed should now be muted
15:04:51 <pchampin> pchampin has joined #ldp
15:06:35 <Zakim> +??P1
15:06:43 <pchampin> zakim, ??P1 is me
15:06:43 <Zakim> +pchampin; got it
15:07:08 <Zakim> +Alexandre
15:07:18 <nmihindu> nmihindu has joined #ldp
15:08:29 <pchampin> scribe: pchampin
15:08:42 <SteveS> Passing on regrets from JohnArwe
15:09:22 <pchampin> topic: admin
15:09:48 <pchampin> arnaud: last minutes were made from my own IRC log
15:09:53 <SteveS> +1 on minutes
15:09:56 <pchampin> ... as all the bots were having problems
15:09:56 <betehess> +1
15:10:16 <pchampin> PROPOSED: approve last minutes  https://www.w3.org/2013/meeting/ldp/2013-11-25
15:10:22 <pchampin> RESOLVED: approve last minutes  https://www.w3.org/2013/meeting/ldp/2013-11-25
15:10:46 <pchampin> next meeting: next monday dec 9
15:11:08 <pchampin> topic: action tracking
15:11:25 <pchampin> arnaud: two editor actions pending reviews
15:12:05 <pchampin> steve: both are completed
15:12:11 <Zakim> +??P26
15:12:35 <nmihindu> Zakim, ??P26 is me
15:12:35 <Zakim> +nmihindu; got it
15:12:38 <pchampin> arnaud: ACTION-100 about LDPC/LDPR is now reflected in the spec
15:12:48 <nmihindu> Zakim, mute me
15:12:49 <Zakim> nmihindu should now be muted
15:12:55 <pchampin> steve: ACTION-101 is about security and expectations;
15:13:09 <pchampin> ... might need a little more discussions,
15:13:22 <pchampin> ... but I added an informative section about security considerations
15:13:50 <pchampin> arnaud: let's close it; it's everybody's responsibility to look at the change and decide if they are happy with it
15:14:16 <pchampin> ashok: as I motivated one of these changes, I especially will have a look at it
15:14:19 <pchampin> close ACTION-100
15:14:19 <trackbot> Closed ACTION-100.
15:14:31 <pchampin> close ACTION-101
15:14:31 <trackbot> Closed ACTION-101.
15:14:48 <Zakim> +bblfish
15:15:04 <pchampin> arnaud: does anyone want to claim victory on an open action?
15:15:07 <bblfish> bblfish has joined #ldp
15:15:14 <bblfish> hi
15:15:16 <pchampin> ... the list is very long, some of them being very old
15:15:35 <pchampin> ... please everybody look at them and see if you can progress on one of those
15:15:44 <pchampin> topic: remaining issues
15:16:07 <pchampin> arnaud: call closed last week
15:16:20 <Zakim> +Roger
15:16:22 <roger> roger has joined #ldp
15:16:34 <pchampin> ... we have to discuss issues one by one, understand what they are, and see if we should officially open them
15:16:38 <pchampin> ISSUE-85
15:16:38 <trackbot> ISSUE-85 -- membershipXXX rules -- raised
15:16:38 <trackbot> http://www.w3.org/2012/ldp/track/issues/85
15:17:05 <pchampin> arnaud: Henry was complaining about the membership rules becoming more and more complicated
15:17:32 <pchampin> ... I have posted a page explaining it; is it sufficient?
15:18:00 <pchampin> bblfish: perhaps I could turn this issue into a simpler question
15:20:00 <Ashok> q+
15:20:11 <Arnaud> ack Ashok
15:20:13 <pchampin> ... Let's close this issue; I will open a new one, more specific
15:20:31 <SteveS> I'm with Arnaud, I don't understand what the details of the are...so maybe a new one might be good to elaborate
15:20:45 <betehess>  /me liked Henry's idea "One should either remove them, or think in terms of them as specifying the consequences of POSTing to a container."
15:20:53 <pchampin> ashok: can you explain your issue?
15:20:54 <Zakim> +Sandro
15:21:13 <betehess> that would simplify *everything*, just double the number of triples in an LDPC
15:21:20 <betehess> (potentially)
15:22:05 <pchampin> bblfish: we seem to require that the client to do some inference, that it MUST understand the triples that are created
15:22:46 <bblfish> http://lists.w3.org/Archives/Public/public-ldp-wg/2013Nov/0022.html
15:23:11 <pchampin> ... the client should not POST to a container if it does not understand the meaning of the properties that will be created
15:23:31 <pchampin> ericP: isn't it the same for every protocol?
15:24:02 <Zakim> -bblfish
15:24:15 <pchampin> henry: can't speak right now (other people in the office); close the issue, I'll open a more specific one
15:24:20 <pchampin> close ISSUE-85
15:24:20 <trackbot> Closed ISSUE-85.
15:24:37 <pchampin> ISSUE-86
15:24:37 <trackbot> ISSUE-86 -- "membership triples" misnamed -- raised
15:24:37 <trackbot> http://www.w3.org/2012/ldp/track/issues/86
15:25:27 <pchampin> arnaud: I don't think there is a problem
15:25:27 <betehess> re: issue-86, I believe that Henry would be happy with the default member triple being ldp:member
15:25:44 <betehess> that issue was opened before Arnaud's proposal from last week
15:25:50 <pchampin> ... "membership" is defined that way by the spec
15:26:21 <pchampin> ericP: I think that some people want to use domain triples for asserting membership in a container
15:26:47 <betehess> +1 to eric's description
15:26:58 <bblfish_> bblfish_ has joined #ldp
15:26:59 <pchampin> ... Henry is ok with having *both* the LDP membership triple and the domain triple, but some people are not
15:27:30 <Zakim> +bblfish
15:27:39 <bblfish_> ok back
15:27:54 <bblfish_> issue-86?
15:27:54 <trackbot> issue-86 -- "membership triples" misnamed -- raised
15:27:54 <trackbot> http://www.w3.org/2012/ldp/track/issues/86
15:29:04 <SteveS> What ericP describes, is how Arnaud split the kinds of containers http://www.w3.org/2012/ldp/wiki/Containers
15:29:33 <bblfish_> q+
15:29:45 <pchampin> arnaud: I think it is closely related to ISSUE-89
15:30:15 <pchampin> ... and if we change the way things work, according to ISSUE-89, then we will have to rename things
15:30:18 <betehess> agree with Arnaud, with last week's changes, I think we can close this issue
15:30:25 <pchampin> ... but in the current state, I don't see the point of renaming them
15:31:05 <pchampin> bblfish: the problem is that those properties have not much to do with "membership"
15:31:31 <pchampin> ... they are more consequences of the action of POSTing
15:33:40 <pchampin> ericP: I think it is very practical to use domain triples to assert membership
15:34:08 <pchampin> ... and many people seem happy doing that; the problem is philosophical
15:34:41 <bblfish_> It is not philosophical, its a relation between two things and the relation can be anything.
15:35:07 <pchampin> arnaud: it does not meet your expectation about "membership",
15:35:18 <pchampin> ... but if you read the spec without any expectation,
15:35:29 <pchampin> ... and accept the fact that the spec calls it "membership",
15:36:07 <pchampin> ... then the spec makes sense (although you are entitled to not like it)
15:36:33 <pchampin> q+
15:36:53 <TallTed> Zakim, unmute me
15:36:53 <Zakim> TallTed should no longer be muted
15:36:57 <TallTed> q+
15:37:21 <Arnaud> ack bblfish_
15:37:39 <betehess> it's true, it took me a long time to see what problems were behind the membership thing
15:37:47 <Arnaud> ack pchampin
15:38:52 <bblfish_> so why not call it commitment relationships
15:39:04 <bblfish> q?
15:39:06 <Arnaud> ack TallTed
15:39:14 <Ashok> PAC:  Agrees with Eric ...
15:40:14 <pchampin> pchampin: Henry, whatever commitment is entailed by POSTing  to the container, I can consider that container as the set of "members" who have made that commitment
15:40:52 <pchampin> TallTed: we are using overloaded terms (membership) for things that they are not really suited to;
15:41:04 <TallTed> Zakim, mute me
15:41:04 <Zakim> TallTed should now be muted
15:41:07 <pchampin> ... that is why we keep having the same conversion ;
15:41:14 <pchampin> ... unfortunately, I don't have a better proposal
15:41:32 <pchampin> arnaud: we do have a proposal using XYZ instead of membership :)
15:41:32 <bblfish> Could we just allow some proposals of better names?
15:42:04 <bblfish> q+
15:42:38 <Arnaud> ack bblfish
15:43:32 <betehess> scribenick: betehess
15:43:57 <Ashok> scribenick: Ashok
15:43:58 <bblfish> issue-89?
15:43:58 <trackbot> issue-89 -- Tie the interaction model with the LDP data model through the notion of Managed Resources -- raised
15:43:58 <trackbot> http://www.w3.org/2012/ldp/track/issues/89
15:44:06 <Ashok> Topic:  Issue-89
15:44:59 <Ashok> Alexandre:  There are 2 different views of membership
15:45:43 <Ashok> ... cannot tell via membership what resources were created
15:45:47 <bblfish> q+
15:46:32 <roger> roger has joined #ldp
15:46:39 <bblfish> q-
15:46:45 <bblfish> where is the url?
15:47:03 <bblfish> http://www.w3.org/2012/ldp/wiki/Containers
15:47:37 <Zakim> +EricP
15:47:38 <Zakim> -ericP
15:47:39 <bblfish> q+
15:49:49 <pchampin> arnaud: regarding http://www.w3.org/2012/ldp/wiki/Containers
15:50:00 <pchampin> ... what is missing that ldp:xyz provides
15:50:04 <pchampin> ... ?
15:50:48 <pchampin> betehess: I agree with what you are implying
15:51:13 <pchampin> ... the information is there in all three cases (SimpleContainer, DirectContainer, IndirectContainer)
15:51:20 <pchampin> ... but it is different in each case
15:51:33 <pchampin> ... so that is a burden on the client
15:52:15 <pchampin> arnaud: I provided the SPARQL, to show exactly how heavy the burden is
15:52:15 <Arnaud> ack bblfish
15:55:01 <pchampin> bblfish: we don't really need two predicates ldp:member and ldp:memberResource; ldp:member is enough
15:56:05 <pchampin> pchampin: ldp:memberResource is "weaker", in a way, than ldp:member
15:57:11 <pchampin> q+
15:58:50 <Arnaud> ack pchampin
15:59:49 <betehess> for what I understand: 1. for SimpleContainer, ldp:member matches ldp:xyz  2. for DirectContainer, the ldp:containsRelation value matches ldp:xyz  3. for IndirectContainer, ldp:create matches ldp:xyz
16:00:49 <betehess> it's some kind of LDP entailment
16:00:53 <bblfish> q?
16:02:42 <pchampin> arnaud: in the spec, before we created the IndirectContainer pattern, ldp:member was 1-1 mapped with ldp:xyz / ldp:created / ldp:memberResource
16:02:51 <bblfish> q+
16:03:20 <pchampin> ... we added the IndirectContainer, it was necessary to link a non-information resource as the member,
16:03:26 <Arnaud> ack bblfish
16:03:30 <pchampin> ... and to keep track of the created information resource
16:03:33 <Zakim> -nmihindu
16:07:04 <pchampin> betehess: the focus of ISSUE-89 is to make explicit a relation related to HTTP *interaction*
16:07:25 <pchampin> ... true, this relation can be derived from "membership" triples
16:07:42 <pchampin> ... but at least, the impact on *interaction* of those triples should be made explicit in the spec
16:07:46 <pchampin> ... that would be a good first step
16:08:44 <bblfish> s/meaningful/mindful/ ;-)
16:08:57 <bblfish> q+
16:09:11 <Arnaud> ack bblfish
16:09:12 <bblfish> q-
16:09:14 <pchampin> arnaud: making the triple explicit, this would double the number of triples in the DirectContainer
16:09:18 <bblfish> Q+
16:09:31 <pchampin> betehess: only if you chose to materialize them, which you don't *have* to do
16:09:46 <Arnaud> ack bblfish
16:11:40 <Ashok> q+
16:11:53 <betehess> to put my idea in one sentence: we could define ldp:xyz as a entailment rule (derived from Arnaud's SPARQL), then we can tie that to the interaction model
16:11:57 <Arnaud> ack Ashok
16:12:07 <pchampin> arnaud: if it is only about infering that relation, I think that nobody will object
16:12:31 <pchampin> ... I think it was already there, only not explicitly
16:12:42 <betehess> yes, that's the idea :-)
16:13:02 <betehess> ldp:Container with ldp:xyz and the right interaction model :-)
16:13:39 <betehess> big +1 to ashok's idea
16:13:52 <bblfish> I did not hear ashok's idea
16:14:17 <pchampin> arnaud: it seems that we must open issue-89, regarding the time we just spent on it
16:14:21 <pchampin> ... no objection ?
16:14:28 <pchampin> open ISSUE-89
16:15:05 <TallTed> ashok's idea (roughly): if these containers we're describing could be defined as subtypes of a (defined) generic container type, leading to extensible container types, that'd be great
16:15:21 <pchampin> ISSUE-90
16:15:21 <trackbot> ISSUE-90 -- An LDPC/LDPR is a Named Graph -- raised
16:15:21 <trackbot> http://www.w3.org/2012/ldp/track/issues/90
16:16:39 <pchampin> arnaud: we are commited to comply as much as possible with the SPARQL Graph Proptocol
16:17:32 <betehess> s/Graph Proptocol/Graph Store Protocol/
16:17:33 <pchampin> betehess: for SGP, graphs are explicitly paired with URI; in our case this is a little harder
16:17:34 <bblfish> s/Graph Protocol/Graph Store Protocol/
16:17:54 <pchampin> ... we must make it explicit that GET only gets you the "content" of the LDPR
16:18:19 <pchampin> arnaud: betehess can you propose a text to modify the spec?
16:18:23 <pchampin> betehess: yes
16:18:31 <pchampin> arnaud: let's open ISSUE-90, then
16:18:46 <bblfish> Issue-91?
16:18:46 <trackbot> Issue-91 -- The LDP (REST) interactions must be driven by the rel='type' Link header -- raised
16:18:46 <trackbot> http://www.w3.org/2012/ldp/track/issues/91
16:18:55 <TallTed> reopen issue-91
16:18:55 <trackbot> Re-opened issue-91.
16:19:04 <TallTed> damn, typo
16:19:07 <TallTed> reopen issue-90
16:19:08 <trackbot> Re-opened issue-90.
16:19:16 <betehess> ACTION: betehess to propose a text to modify the spec re: ISSUE-90
16:19:17 <trackbot> Created ACTION-115 - Propose a text to modify the spec re: issue-90 [on Alexandre Bertails - due 2013-12-09].
16:20:18 <pchampin> arnaud: there has been heated debates between "REST people" and "SemWeb people"
16:20:41 <betehess> and for the record, the Link "tag" was only defined for the GET
16:20:43 <pchampin> ... the former wanting to distinguish the data-format (turtle) from the interaction model
16:21:17 <pchampin> ... we settled on keeping text/turtle as the content-type, and specify the interaction model in the rel=type Link
16:21:43 <pchampin> ... now Alexandre is arguing that LDPR and LDPC have different interaction models
16:21:54 <pchampin> ... so the rel=type Link should be different
16:22:05 <pchampin> q+
16:22:52 <pchampin> arnaud: we can easily extend today's solution with 2 different kinds of rel=type links
16:23:16 <pchampin> ... but then do we want more (e.g. one for each kind of container -- Simple, Direct, Indirect)?
16:23:51 <Arnaud> ack pchampin
16:24:10 <bhyland> bhyland has joined #ldp
16:25:21 <pchampin> pchampin: personnally, I think we can stick with one rel=type Link
16:25:35 <betehess> ACTION: betehess to propose a text to modify the spec re: ISSUE-91
16:25:35 <trackbot> Created ACTION-116 - Propose a text to modify the spec re: issue-91 [on Alexandre Bertails - due 2013-12-09].
16:25:38 <pchampin> ... clients understanding it know how to inspect the data to recognize an LDPC from a simple LDPR
16:25:59 <pchampin> ... but if we want different rel=type Links, we can have two for containers : simple LDPR + LDPC
16:26:28 <pchampin> arnaud: let's open ISSUE-91, and have betehess make a more precise proposal
16:27:44 <pchampin> arnaud: Ashok made two comments, which I addressed off-line
16:28:02 <pchampin> ashok: I'm satisfied with Arnaud's responses
16:30:54 <bblfish> thanks
16:31:45 <pchampin> arnaud: we need to quickly solve the last issues
16:32:07 <ericP> ACTION: ericP to get response from TimBL re: 1. no resources to push 209 through IEFT, 2. no standard scheme to advertise PUT-CREATE, 3. rest OK'd per telecon
16:32:08 <trackbot> Created ACTION-117 - Get response from timbl re: 1. no resources to push 209 through ieft, 2. no standard scheme to advertise put-create, 3. rest ok'd per telecon [on Eric Prud'hommeaux - due 2013-12-09].
16:32:11 <pchampin> ... 2nd LC must be 3 weeks long, so we have to issue
16:32:58 <pchampin> ... regarding next F2F, we are supposed to give a 8 weeks notice
16:33:26 <pchampin> ... so we should plane the next one in February instead of January
16:34:54 <pchampin> ... if we want to meet after the 2nd LC period, this brings us to the end of February
16:36:46 <bblfish> I did raise these issues in summer but they were closed
16:36:51 <bblfish> very quickly
16:37:03 <bblfish> q+
16:37:20 <bblfish> q-
16:37:38 <betehess> was the 3 container thing reflected in the specification already?
16:37:54 <Zakim> -Ashok_Malhotra
16:37:57 <Zakim> -Sandro
16:37:59 <Zakim> -Alexandre
16:37:59 <Zakim> -TallTed
16:38:01 <Zakim> -Roger
16:38:01 <Zakim> -bblfish
16:38:02 <Zakim> -EricP
16:38:22 <Zakim> -SteveS
16:38:23 <bblfish> In fact I raised these issues  9 months ago.
16:38:33 <bblfish> or more.
16:38:37 <Zakim> -Arnaud
16:38:38 <Zakim> -pchampin
16:38:38 <Zakim> SW_LDP()10:00AM has ended
16:38:38 <Zakim> Attendees were Arnaud, Ashok_Malhotra, ericP, SteveS, TallTed, pchampin, Alexandre, nmihindu, bblfish, Roger, Sandro
16:54:26 <SteveS> SteveS has joined #ldp
16:56:45 <bblfish> bblfish has joined #ldp
17:04:07 <bblfish> bblfish has joined #ldp
17:09:30 <alehors> alehors has joined #ldp
17:34:01 <Arnaud1> Arnaud1 has joined #ldp
18:07:05 <deiu> deiu has joined #ldp
18:55:51 <Zakim> Zakim has left #ldp
20:00:07 <bblfish> bblfish has joined #ldp
20:13:56 <jmvanel> jmvanel has joined #ldp
20:58:24 <SteveS> SteveS has joined #ldp
21:32:03 <SteveS> SteveS has joined #ldp
21:34:08 <bhyland> bhyland has joined #ldp
22:04:42 <bblfish> bblfish has joined #ldp
22:28:38 <bhyland> bhyland has joined #ldp
22:29:38 <bblfish> bblfish has joined #ldp