edit

Linked Data Platform (LDP) Working Group Teleconference

Minutes of 03 March 2014

Agenda
http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2014.03.03
Seen
Arnaud Le Hors, Ashok Malhotra, Cody Burleson, Eric Prud'hommeaux, Henry Story, John Arwe, Nandana Mihindukulasooriya, Pierre-Antoine Champin, Roger Menday, Sandro Hawke, Steve Battle, Steve Speicher, Ted Thibodeau
Regrets
Cody Burleson, Pierre-Antoine Champin, Steve Battle
Chair
Arnaud Le Hors
Scribe
John Arwe
IRC Log
Original
Resolutions
  1. Minutes of 24 February approved unanimously link
  2. 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. link
  3. 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. link
  4. Fold client section into others, in effect removing it link
  5. Publish specification as LC2, with 3 week comment period link
Topics
14:59:37 <RRSAgent> logging to http://www.w3.org/2014/03/03-ldp-irc

RRSAgent IRC Bot: logging to http://www.w3.org/2014/03/03-ldp-irc

14:59:39 <trackbot> RRSAgent, make logs public

Trackbot IRC Bot: RRSAgent, make logs public

14:59:41 <trackbot> Zakim, this will be LDP

Trackbot IRC Bot: Zakim, this will be LDP

14:59:41 <Zakim> ok, trackbot; I see SW_LDP()10:00AM scheduled to start in 1 minute

Zakim IRC Bot: 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

Zakim IRC Bot: SW_LDP()10:00AM has now started

15:00:32 <Zakim> +Sandro

Zakim IRC Bot: +Sandro

15:00:40 <Zakim> +Arnaud

Zakim IRC Bot: +Arnaud

15:00:44 <Zakim> +OpenLink_Software

Zakim IRC Bot: +OpenLink_Software

15:01:05 <TallTed> Zakim, OpenLink_Software is temporarily me

Ted Thibodeau: Zakim, OpenLink_Software is temporarily me

15:01:05 <Zakim> +TallTed; got it

Zakim IRC Bot: +TallTed; got it

15:01:10 <TallTed> Zakim, mute me

Ted Thibodeau: Zakim, mute me

15:01:10 <Zakim> TallTed should now be muted

Zakim IRC Bot: TallTed should now be muted

15:01:55 <Zakim> +JohnArwe

Zakim IRC Bot: +JohnArwe

15:02:38 <Zakim> +Steve_Speicher

Zakim IRC Bot: +Steve_Speicher

15:02:59 <SteveS> zakim, Steve_Speicher is me

Steve Speicher: zakim, Steve_Speicher is me

15:02:59 <Zakim> +SteveS; got it

Zakim IRC Bot: +SteveS; got it

15:03:48 <Zakim> +bblfish

Zakim IRC Bot: +bblfish

15:04:05 <bblfish_> jo

Henry Story: jo

15:04:42 <Zakim> +Roger

Zakim IRC Bot: +Roger

15:05:30 <bblfish> Status Quo: http://www.youtube.com/watch?v=t-HBdlFmTuY

Henry Story: Status Quo: http://www.youtube.com/watch?v=t-HBdlFmTuY

15:05:47 <Arnaud> zakim, who's on the phone?

Arnaud Le Hors: zakim, who's on the phone?

15:05:47 <Zakim> On the phone I see Sandro, Arnaud, TallTed (muted), JohnArwe, SteveS, bblfish, Roger

Zakim IRC Bot: 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.

John Arwe: if you want me to scribe, I can. not really caught up after pulse, so pretty useless otherwise.

15:06:37 <JohnArwe> scribe: JohnArwe

(Scribe set to John Arwe)

<JohnArwe> chair: Arnaud
<JohnArwe> agenda: http://www.w3.org/2012/ldp/wiki/Meetings:Telecon2014.03.03
15:07:03 <JohnArwe> Topic: Admin

1. Admin

<JohnArwe> PROPOSED: Approval of last meeting's minutes

PROPOSED: Approval of last meeting's minutes

15:07:16 <JohnArwe> minutes at http://www.w3.org/2013/meeting/ldp/2014-02-24

minutes at http://www.w3.org/2013/meeting/ldp/2014-02-24

15:07:21 <Zakim> +Ashok_Malhotra

Zakim IRC Bot: +Ashok_Malhotra

