Chatlog 2012-11-02

See original RRSAgent log or preview nicely formatted version.

Please justify/explain all edits to this page, in your "edit summary" text.

<sandro> Meeting: Linked Data Platform (LDP) Working Group F2F1 (Day 2)
<sandro> Agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_2_-_November_2nd
<sandro> Guest: Ivan Herman, W3C
<sandro> Guest: Jonathan Dray
<cygri> guest: Fabien Gandon
<cygri> guest: Tim (timbl) Berners-Lee
<cygri> guest: Norman Richter
<sandro> guest: Nathan (webr3) Rixham
<sandro> Guest: Melvin (melvster) Carvalho
<sandro> Present: Eric, Sandro, Raúl, Nandana, Cygri, Steves, Bart, Kevin, Alexandre, Arnaud, Ashok, Henry, Serena, Olivier, Antonis, Armin, SteveB
<sandro> Around the table: TimBL, Eric, Ivan, Sandro, Raúl, Nandana, Cygri, Steves, Bart, Kevin, Alexandre, Arnaud, Ashok, Henry, ?, Fabien, Serena, Olivier, Jonathan, Antonis, Armin, SteveB
<sandro> Remote: Yves, Arwe, AndyS, macted
07:58:18 <RRSAgent> RRSAgent has joined #ldp
07:58:18 <RRSAgent> logging to http://www.w3.org/2012/11/02-ldp-irc
07:58:20 <trackbot> RRSAgent, make logs public
07:58:20 <Zakim> Zakim has joined #ldp
07:58:22 <trackbot> Zakim, this will be LDP
07:58:22 <Zakim> ok, trackbot; I see SW_LDP()2:30AM scheduled to start 88 minutes ago
07:58:23 <trackbot> Meeting: Linked Data Platform (LDP) Working Group Teleconference
07:58:23 <trackbot> Date: 02 November 2012
08:01:42 <bblfish> bblfish has joined #ldp
08:02:15 <jonathandray> jonathandray has joined #ldp
08:03:58 <Arnaud> zakim, who's on the phone?
08:03:58 <Zakim> SW_LDP()2:30AM has not yet started, Arnaud
08:03:59 <Zakim> On IRC I see jonathandray, Zakim, RRSAgent, antonis, Arnaud, SteveS, BartvanLeeuwen, LeeF, trackbot, tpacbot, webr3, Yves, sandro, ericP
08:04:50 <jmvanel> jmvanel has joined #ldp
08:05:39 <sandro> Zakim, call Saint_Claire_3b
08:05:39 <Zakim> I am sorry, sandro; I do not know a number for Saint_Claire_3b
08:05:43 <sandro> Zakim, call SaintClaire_3b
08:05:43 <Zakim> I am sorry, sandro; I do not know a number for SaintClaire_3b
08:05:47 <sandro> Zakim, call SaintClaire3b
08:05:47 <Zakim> I am sorry, sandro; I do not know a number for SaintClaire3b
08:05:53 <sandro> Zakim, call SaintClaire3B
08:05:53 <Zakim> I am sorry, sandro; I do not know a number for SaintClaire3B
08:05:57 <sandro> Zakim, call Saint_Claire3B
08:05:57 <Zakim> I am sorry, sandro; I do not know a number for Saint_Claire3B
08:06:15 <ahaller2> ahaller2 has joined #ldp
08:06:31 <sandro> zakim, call St_Clair_3B
08:06:31 <Zakim> ok, sandro; the call is being made
08:06:32 <Zakim> SW_LDP()2:30AM has now started
08:06:33 <Zakim> +St_Clair_3B
08:06:52 <develD> develD has joined #ldp
08:07:06 <Zakim> -St_Clair_3B
08:07:07 <Zakim> SW_LDP()2:30AM has ended
08:07:07 <Zakim> Attendees were St_Clair_3B
08:07:31 <sandro> zakim, call St_Clair_3B
08:07:31 <Zakim> ok, sandro; the call is being made
08:07:32 <Zakim> SW_LDP()2:30AM has now started
08:07:32 <Zakim> +St_Clair_3B
08:07:50 <svillata> svillata has joined #ldp
08:08:45 <oberger> oberger has joined #ldp
08:10:03 <bblfish> bblfish has joined #ldp
08:10:33 <krp> krp has joined #ldp
08:10:57 <rgarcia> rgarcia has joined #ldp
08:11:00 <cygri> scribe: krp
08:11:00 <topic> topic: Admin, Protocol
08:11:46 <krp> Arnaud: added the primer to the agenda for this afternoon
08:12:46 <krp> Arnaud: yesterday first f2f, ramping up, but feedback to try and speed up discussions
08:13:07 <cygri> cygri has joined #ldp
08:13:24 <cygri> cygri has joined #ldp
08:13:26 <krp> ... status quo is the spec as is
08:13:39 <nmihindu> nmihindu has joined #ldp
08:13:48 <krp> ... burden is on those who have issue with spec to explain what that is
08:14:17 <betehess> betehess has joined #ldp
08:14:29 <krp> ... discussion centred around: 1. what the problems is (ensuring everyone understands it) 2. how to solve it (proposals)
08:15:45 <chsiao> chsiao has joined #ldp
08:15:48 <krp> ... make sure we are talking about a specific problem and specific problem rather than debating in the round
08:15:49 <oberger> btw, http://bikeshed.org/ for those who don't know
08:16:34 <krp> ... 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 <Arnaud> q?
08:17:13 <krp> oberger: we can only discuss issues where the person who raised it is present?
08:17:26 <SteveBattle> SteveBattle has joined #ldp
08:17:57 <SteveBattle> SteveBattle has left #ldp
08:18:02 <krp> 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_> betehess_ has joined #ldp
08:18:09 <SteveBattle> SteveBattle has joined #ldp
08:18:10 <cygri> summary: The group should avoid bikeshedding, and the Chair will try to speed up discussion.
08:18:12 <krp> TOPIC: WG Note on Access Control
08:18:20 <oberger> http://www.w3.org/2012/ldp/charter
08:18:42 <sandro> " 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 <krp> 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:20:07 <krp> ... compromise in the charter: a note. Need to figure out what will be in it, who will be editors
08:20:14 <bblfish> q+
08:20:18 <krp> ... we need to define what we want to do
08:20:22 <betehess> q+
08:20:26 <Arnaud> ack bblfish
08:20:54 <krp> bblfish: identify those interested in distributed access control. I wish to implement this... who else?
08:20:57 <FabGandon> FabGandon has joined #ldp
08:21:12 <Arnaud> ack bete
08:21:28 <FabGandon> Present+FabGandon
08:21:56 <SteveBattle> q+
08:21:59 <sandro> q+ to talk about W3C member-access as a user story
08:22:23 <Arnaud> ack steveb
08:22:23 <krp> 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 <sandro> betehess, I think this is 100% about authorization
08:22:40 <Ashok_Malhotra> Ashok_Malhotra has joined #ldp
08:22:44 <krp> stevebattle: is there anything in the spec incompatible with ACLs etc.?
08:22:44 <Ashok_Malhotra> q+
08:22:49 <bblfish> here is an interesting thing: http://www.w3.org/wiki/WebAccessControl
08:22:58 <nmihindu> present+ Nandana_Mihindukulasooriya
08:23:10 <Arnaud> ack sandro
08:23:10 <Zakim> sandro, you wanted to talk about W3C member-access as a user story
08:23:12 <bblfish> that is what betehess means by WebACL
08:23:19 <BartvanLeeuwen> present+ BartvanLeeuwen
08:23:23 <krp> betehess: so far nothing in spec. For WebACL just need to provide ontologies.
08:23:41 <antonis> present+ AntonisLoizou
08:23:54 <rgarcia> present+ Raul_Garcia-Castro
08:24:10 <bblfish> +1 there is a requirement for a distributed authentication
08:24:11 <ivan> ivan has joined #ldp
08:24:14 <krp> 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 <oberger> sandro, would you add it to the UCR ?
08:24:16 <svillata> present+ Serena Villata
08:24:18 <Arnaud> ack ashok
08:24:18 <jonathandray> present+ Jonathan_Dray
08:24:22 <betehess> sandro, that use-case is definitely what people call "decentralized" here
08:24:29 <oberger> present+Olivier_Berger
08:24:37 <SteveS> present+ Steve_Speicher
08:24:39 <bblfish> q+
08:24:40 <oberger> present+ Olivier_Berger
08:24:45 <cygri> present+ Richard Cyganiak
08:25:09 <betehess> q+
08:25:11 <sandro> present+ Sandro Hawke
08:25:17 <SteveS> sandro, good use case should it be added to issue tracker or in minutes enough?
08:25:18 <Arnaud> ack bblfish
08:25:22 <betehess> present+ Alexandre_Bertails
08:25:39 <krp> ashok: typically access control is based on underlying storage engine. I can help edit.
08:25:54 <svillata> q?
08:26:27 <sandro> q+ to ask about possible requirement -- do resources have different representations for different-access users?
08:26:27 <oberger> q+
08:26:30 <krp> 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 <Arnaud> ack bete
08:26:42 <betehess> http://presbrey.mit.edu/
08:27:12 <bblfish> presbrey built http://data.fm/
08:27:22 <krp> betehess: let's be concrete (see link)... first implementation of linked data server... let's start by reviewing this
08:27:45 <cygri> q+
08:27:48 <Zakim> +Yves
08:28:17 <Arnaud> ack sandro
08:28:17 <Zakim> sandro, you wanted to ask about possible requirement -- do resources have different representations for different-access users?
08:28:33 <krp> 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 <Arnaud> ack oberger
08:29:31 <krp> 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 <betehess> q+
08:29:48 <krp> oberger: are people interested in oauth? is there anything to say about it?
08:29:58 <betehess> q+ to comment on other technologies
08:30:05 <Arnaud> ack cygri
08:30:07 <krp> ... it can delegate tokens to applications to do things on you behalf
08:30:48 <oberger> oberger: interesting use case : delegating "tokens" to apps to act on your behalf, in oauth
08:31:06 <krp> 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 <bblfish> q+
08:31:49 <oberger> sandro, I think the point you raised is interesting to the group indeed
08:31:54 <krp> ... 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 <bblfish> Cygri, is right. 0ne does not need to list all the technologies up. There are parts that remain open.
08:32:11 <oberger> sandro, worth an issue ?
08:32:25 <Arnaud> ack bete
08:32:25 <Zakim> betehess, you wanted to comment on other technologies
08:32:34 <krp> 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 <ericP> q?
08:34:02 <krp> 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 <krp> arnaud: not here to revisit charter
08:34:37 <krp> ... the question is not whether we should do it (the note)
08:34:47 <BartvanLeeuwen> q+
08:35:25 <betehess> does "Deliverables - Not Recommendation Track" even mean that we need to deliver a NOTE? whyh not just a wiki page?
08:35:32 <Arnaud> ack bblfish
08:35:38 <oberger> betehess, it's too soon to discuss that IMHO
08:35:55 <oberger> let's see UC and needs of the group more explicited
08:35:57 <krp> ... 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 <cygri> 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 <oberger> cygri, ack
08:36:32 <cygri> betehess, oberger, whether that's a good thing or not, i don't know :-)
08:36:47 <oberger> cygri, we'll see while doing
08:37:00 <betehess> cygri, yeah, just saw that (I wasn't the one who added that in the charter :-)
08:37:01 <Arnaud> ack bart
08:37:06 <krp> 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 <SteveS> q+
08:38:18 <krp> 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 <Arnaud> ack steves
08:38:42 <betehess> q+
08:39:05 <krp> 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_> timbl_ has joined #ldp
08:39:07 <cygri> SteveS++
08:39:17 <Arnaud> ack bete
08:39:20 <timbl_> RRSAgent, pointer?
08:39:20 <RRSAgent> See http://www.w3.org/2012/11/02-ldp-irc#T08-39-20
08:39:21 <krp> ... seems like we should get the wiki page up to start getting input
08:40:26 <krp> 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 <krp> steves: not saying isn't useful to standardise
08:41:13 <Arnaud> q?
08:41:15 <timbl_> 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 <krp> arnaud: whole point of note is to gather this information: what to you need from access control?
08:41:28 <Arnaud> ack timbl
08:41:28 <Zakim> 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 <bblfish> Arnaud: note is a way to gather information together about what people would like to do
08:42:46 <krp> 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 <SteveS> 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:56 <krp> arnaud: ashok to create and structure wiki page to gather use cases and requirements
08:44:04 <cygri> ACTION: Ashok to set up wiki page on Access Control
08:44:04 <trackbot> Created ACTION-21 - Set up wiki page on Access Control [on Ashok Malhotra - due 2012-11-09].
08:44:23 <bblfish> +1
08:44:25 <Arnaud> q?
08:44:26 <krp> ... everyone add your ucr, please check whether there's already something there... modify/add rather than duplicate
08:44:27 <cygri> +1
08:44:30 <SteveS> +1
08:44:43 <ericP> Ashok_Malhotra, i already started by dropping an example into http://www.w3.org/2012/ldp/wiki/AccessControl
08:44:46 <krp> ... a reasonable approach?
08:45:05 <ericP> i can continue with a couple others
08:45:19 <krp> ... I think that's all we need to do on this today
08:45:55 <timbl_> http://www.w3.org/wiki/WebAccessControl
08:46:17 <krp> ericP: already have a starting page in place http://www.w3.org/wiki/WebAccessControl
08:46:38 <oberger> ericP, could you explicit the syntax of the example ?
08:47:10 <SebastianS___> SebastianS___ has joined #ldp
08:47:17 <krp> ashok: what does this syntax mean?
08:47:32 <krp> arnaud: eric, could you give more explanation of this example?
08:49:00 <krp> arnaud: call for which issues to discuss and defend
08:49:00 <cygri> summary: Discussion of the scope and format of this deliverable. The focus should be on UC&R for access control. Ashok will set up a wiki page.
08:49:14 <cygri> q+
08:49:18 <krp> TOPIC: ISSUE-25 and ISSUE-7 — Containers, Composition, Aggregation
08:49:31 <bblfish> Issue-25?
08:49:31 <trackbot> ISSUE-25 -- Weak aggregation and strong composition in containers -- open
08:49:31 <trackbot> http://www.w3.org/2012/ldp/track/issues/25
08:49:43 <cygri> q-
08:51:12 <krp> 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 <krp> oberger: addition of something to container would be a good subject to consider this
08:52:25 <krp> arnaud: Steve, do you have a proposal as how to modify spec?
08:53:01 <Ashok_Malhotra> q+
08:53:05 <SteveS> q+
08:53:07 <krp> stevebattle: proposal is to use hierarchical URIs to represent containment
08:53:24 <oberger> q+
08:54:26 <krp> arnaud: aggregation vs. composition, but the spec isn't clear? do you want it to do one or the other?
08:54:49 <krp> stevebattle: to do both but be clear when it is doing which
08:55:46 <krp> q+
08:55:57 <Arnaud> ack ashok
08:55:58 <bblfish> q+
08:56:13 <Arnaud> ack steves
08:56:27 <krp> ashok: when you add a container to a container is it hierarchical?
08:56:31 <krp> stevebattle: yes
08:57:44 <krp> steves: not sure how the uri structure is related to containment, not sure the spec should specify uri structure.
08:57:48 <Arnaud> ack oberger
08:58:00 <cygri> SteveBattle, please phrase a proposal on IRC
08:58:00 <bblfish> but the solution seems simple to me: why not just have a class of containers that seperates the two cases ?
08:58:37 <bblfish> -1 for adding new verbs, only a last resort
08:58:45 <krp> 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 <sandro> so POST might be CREATE + ADD-TO-CONTAINER ?
08:59:23 <SteveBattle> a single container might support both aggregation and composition so I'm not sure we can do it by container type.
08:59:34 <ericP> q+ to resolve issue-25 adding a Container property called "deletesMembers" which applies regardless of the URI structure
08:59:34 <sandro> q+
09:00:11 <Arnaud> ack krp
09:00:14 <sandro> krp: I'm a little confused about the proposal.   You want the client to understand whether it's containment?
09:01:29 <sandro> q-
09:01:57 <cygri> PROPOSAL: DELETE on a container deletes the container and any resources with URIs below in a path hierarchy, and nothing else.
09:02:05 <timbl_> q?
09:02:17 <sandro> 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 <antonis> q+
09:02:27 <Arnaud> ack bblfish
09:02:28 <timbl_> Thius syetm must have rigidly defined and simple semantics. Think unix file syetm.
09:02:35 <SteveBattle> q+
09:02:39 <oberger> q+
09:02:52 <timbl_> q+
09:02:52 <krp> bblfish: proposal to have two type of containers specified
09:02:52 <antonis> q-
09:03:19 <sandro> 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 <sandro> +1 I rather like that.
09:03:35 <SteveBattle> I like cygri's wording - very concise.
09:03:37 <nmihindu> q+
09:03:39 <sandro> s/to r/two r/
09:03:46 <krp> ... 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 <cygri> SteveBattle, note, not intended to be spec text, just a design to be turned into spec text by the editor
09:04:36 <rgarcia> q+ to say why don't we define two membership properties, one for weak and another for strong aggregation
09:05:05 <krp> oberger: do the different types map to the two examples in the spec
09:05:07 <SteveS> 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 <ericP> rgarcia, i've typed a proposal like that at 9:59:34
09:05:25 <oberger> q-
09:05:27 <Arnaud> ack eric
09:05:27 <Zakim> ericP, you wanted to resolve issue-25 adding a Container property called "deletesMembers" which applies regardless of the URI structure
09:06:18 <bblfish> agree that I don't think that speaking of URL hierachies is useful
09:06:50 <BartvanLeeuwen> q+
09:06:56 <krp> 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 <bblfish> s/that I/I/
09:07:07 <Arnaud> ack steveb
09:07:11 <krp> it is not a sufficient mechanism to inform the client
09:07:33 <Ashok_Malhotra> q+
09:08:07 <cygri> q+
09:08:09 <Arnaud> ack timbl
09:08:12 <krp> stevebattle: don't believe the typing proposal works... can't add same resources to multiple containers but can to aggregations
09:08:35 <ericP> what if we just give up on DELETE delting any members? any use cases which motivate this complexity?
09:09:45 <Ashok_Malhotra> q-
09:10:11 <krp> 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 <krp> ... so group should focus on containers. other forms of aggregation are described by a number of different ontologies.
09:11:04 <cygri> PROPOSAL: DELETE on a container deletes the container and any resources with URIs below in a path hierarchy, and nothing else.
09:11:42 <timbl_>  Clarification: Does the URI path match the containership at all times?
09:12:04 <Arnaud> ack nmihindu
09:12:09 <SteveS> q+
09:12:10 <krp>  clarification: can there be any members *not* under the path hierarchy?
09:12:31 <SteveBattle> Ah, cygri, your definition says nothing about the URIs created in POST.
09:12:54 <BartvanLeeuwen> q-
09:12:54 <Arnaud> ack rgarcia
09:12:55 <cygri> SteveBattle, do you want to rephrase it?
09:12:56 <Zakim> 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> AndyS has joined #ldp
09:13:37 <Arnaud> ack cygri
09:14:09 <krp> rgarcia: define two membership properties
09:14:10 <timbl_> 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 <SteveBattle> "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 <bblfish> 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 <krp> cygri: spec allows domain specific subclassing and this will quickly get complicated with two properties
09:15:21 <antonis>  ldp:compositionPredicate rdfs:subClassOf ldp:memberhiPredicate . ldp:aggregationPredicate rdfs:subClassOf ldp:memberhiPredicate .
09:15:28 <krp> .. do need to support both cases (strong and weak aggregation). container as designed seems to be about strong
09:15:28 <antonis> ?
09:15:33 <rgarcia> 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 <SteveBattle> Ughh- that's going to get ugly PRETTY quickly (ld composition predicates)
09:16:04 <bblfish> +1 for how to do weak agregation sounds good.
09:16:22 <krp> ... but we need to be clear how to do weak aggregation
09:16:32 <betehess> can somebody gives a use-case for weak-aggregation?
09:16:38 <timbl_> 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 <antonis> s/rdfs:subClassOf/rdfs:subPropertyOf/
09:17:11 <ericP> lastlog propos
09:17:15 <timbl_> q?
09:17:21 <krp> oberger: we need to decide which way container is, and whether we need the other
09:17:34 <Arnaud> ack steves
09:17:36 <SteveBattle> q+
09:18:35 <cygri> oberger++
09:18:36 <krp> steves: say that instead of a hierarchy of uris say a resource  hierarchy managed by that server
09:19:51 <Arnaud> ack timbl
09:19:51 <Zakim> 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 <Zakim> ... protocol (data types, preferred vocabulary, aggregation membership).
09:21:16 <krp> 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 <krp> ... go through spec and consider "does the server need to be aware of this"
09:22:05 <Arnaud> ack rgarcia
09:22:05 <Zakim> 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 <cygri> 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 <FabGandon> ack SteveBattle
09:23:42 <cygri> q+
09:24:01 <krp> stevebattle: Tim is correct, the LDP is primarily about containment. but we do need aggregation.
09:24:26 <SteveS> +1 to cygri 10:22 proposal
09:24:32 <timbl_> q+ to point out hierarchical URIs connect with WebDav and also give locality of reference with relative URIs.
09:24:35 <oberger> q+ to know why rdfs:Container isn't reused
09:24:35 <krp> ... other precedents for hierarchical URIs
09:25:00 <Arnaud> ack cygri
09:25:01 <SteveBattle> I'd still prefer the use of hierarchical URIs.
09:25:23 <SteveS> oberger, could also look at skos:Collection as the type to indicate aggregation
09:25:34 <Arnaud> ack timbl
09:25:34 <Zakim> timbl_, you wanted to point out hierarchical URIs connect with WebDav and also give locality of reference with relative URIs.
09:25:37 <sandro> I have a hard time imagining it's okay to delete /foo and still have /foo/bar exist.
09:25:53 <SteveBattle> TOTALLY agree
09:26:21 <ahaller2> sandro++
09:26:54 <Yves> +1 to sandro
09:27:19 <betehess> agree with tim, we're conflating different problems and solutions here
09:27:26 <ericP> q?
09:27:30 <sandro> +1 timbl: paging large agregates is something you need with any kind of large RDF Graph
09:28:08 <krp> 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 <SteveBattle> paging is currently tied to the aggregation - I think that's right.
09:28:13 <Yves> 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 <krp> timbl: that sounds like an RDF graph. can we not have paging on all RDF graphs?
09:28:43 <bblfish> +1 to follow up on looking at separating paging more clearly
09:28:50 <betehess> Yves: that's an analysis or a proposal?
09:28:51 <Arnaud> ack oberger
09:28:51 <Zakim> oberger, you wanted to know why rdfs:Container isn't reused
09:28:55 <cygri> cygri: we call it "container" even though it's really a controller for a subject-predicate pair
09:29:11 <Yves> betehess, an analysis of what people seems to want
09:29:14 <krp> oberger: proposed to use rdfs:member, but I also see rdfs: container
09:29:23 <timbl_> 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 <Yves> and it seems logical too ;)
09:29:39 <krp> ... so maybe we shouldn't call it container?
09:29:41 <SteveBattle> But we can also use skos:Collection - don't overload refs:Container
09:29:52 <cygri> +1 to timbl's proposal
09:30:15 <krp> arnaud: good time to have a break?
09:30:19 <betehess> +1 to timbl
09:30:29 <sandro> +1 timbl's
09:30:38 <rgarcia> +1 to timbl's
09:30:56 <ericP>  Proposals:
09:30:56 <ericP> .. hierarchical URIs represent containment (and delelete members) (stevebattle)
09:30:56 <ericP> .. class type specifies whether members are contained (bblfish)
09:30:56 <ericP> .. { <SomeContainer> ldp:deletesMembers true } deletes members regardless of URI (ericP)
09:30:59 <ericP> .. the membership property specifies containment (rgarcia)
09:31:02 <ericP> .. all containers delete members (timbl)
09:31:04 <ericP> .. all created (by POST) resources are contained
09:31:26 <timbl_> 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 <SteveBattle> Clarification neede: Does this separation imply that we drop ldp:membershipPredicate or not?
09:37:16 <JohnArwe> JohnArwe has joined #ldp
09:48:25 <Zakim> -Yves
09:57:34 <rgarcia> rgarcia has joined #ldp
09:58:23 <nmihindu> nmihindu has joined #ldp
09:59:11 <cygri> cygri has joined #ldp
09:59:20 <cygri> cygri has joined #ldp
09:59:57 <sandro> JohnArwe, we are returning from break now.
10:00:29 <oberger> q+ to question the role of dc:creator for ownership wrt DELETE
10:00:37 <Zakim> +JohnArwe
10:00:38 <Zakim> -JohnArwe
10:00:38 <Zakim> +JohnArwe
10:02:56 <oberger> q-
10:03:26 <betehess> s/JohnArwe, we are returning from break now.//
10:04:02 <ahaller2> ISSUE-25
10:04:05 <SteveBattle> SteveBattle has joined #ldp
10:04:19 <oberger> JohnArwe, we have wandered a bit far from the issue
10:04:20 <nmihindu> scribe: nmihindu
10:04:34 <sandro> "Weak aggregation and strong composition in containers"
10:05:07 <nmihindu> Arnaud: We are talking about many issues within this issues
10:05:26 <cygri> STRAWPOLL: Do we need weak aggregation in the spec?
10:05:30 <sandro> Arnaud: I take for granted that we need Strong Compisition.  Any objection?  ...  none ...
10:05:37 <nmihindu> Arnaud: do we need to have weak aggregation ?
10:05:38 <cygri> +1 Yes we need it
10:05:41 <BartvanLeeuwen> +1
10:05:41 <ahaller2> +1
10:05:41 <antonis> +1
10:05:42 <rgarcia> +1
10:05:44 <oberger> +1
10:05:44 <SteveS> +1
10:05:50 <betehess> +1
10:05:52 <bblfish> +1
10:05:54 <SteveBattle> would like to hear what Time had to say before I vote
10:06:00 <nmihindu> Arnaud: do we need aggregation ?
10:06:01 <SteveBattle> s/Time/Tim
10:06:11 <sandro> +0  apps need it, but I don't think *we* necessarily need to spec anything
10:06:13 <bblfish> +0
10:06:20 <Zakim> +Yves
10:06:21 <timbl_> -1
10:06:23 <betehess> s/+1/+1 but in other terms/
10:06:23 <nmihindu> Arnaud: aggregation is weak composition
10:06:28 <oberger> I'm not sure I understand what "need" means
10:06:48 <Yves> +0 we might provision for it, but not define it
10:06:54 <nmihindu> Arnaud: do we need to address weak aggregation in this spec ?
10:06:59 <JohnArwe> what is composition as you're using the term, since I need to understand that in order to parse your definition of aggregation as weak comp
10:06:59 <bblfish> I am not sure
10:07:07 <bblfish> I need to implement it
10:07:21 <nmihindu> oberger: do paging is included in this ?
10:08:26 <antonis> strong composition: when a container is deleted, all contained resources are also deleted
10:08:41 <nmihindu> timbl: why does the server have to know those arcs have to do with aggregation ?
10:08:53 <antonis> weak aggregation: when a container is deleted, resources under it are not
10:08:54 <SteveBattle> +1
10:08:56 <betehess> as a developer, I have no need at all for weak aggregation as I have RDF graphs already, but I see value in paging for any kind of resource
10:09:07 <krp> Do we need weak aggregation for *anything other than paging*? (if not, we can split out the paging issue)
10:09:16 <sandro> +1 timbl: general aggregation is something clients to can, without knowledge/support from the server.   but LDP servers should provide paging of that data, if necessary.
10:09:17 <bblfish> So one should consider other methods one can use to do the same. Eg. Post an rdf:Collection to a ldp:Collection, then one can use some form of SPARQL update on the collection when making changes
10:09:25 <bblfish> q+
10:09:42 <nmihindu> SteveS: aggregation is important for ordering
10:10:19 <sandro> subtopic? What does the server need to implement about aggregation?
10:10:30 <betehess> q+
10:10:31 <Arnaud> ack bblfish
10:10:39 <cygri> q+ to say we need aggregation to associate two existing� resources
10:10:41 <SteveBattle> I agree the spec doesn't NEED weak aggregation - it's a convenience.
10:10:53 <svillata> q?
10:11:15 <cygri> q+ to say we need something aggregation-like in the client-server protocol to associate two existing resources
10:11:24 <SteveS> wondering if using RDF collections to specify ordering in the model across pages will impose inserting stuff in graph
10:11:39 <nmihindu> bblfish: if we have use cases for this, we can see how they fit
10:11:42 <timbl_> Hmmm …. SPARQL updates for adding things to a list are something we do not have right now, we have to replace the list.
10:12:08 <Arnaud> ack bete
10:12:10 <krp> +q
10:12:13 <nmihindu> Arnaud: we are not sure what are the requirements are and what problems we need to solve
10:13:22 <nmihindu> betehess: I need to have composition for resources I created and rest I can do in my application
10:14:13 <timbl_> ?
10:14:19 <nmihindu> Arnaud: we need to see whether we have a UC for weak aggregation
10:14:54 <bblfish> which issue?
10:15:03 <betehess> the issue may not be describing the UC very well
10:15:07 <Arnaud> ack cygri
10:15:07 <Zakim> cygri, you wanted to say we need aggregation to associate two existing� resources and to say we need something aggregation-like in the client-server protocol to associate two
10:15:08 <ahaller2> example use case: a web form at /foo, data for this form at /foo/bar1 and /foo/bar2, but I want to keep these instances when I delete /foo, because the instances are independent resources of the web form
10:15:10 <Zakim> ... existing resources
10:15:12 <nmihindu> Arnaud: we need to decide whether this a requirement we need address
10:15:21 <SteveBattle> weak aggregation was indirectly raised in issue 7
10:16:00 <nmihindu> cygri: rdf triple by default is weak aggregation
10:16:02 <bblfish> Issue-7?
10:16:02 <trackbot> ISSUE-7 -- What operations are permittered on containers and how do they get invoked? -- open
10:16:03 <trackbot> http://www.w3.org/2012/ldp/track/issues/7
10:16:21 <betehess> I'm not sure if people here agee with cygri's definition of weak aggregation
10:16:36 <betehess> s/agee/agree/
10:16:38 <SteveBattle> I do
10:16:40 <bblfish> q?
10:16:42 <bblfish> q+
10:16:46 <nmihindu> cygri: I need some mechanism for doing paging and may be we can weak aggregation for this
10:17:06 <betehess> SteveBattle, care to put down in words definitions for weak and strong?
10:17:07 <bblfish> so my question is why can the weakly agregated collection not be just a document that contains links to other resources?
10:17:41 <nmihindu> sandro: whether PATCH will solve this problem ?
10:18:01 <bblfish> mhh. I thought we were going to have patch
10:18:01 <nmihindu> cygri: it might
10:18:03 <timbl_> q+
10:18:22 <bblfish> or something like it - ie sending a SPARQL update type of message to a resource
10:18:55 <betehess> I'm hearing timbl_'s proposal I believe
10:19:43 <Arnaud> ack krp
10:19:52 <bblfish> q-
10:19:53 <sandro> I actually think we should offer basic graph operations -- single triple match, and paging -- standard on all resources.
10:19:53 <bblfish> q+
10:20:07 <nmihindu> cygri: there are two main things related to containers 1) management of properties 2) creating new resources
10:20:32 <Arnaud> ack timbl
10:20:46 <nmihindu> krp: concrete use case for weak aggregation
10:20:58 <bblfish> q-
10:22:10 <bblfish> timple makes a strong case for PATCH
10:22:13 <nmihindu> timbl: with PATCH this issue can be handled
10:22:13 <betehess> I thought that some kind of PATCH was a given
10:22:35 <JohnArwe> s/timple/timbl/
10:22:39 <SteveS> q+
10:22:53 <nmihindu> timbl: did you make decision to make PATCH optional ?
10:23:37 <Arnaud> ack steves
10:23:57 <nmihindu> Arnaud: We can make patch mandatory how if we define how it will work
10:24:16 <Yves> we need a patch format...
10:24:47 <nmihindu> SteveS: we will not reinvent the wheel but point to existing solutions
10:25:12 <SteveBattle> Composition is a 'part-of' relationship; the lifecycle of the subordinate resource is tied to the container. Aggregation is a 'member-of' relation; and the lifecycle of the subordinate object is not linked to the container.
10:25:23 <nmihindu> SteveS: we didn't include the PATCH as we couldn't agree on a PATCH format etc.
10:26:02 <krp> For our application we need weak aggregation, but I believe this can be handled in the domain model. If I wanted to manipulate this membership through LDP, rather than manipulating the wider graph, then the membership triples could be an explicit separate resource that can be manipulated (e.g. DELETE). Strong containers are the distinct case where we would want to be explicit that the server attempt to recursively delete members.
10:26:29 <betehess> krp, +1
10:26:30 <nmihindu> Arnaud: We first make spec address strong aggregation and then take a look at weak aggregation issue
10:26:39 <sandro> PROPOSAL: Make the containers in the spec be about Strong Composition, then accept proposals for how to do weak aggregation.   And separate proposals for paging, etc.
10:26:45 <SteveBattle> A given resource may both contain and aggregate many objects.
10:26:49 <krp> +1
10:27:01 <SteveBattle> +1
10:27:04 <rgarcia> +
10:27:04 <cygri> +
10:27:05 <sandro> +1
10:27:05 <antonis> +1
10:27:06 <rgarcia> +1
10:27:06 <cygri> +1
10:27:07 <betehess> +1
10:27:08 <bblfish> +1
10:27:10 <nmihindu> +1
10:27:15 <timbl_> +1
10:27:16 <SteveBattle> q+
10:27:17 <Arnaud> +1
10:27:17 <svillata> +1
10:27:20 <Yves> +!
10:27:21 <ahaller2> +1
10:27:24 <Yves> +1
10:27:27 <SteveS> +1
10:27:27 <BartvanLeeuwen> +1
10:27:30 <ericP> +1
10:27:30 <oberger> +1
10:27:43 <sandro> RESOLVED: Make the containers in the spec be about Strong Composition, then accept proposals for how to do weak aggregation.   And separate proposals for paging, etc.
10:27:55 <Arnaud> ack steveb
10:28:32 <nmihindu> SteveBattle: Do you mean the spec as it is or with changes ?
10:28:58 <cygri> q+ to say that's a client-client issue
10:29:00 <nmihindu> SteveBattle: I am against using rdfs:member for composition
10:29:15 <JohnArwe> I thought the resolution was, if you will, at the conceptual level.  Agreeing on that concept might imply that spec changes are a consequence.
10:29:19 <bblfish> I understand the issue with rdfs:member being perhaps not precise enough.
10:29:33 <bblfish>  ldp:member
10:29:36 <cygri> q?
10:29:48 <timbl_> q+
10:29:48 <Arnaud> ack cygri
10:29:49 <Zakim> cygri, you wanted to say that's a client-client issue
10:30:02 <JohnArwe> ...i.e., if we agree the spec *should* be describing strong composition and we find cases where it is not, well that's what comments are for.
10:30:33 <SteveBattle> I still think that overloads rdfs:member
10:30:36 <krp> Though while I think weak composition can/should be done in the domain model, I think this approach will need explanation through example (e.g. in a primer)
10:30:49 <oberger> http://www.w3.org/TR/rdf-schema/#ch_member 5.1.6 rdfs:member
10:30:49 <oberger>  rdfs:member is an instance of rdf:Property that is a super-property of all the container membership properties i.e. each container membership property has an rdfs:subPropertyOf relationship to the property rdfs:member.
10:30:55 <nmihindu> cygri: we are not using rdfs:member for composition but the ldp container class
10:31:05 <betehess> please no sub-properties
10:31:16 <Arnaud> ack timbl
10:32:05 <oberger> are we done with issue 25 ?
10:32:40 <nmihindu> timbl_: SPARQL update is the clear choice for PATCH
10:32:46 <SteveBattle> I proposed changesets as a PATCH format :(
10:32:46 <sandro> q?
10:32:50 <sandro> q+
10:33:52 <nmihindu> Arnaud: I don't think we can close the ISSUE 25
10:34:13 <bblfish> so we need to open a new issue on patch
10:34:41 <bblfish> +1
10:34:48 <cygri> ISSUE-7?
10:34:48 <trackbot> ISSUE-7 -- What operations are permittered on containers and how do they get invoked? -- open
10:34:48 <trackbot> http://www.w3.org/2012/ldp/track/issues/7
10:34:48 <nmihindu> cygri: we need to answer the four points of the ISSUE 25, if PATCH is there is solves the issue. If it is not there we need to address those.
10:34:58 <cygri> ISSUE-17?
10:34:58 <trackbot> ISSUE-17 -- changesets as a recommended PATCH format -- open
10:34:58 <trackbot> http://www.w3.org/2012/ldp/track/issues/17
10:35:05 <betehess> q+
10:35:39 <sandro> q-
10:35:41 <nmihindu> sandro: Issue 17 is related to PATCH, may be we should rename it to handle PATCH
10:36:15 <timbl_> Arnaud's  division above separates the paging and patch be defined independently of containers is wise, and does require new issues about defining PATCH and generalizing paging.
10:36:34 <timbl_> q?
10:36:37 <Arnaud> ack bete
10:36:41 <sandro> Arnaud: Close issue-25 but make sure we have open ones on Patch and General-Paging
10:36:44 <nmihindu> Arnaud: We need an issue about aggregation, and issue 17 will handle PATCH
10:36:51 <BartvanLeeuwen> Issue-7?
10:36:52 <trackbot> ISSUE-7 -- What operations are permittered on containers and how do they get invoked? -- open
10:36:52 <trackbot> http://www.w3.org/2012/ldp/track/issues/7
10:37:03 <bblfish> q+
10:37:09 <AndyS> FWIW - Changesets can be translated directly to a SPARQL Update (a DELETE DATA and a INSERT DATA) mechanically.
10:37:29 <sandro> cygri: If we define a required patch format, then that solves issue-25, yes.
10:38:32 <nmihindu> Arnaud: we should have an issue on paging
10:38:39 <deiu> deiu has joined #ldp
10:38:41 <oberger> issue-17?
10:38:41 <trackbot> ISSUE-17 -- changesets as a recommended PATCH format -- open
10:38:41 <trackbot> http://www.w3.org/2012/ldp/track/issues/17
10:38:48 <cygri> ISSUE-18?
10:38:48 <trackbot> ISSUE-18 -- container membership and robust pagination -- open
10:38:48 <trackbot> http://www.w3.org/2012/ldp/track/issues/18
10:39:01 <nmihindu> oberger: do we need more used cases for aggregation ?
10:39:17 <nmihindu> cygri: we already have one
10:39:37 <nmihindu> s/used/use
10:39:45 <SteveS> http://lists.w3.org/Archives/Public/public-ldp-wg/2012Sep/0089.html
10:40:11 <SteveBattle> I believe that all any's scenarios are covered in UC&R
10:40:19 <SteveBattle> s/any/andy
10:40:20 <cygri> ACTION: cygri to open an issue on paging
10:40:20 <trackbot> Created ACTION-22 - Open an issue on paging [on Richard Cyganiak - due 2012-11-09].
10:42:22 <nmihindu> Arnaud: we need to close some issue and open more granular ones that addresses the raised points
10:43:11 <bblfish> AndyS: hi
10:43:13 <SteveBattle> Are you there Andy?
10:43:16 <Arnaud> q?
10:43:32 <AndyS> Hello
10:43:36 <krp> +1 to clearly scoped narrower issues
10:43:46 <AndyS> On IRC
10:44:12 <AndyS> (can phone in but need time to move room and dial-in).
10:44:28 <BartvanLeeuwen> AndyS, just read along
10:44:41 <cygri> AndyS, I'm going to create a new issue on managing weak aggregation, to subsume ISSUE-7
10:44:46 <sandro> AndyS, it's not clear what we're about to talk about next.
10:44:52 <AndyS> I am :-) Fascinating.
10:45:12 <cygri> ACTION: cygri to create a new issue on managing weak aggregation, to subsume ISSUE-7; PATCH might be one way to do it
10:45:12 <trackbot> Created ACTION-23 - Create a new issue on managing weak aggregation, to subsume ISSUE-7; PATCH might be one way to do it [on Richard Cyganiak - due 2012-11-09].
10:45:35 <SteveBattle> Resources under the same authority can be distributed across many servers.
10:45:39 <timbl_> ISSUE: Should the PATCH method be used, as oppose t POST with a given mime type?   What systems can support PATCH easily? (tabulator uses POST but could change of course)
10:45:39 <trackbot> Created ISSUE-27 - Should the PATCH method be used, as oppose t POST with a given mime type?   What systems can support PATCH easily? (tabulator uses POST but could change of course) ; please complete additional details at http://www.w3.org/2012/ldp/track/issues/27/edit .
10:45:39 <rgarcia> oberger, that is one problem of having strong aggregation using  an URI schema. I we don't do it there should not be
10:45:59 <Arnaud> q?
10:46:02 <bblfish> q-
10:46:23 <betehess> PROPOSAL: close #25
10:46:30 <nmihindu> Arnaud: can we close ISSUE 25 now ?
10:46:57 <nmihindu> cygri: with the two actions created I think we can close the issue
10:47:05 <bblfish> +1
10:47:06 <betehess> +1
10:47:09 <rgarcia> +1
10:47:09 <krp> +1
10:47:10 <SteveS> +1
10:47:10 <svillata> +1
10:47:11 <nmihindu> +1
10:47:11 <oberger> +1
10:47:14 <cygri> +1
10:47:21 <Arnaud> +1
10:47:22 <BartvanLeeuwen> +1
10:47:23 <SteveBattle> +1
10:47:34 <sandro> +1
10:47:37 <antonis> +1
10:47:41 <betehess> APPROVED: close #25
10:47:55 <betehess> RESOLVED: close #25
10:48:11 <betehess> RESOLVED: Close ISSUE-25
10:48:19 <betehess> s/APPROVED: close #25//
10:48:25 <betehess> s/RESOLVED: close #25//
10:48:30 <oberger> q+ to know if we need to create an issue on examples only using resources on same server ans subpaths for (strong) composition
10:48:45 <timbl_> Ooops  I didn't mean to create an issue in the system.   it let me create an issue but not edit it.
10:48:46 <Arnaud> ack oberger
10:48:46 <Zakim> oberger, you wanted to know if we need to create an issue on examples only using resources on same server ans subpaths for (strong) composition
10:49:28 <timbl_> q+
10:49:30 <SteveBattle> Isn't this kind of federation an implementation issue?
10:49:38 <betehess> q+
10:49:41 <nmihindu> oberger: we should make explicit or provide examples that resources can be all over the world even with composition
10:50:00 <bblfish> +1 for cygri: strong composition means you have to go through the container to create the resource.
10:50:40 <nmihindu> cygri: strong composition usually implies it is created by the container on the same server
10:51:18 <nmihindu> oberger: disagree, it could be possible to have something similar to factories in OOP
10:51:42 <webr3> how do you make an LDPC?
10:51:42 <betehess> q-
10:52:07 <sandro> sandro: When you POST to create a resource in a container, it might be given a URL on a different host, yes.     eg posting to api.example.com might make resources show up on {username}.example.com based on who did the post.
10:52:16 <nmihindu> Arnaud: oberger does not want the strong composition to imply the resources are on the same server
10:53:01 <JohnArwe> I think all olivier is asking for it to make at least one EXAMPLE show a container whose "output" member URI has no visible relationship to the container URI
10:53:17 <nmihindu> oberger: The spec does not say that but people might have a misunderstanding without an explicit example
10:53:19 <SteveBattle> A container SHOULD NOT manage resources under a different authority.
10:53:22 <rgarcia> +1 to having an example
10:53:53 <cygri> PROPOSAL: State in the spec that composition doesn't mean that the resources must reside in the same hierarchy or even on the same server
10:53:58 <sandro> +1
10:53:59 <Arnaud> +1
10:54:00 <nmihindu> +1
10:54:00 <rgarcia> +1
10:54:02 <oberger> +1
10:54:02 <svillata> +1
10:54:03 <SteveS> +1
10:54:04 <BartvanLeeuwen> +1
10:54:05 <krp> +1
10:54:06 <SteveBattle> -0
10:54:09 <ericP> +1
10:54:09 <cygri> +0.2 sure why not
10:54:12 <JohnArwe> +1
10:54:13 <webr3> +1
10:54:13 <betehess> +1
10:54:51 <timbl_> q+
10:55:12 <nmihindu> SteveBattle: with my early proposal, they should be strictly in the same hierarchy
10:55:17 <Arnaud> ack timbl
10:55:19 <sandro> SteveBattle: I like having the contained-item URLs be in the hierarchy under the container URLs
10:55:57 <sandro> q+
10:56:05 <nmihindu> timbl: at some point we need to have the concept of ownership
10:56:28 <SteveBattle> Yes - I admit it - I do look at URL's - I don't always wear the opaque glasses.
10:56:36 <bblfish> so the point is one of domain name ownership.
10:57:06 <krp> q+ So is there an issue that with strong containers deletion of a container deletes the members, but the client is not informed which member resources have been successfully deleted - it has to assume or guess?
10:57:14 <SteveBattle> I also like slugs.
10:57:27 <rgarcia> +q to say that the directory structure can mislead clients when differentiating between paths and resources
10:57:36 <bblfish> q+
10:57:43 <bblfish> q-
10:57:48 <krp> q+
10:57:52 <Ashok_Malhotra> q+
10:58:50 <Arnaud> ack sandro
10:59:32 <JohnArwe> q+ to say coming from highly robust implementation background, making the members owned by the container's implementation does *improve your odds* but it is NOT an iron-clad guarantee against inconsistent results due to failures in underlying code layers
10:59:37 <bblfish> PROPOSAL: perhaps the example in the spec should be something close to the livesjournal example
10:59:43 <Arnaud> ack rgarcia
10:59:43 <Zakim> rgarcia, you wanted to say that the directory structure can mislead clients when differentiating between paths and resources
10:59:44 <cygri> sandro++
11:00:04 <bblfish> q+
11:00:31 <Arnaud> ack krp
11:00:35 <nmihindu>  rgarcia: in the url, can we assume every part of it is a resource ?
11:00:50 <Ashok_Malhotra> q-
11:00:50 <nmihindu> cygri: no
11:01:01 <timbl_> q+
11:01:32 <svillata> q?
11:01:35 <cygri> webr3, all containers are resources too. if there are conflicts, it's a bug.
11:02:17 <SteveBattle> Nothing to stop you using a PUT to create a container, or a POST if you have another container.
11:02:23 <timbl_> q+ to say that from client app point ov view, it is important to keep local data in sync with data in the LDP server, so please restrict results to "Your delete of the  container worked" or "failed completely" but not "may be in any half-deleted state".
11:02:52 <nmihindu> Arnaud: where do you stand in this proposal ?
11:03:00 <krp> with strong containers when the container is deleted the members should be deleted, but this isn't always possible (not on server, access control). This could be clarified by returning to the client the resources that have actually successfully been deleted (which may not be all members after all)
11:03:29 <Ashok_Malhotra> Tim is asking for transactions!
11:03:43 <webr3> +20 to transactions!
11:03:45 <JohnArwe> ...distributed trxns no less
11:03:50 <sandro> tim: I'm okay with this proposal as long as it's clear the client can't just add something across the web to the "strong Container" and expect it too be deleted when the container is deleted!
11:05:16 <rgarcia> cygri, yes, my only comment was that it can be misleading for clients
11:05:30 <melvster> melvster has joined #ldp
11:05:34 <oberger> q+ to ask if there's something wrong with 5.6.1
11:05:51 <nmihindu> timbl: I prefer the make sure the delete happens or say it is forbidden to delete
11:05:56 <Arnaud> ack john
11:05:56 <Zakim> JohnArwe, you wanted to say coming from highly robust implementation background, making the members owned by the container's implementation does *improve your odds* but it is NOT
11:05:59 <Zakim> ... an iron-clad guarantee against inconsistent results due to failures in underlying code layers
11:06:16 <melvster> hi all ... just following remotely :) melvster == Melvin Carvalho
11:06:58 <Arnaud> q?
11:06:58 <bblfish> q-
11:07:02 <sandro> issue-28?
11:07:02 <trackbot> ISSUE-28 -- transaction/rollback when deleting resources from a LDPC -- raised
11:07:02 <trackbot> http://www.w3.org/2012/ldp/track/issues/28
11:07:11 <Arnaud> ack timbl
11:07:11 <Zakim> timbl_, you wanted to say that from client app point ov view, it is important to keep local data in sync with data in the LDP server, so please restrict results to "Your delete of
11:07:14 <Zakim> ... the  container worked" or "failed completely" but not "may be in any half-deleted state".
11:07:21 <Arnaud> q?
11:07:43 <bblfish> q+
11:07:53 <krp> for the server to guarantee it can fully delete the container and all members, it must restrict the members it accepts to those it would be able to delete?
11:08:10 <Arnaud> ack oberger
11:08:10 <Zakim> oberger, you wanted to ask if there's something wrong with 5.6.1
11:08:16 <timbl_> kip, the server never :"accep[ts" members -- it creates them
11:08:29 <timbl_> so it can control them
11:08:40 <nmihindu> oberger: Is there an issue with 5.6.1 ?
11:08:41 <timbl_> s/kip/krp/
11:08:48 <sandro> earlier mostly-resolved:  <cygri> PROPOSAL: State in the spec that composition doesn't mean that the resources must reside in the same hierarchy or even on the same server
11:09:24 <timbl_> but point out that the resources will all be under the direct control of the same system.
11:09:25 <Arnaud> ack bblfish
11:09:42 <nmihindu> Arnaud: should we amend the proposal ?
11:09:48 <timbl_>  PROPOSAL: State in the spec that composition doesn't mean that the resources must reside in the same hierarchy or even on the same server but point out that the resources will all be under the direct control of the same system.
11:09:50 <Zakim> +[IPcaller]
11:10:14 <nmihindu> bblfish: we can add an example to the spec with a concrete case
11:10:18 <sandro> PROPOSAL: State in the spec that composition doesn't mean that the resources must reside in the same hierarchy or even have the same "host" part of the URL.    Try to have example that motivates it, such as livejournal cross-origin issue
11:10:23 <betehess> can we just decouple creation from deletion for now?
11:10:57 <SteveBattle> My concern is that I'm a fan of human readable URIs - which kind of implies hierarchy <vhttp://www.jenitennison.com/blog/node/114>
11:11:24 <nmihindu> krp: direct control potion of timl is important
11:11:46 <sandro> SteveBattle, I think that's a Best Practice, not something we should mandate.
11:12:28 <SteveBattle> Yeah - I'm happy with that 'MUST' in the proposal.
11:12:44 <sandro> +1 cygri since the server had the power to CREATE the resource, presumably it has the power to DELETE it.
11:12:55 <Arnaud> q?
11:13:02 <nmihindu> cygri: if the container has the power to create a resource probably it has the power to delete it
11:13:10 <cygri> How about this: Composition means that resources are created only through the container; however it doesn't mean that the resources must reside in the same hierarchy or even on the same server
11:13:29 <sandro> +1
11:13:33 <BartvanLeeuwen> +1
11:13:35 <rgarcia> +1
11:13:36 <SteveBattle> +1
11:13:48 <JohnArwe> hold on, the server creates it under the access controls of the authenticated user.  ditto delete.  those are different requests, potentially coming from different principals, and there may be method-level permissions involved.
11:13:57 <ericP> +1
11:14:00 <svillata> +1
11:14:22 <SteveS> +1
11:14:23 <krp> the "direct control" part is more important for deletion. I think Tim's point was that we make deleting a (strong) container clear by putting the requirement on the server to control those resources - and it controls that from creation
11:14:31 <nmihindu> Ashok: do you need to follow up it with the information about delete ?
11:14:37 <SteveBattle> Just checking - does that mean 'subordinate resources'. We can still create stand-alone resources some other way - yes?
11:14:52 <timbl_> The server takes on responsibility for being able to efficiently delete the new resource when the container is deleted.
11:15:09 <nmihindu> cygri: The follow up with create a long discussion it is better to stick with this
11:15:18 <cygri> JohnArwe, absolutely anything can fail due to access control
11:15:23 <nmihindu> s/with/will
11:15:29 <cygri> PROPOSAL: Composition means that resources are created only through the container; however it doesn't mean that the resources must reside in the same hierarchy or even on the same server
11:15:32 <cygri> +1
11:15:34 <sandro> +1
11:15:34 <rgarcia> +1
11:15:35 <ericP> +1
11:15:36 <svillata> +1
11:15:36 <nmihindu> +1
11:15:36 <Arnaud> +1
11:15:37 <SteveS> +1
11:15:37 <betehess> +1
11:15:37 <BartvanLeeuwen> +1
11:15:37 <krp> +1
11:15:39 <bblfish> +1
11:15:40 <oberger> +1
11:15:43 <ahaller2> +1
11:15:44 <SteveBattle> ???
11:15:47 <JohnArwe> +1
11:15:48 <antonis> +1
11:15:49 <timbl_> +1
11:15:53 <Yves> =0
11:16:15 <SteveBattle> +1
11:16:25 <nmihindu> SteveBattle: is this just taking about the resources created by a container ?
11:16:35 <nmihindu> cygri: yes
11:16:54 <SteveBattle> "resources are created ONLY through the container" - what's the scope of that?
11:17:04 <JohnArwe> I do seem to remember existing text saying that containers were allowed to add members through other means outside the spec, so "created only through the container" MIGHT conflict with that.
11:17:28 <nmihindu> RESOLVED: Composition means that resources are created only through the container; however it doesn't mean that the resources must reside in the same hierarchy or even on the same server
11:17:35 <jonathandray> jonathandray has joined #ldp
11:18:09 <nmihindu> Arnaud: Do we need to change the text in 5.6.1 in the spec ?
11:18:12 <SteveBattle> Can we have minuted clarification of that last point?
11:18:42 <nmihindu> SteveS: yes, it is an editorial change.
11:18:43 <Arnaud> q?
11:18:43 <cygri> q?
11:18:47 <sandro> looks like 5.6.1 turns int o a MUST.         Deleting a container means MUST delete containted resources.
11:18:53 <rgarcia> +q to remark JohnArwe 's comment
11:19:32 <bblfish> q+
11:19:45 <bblfish> MUST does not mean it cannot fail
11:19:48 <krp> +q to say some of these are errors
11:20:20 <nmihindu> cygri: MUST not be possible for various reasons, we can change it to SHOULD or say the server must notify if something bad happens
11:20:30 <betehess> but these things are already defined in HTTP!
11:20:52 <rgarcia> +1 to indicate that the server must notify the client when something wrong happens
11:21:13 <nmihindu> Arnaud: it is common case for many issues, though it is a MUST, errors can happen
11:22:00 <cygri> summary: Long discussion of (strong) composition versus (weak) aggregation. The group resolves that LDP containers are for strong aggregation. The question what exactly this means for deletion of containers remains unresolved. Various uses for weak aggregation, such as paging, ordering and linking/unlinking resources, are to be treated as separate issues. ACTIONs are taken to raise and refactor some issues accordingly. The group mostly rejects the idea that composition requires URIs to be in a hierarchy.
12:35:00 <cygri> scribenick: rgarcia
12:35:00 <cygri> TOPIC: Agenda Adjustments
12:35:47 <RRSAgent> RRSAgent has joined #ldp
12:35:47 <RRSAgent> logging to http://www.w3.org/2012/11/02-ldp-irc
12:36:01 <betehess> RRSAgent, please make minutes
12:36:01 <RRSAgent> I have made the request to generate http://www.w3.org/2012/11/02-ldp-minutes.html betehess
12:36:49 <rgarcia> q?
12:36:52 <nmihindu> nmihindu has joined #ldp
12:36:57 <sandro> RRSAgent, pointer?
12:36:57 <RRSAgent> See http://www.w3.org/2012/11/02-ldp-irc#T12-36-57
12:37:12 <cygri> cygri has joined #ldp
12:37:59 <timbl> timbl has joined #ldp
12:38:03 <Arnaud> zakim, who's on the phone
12:38:03 <Zakim> I don't understand 'who's on the phone', Arnaud
12:38:13 <Arnaud> zakim, who's on the phone?
12:38:13 <Zakim> sorry, Arnaud, I don't know what conference this is
12:38:14 <Zakim> On IRC I see timbl, cygri, nmihindu, RRSAgent, Zakim, svillata, bblfish, rgarcia, AndyS, betehess, oberger, webr3, melvster, krp, antonis, jmvanel, Yves, sandro, Arnaud, ericP,
12:38:14 <Zakim> ... ahaller2, JohnArwe, jonathandray, LeeF
12:38:31 <sandro> zakim, this is ldp
12:38:31 <Zakim> ok, sandro; that matches SW_LDP()2:30AM
12:38:39 <sandro> zakim, who is here?
12:38:39 <Zakim> On the phone I see St_Clair_3B
12:38:40 <Zakim> On IRC I see timbl, cygri, nmihindu, RRSAgent, Zakim, svillata, bblfish, rgarcia, AndyS, betehess, oberger, webr3, melvster, krp, antonis, jmvanel, Yves, sandro, Arnaud, ericP,
12:38:40 <Zakim> ... ahaller2, JohnArwe, jonathandray, LeeF
12:38:50 <SteveS> SteveS has joined #ldp
12:39:15 <rgarcia> scribenick rgarcia
12:39:50 <rgarcia> Arnaud: let's talk about the agenda this afternoon
12:40:56 <ivan> ivan has joined #ldp
12:41:16 <rgarcia> ... we should add a deadline for the ACL note
12:41:35 <rgarcia> s/deadline/timeline/
#12:42:43 <sandro> topic: Test Suite & Validator
#12:42:59 <sandro> s/topic: Test Suite & Validator//
12:43:15 <Ashok_Malhotra> Ashok_Malhotra has joined #ldp
12:43:35 <cygri> q+
12:44:05 <develD> develD has joined #ldp
12:44:11 <Arnaud> ack cygri
12:44:36 <BartvanLeeuwen> BartvanLeeuwen has joined #ldp
12:44:58 <rgarcia> cygri: Also talk about deployment guide (non normative)
12:45:09 <oberger> hi BartvanLeeuwen, the discussion on the test suite should start soon, FWIW
12:45:32 <oberger> BartvanLeeuwen, sorry... confusion with ruben (again ;)
12:46:02 <rgarcia> ... and about potential implementors
12:46:52 <rgarcia> ... such as client libraries or user interfaces
12:47:13 <sandro> timbl: Does Tabulator count as this kind of Generic LDP Client?
12:47:35 <betehess> q+
12:47:43 <betehess> q-
12:48:33 <bblfish> rww giup http://www.w3.org/community/rww/wiki/TPAC-Lyon-2012
12:48:37 <cygri> http://www.w3.org/community/rww/
12:48:43 <Arnaud> q?
12:48:43 <bblfish> we mentioned this group here in our meeting
12:49:01 <sandro> tim: Yes, Tabulator should be a generic LDP client, and you may find other clients in the RWW CG
12:49:25 <bblfish> q+
12:48:00 <rgarcia> TOPIC: Timeline for Access Control Note
12:49:29 <rgarcia> Arnaud: Ashok, how long it will take you for a first draft?
12:49:36 <rgarcia> Ashok_Malhotra: One week
12:49:41 <cygri> http://www.w3.org/2012/ldp/wiki/AccessControl
12:50:12 <trackbot> trackbot has joined #ldp
12:50:24 <bblfish> q-
12:50:42 <bblfish> q+
12:50:49 <rgarcia> Ashok_Malhotra: By November 12th the draft will be ready for review
12:50:52 <timbl> Ashok, can you do it in http://www.w3.org/wiki/WebAccessControl ?
12:51:08 <oberger> rgarcia, I think it's ready for additions, not review ?
12:51:12 <ericP> q+ to point out that Chris Bizer has already provided the reading list: http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/
12:51:45 <cygri> (Ashok_Malhotra has an action https://www.w3.org/2012/ldp/track/actions/21 )
12:51:54 <JohnArwe> JohnArwe has joined #ldp
12:52:04 <timbl> Pk, I see http://www.w3.org/wiki/WebAccessControl is not covered by the group patent policy
12:52:09 <sandro> action-21?
12:52:09 <trackbot> ACTION-21 -- Ashok Malhotra to set up wiki page on Access Control -- due 2012-11-12 -- OPEN
12:52:09 <trackbot> http://www.w3.org/2012/ldp/track/actions/21
12:52:12 <nandana> nandana has joined #ldp
12:52:17 <rgarcia> s/ By November 12th the draft will be ready for review/ By November 12th the draft will be ready for additions/
12:52:39 <bblfish>  perhaps we just see how people feel about it
12:52:58 <svillata> svillata has joined #ldp
12:53:02 <rgarcia> Arnaud: Let's not predict now the effort needed for working in the document
12:53:28 <cygri> ericP, the ChrisB resource guide hasn't been updated since 2005
12:53:31 <timbl> http://www.w3.org/wiki/WebAccessControl
12:53:35 <rgarcia> timbl: There is already a document about the topic
12:53:39 <oberger> I think we should proceed and revise this on 12th
12:54:02 <rgarcia> Arnaud: That is a solution, we need use cases and requirements
12:54:50 <tpacbot> tpacbot has joined #ldp
12:55:57 <rgarcia> ericP: Taking a look at Bizer's document we can inspire
12:56:52 <Arnaud> q?
12:56:52 <rgarcia> Arnaud: By November 26th people must have added their contributions to the draft and we decide what to do  next
12:57:01 <bblfish> q-
12:57:14 <Arnaud> ack eric
12:57:14 <Zakim> ericP, you wanted to point out that Chris Bizer has already provided the reading list: http://www4.wiwiss.fu-berlin.de/bizer/SWTSGuide/
12:58:00 <cygri> summary: A draft will be available by November 12th, and the WG has until November 26th to submit material for an initial draft.
12:58:20 <rgarcia> TOPIC: Client Implementations
12:58:32 <bblfish> q+
12:58:48 <betehess> q+
12:59:07 <rgarcia> cygri: There are plenty of servers and some people have/will develop clients
12:59:25 <SteveS> q+
12:59:37 <ericP> q+ to ask about domain-specific implementations
12:59:37 <Arnaud> ack bblfish
12:59:38 <rgarcia> sandro: The validator can do the client part in some ways
12:59:52 <sandro> q+
13:00:28 <rgarcia> bblfish: Has an implementation with WebID and ACL
13:00:38 <rgarcia> cygri: But that is different
13:01:28 <rgarcia> Arnaud: what's the point of the client? Testing?
13:01:41 <rgarcia> cygri: No, something more useful than simple CURL
13:01:43 <oberger> cygri, needs a GUI ?
13:01:45 <bblfish> Tabulator is good for that
13:02:07 <bblfish> http://dig.csail.mit.edu/2005/ajar/ajaw/tab.html
13:02:40 <rgarcia> cygri: Something like Tabulator, but wants to know if there will me more similar implementations
13:02:48 <Arnaud> ack bete
13:03:24 <rgarcia> betehess: for me, a client is a Java library
13:03:25 <timbl> Three things:
13:03:29 <Arnaud> ack steves
13:03:47 <timbl> 1) Fancy UI client like Tabulator
13:03:56 <timbl> 2) Cmmon client library
13:04:01 <rgarcia> SteveS: Need some reference implementations
13:04:04 <timbl> 3) Test suite for testing srevers
13:04:06 <betehess> s/ a client is a Java library/ a client is a primarily a Java or Scala library, not that much a Web interface/
13:04:10 <cygri> timbl++
13:04:23 <betehess> yes, what timbl said
13:04:26 <sandro> q?
13:04:28 <bblfish> Tabulator https://github.com/linkeddata/tabulator
13:04:31 <BartvanLeeuwen> timbl++
13:04:40 <Arnaud> ack eric
13:04:40 <Zakim> ericP, you wanted to ask about domain-specific implementations
13:05:15 <sandro> 4) server validator (implements the server test suite)
13:05:19 <betehess> what I'm talking about https://github.com/w3c/banana-rdf/blob/master/rdf-test-suite/src/main/scala/LinkedDataStoreTest.scala#L58
13:05:20 <rgarcia> ericP: there will be generic clients and application-specific clients
13:05:42 <Arnaud> ack sandro
13:06:12 <SteveS> We have a set of domain specific (ALM/tool integration) at http://eclipse.org/lyo
13:06:22 <betehess> sounds likes the current UC&R that we currently have
13:06:33 <oberger> SteveS, yes, we have ;)
13:06:40 <betehess> s/likes/like/
13:06:52 <rgarcia> sandro: The Graphstore protocol is being tested using NL test cases and there is a validator, it could be useful here
13:07:30 <betehess> Arnaud, what do you want to know about implementation???
13:07:52 <bblfish> where?
13:08:05 <rgarcia> Arnaud: we already have said that we will create a web page for implementations
13:08:10 <BartvanLeeuwen> http://www.w3.org/2012/ldp/wiki/Implementations
13:08:31 <oberger> q+
13:08:50 <svillata> svillata has joined #ldp
13:08:57 <rgarcia> SteveS: Talks about Eclipse Lyo
13:09:01 <oberger> eclipse.org/lyo/
13:09:11 <oberger> http://eclipse.org/lyo/
13:09:21 <betehess> shouldn't we list here implementations that at least claim to comply with LDP? (not only linked data)
13:09:33 <bblfish> is this page public?
13:09:42 <rgarcia> ... includes frontends (ej. to bugzilla)
13:09:44 <bblfish> q+
13:09:58 <rgarcia> Arnaud: it is based on OSLC
13:10:06 <nmihindu> nmihindu has joined #ldp
13:10:11 <Arnaud> ack oberger
13:10:20 <MacTed> MacTed has joined #ldp
13:10:40 <rgarcia> oberger: we contributed a Perl library to Lyo (a REST client compatible with OSLC)
13:10:45 <Arnaud> ack bblfish
13:11:31 <rgarcia> bblfish: Implementations from outside the group could be added to the implementations page
13:11:34 <betehess> q+
13:11:56 <oberger> we could use ADMS.SW to fill the page
13:11:58 <rgarcia> sandro: is drafting the minimal content that implementations should provide
13:12:24 <oberger> https://joinup.ec.europa.eu/asset/adms_foss/release/release100
13:12:53 <oberger> BartvanLeeuwen, you too ?
13:13:13 <rgarcia> Arnaud: Are we going to exercise control on the web page?
13:13:16 <Arnaud> q?
13:13:34 <Arnaud> ack bete
13:14:01 <rgarcia> betehess: in favour of opening the page but leaving clear that they are LDP implementation
13:14:08 <Zakim> +Yves
13:14:10 <rgarcia> s/implementation/implementations/
13:15:21 <oberger> q+ to propose to rename the page to Implementation_plans
13:15:44 <betehess>  /me wouldn't open the page before we have a test suite
13:16:11 <Arnaud> ack oberger
13:16:11 <Zakim> oberger, you wanted to propose to rename the page to Implementation_plans
13:16:26 <rgarcia> oberger: proposes to rename the page to Implementation_plans
13:16:44 <timbl> Note http://www.w3.org/community/rww/wiki/Main_Page codes not have a pointer to LDP
13:16:50 <MacTed> MacTed has changed the topic to: Linked Data Platform WG -- current agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_2_-_November_2nd  --  please do add yourself, e.g., [ present+ Alexandre_Bertails ] (NO_SPACE)
13:17:11 <rgarcia> ACTION: sandro to create a new page open to anyone with a W3C account in the W3C wiki
13:17:11 <trackbot> Created ACTION-24 - Create a new page open to anyone with a W3C account in the W3C wiki [on Sandro Hawke - due 2012-11-09].
13:17:33 <timbl> ericp, http://www.w3.org/community/rww/wiki/Main_Page
13:17:45 <sandro> sandro has changed the topic to: Linked Data Platform WG -- current agenda: http://www.w3.org/2012/ldp/wiki/F2F1#Day_2_-_November_2nd  --
13:17:54 <Arnaud> q?
13:18:29 <timbl> See also: http://www.w3.org/wiki/EditingData has list of implementations
13:18:00 <cygri> summary: The group identifies different kinds of client implementation, and Sandro takes an action to start a public wiki page to collect implementations.
13:18:23 <rgarcia> TOPIC: Test Suite and Validator
13:18:50 <betehess> q+
13:18:53 <rgarcia> Arnaud: what are we going to do in this respect?
13:19:23 <cygri> q+
13:19:27 <svillata> svillata has joined #ldp
13:19:31 <rgarcia> Arnaud: the examples in the UCR could be included in the test suite
13:19:50 <rgarcia> timbl: Every time you take a decision, you create a test case for the resolution
13:19:52 <Arnaud> ack bete
13:20:47 <nmihindu> q+ to say BDD would be a nice way to document the test cases
13:20:59 <rgarcia> betehess: agrees to start with UCR examples
13:21:07 <Arnaud> ack cygri
13:21:23 <oberger> betehess: start with a curl based suite
13:21:41 <rgarcia> cygri: it would be worth to have tests in an automatable format
13:21:49 <betehess> q+
13:21:57 <nmihindu> BDD frameworks - http://behaviour-driven.org/Implementations
13:22:44 <oberger> SteveS, ^ ?
13:22:47 <Arnaud> ack nmihindu
13:22:47 <Zakim> nmihindu, you wanted to say BDD would be a nice way to document the test cases
13:23:26 <rgarcia> nmihindu: test specification + automation can be done using BDD (Behaviour Driven Development)
13:23:34 <Arnaud> ack bete
13:23:38 <rgarcia> ... we are doing that and can provide more information
13:23:58 <rgarcia> betehess: proposes to have a first version by some weeks
13:24:51 <svillata_> svillata_ has joined #ldp
13:24:51 <rgarcia> Arnaud: do we have a test harness that we want to adopt?
13:24:54 <cygri> q+ to mention http://www.w3.org/TR/HTTP-in-RDF10/
13:25:17 <bblfish> q+
13:25:19 <SteveS> q+
13:25:41 <oberger> nmihindu, any URL for BDD ?
13:25:53 <Arnaud> ack cygri
13:25:53 <Zakim> cygri, you wanted to mention http://www.w3.org/TR/HTTP-in-RDF10/
13:25:59 <betehess> http://en.wikipedia.org/wiki/Behavior-driven_development
13:26:14 <rgarcia> cygri: HTTP-in-RDF may be relevant for this
13:26:35 <rgarcia> ... for HTTP interactions in test cases
13:26:35 <bblfish> q?
13:27:03 <rgarcia> betehess: that is not enough for our case
13:27:08 <bblfish> there is also http://www.w3.org/TR/2002/WD-EARL10-20021206/
13:27:10 <rgarcia> ... and is not an implementation
13:27:11 <svillata> svillata has joined #ldp
13:27:19 <bblfish> sorry there is this: http://www.w3.org/TR/EARL10/
13:27:25 <ericP> note that EARL is used for the SPARQL tests
#13:27:36 <rgarcia> +q
13:27:39 <Arnaud> ack bblfish
#13:27:52 <ericP> q+ rgarcia
13:28:13 <rgarcia> bblfish: we should make things clear
13:28:17 <Arnaud> ack steves
13:28:28 <betehess> http://en.wikipedia.org/wiki/Behavior-driven_development
13:28:44 <oberger> q+
13:28:46 <betehess> can people take 2 minutes to read the wikipedia page please?
13:29:07 <rgarcia> SteveS: need requirements for any of these frameworks
13:29:08 <ericP> SteveS, we had XSLT to pull tests out of the SPARQL spec
13:29:45 <Arnaud> ack rgarcia
13:30:08 <Arnaud> ack oberger
13:30:23 <rgarcia> rgarcia: specification and implementation can be solved through different approaches
13:30:26 <rgarcia> oberger:
13:30:48 <betehess> q+ to advocate for executable requirements with BDD
13:31:03 <cygri> q+
13:31:05 <rgarcia> oberger: add anchors (URIs) for requirements to enable traceability
13:31:12 <Arnaud> ack bete
13:31:12 <Zakim> betehess, you wanted to advocate for executable requirements with BDD
13:31:17 <SteveS> ericP, we did same thing with CDF specs…pointer to xslt?
13:31:29 <ericP> oof
13:31:33 <rgarcia> betehess: requirements and test suite should be the same and in executable format
13:31:57 <Arnaud> ack cygri
13:32:15 <nmihindu> q+
13:32:56 <oberger> q+ to ask whether we have an open source framework reasonably usable that implements BDD (based on EARL ?)
13:33:32 <rgarcia> timbl: A lot of people associates tests with parts of the specifications
13:33:52 <cygri> example of UC&R: http://www.w3.org/TR/rdf-dawg-uc/
13:34:56 <svillata> svillata has joined #ldp
13:35:41 <cygri> q+
13:36:30 <Arnaud> ack nmihindu
13:36:38 <svillata> q?
13:36:49 <bblfish> q+
13:37:05 <bblfish> q-
13:37:21 <Arnaud> ack oberger
13:37:21 <Zakim> oberger, you wanted to ask whether we have an open source framework reasonably usable that implements BDD (based on EARL ?)
13:37:28 <rgarcia> nmihindu: there can be a 1-to-many correspondence between requirements and tests that ensures traceability
13:37:41 <rgarcia> oberger: Anyone knows of a concrete framework?
13:37:48 <betehess> I already offered time and energy there
13:38:03 <Arnaud> ack cygri
13:38:20 <nmihindu> there are a lot of open source tools http://behaviour-driven.org/Implementations
13:38:23 <oberger> Eclipse Lyo may provide some elements
13:38:32 <betehess> if 2 weeks is ok as schedule for the WG, I volunteer
13:38:33 <oberger> based on JUnit ?
13:38:40 <rgarcia> cygri: people in the group should provide examples so we can choose
13:39:07 <rgarcia> ericP: I already have a test
13:39:39 <ericP> https://github.com/ericprud/SWObjects/blob/sparql11/tests/test_LDP.cpp#L500
13:39:59 <bblfish> q+
13:40:13 <Arnaud> ack bblfish
13:40:29 <rgarcia> bblfish: some specs use EARL for describing tests
13:40:44 <rgarcia> ... then people implements tests in the way that they want
13:41:05 <rgarcia> q+
13:41:07 <SteveS> oberger, like the opportunity to do something better if possible but Lyo is a fallback
13:41:21 <oberger> SteveS, yes, thinking bottom->up
13:41:39 <bblfish> http://www.w3.org/TR/EARL10/]
13:41:42 <bblfish> http://www.w3.org/TR/EARL10/
13:42:48 <rgarcia> q-
13:43:15 <bblfish> q+
13:43:15 <oberger> q+ to ask about validator vs test suite ?
13:43:27 <Arnaud> ack bblfish
13:43:30 <rgarcia> Arnaud: are we in progress in the test suite or the validator?
13:43:48 <rgarcia> bblfish: we can start with some specifications
13:43:55 <antonis> \me has to leave for the airport soon
13:43:58 <rgarcia> and later think about the tools
13:44:10 <Arnaud> ack oberger
13:44:10 <Zakim> oberger, you wanted to ask about validator vs test suite ?
13:44:13 <rgarcia> s/and later think about the tools/...and later think about the tools/
13:44:44 <rgarcia> oberger: how would be the validator?
13:44:55 <jonathandray> from antonis: flying from geneva
13:45:14 <bblfish> so my point was to write out in english some clear cases of the rules we need to prove . Perhaps we have those allready. That would help work out what expressivity we need.
13:46:28 <rgarcia> sandro: a validator could be hosted (or proxied) through the W3C
13:46:54 <oberger> sandro: the validator could be validating either servers or clients
13:47:10 <rgarcia> Arnaud: All the options are open at this point
#13:47:21 <cygri> webr3, no
13:47:23 <sandro> sandro: ... in theory, but I don't know how to do clients
13:48:19 <betehess> q+
13:48:19 <rgarcia> q+
13:48:19 <bblfish> q+
13:48:28 <Arnaud> ack bete
13:48:37 <rgarcia> betehess: I have some concrete proposals
13:49:01 <cygri> betehess++
13:49:13 <betehess> s/I have some/I'd rather go with/
13:49:25 <Arnaud> ack rgarcia
13:49:29 <bblfish> q-
13:49:37 <betehess> we have test cases already
13:50:00 <svillata> svillata has joined #ldp
13:50:37 <rgarcia> rgarcia: we can go step by step: test definition -> test machine readable -> test automatable
13:50:44 <rgarcia> oberger: or the other way around
13:52:24 <oberger> betehess, do you commit to an action ?
13:53:17 <rgarcia> ACTION: betehess to create a wiki page for the test suite and validator proposals
13:53:17 <trackbot> Created ACTION-25 - Create a wiki page for the test suite and validator proposals [on Alexandre Bertails - due 2012-11-09].
13:54:06 <oberger> sandro, could you provide more details about a REST validator ?
13:54:09 <rgarcia> ... the deadline for this is November 26th
13:54:19 <oberger> around the same timeframe...
13:54:19 <cygri> summary: The group discusses Behaviour-Driven Development, EARL, the HTTP-in-RDF vocabulary, options for hosting a validator, and other aspects of testing and validation. Alexandre will set up a wiki page where proposals are to be collected; deadline for proposals is November 26th.
13:54:20 <cygri> TOPIC: LDP Implementations Wiki Page
13:54:30 <sandro> q+ to talk about implemntations page
13:54:40 <sandro> http://www.w3.org/wiki/LDP_Implementations
13:54:42 <Arnaud> ack sandro
13:54:42 <Zakim> sandro, you wanted to talk about implemntations page
13:54:57 <cygri> q+ to suggest LDP/Implementations
13:55:04 <cygri> q-
13:55:12 <cygri> sandro, why not /wiki/LDP/Implementations
13:55:34 <webr3> do implementations need to be full implementations, as I'm 95% sure I don't need or want LDPC's
13:55:50 <cygri> (assuming that /wiki/LDP will get content about our work at some point)
13:57:07 <Zakim> +??P6
13:57:24 <deiu> deiu has joined #ldp
13:57:50 <oberger> hi deiu too
13:57:51 <cygri> zakim, ??P6 is webr3
13:57:51 <Zakim> +webr3; got it
13:58:23 <cygri> http://www.w3.org/2012/ldp/track/actions/open
13:59:17 <oberger> timbl, is there a DOAP for tabulator ?
13:59:30 <sandro> close action-24
13:59:30 <trackbot> ACTION-24 Create a new page open to anyone with a W3C account in the W3C wiki closed
13:59:53 <Arnaud> q?
14:00:00 <cygri> summary: Sandro claims victory on his action to create an LDP Implementations wiki page.
14:00:46 <oberger> sandro, maybe adding a DOAP field ?
14:01:42 <rgarcia> Arnaud: we won't add test cases for authentication
14:02:37 <sandro> oberger, is there a problem just linking via the Project Homepage URL?
14:02:29 <rgarcia> topic: Use Cases and Requirements Document
14:03:17 <rgarcia> Arnaud: is not comfortable with the current state of UC&R
14:03:22 <oberger> sandro, DOAP contains doap:homepage, but I think the 2 are better than only doap for non-semweb people
14:03:56 <svillata> svillata has joined #ldp
14:04:03 <sandro> oberger, I'm saying that given the project homepage, which is on this wiki page, people (and machines) should be able to find the DOAP information.
14:04:22 <SteveS> http://lists.w3.org/Archives/Public/public-ldp-wg/2012Nov/0010.html
14:04:46 <oberger> sandro, in principle, yes, that'd be great if all project homepages did :-)
14:05:39 <rgarcia> Arnaud: talks about the proposed timeline for the UC&R document
14:05:58 <rgarcia> ... http://lists.w3.org/Archives/Public/public-ldp-wg/2012Nov/0010.html
14:06:06 <sandro> oberger, I'm just saying that if they're not going to do that, there's not much we can do about.    We *can* make our fancy test-results-driven implementation report get the project info via DOAP.   That'd be cool.
14:06:23 <svillata_> svillata_ has joined #ldp
14:06:53 <rgarcia> Arnaud: there are blocker issues and non-blocking issues
14:07:23 <oberger> are we distinguishing user stories from use cases here ?
14:08:14 <svillata> svillata has joined #ldp
14:08:52 <oberger> q+ to say that user stories are redundant and use cases insufficiant
14:08:55 <rgarcia> Arnaud: we should agree on which part of the current document should go into the final UC&R document
14:09:06 <Arnaud> ack oberger
14:09:06 <Zakim> oberger, you wanted to say that user stories are redundant and use cases insufficiant
14:09:25 <rgarcia> oberger: there are too many user stories and too redundant
14:10:43 <Ashok_Malhotra> q+
14:11:03 <timbl> Sandro, http://tabulator.org/wiki/annnotation/usefulinc.com/ns/doap#id1351864713218
14:11:41 <cygri> q+
14:11:52 <ericP> PROPOSAL: start with teh current UC&R document, giving the editor time to mark pieces as intended to be moved to another document, with an SOTD indicating that plan
14:11:53 <Arnaud> ack ashok
14:12:02 <rgarcia> Arnaud: we should not ignore what we have already done
14:12:41 <rgarcia> Ashok_Malhotra: put requirements on top and in each of them put links to user stories
14:12:41 <Arnaud> ack cygri
14:12:50 <rgarcia> cygri: ...
14:13:21 <rgarcia> ericP: I have drafted a new document structure
14:13:32 <ahaller2> s/teh/the/
14:14:49 <Zakim> -webr3
14:15:40 <cygri> q+
14:15:43 <rgarcia> Arnaud: Let's keep the current document as the basis for the work
14:16:12 <oberger> q+ to suggest a matrix that points from the UC -> US
14:17:08 <cygri> q?
14:17:25 <rgarcia> oberger: to add pointers from the use cases to the user stories
14:17:35 <Arnaud> ack cygri
14:17:46 <rgarcia> s/to add pointers from the use cases to the user stories/proposes to add pointers from the use cases to the user stories/
14:17:51 <betehess> cygri++
14:18:08 <rgarcia> cygri: Let's take a look to the UC&R documents in other W3C specifications
14:18:08 <SteveS> q+
14:18:15 <oberger> q-
14:18:38 <Arnaud> ack steve
14:19:09 <rgarcia> SteveS: we already talked about this in the past
14:20:23 <rgarcia> Arnaud: Maybe we didn't review in detail the document when we should have
14:20:44 <Arnaud> s/document/proposed template/
14:22:29 <betehess> Arnaud, we set a deadline (Nov 26th) for testing proposals. we didn't say if it was the same for validators/validation as well
14:22:29 <oberger> cygri, do you have concrete pointers for better documents ?
14:23:35 <betehess> q+
14:24:20 <betehess> q-
14:25:08 <rgarcia> Arnaud: we can keep the current timeline in the email
14:26:53 <SteveS> Orignal UCR proposal structure http://lists.w3.org/Archives/Public/public-ldp-wg/2012Aug/0137.html
14:26:59 <rgarcia> ... or to shift those dates
14:28:19 <rgarcia> SteveS: will talk with Steve Battle and give feedback on the document
14:28:26 <SteveS> http://www.w3.org/TR/powder-use-cases/
14:32:26 <rgarcia> Arnaud: Let's try to figure out how to structure the document
14:32:54 <rgarcia> ... or someone takes the action to do so
14:34:56 <rgarcia> cygri: there is some confusion on the use of the term "requirement" in the document
14:35:20 <Ashok_Malhotra> q+
14:35:32 <Arnaud> ack ashok
14:36:15 <bblfish> q+
14:36:41 <bblfish> q-
14:40:43 <SteveS> PROPOSAL: Work to get UCR closer to what is found in docs like http://www.w3.org/TR/powder-use-cases/, moving other parts to primer, test cases, spec analysis, etc
14:40:58 <cygri> +1
14:41:02 <rgarcia> +1
14:41:03 <Arnaud> +1
14:41:06 <krp> +1
14:41:06 <betehess> +1
14:41:08 <oberger> +1
14:41:17 <SteveS> +1
14:41:31 <svillata> +1
14:41:45 <rgarcia> Arnaud: in November 12th we will discuss the timeline
14:42:15 <nmihindu> +1
14:42:37 <rgarcia> RESOLVED: Work to get the UC&R document closer to what is found in docs like http://www.w3.org/TR/powder-use-cases/, moving other parts to Primer, Test Cases, spec analysis, etc.
14:42:41 <oberger> in the meantime, we don't create issues about the UCR
14:43:28 <rgarcia> cygri: it is better to wait until having the new document before adding more content
14:44:02 <rgarcia> ... people can still send things to mailing list
14:44:30 <cygri> summary: The group tries without much success to sort out the terminology around User Stories, Use Cases, Requirements and so on. Consensus is that the current UC&R draft is too detailed, and some material should be moved to Test Cases.
14:45:36 <Zakim> -Yves
14:53:37 <timbl> timbl has joined #ldp
14:56:30 <deiu> deiu has joined #ldp
15:05:38 <oberger> cygri, http://www-public.telecom-sudparis.eu/~berger_o/weblog/2012/08/29/debian-package-tracking-system-now-produces-rdf-description-of-source-packages/
15:05:47 <oberger> it's not the paper but has links
15:09:35 <BartvanLeeuwen> BartvanLeeuwen has joined #ldp
15:10:07 <SteveS> SteveS has joined #ldp
15:10:58 <nmihindu> nmihindu has joined #ldp
15:11:39 <svillata> svillata has joined #ldp
15:12:21 <betehess> http://www.w3.org/mid/5093E294.2040005@w3.org Gathering Testing and Validation proposals
15:12:22 <SteveS> Scribe: SteveS
15:12:41 <SteveS> Topic: Primer
15:12:52 <oberger> q+ to propose looking at http://patterns.dataincubator.org/book/ somehow
15:13:57 <SteveS> Arnaud: been talking about it a bunch, need a editor/driver for it, who is the target audience, scope of document
15:14:55 <sandro> q+
15:15:14 <Arnaud> ack oberger
15:15:14 <Zakim> oberger, you wanted to propose looking at http://patterns.dataincubator.org/book/ somehow
15:15:17 <SteveS> …should it be focused for developers or whatever
15:15:53 <Arnaud> ack sandro
15:15:59 <SteveS> oberger: consider looking at http://patterns.dataincubator.org/book/ as motivation for something for spec and primer
15:16:39 <SteveS> sandro: main spec is really for experts, many people need something different as an on-ramp to the spec and technology
15:16:49 <SteveS> PROPOSAL: we should do a primer
15:17:00 <cygri> q+
15:17:27 <bblfish> bblfish has joined #ldp
15:17:41 <oberger> q+
15:17:42 <SteveS> Arnaud: don't expect to provide all background but some good intro, the primer might be good as this
15:17:46 <Arnaud> ack cygri
15:17:49 <SteveS> …find a good primer example to follow
15:19:01 <SteveS> cygri: wonder if w3c note for primer is worthwhile, maybe some other place would be good, something very focused
15:19:22 <SteveS> q+
15:20:18 <SteveS> ….primer may be enough but should have supporting and more live document
15:20:30 <Arnaud> ack oberger
15:20:33 <Ashok_Malhotra> q+
15:20:42 <SteveS> Arnaud: another options may make sense
15:20:57 <betehess> sandro, Doug said explicitly during the AC that they were focusing on client (browser) technologies
15:21:00 <sandro> sandro: what about webplatform.org for the primer?    I don't know if it's a good fit.
15:21:09 <SteveS> sandro: could use webplatform.org as well
15:21:32 <Arnaud> ack steve
15:21:33 <SteveS> oberger: be good to have the primer that is executable
15:22:01 <betehess> q+
15:22:15 <SteveS> ack me
15:22:15 <Arnaud> ack ashok
15:22:15 <oberger> SteveS, or at least that illustrates examples with the Gui that we need to collaborate on
15:22:46 <oberger> http://www.webplatform.org/
15:23:19 <oberger> BartvanLeeuwen, you want to q+ ?
15:23:21 <oberger> q?
15:23:30 <SteveS> Ashok_Malhotra: RDF not part of webplatform.org yet, need someone to drive it
15:23:51 <Arnaud> ack bete
15:24:08 <BartvanLeeuwen> oberger, well I don't have dialin :)
15:24:29 <sandro> q+
15:24:32 <oberger> BartvanLeeuwen, condelances
15:24:41 <SteveS> betehess: wonder if it is too soon to talk about this, we could possibly doing something at webplatform.org
15:24:44 <Arnaud> ack sandro
15:25:18 <SteveS> sandro: suggest we don't figure out where it ends up, just that we do one and evolve it to where it might be
15:25:57 <oberger> should we have a blog to start drafting "articles" that could end-up in a primer ?
15:26:04 <SteveS> Arnaud: not sure we should rush into it but plan on it, not getting in way of near-term deliverables
15:26:22 <SteveS> maybe we should have http://LinkedDataPlatform.org
15:26:56 <SteveS> sandro: be good to have a set of materials for various clients
15:26:58 <cygri> q+
15:26:59 <oberger> SteveS, it's there isn't it ?
15:27:27 <SteveS> ahaller2: be good to have purpose built for certain audiences and from the wg
15:27:36 <betehess> also worried to ask people to review too many different documents
15:28:21 <ivan> q+
15:28:29 <Arnaud> ack cygri
15:28:38 <SteveS> Arnaud: worry that if published at webplatform.org that it doesn't show that is endorsed by the wg just some authors
15:29:04 <deiu> deiu has joined #ldp
15:29:40 <SteveS> cygri: need it to help server implementers and various client applications, so the purpose built client apps may have certain needs
15:30:28 <Arnaud> ack ivan
15:30:49 <SteveS> oberger: asks who went to LD for devs with javascript, may need focused for them
15:31:46 <SteveS> ivan: suggest all SemanticWeb WGs produce primers, even if the primer only good for 2 years it still would be extremely valuable
15:32:56 <betehess> q+
15:33:54 <SteveS> Arnaud: think spec is best for server side implementers and primer is for developers
15:34:59 <SteveS> oberger: need to make sure we treat full community client and server developers are equally important
15:35:21 <Arnaud> ack bete
15:35:28 <SteveS> …we often have to talk to community of various existing web service technologies
15:36:35 <SteveS> betehess: wants to be able to users of client sdk and application, that they would get enough on the concepts and overview of LDP to help them out
15:38:33 <SteveS> Arnaud: since spec touches on client and server
15:38:40 <nmihindu> agrees with betehess. Most of the time implementations of the specs are the middle-ware providers and I expect most of the developers will be using LDP libraries to build LDP applications.
15:39:14 <SteveS> oberger and SteveS agree to help move primer along and consider who wants to really drive/own it laterd
15:39:30 <cygri> summary: Discussion of purpose and audience of Primer. Olivier and SteveS agree to help move the Primer along and consider who wants to really drive/own it later.
15:39:52 <cygri> cygri has joined #ldp
15:40:01 <SteveS> TOPIC: Deployment Guide
15:40:26 <oberger> thx BartvanLeeuwen ;-)
15:40:32 <SteveS> BartvanLeeuwen, saw it from before, thanks
15:41:07 <BartvanLeeuwen> thx for the confirmation
15:41:15 <SteveS> cygri: some guidance on how things are deployed in a common way in that it is probably not a MUST level spec
15:42:21 <betehess> q+
15:42:32 <SteveS> …proposal to have a separate document to say what is a good idea if you impl a client and server, possibly move some out of the spec to this document
15:42:48 <Arnaud> ack bete
15:42:55 <SteveS> Ashok_Malhotra: you could also reference this from the spec
15:43:55 <betehess> q+
15:44:42 <oberger> architectural best practices ?
15:44:46 <Arnaud> ack bete
15:45:12 <SteveS> SteveS: details on deployment guide like what Tim called client-to-client section?
15:45:16 <sandro> +1 cygri lets have an LDP Best Practices spec which can include things like suggested datatypes and vocabularies, to maximize interoperability and reuse.
15:45:35 <SteveS> cygri: yes like this and overall guide on using LDP
15:45:59 <SteveS> betehess: agree that be good to follow this overall guideline
15:46:05 <oberger> q+
15:46:35 <Arnaud> ack oberger
15:47:10 <betehess>  /me notes that this kind of document would make the main spec a lot lighter
15:47:40 <SteveS> oberger: spec includes words about best practices and anti-patterns, suggest that we tweak the text on this
15:49:57 <betehess> q+
15:50:50 <Arnaud> ack bete
15:51:27 <SteveS> Arnaud: don't want to commit too much wg time to more docs that don't have owners
15:51:29 <deiu> deiu has joined #ldp
15:52:01 <betehess> q+
15:52:22 <Arnaud> ack bete
15:52:33 <SteveS> oberger: be good to have some expert focus on the primer or such material, instead too much focus on spec
15:52:52 <cygri> q+
15:53:26 <deiu> deiu has joined #ldp
15:54:03 <Arnaud> ack cygri
15:54:18 <SteveS> betehess: need to focus on charter deliverables, be good to start with wiki to gather some of this, use it for education and then make it more formal
15:54:26 <oberger> deiu, we're almost done here... too late ;)
15:55:07 <SteveS> cygri: be happy to create a wiki page for the deployment guide
15:55:43 <SteveS> Arnaud: possible to create task force if we need it, people can go off and do it and don't want to proposal it
15:56:00 <SteveS> …keep it informal to begin with it and have cygri be lead maintainer of it
15:56:00 <betehess> q+
15:56:37 <Arnaud> ack bete
15:56:40 <cygri> ACTION: cygri to create wiki page for Deployment Guide
15:56:40 <trackbot> Created ACTION-26 - Create wiki page for Deployment Guide [on Richard Cyganiak - due 2012-11-09].
15:57:12 <oberger> BartvanLeeuwen, that has been dicsussed a bit
15:57:19 <Arnaud> bart, no the primer is limited in scope to the spec
15:57:31 <Arnaud> the guide would go beyond into best practices
15:57:39 <SteveS> betehess: perhaps we can suggest same for those of interest of access control, best practices in addition if makes sense
15:58:58 <Arnaud> q?
15:59:00 <cygri> summary: Richard takes an action to set up a wiki page to collect deployment best practices and anti-patterns. Time permitting, this might become a WG Note.
15:59:00 <cygri> TOPIC: Wrap-up
#15:59:10 <SteveS> Arnaud: Let's call this done
15:59:22 <SteveS> Arnaud: Let's call this done
15:59:49 <SteveS> sandro: applauds Arnaud for chairing for 2 days (room agrees) \o/
16:00:06 <oberger> all applause
16:00:14 <oberger> BartvanLeeuwen, :-)
16:00:21 <BartvanLeeuwen> people start staring at you if you do that
16:01:13 <oberger> we applaude each-other
16:01:23 <SteveS> Arnaud: meeting closed
16:01:55 <SteveS> Arnaud: will have telecom on Monday, 5 November for informal review
16:02:33 <SteveS> sandro: suggest people to review and fixup minutes by editable wiki
16:03:10 <SteveS> Arnaud: demos irc logs, editable wiki, ...
# SPECIAL MARKER FOR CHATSYNC.  DO NOT EDIT THIS LINE OR BELOW.  SRCLINESUSED=00001328