07:58:18 RRSAgent has joined #ldp 07:58:18 logging to http://www.w3.org/2012/11/02-ldp-irc 07:58:20 RRSAgent, make logs public 07:58:20 Zakim has joined #ldp 07:58:22 Zakim, this will be LDP 07:58:22 ok, trackbot; I see SW_LDP()2:30AM scheduled to start 88 minutes ago 07:58:23 Meeting: Linked Data Platform (LDP) Working Group Teleconference 07:58:23 Date: 02 November 2012 08:01:42 bblfish has joined #ldp 08:02:15 jonathandray has joined #ldp 08:03:58 zakim, who's on the phone? 08:03:58 SW_LDP()2:30AM has not yet started, Arnaud 08:03:59 On IRC I see jonathandray, Zakim, RRSAgent, antonis, Arnaud, SteveS, BartvanLeeuwen, LeeF, trackbot, tpacbot, webr3, Yves, sandro, ericP 08:04:50 jmvanel has joined #ldp 08:05:39 Zakim, call Saint_Claire_3b 08:05:39 I am sorry, sandro; I do not know a number for Saint_Claire_3b 08:05:43 Zakim, call SaintClaire_3b 08:05:43 I am sorry, sandro; I do not know a number for SaintClaire_3b 08:05:47 Zakim, call SaintClaire3b 08:05:47 I am sorry, sandro; I do not know a number for SaintClaire3b 08:05:53 Zakim, call SaintClaire3B 08:05:53 I am sorry, sandro; I do not know a number for SaintClaire3B 08:05:57 Zakim, call Saint_Claire3B 08:05:57 I am sorry, sandro; I do not know a number for Saint_Claire3B 08:06:15 ahaller2 has joined #ldp 08:06:31 zakim, call St_Clair_3B 08:06:31 ok, sandro; the call is being made 08:06:32 SW_LDP()2:30AM has now started 08:06:33 +St_Clair_3B 08:06:52 develD has joined #ldp 08:07:06 -St_Clair_3B 08:07:07 SW_LDP()2:30AM has ended 08:07:07 Attendees were St_Clair_3B 08:07:31 zakim, call St_Clair_3B 08:07:31 ok, sandro; the call is being made 08:07:32 SW_LDP()2:30AM has now started 08:07:32 +St_Clair_3B 08:07:50 svillata has joined #ldp 08:08:45 oberger has joined #ldp 08:10:03 bblfish has joined #ldp 08:10:33 krp has joined #ldp 08:10:57 rgarcia has joined #ldp 08:11:46 Arnaud: added the primer to the agenda for this afternoon 08:12:46 Arnaud: yesterday first f2f, ramping up, but feedback to try and speed up discussions 08:13:07 cygri has joined #ldp 08:13:24 cygri has joined #ldp 08:13:26 ... status quo is the spec as is 08:13:39 nmihindu has joined #ldp 08:13:48 ... burden is on those who have issue with spec to explain what that is 08:14:17 betehess has joined #ldp 08:14:29 ... discussion centred around: 1. what the problems is (ensuring everyone understands it) 2. how to solve it (proposals) 08:15:45 chsiao has joined #ldp 08:15:48 ... make sure we are talking about a specific problem and specific problem rather than debating in the round 08:15:49 btw, http://bikeshed.org/ for those who don't know 08:16:34 ... all exercise some self discipline... don't repeat what others have already say... remove yourself from queue if this happens... then we'll straw poll 08:16:45 q? 08:17:13 oberger: we can only discuss issues where the person who raised it is present? 08:17:26 SteveBattle has joined #ldp 08:17:57 SteveBattle has left #ldp 08:18:02 arnaud: if no one present can defend the position we should just skip it. but e.g. yesterday others managed to represent the view 08:18:09 betehess_ has joined #ldp 08:18:09 SteveBattle has joined #ldp 08:18:12 TOPIC: Access control 08:18:20 http://www.w3.org/2012/ldp/charter 08:18:42 " The Working Group will not produce a Recommendation specifying solutions for access control and authentication for Linked Data. However the Working Group may identify, based on a set of real world use cases, requirements for authentication and authorization technologies for use with Linked Data. " -- the charter 08:19:32 arnaud: when discussing charter two positions: shouldn't do access control as it's a bigger problem; or that how could we not consider the topic 08:19:33 he said it depends... 08:19:42 s/he said it depends...// 08:20:07 ... compromise in the charter: a note. Need to figure out what will be in it, who will be editors 08:20:14 q+ 08:20:18 ... we need to define what we want to do 08:20:22 q+ 08:20:26 ack bblfish 08:20:54 bblfish: identify those interested in distributed access control. I wish to implement this... who else? 08:20:57 FabGandon has joined #ldp 08:21:12 ack bete 08:21:28 Present+FabGandon 08:21:56 q+ 08:21:59 q+ to talk about W3C member-access as a user story 08:22:23 ack steveb 08:22:23 betehess: first access control, then distributed access control. Need to split the issues. Identity, authorisation. Don't want to do anything on auth? 08:22:36 betehess, I think this is 100% about authorization 08:22:40 Ashok_Malhotra has joined #ldp 08:22:44 stevebattle: is there anything in the spec incompatible with ACLs etc.? 08:22:44 q+ 08:22:49 here is an interesting thing: http://www.w3.org/wiki/WebAccessControl 08:22:58 present+ Nandana_Mihindukulasooriya 08:23:10 ack sandro 08:23:10 sandro, you wanted to talk about W3C member-access as a user story 08:23:12 that is what betehess means by WebACL 08:23:19 present+ BartvanLeeuwen 08:23:23 betehess: so far nothing in spec. For WebACL just need to provide ontologies. 08:23:41 present+ AntonisLoizou 08:23:54 present+ Raul_Garcia-Castro 08:24:10 +1 there is a requirement for a distributed authentication 08:24:11 ivan has joined #ldp 08:24:14 sandro: W3C member access control... get to say employees of members to access parts of W3C site... this could be use case for LDP, delegating the access to member orgs 08:24:14 sandro, would you add it to the UCR ? 08:24:16 present+ Serena Villata 08:24:18 ack ashok 08:24:18 present+ Jonathan_Dray 08:24:22 sandro, that use-case is definitely what people call "decentralized" here 08:24:29 present+Olivier_Berger 08:24:37 present+ Steve_Speicher 08:24:39 q+ 08:24:40 present+ Olivier_Berger 08:24:45 present+ Richard Cyganiak 08:25:09 q+ 08:25:11 present+ Sandro Hawke 08:25:17 sandro, good use case should it be added to issue tracker or in minutes enough? 08:25:18 ack bblfish 08:25:22 present+ Alexandre_Bertails 08:25:39 ashok: typically access control is based on underlying storage engine. I can help edit. 08:25:54 q? 08:26:27 q+ to ask about possible requirement -- do resources have different representations for different-access users? 08:26:27 q+ 08:26:30 bblfish: at the RESTful layer need to expose the metadata... the ACLs for a file... the identity needs to be global for an LDP system that is global and interoperable, automatically distributing 08:26:36 ack bete 08:26:42 http://presbrey.mit.edu/ 08:27:12 presbrey built http://data.fm/ 08:27:22 betehess: let's be concrete (see link)... first implementation of linked data server... let's start by reviewing this 08:27:45 q+ 08:27:48 +Yves 08:28:17 ack sandro 08:28:17 sandro, you wanted to ask about possible requirement -- do resources have different representations for different-access users? 08:28:33 arnaud: to clarify, we're not going to develop a spec that solves this problem. but want to know what people think. create a wiki page for this to develop the ucr for this. 08:29:30 ack oberger 08:29:31 sandro: do you want to get different triples dependent on who you are identified as? Is there consensus to this approach? Can we clarify when this is reasonable to do? 08:29:44 q+ 08:29:48 oberger: are people interested in oauth? is there anything to say about it? 08:29:58 q+ to comment on other technologies 08:30:05 ack cygri 08:30:07 ... it can delegate tokens to applications to do things on you behalf 08:30:48 oberger: interesting use case : delegating "tokens" to apps to act on your behalf, in oauth 08:31:06 cygri: as someone who would like a ready-made solution that I'd like to take of the shelf... most useful in the note for me would be use case and requirements 08:31:25 q+ 08:31:49 sandro, I think the point you raised is interesting to the group indeed 08:31:54 ... vs. we can't recommend particular tech anyway, so a laundry list of different technologies doesn't seem to be what we're chartered to do 08:31:55 Cygri, is right. 0ne does not need to list all the technologies up. There are parts that remain open. 08:32:11 sandro, worth an issue ? 08:32:25 ack bete 08:32:25 betehess, you wanted to comment on other technologies 08:32:34 arnaud: per the charter, it ought to be ucr. however, if there are those in the group who are interested, don't want to stop that... as long as it doesn't get in the way of the ucr 08:33:43 q? 08:34:02 betehess: if you tell people the note will just be about listing stuff it will be a waste of time... so maybe better not to make a note? what happens if someone comes with a specific proposal, do we turn away? 08:34:15 arnaud: not here to revisit charter 08:34:37 ... the question is not whether we should do it (the note) 08:34:47 q+ 08:35:25 does "Deliverables - Not Recommendation Track" even mean that we need to deliver a NOTE? whyh not just a wiki page? 08:35:32 ack bblfish 08:35:38 betehess, it's too soon to discuss that IMHO 08:35:55 let's see UC and needs of the group more explicited 08:35:57 ... but implementers need to know how to solve this... see this as a starting point to define the problem... leading to solutions and maybe, eventually, a later process for a recommendation 08:36:04 betehess, oberger, the charter clearly says "Working Group Note on Use Cases and Requirements for access control and authentication mechanisms needed for this work." 08:36:20 cygri, ack 08:36:32 betehess, oberger, whether that's a good thing or not, i don't know :-) 08:36:47 cygri, we'll see while doing 08:37:00 cygri, yeah, just saw that (I wasn't the one who added that in the charter :-) 08:37:01 ack bart 08:37:06 bblfish: in order to test interop we'll need to have something there. but don't need to fully dive into the "identity pit hole of hell" to do this. but we need to have something there to get acceptance from gov etc. 08:37:50 q+ 08:38:18 bart: discussing things that potentially could go wrong with spec. why don't we have implementers trying this to find the problems? does this make it easier to spot the issues rather than discussing all possible issues 08:38:18 ack steves 08:38:42 q+ 08:39:05 steves: not sure what we need to standardise to grant access to individuals, we can do that today in several different ways, do we need to standardise? 08:39:05 timbl_ has joined #ldp 08:39:07 SteveS++ 08:39:17 ack bete 08:39:20 RRSAgent, pointer? 08:39:20 See http://www.w3.org/2012/11/02-ldp-irc#T08-39-20 08:39:21 ... seems like we should get the wiki page up to start getting input 08:40:26 betehess: for many people the success of ldp will be including some standardisation for problems like access control so that it comes with ldp 08:40:54 steves: not saying isn't useful to standardise 08:41:13 q? 08:41:15 q+ to suggest that the art of launching th system is about both having a clean consistent vision and also connecting it to th existing things people are now using. 08:41:21 arnaud: whole point of note is to gather this information: what to you need from access control? 08:41:28 ack timbl 08:41:28 timbl_, you wanted to suggest that the art of launching th system is about both having a clean consistent vision and also connecting it to th existing things people are now using. 08:42:42 Arnaud: note is a way to gather information together about what people would like to do 08:42:46 timbl: to get system off the ground needs clear consistent system, but also bringing in those who are tied into existing systems so they will accept future solution. in ideal world finding a clear conversion from existing sys to rdf would be nice. 08:43:40 Think access control is important to success of LDP in long term, just not sure a minimal requirement….impls will impose access restrictions regardless of what we say 08:43:51 ACTION: Ashok_Malhotra to set up wiki page on Access Control 08:43:51 Sorry, couldn't find Ashok_Malhotra. You can review and register nicknames at . 08:43:56 arnaud: ashok to create and structure wiki page to gather use cases and requirements 08:44:04 ACTION: Ashok to set up wiki page on Access Control 08:44:04 Created ACTION-21 - Set up wiki page on Access Control [on Ashok Malhotra - due 2012-11-09]. 08:44:23 +1 08:44:25 q? 08:44:26 ... everyone add your ucr, please check whether there's already something there... modify/add rather than duplicate 08:44:27 +1 08:44:30 +1 08:44:43 Ashok_Malhotra, i already started by dropping an example into http://www.w3.org/2012/ldp/wiki/AccessControl 08:44:46 ... a reasonable approach? 08:45:05 i can continue with a couple others 08:45:19 ... I think that's all we need to do on this today 08:45:55 http://www.w3.org/wiki/WebAccessControl 08:46:17 ericP: already have a starting page in place http://www.w3.org/wiki/WebAccessControl 08:46:38 ericP, could you explicit the syntax of the example ? 08:47:10 SebastianS___ has joined #ldp 08:47:17 ashok: what does this syntax mean? 08:47:32 arnaud: eric, could you give more explanation of this example? 08:49:00 arnaud: call for which issues to discuss and defend 08:49:14 q+ 08:49:18 TOPIC: Issue 25 08:49:31 Issue-25? 08:49:31 ISSUE-25 -- Weak aggregation and strong composition in containers -- open 08:49:31 http://www.w3.org/2012/ldp/track/issues/25 08:49:31 ISSUE-25? 08:49:31 ISSUE-25 -- Weak aggregation and strong composition in containers -- open 08:49:32 http://www.w3.org/2012/ldp/track/issues/25 08:49:43 q- 08:51:12 stevebattle: ldp spec introduces issue of containers. when you think about these you'd normally consider the strength of these. aggregation is weak with a focus on membership, composition is stronger and considers the lifecycle e.g. deleting resource when container is deleted 08:52:12 oberger: addition of something to container would be a good subject to consider this 08:52:25 arnaud: Steve, do you have a proposal as how to modify spec? 08:53:01 q+ 08:53:05 q+ 08:53:07 stevebattle: proposal is to use hierarchical URIs to represent containment 08:53:24 q+ 08:54:26 arnaud: aggregation vs. composition, but the spec isn't clear? do you want it to do one or the other? 08:54:49 stevebattle: to do both but be clear when it is doing which 08:55:46 q+ 08:55:57 ack ashok 08:55:58 q+ 08:56:13 ack steves 08:56:27 ashok: when you add a container to a container is it hierarchical? 08:56:31 stevebattle: yes 08:57:44 steves: not sure how the uri structure is related to containment, not sure the spec should specify uri structure. 08:57:48 ack oberger 08:58:00 SteveBattle, please phrase a proposal on IRC 08:58:00 but the solution seems simple to me: why not just have a class of containers that seperates the two cases ? 08:58:37 -1 for adding new verbs, only a last resort 08:58:45 oberger: not entirely clear what a container is in terms of semantics. we need to define what actions we can perform on containers, then map to GET/PUT/POST/DELETE 08:58:50 so POST might be CREATE + ADD-TO-CONTAINER ? 08:59:23 a single container might support both aggregation and composition so I'm not sure we can do it by container type. 08:59:34 q+ to resolve issue-25 adding a Container property called "deletesMembers" which applies regardless of the URI structure 08:59:34 q+ 09:00:11 ack krp 09:00:14 krp: I'm a little confused about the proposal. You want the client to understand whether it's containment? 09:01:29 q- 09:01:57 PROPOSAL: DELETE on a container deletes the container and any resources with URIs below in a path hierarchy, and nothing else. 09:02:05 q? 09:02:17 Arnaud: I'm hearing people want to know what the server is going to do when a container is deleted, as far as deleting the contained resources. 09:02:21 q+ 09:02:27 ack bblfish 09:02:28 Thius syetm must have rigidly defined and simple semantics. Think unix file syetm. 09:02:35 q+ 09:02:39 q+ 09:02:52 q+ 09:02:52 bblfish: proposal to have two type of containers specified 09:02:52 q- 09:03:19 bblfish: I propose to rdf:types of containers. One type deletes its contained resources when it's deleted; the other type does not. 09:03:27 +1 I rather like that. 09:03:35 I like cygri's wording - very concise. 09:03:37 q+ 09:03:39 s/to r/two r/ 09:03:46 ... so when client does a GET it knows whether it's an aggregation or container and what the behaviour is when DELETE 09:04:00 SteveBattle, note, not intended to be spec text, just a design to be turned into spec text by the editor 09:04:36 q+ to say why don't we define two membership properties, one for weak and another for strong aggregation 09:05:05 oberger: do the different types map to the two examples in the spec 09:05:07 Like what cygri, though instead requiring uri hierarchy structure why not say something like "and any resources managed by the same server as the container" 09:05:20 rgarcia, i've typed a proposal like that at 9:59:34 09:05:25 q- 09:05:27 ack eric 09:05:27 ericP, you wanted to resolve issue-25 adding a Container property called "deletesMembers" which applies regardless of the URI structure 09:06:18 agree that I don't think that speaking of URL hierachies is useful 09:06:50 q+ 09:06:56 if URL hierarchies are useful, it is only for implementation on the server (where to me it doesn't seem useful, but hey) 09:06:56 s/that I/I/ 09:07:07 ack steveb 09:07:11 it is not a sufficient mechanism to inform the client 09:07:33 q+ 09:08:07 q+ 09:08:09 ack timbl 09:08:12 stevebattle: don't believe the typing proposal works... can't add same resources to multiple containers but can to aggregations 09:08:35 what if we just give up on DELETE delting any members? any use cases which motivate this complexity? 09:09:45 q- 09:10:11 timbl: don't agree that we can make it a general case, sets and lists are different. containment seems like a clear implementation to a filesystem structure and how a service is likely to be implemented 09:10:40 ... so group should focus on containers. other forms of aggregation are described by a number of different ontologies. 09:11:04 PROPOSAL: DELETE on a container deletes the container and any resources with URIs below in a path hierarchy, and nothing else. 09:11:42 Claification: Does the URI path match the containership at all times? 09:12:04 ack nmihindu 09:12:09 q+ 09:12:10 clarification: can there be any members *not* under the path hierarchy? 09:12:31 Ah, cygri, your definition says nothing about the URIs created in POST. 09:12:54 q- 09:12:54 ack rgarcia 09:12:55 SteveBattle, do you want to rephrase it? 09:12:56 rgarcia, you wanted to say why don't we define two membership properties, one for weak and another for strong aggregation 09:12:58 AndyS has joined #ldp 09:13:37 ack cygri 09:14:09 rgarcia: define two membership properties 09:14:10 PROPOSAL: The group drop discussion of the aggregation model as that does not require mutual understanding between client and server, only between client and client. 09:14:39 "DELETE on a container deletes the container and any resources with URIs below in a path hierarchy, and nothing else. POST on a container creates a new resource URI hierarchically below the container." 09:14:47 we forgot timbls proposal: the container of the spec is/(should be?) the agregation type of container with the propoerty that if you delete it you delete all sub-resources, managed by that server. Weak agregation could be done using other ontologies by just publishing information in an rdf resource 09:14:53 cygri: spec allows domain specific subclassing and this will quickly get complicated with two properties 09:15:21 ldp:compositionPredicate rdfs:subClassOf ldp:memberhiPredicate . ldp:aggregationPredicate rdfs:subClassOf ldp:memberhiPredicate . 09:15:28 .. do need to support both cases (strong and weak aggregation). container as designed seems to be about strong 09:15:28 ? 09:15:33 q+ to say that if we don't have both membership properties then we are forcing that domain-specific membership properties are always weak aggregation ones 09:16:03 Ughh- that's going to get ugly PRETTY quickly (ld composition predicates) 09:16:04 +1 for how to do weak agregation sounds good. 09:16:22 ... but we need to be clear how to do weak aggregation 09:16:32 can somebody gives a use-case for weak-aggregation? 09:16:38 q+ to suggest that the group separate out into separate sections of the document the client-server protocol (includes containers, ACL) and the client-client protocol (data types, preferred vocabulary, aggregation membership). 09:17:02 s/rdfs:subClassOf/rdfs:subPropertyOf/ 09:17:11 lastlog propos 09:17:15 q? 09:17:21 oberger: we need to decide which way container is, and whether we need the other 09:17:34 ack steves 09:17:36 q+ 09:18:35 oberger++ 09:18:36 steves: say that instead of a hierarchy of uris say a resource hierarchy managed by that server 09:19:51 ack timbl 09:19:51 timbl_, you wanted to suggest that the group separate out into separate sections of the document the client-server protocol (includes containers, ACL) and the client-client 09:19:54 ... protocol (data types, preferred vocabulary, aggregation membership). 09:21:16 timbl: separate client-client protocol from client-server. allow clients to build new kinds of structure and the server doesn't need to be away. server needs to be aware of things like managing the stored resources and backing to (file)storage 09:21:29 ... go through spec and consider "does the server need to be aware of this" 09:22:05 ack rgarcia 09:22:05 rgarcia, you wanted to say that if we don't have both membership properties then we are forcing that domain-specific membership properties are always weak aggregation ones 09:22:38 PROPOSAL: We need containers for both composition and aggregation. Container-created resources is composition. It's good practice but not required that URI hierarchy match composition. 09:23:23 ack SteveBattle 09:23:42 q+ 09:24:01 stevebattle: Tim is correct, the LDP is primarily about containment. but we do need aggregation. 09:24:26 +1 to cygri 10:22 proposal 09:24:32 q+ to point out hierarchical URIs connect with WebDav and also give locality of reference with relative URIs. 09:24:35 q+ to know why rdfs:Container isn't reused 09:24:35 ... other precedents for hierarchical URIs 09:25:00 ack cygri 09:25:01 I'd still prefer the use of hierarchical URIs. 09:25:23 oberger, could also look at skos:Collection as the type to indicate aggregation 09:25:34 ack timbl 09:25:34 timbl_, you wanted to point out hierarchical URIs connect with WebDav and also give locality of reference with relative URIs. 09:25:37 I have a hard time imagining it's okay to delete /foo and still have /foo/bar exist. 09:25:53 TOTALLY agree 09:26:21 sandro++ 09:26:54 +1 to sandro 09:27:19 agree with tim, we're conflating different problems and solutions here 09:27:26 q? 09:27:30 +1 timbl: paging large agregates is something you need with any kind of large RDF Graph 09:28:08 cygri: consider a container with a common relationship to lots of resources, which the container has not control over, but facilities such as paging are still useful 09:28:10 paging is currently tied to the aggregation - I think that's right. 09:28:13 a POST on a container /foo MAY create multiple resources under /foo, DELETE on a container /foo MUST delete all its underlying resources 09:28:26 timbl: that sounds like an RDF graph. can we not have paging on all RDF graphs? 09:28:43 +1 to follow up on looking at separating paging more clearly 09:28:50 Yves: that's an analysis or a proposal? 09:28:51 ack oberger 09:28:51 oberger, you wanted to know why rdfs:Container isn't reused 09:28:55 cygri: we call it "container" even though it's really a controller for a subject-predicate pair 09:29:11 betehess, an analysis of what people seems to want 09:29:14 oberger: proposed to use rdfs:member, but I also see rdfs: container 09:29:23 PROPOSAL: the paging functionality be applied to any subject for any property, and that be separated in the spec from containment, and it apply to containment as a example with no further design. 09:29:33 and it seems logical too ;) 09:29:39 ... so maybe we shouldn't call it container? 09:29:41 But we can also use skos:Collection - don't overload refs:Container 09:29:52 +1 to timbl's proposal 09:30:15 arnaud: good time to have a break? 09:30:19 +1 to timbl 09:30:29 +1 timbl's 09:30:38 +1 to timbl's 09:30:56 Proposals: 09:30:56 .. hierarchical URIs represent containment (and delelete members) (stevebattle) 09:30:56 .. class type specifies whether members are contained (bblfish) 09:30:56 .. { ldp:deletesMembers true } deletes members regardless of URI (ericP) 09:30:59 .. the membership property specifies containment (rgarcia) 09:31:02 .. all containers delete members (timbl) 09:31:04 .. all created (by POST) resources are contained 09:31:26 PROPOSAL: separate client-client protocol from client-server. allow clients to build new kinds of structure and the server doesn't need to be away. server needs to be aware of things like managing the stored resources and backing to (file)storage. the paging functionality be applied to any subject for any property, and that be separated in the spec from containment, and it apply to containment as a example with no further design. 09:34:48 Clarification neede: Does this separation imply that we drop ldp:membershipPredicate or not? 09:37:16 JohnArwe has joined #ldp 09:48:25 -Yves 09:57:34 rgarcia has joined #ldp 09:58:23 nmihindu has joined #ldp 09:59:11 cygri has joined #ldp 09:59:20 cygri has joined #ldp 09:59:57 JohnArwe, we are returning from break now. 10:00:29 q+ to question the role of dc:creator for ownership wrt DELETE 10:00:37 +JohnArwe 10:00:38 -JohnArwe 10:00:38 +JohnArwe 10:02:56 q- 10:03:26 s/JohnArwe, we are returning from break now.// 10:04:02 ISSUE-25 10:04:05 SteveBattle has joined #ldp 10:04:19 JohnArwe, we have wandered a bit far from the issue 10:04:21 TOPIC: ISSUE-25 10:04:34 "Weak aggregation and strong composition in containers" 10:05:07 Arnaud: We are talking about many issues within this issues 10:05:26 STRAWPOLL: Do we need weak aggregation in the spec? 10:05:30 Arnaud: I take for granted that we need Strong Compisition. Any objection? ... none ... 10:05:37 Arnaud: do we need to have weak aggregation ? 10:05:38 +1 Yes we need it 10:05:41 +1 10:05:41 +1 10:05:41 +1 10:05:42 +1 10:05:44 +1 10:05:44 +1 10:05:50 +1 10:05:52