15:07:43 <JohnArwe> RESOLVED: Minutes of 24 February approved unanimously

RESOLVED: Minutes of 24 February approved unanimously

15:08:17 <JohnArwe> Meet in +1 week; perhaps after that, we can revert to 60 min calls.

Meet in +1 week; perhaps after that, we can revert to 60 min calls.

15:08:20 <JohnArwe> Topic: Tracking of actions

2. Tracking of actions

15:08:37 <JohnArwe> none pending review

none pending review

15:08:57 <JohnArwe> no claims of progress on open actions

no claims of progress on open actions

15:09:13 <Zakim> +??P25

Zakim IRC Bot: +??P25

15:09:26 <nmihindu> Zakim, ??P25 is me

Nandana Mihindukulasooriya: Zakim, ??P25 is me

15:09:26 <Zakim> +nmihindu; got it

Zakim IRC Bot: +nmihindu; got it

15:09:35 <nmihindu> Zakim, mute me

Nandana Mihindukulasooriya: Zakim, mute me

15:09:35 <Zakim> nmihindu should now be muted

Zakim IRC Bot: nmihindu should now be muted

15:09:56 <JohnArwe> Topic: Container classes hierarchy

3. 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.

Arnaud Le Hors: 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)

...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

Henry Story: 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

Arnaud Le Hors: 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

... 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

... Henry's wiki page examines several aspects of this

15:16:00 <bblfish> q+

Henry Story: 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.

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

Arnaud Le Hors: ack bblfish

15:20:31 <SteveS> q+

Steve Speicher: q+

15:20:54 <Arnaud> ack steves

Arnaud Le Hors: ack steves

15:20:58 <sandro> q+

Sandro Hawke: 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

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.

Steve Speicher: 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.

... concerns about confusion for new readers of the spec.

15:24:05 <Arnaud> ack sandro

Arnaud Le Hors: 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.

Arnaud Le Hors: 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.

Sandro Hawke: 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+

Henry Story: q+

15:26:40 <Arnaud> ack bblfish

Arnaud Le Hors: ack bblfish

15:26:54 <JohnArwe> ... I'm not seeing any protocol difference between rel=type ldp:Container and ldp:BasicContainer.  Is there one?

... 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.

... 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.

Henry Story: 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.

Sandro Hawke: 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.

Sandro Hawke: 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.

Arnaud Le Hors: 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+

Henry Story: q+

15:30:53 <Arnaud> ack bblfish

Arnaud Le Hors: 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.

... 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.

Henry Story: 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.

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

Sandro Hawke: +1

15:32:05 <SteveS> +1

Steve Speicher: +1

15:32:11 <bblfish> +1

Henry Story: +1

15:32:36 <roger> +0.5

Roger Menday: +0.5

15:32:43 <JohnArwe> +1

+1

15:32:48 <TallTed> +1

Ted Thibodeau: +1

15:32:50 <nmihindu> +1

Nandana Mihindukulasooriya: +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.

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

Henry Story: 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.

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

Henry Story: +1

15:34:49 <sandro> +1

Sandro Hawke: +1

15:35:06 <JohnArwe> +1

+1

15:35:08 <TallTed> +1

Ted Thibodeau: +1

15:35:11 <sandro> Arnaud: You put the type in the container that you're actually using

Arnaud Le Hors: You put the type in the container that you're actually using [ Scribe Assist by Sandro Hawke ]

15:35:25 <JohnArwe> regrets: cody, pierre-antoine, stevebattle
15:35:38 <roger> +1

Roger Menday: +1

15:35:44 <SteveS> +.83

Steve Speicher: +.83

15:35:46 <Ashok> +1

Ashok Malhotra: +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.

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

4. Non-member-property/EmptyContainer resource

15:38:10 <Zakim> -Roger

Zakim IRC Bot: -Roger

15:38:13 <bblfish> q+

Henry Story: q+

15:38:25 <TallTed> Zakim, unmute me

Ted Thibodeau: Zakim, unmute me

15:38:25 <Zakim> TallTed should no longer be muted

Zakim IRC Bot: TallTed should no longer be muted

15:38:30 <sandro>     ).

Sandro Hawke: ).

15:38:30 <sandro> Empty-container triples

Sandro Hawke: Empty-container triples

