14:59:37 <RRSAgent> RRSAgent has joined #ldp
14:59:37 <RRSAgent> logging to http://www.w3.org/2014/03/03-ldp-irc
14:59:39 <trackbot> RRSAgent, make logs public
14:59:39 <Zakim> Zakim has joined #ldp
14:59:41 <trackbot> Zakim, this will be LDP
14:59:41 <Zakim> ok, trackbot; I see SW_LDP()10:00AM scheduled to start in 1 minute
14:59:42 <trackbot> Meeting: Linked Data Platform (LDP) Working Group Teleconference
14:59:42 <trackbot> Date: 03 March 2014
15:00:24 <Zakim> SW_LDP()10:00AM has now started
15:00:32 <Zakim> +Sandro
15:00:40 <Zakim> +Arnaud
15:00:44 <Zakim> +OpenLink_Software
15:01:05 <TallTed> Zakim, OpenLink_Software is temporarily me
15:01:05 <Zakim> +TallTed; got it
15:01:10 <TallTed> Zakim, mute me
15:01:10 <Zakim> TallTed should now be muted
15:01:25 <JohnArwe> JohnArwe has joined #ldp
15:01:55 <Zakim> +JohnArwe
15:02:02 <SteveS> SteveS has joined #ldp
15:02:38 <Zakim> +Steve_Speicher
15:02:59 <SteveS> zakim, Steve_Speicher is me
15:02:59 <Zakim> +SteveS; got it
15:03:33 <Ashok> Ashok has joined #ldp
15:03:48 <Zakim> +bblfish
15:04:05 <bblfish_> jo
15:04:42 <Zakim> +Roger
15:05:02 <roger> roger has joined #ldp
15:05:30 <bblfish> Status Quo: http://www.youtube.com/watch?v=t-HBdlFmTuY
15:05:47 <Arnaud> zakim, who's on the phone?
15:05:47 <Zakim> On the phone I see Sandro, Arnaud, TallTed (muted), JohnArwe, SteveS, bblfish, Roger
15:06:23 <JohnArwe> if you want me to scribe, I can.  not really caught up after pulse, so pretty useless otherwise.
15:06:37 <JohnArwe> scribe: JohnArwe
15:07:03 <JohnArwe> Topic: approval of last meeting's minutes
15:07:16 <JohnArwe> minutes at http://www.w3.org/2013/meeting/ldp/2014-02-24
15:07:21 <Zakim> +Ashok_Malhotra
15:07:43 <JohnArwe> minutes approved unanimously
15:08:17 <JohnArwe> Meet in +1 week; perhaps after that, we can revert to 60 min calls.
15:08:20 <JohnArwe> Topic: actions
15:08:37 <JohnArwe> none pending review
15:08:57 <JohnArwe> no claims of progress on open actions
15:09:13 <Zakim> +??P25
15:09:26 <nmihindu> Zakim, ??P25 is me
15:09:26 <Zakim> +nmihindu; got it
15:09:35 <nmihindu> Zakim, mute me
15:09:35 <Zakim> nmihindu should now be muted
15:09:56 <JohnArwe> Topic: Container classes hierarchy
15:11:14 <JohnArwe> Arnaud: Based on Sandro's questions as he took a post-RDF-1.1 fresh look at LDP.  Given that we're out of charter time, looked at what we can publish now and build on for the future, even if current text is recognized as imperfect.
15:11:31 <JohnArwe> ...hoping we can agree to move to Last Call (2)
15:12:17 <bblfish> A lot of this is explained in https://www.w3.org/2012/ldp/wiki/ContainerHierarchy
15:12:19 <JohnArwe> Arnaud: summarizes recent events to rearrange class hierarchy
15:14:20 <JohnArwe> ... given doubts from some about future of direct/indirect, don't necessarily want indirect as base of the hierarchy
15:14:48 <JohnArwe> ... Henry's wiki page examines several aspects of this
15:16:00 <bblfish> q+
15:16:56 <JohnArwe> PROPOSED: revert decision of 17 February 2014 on class hierarchy of containers and go back to a flat hierarchy to avoid dependency and give more flexibility for the future ... corresponding to the "minimal consensus position" diagram on Henry's wiki page.
15:17:04 <Arnaud> ack bblfish
15:20:31 <SteveS> q+
15:20:54 <Arnaud> ack steves
15:20:58 <sandro> q+
15:21:15 <JohnArwe> Henry summarizes contents of his wiki page; good to have ldp:Container separate from ldp:IndirectContainer; the 3 children of ldp:Container is a logical consequence of the spec as it is now.  Using OWL to assert the relationships would help the OWL community tell us if we have a problem.  Henry found 1 problem doing this... BC does not say that it must have insertedContentRelation = MemberSubject
15:22:34 <JohnArwe> SteveSpeicher: consequence of this, as Arnaud noted, is defining membership etc and then saying "but they're not here (in the desc of BC)".  I found the same missing rule on BCs, there's a note in the editor's draft; wanted to verify understanding of the hierarchy with WG given the flux.
15:23:00 <JohnArwe> ... concerns about confusion for new readers of the spec.
15:24:05 <Arnaud> ack sandro
15:24:15 <JohnArwe> Arnaud: no doubt that you can define BC/DC as restrictions of IC.  I'm trying to find way to accommodate Sandro's point/concern about DC/IC and future-proofing the spec until we have see what implementations actually do in practice.
15:26:13 <JohnArwe> Sandro: 2 very different things we're trying to do w/ these names.  1=pedagogy, editorial.  2= rel=type header with is a commitment.  It's #2 that we have to be very careful about changing in the future.  I only really care about #2 for Last Call; #1 we can change until Rec.
15:26:17 <bblfish> q+
15:26:40 <Arnaud> ack bblfish
15:26:54 <JohnArwe> ... I'm not seeing any protocol difference between rel=type ldp:Container and ldp:BasicContainer.  Is there one?
15:27:34 <JohnArwe> ... Conclusion is that there's no value in using ldp:Container in rel=type right now.
15:28:37 <JohnArwe> Henry: if set Z (on wiki page) is empty, true.  we'd have to change rel=type to use one of IC, DC, BC.
15:29:07 <JohnArwe> Sandro: propose changing the rel=type header ... never=ldp:Container, must be one of IC, DC, or BC.
15:29:36 <sandro> for now ---- save ldp:Container for the day we have something meaningful for it to be.
15:29:54 <JohnArwe> Arnaud: What will make spec easiest to read; Sandro's email said he did not mind complexity, but only deal with it if/when you need it.
15:30:40 <bblfish> q+
15:30:53 <Arnaud> ack bblfish
15:30:53 <JohnArwe> ... as Steve said, unfortunate that we (now) need introduce membership etc even if they don't care about BC's.  if we flatten things, someone who comes in knowing that they Only Care About BC's can never have to read membership.
15:31:34 <JohnArwe> Henry: another email, could introduce LDP binding rule, and all of these could be described that way.  not sure if that can help in modeling.
15:31:45 <Arnaud> PROPOSED: revert decision of 17 February 2014 on class hierarchy of containers and go back to a flat hierarchy to avoid dependency and give more flexibility for the future ... corresponding to the "minimal consensus position" diagram on Henry's wiki page.
15:32:04 <sandro> +1
15:32:05 <SteveS> +1
15:32:11 <bblfish> +1
15:32:36 <roger> +0.5
15:32:43 <JohnArwe> +1
15:32:48 <TallTed> +1
15:32:50 <nmihindu> +1
15:33:09 <Arnaud> RESOLVED: revert decision of 17 February 2014 on class hierarchy of containers and go back to a flat hierarchy to avoid dependency and give more flexibility for the future ... corresponding to the "minimal consensus position" diagram on Henry's wiki page.
15:33:26 <bblfish> I suppose we should worry that trackbot left
15:34:18 <sandro> PROPOSED: We take out the requirement for rel=type ldp:Container; for now folks have to use one of the three types of container we define.
15:34:44 <bblfish> +1
15:34:49 <sandro> +1
15:35:06 <JohnArwe> +1
15:35:08 <TallTed> +1
15:35:11 <sandro> Arnaud: You put the type in the container that you're actually using
15:35:25 <JohnArwe> regrets: cody, pierre-antoine
15:35:38 <roger> +1
15:35:44 <SteveS> +.83
15:35:46 <Ashok> +1
15:35:54 <sandro> RESOLVED: We take out the requirement for rel=type ldp:Container; for now folks have to use one of the three types of container we define.
15:36:18 <JohnArwe> Topic: Non-member-property/EmptyContainer resource
15:38:10 <Zakim> -Roger
15:38:13 <bblfish> q+
15:38:25 <TallTed> Zakim, unmute me
15:38:25 <Zakim> TallTed should no longer be muted
15:38:30 <sandro>     ).
15:38:30 <sandro> Empty-container triples
15:38:30 <sandro>     The portion of an LDPC's state that would be present when the container is empty. Currently
15:38:46 <SteveS> q+
15:40:04 <Arnaud> ack bblfish
15:41:30 <sandro> q+
15:42:06 <JohnArwe> Henry: we might have it backwards; proposed index in email, looking for that.
15:42:33 <Arnaud> ack steves
15:42:46 <JohnArwe> Arnaud: clarifying - the "empty container" resource is a strict subset of the full container's triples
15:43:07 <TallTed> I think the linkable-resource-containing-metadata-describing-the-container-itself is important.
15:43:07 <TallTed> I fear using "empty container" for this will mean it's often interpreted exactly so -- that it *applies* only to empty containers (even with the clear definition otherwise), so I think the following editorial consideration also important.
15:43:48 <JohnArwe> SteveS: what we've implemented in the past mimics the old non-member properties.  same thing you'd get asking for prefer-empty.
15:43:50 <Arnaud> ack sandro
15:43:59 <bblfish> This was my proposal e-mail http://lists.w3.org/Archives/Public/public-ldp-wg/2014Mar/0005.html
15:44:17 <JohnArwe> Sandro: so posting to that meta would have same effect as posting to the container?  SS: yes
15:44:53 <JohnArwe> ... like Henry's proposal, much better to have membership/containment relations off to the side but may be too big a change for the group to make now.
15:45:06 <JohnArwe> s/... like/... I like/
15:45:27 <JohnArwe> Arnaud: TimBL feedback was to reduce number of gets, not increase it.
15:45:42 <TallTed> +1 sandro
15:45:50 <JohnArwe> Sandro: often we'd really like membership to be separate, that's why we have this prefer hack.
15:46:08 <JohnArwe> Arnaud: can see it both ways.
15:46:37 <JohnArwe> Henry: index doesn't stop people from putting all the data in the same container, just lets those who wish to move it aside.
15:46:54 <JohnArwe> ...we don't have to stop the mixing, it's just a bad practice.
15:47:51 <JohnArwe> Sandro: rel=contents links to TOC, which corresponds to containment triples.  could use that instead of ldp:index.  of course we need to give it a URI.
15:48:33 <JohnArwe> Arnaud: we could expand it later, right?  today's prefer header allows filtering of what you want to see, we can always expand on that in the future by adding new links to resources that return subsets.
15:49:15 <JohnArwe> Sandro: so it's OK if a BC leaves out ldp:contains triples?  no requirement to materialize them, surprising.
15:50:13 <JohnArwe> ... I think that's a problem, but it's soluble via another flag.
15:51:08 <JohnArwe> Sandro: Henry, any problem doing both?
15:52:32 <sandro> For TimBL's problem: how about Prefer: merge-related type=contents
15:52:52 <sandro> q+
15:53:06 <JohnArwe> Henry: one seems wrong way around, b/c of conditional post.  the argument was it's a link to a view and that's where the triples are, look there to see the contents.  I suppose that's fine for people who want to mix it all together, and the other (rel=contents) is for better-architected content that supports conditional post.  Plus all these other things that you can't patch/put to then in fact you can't in effect put/patch.
15:53:07 <Zakim> +EricP
15:53:57 <sandro> For TimBL's problem (avoiding round trips): how about Prefer: merge-related rel=contents
15:54:08 <JohnArwe> Arnaud: 2 sides of same coin; preferred design will be based on app considerations.  Want proposals that people will not object to, and that won't corner us.  We could stay with what's in the spec, and invent-new moving forward.
15:54:24 <SteveS> why not use DirectContainer and use  ldp:memberResource <>, ldp:memberRelation my:index ?
15:55:04 <JohnArwe> Henry: you can leave spec as it is now for people that have these use cases; if you take use case for patching membership or other important metadata seriously, need to be able to ...
15:55:41 <JohnArwe> Sandro: Henry wants post to both resources to MUST be equivalent.
15:57:12 <ericP> q+ to say that we have an ear at IETF on monday
15:57:18 <JohnArwe> Sandro: ...discussion... in LC can leave it as is, server does what it wants, we can define preferences like merge-related later so it's .... (ok enough?)   right now I'm thinking we don't need to do anything, b/c spec is so mushy about what's required.
15:57:21 <sandro> q-
15:57:24 <Arnaud> ack sandro
15:57:37 <Arnaud> ack ericP
15:57:37 <Zakim> ericP, you wanted to say that we have an ear at IETF on monday
15:58:35 <Arnaud> : We take out the requirement for rel=type ldp:Container; for now folks have to use one of the three types of container we define.
15:58:50 <Arnaud> sorry, wrong copy/paste
15:59:32 <sandro> 6.2.1.1 Each Linked Data Platform Container MUST also be a conforming Linked Data Platform RDF Source. LDP clients MAY infer the following triple: whose subject is ldp:Container, whose predicate is rdfs:subClassOf, and whose object is ldp:RDFSource, but there is no requirement to materialize this triple in the LDPC representation.
16:02:16 <sandro> 6.2.3.2 When a successful HTTP POST request to an LDPC results in the creation of an LDPR, a containmemt triple MUST be added to the state of LDPC.
16:03:35 <sandro> sandro: This stops us from doing what Henry wants, unless one uses a different kind of container.
16:04:17 <JohnArwe> discussion about whether or not ldp:contains triples are required
16:08:10 <sandro> sandro: Preference-Applied and rel=type are the two ways the server tells the client what it's commiting to do, that it's implementing some LDP rules.
16:09:06 <JohnArwe> henry: if etags are scoped by preferences, implies posts need same prefs (to update) ... should this be in impl guidance?
16:10:38 <JohnArwe> Arnaud: all I'm asking is, do we want to add a link rel=meta (or similar) that gives you back the same triples as prefer=empty-container does
16:10:51 <JohnArwe> ericp: not seeing immediate use cases for this
16:12:14 <JohnArwe> Arnaud: Sandro, you ok to leave it as is?  Since the 1/27 lost the separate link, could add that back.
16:12:23 <Arnaud> q?
16:12:27 <TallTed> structurally, I think we do need the addressable metadata resource.  editorially, I don't like "emptyContainer" as its name.  "containerMetadata"?  "containerDefinition"?
16:12:42 <JohnArwe> Sandro: URI of container should be = to URI of metadata, as Henry said.  So ok to leave it as is.
16:13:22 <sandro> sandro: Structurally, I prefer segmenting off the containment and/or membership triples, rather than segmenting off the configuration/metadata.   I think...
16:13:28 <SteveS> TallTed, I'm not married to the name...so I'm open
16:13:43 <JohnArwe> Arnaud: so we leave it as is for now.
16:13:47 <JohnArwe> Topic: spec status
16:15:32 <JohnArwe> SteveS: made some changes to separate out concepts we talked about already.  inserted 1 level in each section, with kinds of resources/containers, and their rel.  reworked intro container section text to reflect containment better.  changed it to talk about things in terms of extension rather than restriction.
16:16:16 <JohnArwe> ...Henry already section where we talk about BC membership before that term has been introduced.  Have editor's notes to move things around to fix that.
16:17:23 <JohnArwe> Arnaud: strongly agree with Sandro to save each dollop of complexity until it's needed.
16:18:02 <JohnArwe> Henry: BC = only thing client needs to be bound by is what it posts; others have extra consequences.
16:19:00 <JohnArwe> Arnaud: hoping we can agree to go to last call and let editors continue working on readability in that/later stages.  don't want to hold up the entire process on readability changes.
16:19:32 <bblfish> cool
16:20:53 <JohnArwe> SteveS: separate client section, looks odd in TOC.  all the rules deal with RDF sources.  does it make sense to fold them back in to general section vs keeping them here?
16:21:16 <sandro> q+
16:21:24 <JohnArwe> Arnaud: strong opinion fold back in; odd section.
16:21:35 <TallTed> appendix *may* be too removed.  a clear cross-link from this body section to the appendix might resolve that.  a sidenote/footnote/whatever that says "as will become clearer in section ___, this is the same as that with these attribute(s) and value(s)"
16:21:36 <Arnaud> ack sandro
16:21:47 <JohnArwe> sandro: agree completely
16:21:49 <bblfish> I can't see the Client Section
16:21:52 <bblfish> Where is it?
16:22:02 <bblfish> ah ye
16:22:07 <bblfish> Section 4.1
16:22:15 <bblfish> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpclient
16:23:17 <SteveS> A conforming LDP client is a conforming HTTP client [HTTP11] that follows the rules defined by LDP in section 4. Linked Data Platform Clients.
16:26:12 <Arnaud> PROPOSED: Publish specification as LC2, with 3 week comment period
16:26:18 <SteveS> +1
16:26:20 <sandro> +1
16:26:21 <ericP> +1
16:26:31 <Ashok> +1
16:26:37 <TallTed> +1
16:26:40 <JohnArwe> RESOLVED: fold client section into others, in effect removing it
16:26:50 <bblfish> sounds ok. I suppose this is a good point to get some feedback. There was a lot of improvement.
16:27:04 <JohnArwe> +1
16:27:20 <bblfish> I don't know what LastCall means technically
16:27:25 <sandro> sandro: (I consider all the client rules to be editorial, since they follow logically from constrains on servers.  They are much better stated as constraints on server.)
16:28:00 <bblfish> Ah ok
16:28:04 <bblfish> good
16:28:13 <bblfish> +0.9999
16:28:18 <Arnaud> RESOLVED: Publish specification as LC2, with 3 week comment period
16:28:28 <sandro> sandro: Last Call means the design is stable.  We can't change it significiantly without another LC.
16:29:14 <ericP> topic: 2xx at IETF
16:32:27 <JohnArwe> ericp runs through the arguments he plans to present
16:33:07 <JohnArwe> Arnaud: next up - paging - don't want that to lag too far behind.  then test suite (gates CR/etc) and other companion documents.
16:33:10 <Zakim> -nmihindu
16:33:11 <Zakim> -JohnArwe
16:33:14 <Zakim> -TallTed
16:33:15 <Zakim> -SteveS
16:33:17 <Zakim> -Arnaud
16:33:18 <Zakim> -bblfish
16:33:18 <Zakim> -Sandro
16:33:19 <Zakim> -EricP
16:33:23 <Zakim> -Ashok_Malhotra
16:33:25 <Zakim> SW_LDP()10:00AM has ended
16:33:25 <Zakim> Attendees were Sandro, Arnaud, TallTed, JohnArwe, SteveS, bblfish, Roger, Ashok_Malhotra, nmihindu, EricP
16:33:55 <JohnArwe> JohnArwe has left #ldp
16:35:11 <trackbot> trackbot has joined #ldp
17:55:30 <deiu> deiu has joined #ldp
18:30:35 <Zakim> Zakim has left #ldp
19:43:15 <jmvanel> jmvanel has joined #ldp
19:55:40 <bblfish> bblfish has joined #ldp
20:32:05 <stevebattle15> stevebattle15 has joined #ldp
20:53:48 <bblfish> bblfish has joined #ldp