15:38:30 <sandro>     The portion of an LDPC's state that would be present when the container is empty. Currently

Sandro Hawke: The portion of an LDPC's state that would be present when the container is empty. Currently

15:38:46 <SteveS> q+

Steve Speicher: q+

15:40:04 <Arnaud> ack bblfish

Arnaud Le Hors: ack bblfish

15:41:30 <sandro> q+

Sandro Hawke: q+

15:42:06 <JohnArwe> Henry: we might have it backwards; proposed index in email, looking for that.

Henry Story: we might have it backwards; proposed index in email, looking for that.

15:42:33 <Arnaud> ack steves

Arnaud Le Hors: ack steves

15:42:46 <JohnArwe> Arnaud: clarifying - the "empty container" resource is a strict subset of the full container's triples

Arnaud Le Hors: 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.

Ted Thibodeau: 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.

Ted Thibodeau: 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.

Steve Speicher: 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

Arnaud Le Hors: ack sandro

15:43:59 <bblfish> This was my proposal e-mail http://lists.w3.org/Archives/Public/public-ldp-wg/2014Mar/0005.html

Henry Story: 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

Sandro Hawke: 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.

... I 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.

Arnaud Le Hors: TimBL feedback was to reduce number of gets, not increase it.

15:45:42 <TallTed> +1 sandro

Ted Thibodeau: +1 sandro

15:45:50 <JohnArwe> Sandro: often we'd really like membership to be separate, that's why we have this prefer hack.

Sandro Hawke: 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.

Arnaud Le Hors: 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.

Henry Story: 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.

...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.

Sandro Hawke: 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.

Arnaud Le Hors: 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.

Sandro Hawke: 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.

... I think that's a problem, but it's soluble via another flag.

15:51:08 <JohnArwe> Sandro: Henry, any problem doing both?

Sandro Hawke: Henry, any problem doing both?

15:52:32 <sandro> For TimBL's problem: how about Prefer: merge-related type=contents

Sandro Hawke: For TimBL's problem: how about Prefer: merge-related type=contents

15:52:52 <sandro> q+

Sandro Hawke: 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.

Henry Story: 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

Zakim IRC Bot: +EricP

15:53:57 <sandro> For TimBL's problem (avoiding round trips): how about Prefer: merge-related rel=contents

Sandro Hawke: 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.

Arnaud Le Hors: 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 ?

Steve Speicher: 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 ...

Henry Story: 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.

Sandro Hawke: 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

Eric Prud'hommeaux: 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.

Sandro Hawke: ...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-

Sandro Hawke: q-

15:57:24 <Arnaud> ack sandro

Arnaud Le Hors: ack sandro

15:57:37 <Arnaud> ack ericP

Arnaud Le Hors: ack ericP

15:57:37 <Zakim> ericP, you wanted to say that we have an ear at IETF on monday

Zakim IRC Bot: 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.

Arnaud Le Hors: : 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

Arnaud Le Hors: 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.

Sandro Hawke: 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.

Sandro Hawke: 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.

Sandro Hawke: This stops us from doing what Henry wants, unless one uses a different kind of container. [ Scribe Assist by Sandro Hawke ]

16:04:17 <JohnArwe> discussion about whether or not ldp:contains triples are required

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.

Sandro Hawke: 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. [ Scribe Assist by Sandro Hawke ]

16:09:06 <JohnArwe> henry: if etags are scoped by preferences, implies posts need same prefs (to update) ... should this be in impl guidance?

Henry Story: 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

Arnaud Le Hors: 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

Eric Prud'hommeaux: 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.

Arnaud Le Hors: 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?

Arnaud Le Hors: 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"?

Ted Thibodeau: 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.

Sandro Hawke: 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...

Sandro Hawke: Structurally, I prefer segmenting off the containment and/or membership triples, rather than segmenting off the configuration/metadata. I think... [ Scribe Assist by Sandro Hawke ]

16:13:28 <SteveS> TallTed, I'm not married to the name...so I'm open

Steve Speicher: 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.

Arnaud Le Hors: so we leave it as is for now.

16:13:47 <JohnArwe> Topic: Spec status

5. 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.

Steve Speicher: 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.

...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.

Arnaud Le Hors: 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.

Henry Story: 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.

Arnaud Le Hors: 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

Henry Story: 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?

Steve Speicher: 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+

Sandro Hawke: q+

16:21:24 <JohnArwe> Arnaud: strong opinion fold back in; odd section.

Arnaud Le Hors: 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)"

Ted Thibodeau: 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

Arnaud Le Hors: ack sandro

16:21:47 <JohnArwe> sandro: agree completely

Sandro Hawke: agree completely

16:21:49 <bblfish> I can't see the Client Section

Henry Story: I can't see the Client Section

16:21:52 <bblfish> Where is it?

Henry Story: Where is it?

16:22:02 <bblfish> ah ye

Henry Story: ah ye

16:22:07 <bblfish> Section 4.1

Henry Story: Section 4.1

16:22:15 <bblfish> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpclient

Henry Story: 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.

Steve Speicher: 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:40 <JohnArwe> RESOLVED: Fold client section into others, in effect removing it

RESOLVED: Fold client section into others, in effect removing it

16:26:12 <Arnaud> PROPOSED: Publish specification as LC2, with 3 week comment period

PROPOSED: Publish specification as LC2, with 3 week comment period

16:26:18 <SteveS> +1

Steve Speicher: +1

16:26:20 <sandro> +1

Sandro Hawke: +1

16:26:21 <ericP> +1

Eric Prud'hommeaux: +1

16:26:31 <Ashok> +1

Ashok Malhotra: +1

16:26:37 <TallTed> +1

Ted Thibodeau: +1

16:26:50 <bblfish> sounds ok. I suppose this is a good point to get some feedback. There was a lot of improvement.

Henry Story: sounds ok. I suppose this is a good point to get some feedback. There was a lot of improvement.

16:27:04 <JohnArwe> +1

+1

16:27:20 <bblfish> I don't know what LastCall means technically

Henry Story: 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.)

Sandro Hawke: (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.) [ Scribe Assist by Sandro Hawke ]

16:28:00 <bblfish> Ah ok

Henry Story: Ah ok

16:28:04 <bblfish> good

Henry Story: good

16:28:13 <bblfish> +0.9999

Henry Story: +0.9999

16:28:18 <Arnaud> RESOLVED: Publish specification as LC2, with 3 week comment period

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.

Sandro Hawke: Last Call means the design is stable. We can't change it significiantly without another LC. [ Scribe Assist by Sandro Hawke ]

16:29:14 <ericP> Topic: 2xx at IETF

6. 2xx at IETF

16:32:27 <JohnArwe> ericp runs through the arguments he plans to present

ericp runs through the arguments he plans to present

<JohnArwe> ... if people have use cases they'd like him to present let him know

... if people have use cases they'd like him to present let him know

<JohnArwe> topic: Adjourn

7. Adjourn

16:33:07 <JohnArwe> Arnaud: will check the dates for the F2F still work, we can scale back our call to 1h. next up - paging - don't want that to lag too far behind. then test suite (gates CR/etc) and other companion documents.

Arnaud Le Hors: will check the dates for the F2F still work, we can scale back our call to 1h. 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

Zakim IRC Bot: -nmihindu

16:33:11 <Zakim> -JohnArwe

Zakim IRC Bot: -JohnArwe

16:33:14 <Zakim> -TallTed

Zakim IRC Bot: -TallTed

16:33:15 <Zakim> -SteveS

Zakim IRC Bot: -SteveS

16:33:17 <Zakim> -Arnaud

Zakim IRC Bot: -Arnaud

16:33:18 <Zakim> -bblfish

Zakim IRC Bot: -bblfish

16:33:18 <Zakim> -Sandro

Zakim IRC Bot: -Sandro

16:33:19 <Zakim> -EricP

Zakim IRC Bot: -EricP

16:33:23 <Zakim> -Ashok_Malhotra

Zakim IRC Bot: -Ashok_Malhotra

16:33:25 <Zakim> SW_LDP()10:00AM has ended

Zakim IRC Bot: SW_LDP()10:00AM has ended

16:33:25 <Zakim> Attendees were Sandro, Arnaud, TallTed, JohnArwe, SteveS, bblfish, Roger, Ashok_Malhotra, nmihindu, EricP

Zakim IRC Bot: Attendees were Sandro, Arnaud, TallTed, JohnArwe, SteveS, bblfish, Roger, Ashok_Malhotra, nmihindu, EricP



Formatted by CommonScribe