14:59:56 <RRSAgent> RRSAgent has joined #ldp
14:59:56 <RRSAgent> logging to http://www.w3.org/2014/01/06-ldp-irc
14:59:58 <trackbot> RRSAgent, make logs public
14:59:58 <Zakim> Zakim has joined #ldp
15:00:00 <trackbot> Zakim, this will be LDP
15:00:00 <Zakim> ok, trackbot, I see SW_LDP()10:00AM already started
15:00:01 <trackbot> Meeting: Linked Data Platform (LDP) Working Group Teleconference
15:00:01 <trackbot> Date: 06 January 2014
15:00:06 <Zakim> +??P5
15:00:09 <Zakim> +Ashok_Malhotra
15:00:14 <pchampin> zakim, ??P5 is me
15:00:15 <Zakim> +pchampin; got it
15:01:00 <Zakim> +Arnaud
15:01:18 <Zakim> +[IBM]
15:01:31 <SteveS> Zakim, [IBM] is me
15:01:31 <Zakim> +SteveS; got it
15:02:37 <Zakim> +Roger
15:02:44 <Zakim> +Alexandre
15:02:44 <roger> roger has joined #ldp
15:02:55 <Zakim> +JohnArwe
15:02:56 <JohnArwe> JohnArwe has joined #ldp
15:03:05 <Zakim> -Alexandre
15:03:07 <Zakim> +OpenLink_Software
15:03:13 <TallTed> Zakim, OpenLink_Software is temporarily me
15:03:13 <Zakim> +TallTed; got it
15:03:15 <TallTed> Zakim, mute me
15:03:15 <Zakim> TallTed should now be muted
15:03:19 <JohnArwe> almighty zakim seems tired today
15:03:26 <JohnArwe> I hear nothing
15:03:35 <JohnArwe> now I hear Arnaud
15:03:48 <JohnArwe> question is, which state is preferred ;-)
15:04:15 <Arnaud> zakim, who's on the phone?
15:04:15 <Zakim> On the phone I see +1.214.537.aaaa, Sandro, pchampin, Ashok_Malhotra, Arnaud, SteveS, Roger, JohnArwe, TallTed (muted)
15:04:17 <Zakim> +Alexandre
15:04:27 <codyburleson> +Cody
15:04:31 <bblfish_> bblfish_ has joined #ldp
15:04:47 <codyburleson> Cody here; dunno how to add to Zakim
15:05:41 <Zakim> +bblfish
15:05:42 <Zakim> -Alexandre
15:05:56 <bblfish_> hi
15:07:05 <bblfish_> ah yes, Sebastien also had an issue with his little laptop. I think it's a Galaxy S4 too - that's the one that comes with Linux pre-installed right?
15:07:09 <Arnaud> zakim, who's on the phone?
15:07:09 <Zakim> On the phone I see +1.214.537.aaaa, Sandro, pchampin, Ashok_Malhotra, Arnaud, SteveS, Roger, JohnArwe, TallTed (muted), bblfish
15:07:47 <Arnaud> zakim, aaaa is cody
15:07:49 <Zakim> +cody; got it
15:08:35 <JohnArwe> Scribe: JohnArwe
15:08:43 <betehess> also, I'm deeply sorry towards JohnArwe, couldn't/didn't take time to answer http://lists.w3.org/Archives/Public/public-ldp-wg/2013Dec/0076.html ...
15:09:07 <JohnArwe> Topic: approve Dec 16 minutes
15:09:59 <JohnArwe> Resolution: Dec 16 minutes approved without objection
15:10:09 <Arnaud> http://www.w3.org/2013/meeting/ldp/2013-12-16
15:10:15 <JohnArwe> Topic: Actions
15:10:40 <Zakim> +Alexandre
15:10:45 <JohnArwe> Next meeting Mon next week, resuming weekly, 90 minutes until we get to LC 2
15:12:41 <JohnArwe> http://www.w3.org/2012/ldp/track/actions/122 see note
15:13:22 <JohnArwe> http://www.w3.org/2012/ldp/track/actions/119 was pretty simple
15:14:51 <JohnArwe> Resolution: Arnaud will close the 2 actions above
15:15:04 <JohnArwe> Cody: I closed one on Best Practices
15:15:20 <JohnArwe> Arnaud: hope to get spec done soon and turn full attn to other docs
15:15:24 <JohnArwe> Topic: Paging
15:16:35 <JohnArwe> TimBL responded to our response to his LC comments, he thinks the 200 solution "there be dragons"
15:16:48 <JohnArwe> TimBL email at http://lists.w3.org/Archives/Public/public-ldp-comments/2013Dec/0000.html
15:18:42 <Ashok> q+
15:19:42 <JohnArwe> Arnaud summarizes options/history, convergence issues if we define at w3c now and run it in ietf later.
15:19:50 <Arnaud> ack Ashok
15:20:24 <JohnArwe> Ashok: if we defined 209 would help other wgs too.  could we work with anyone from those other wgs to move this along?
15:20:40 <SteveS> FYI, not exactly what we are talking about but found this TAG-57 http://www.w3.org/2001/tag/awwsw/issue57/20120202/#status-code
15:22:18 <JohnArwe> Arnaud: anyone could use this, that's one reason TimBL thought it a good idea to define (and was hoping we'd finally be the ones to do it, instead of punting to "someone else").  No other natural owner, aside from IETF.  TimBL raised it with TAG, initial response before holidays was "why do you need this".
15:24:42 <JohnArwe> Not asking for a decision today; let TAG discussion proceed for a while.  Last we talked in this WG, we seemed mostly ok with reverting to 303 in LDP.  Depending on how likely it seems that someone else will take this on, we might choose differently.  Obviously we don't want TimBL raising this at LC2.
15:24:55 <JohnArwe> Topic: issue-92
15:25:24 <JohnArwe> issue-92?
15:25:24 <trackbot> issue-92 -- Change rel=type to rel=profile for client introspection of interaction model -- raised
15:25:24 <trackbot> http://www.w3.org/2012/ldp/track/issues/92
15:26:47 <SteveS> FYI URLs in Data recommends rel=profile for document properties used within data http://www.w3.org/TR/urls-in-data/#locating-property-documentation
15:26:50 <JohnArwe> profile is defined in RFC 6906 at http://tools.ietf.org/html/rfc6906#section-3.1
15:27:25 <bblfish_> q+
15:27:33 <SteveS> q+
15:27:44 <Arnaud> ack bblfish
15:28:57 <JohnArwe> bblfish: disagrees with the argument that type is wrong
15:29:18 <JohnArwe> ...just now sent email to list
15:29:39 <Arnaud> ack SteveS
15:30:10 <JohnArwe> I can tell you Henry that I round-tripped with Erik W (the RFC author) and he thought using profile this way was reasonable.
15:30:49 <betehess> was rel=profile deployed in other specs/products?
15:30:59 <bblfish> profile, seems to be very syntactic http://tools.ietf.org/html/rfc6906#section-3.1
15:32:18 <Arnaud> http://www.w3.org/2013/meeting/ldp/2013-12-16#Issue_91
15:32:32 <JohnArwe> @betehess, I don't know of any products that it's deployed in.  It's Informational RFC in IETF, which Erik explained is usually what they do now for something that sounds mostly-reasonable but is not currently widely deployed.
15:33:02 <betehess> makes sense
15:33:34 <JohnArwe> ... the urls-in-data link SS provided has this, since I know you're not hearing the conv well: 4.4 Locating Property Documentation
15:33:34 <JohnArwe> The previous sections have discussed how important it is to have documentation that includes information about how URLs used within data should be interpreted and specifically whether properties within the data apply to the content found at a URL or to something that content describes. This documentation should be published somewhere such that it's possible for those developers to find it. Possible routes for doing this explicitly include:
15:33:34 <JohnArwe>     if the data is provided through a protocol that supports it, such as through HTTP, by explicitly indicating the media type of the data, and registering that media type such that documentation can be found for it through the IANA media type registry
15:33:35 <JohnArwe>     if the media type is generic (such as application/json), by providing supplementary documentation through a profile link relationship, for example within a HTTP Link header
15:33:35 <JohnArwe>     embedding links to the documentation within the data itself, for example through a resolvable XML namespace or @xsi:schemaLocation attribute in XML or by using resolvable URLs for classes and properties in RDF
15:33:58 <JohnArwe> ...those last 3 are bullet points; the doc is a FPWD
15:34:18 <Arnaud> q?
15:34:38 <SteveS> +1 for opening
15:34:42 <Arnaud> PROPOSED: Open ISSUE-92
15:34:46 <pchampin> +1
15:34:47 <bblfish> +1 for opening
15:34:47 <betehess> +1
15:34:48 <SteveS> +1
15:35:09 <roger> +1
15:35:17 <JohnArwe> +1
15:35:26 <sandro> issue-92?
15:35:26 <trackbot> issue-92 -- Change rel=type to rel=profile for client introspection of interaction model -- raised
15:35:26 <trackbot> http://www.w3.org/2012/ldp/track/issues/92
15:35:33 <TallTed> +1
15:35:35 <codyburleson> +1
15:35:39 <Ashok> +1
15:36:32 <Arnaud> RESOLVED: Open ISSUE-92
15:36:49 <JohnArwe> Arnaud: do not want to re-open whole discussion of how many headers etc, just what syntax we use to express the semantics we've already agreed to
15:36:56 <JohnArwe> Topic: Issue-89
15:36:59 <JohnArwe> issue-89?
15:36:59 <trackbot> issue-89 -- Tie the interaction model with the LDP data model through the notion of Managed Resources -- open
15:36:59 <trackbot> http://www.w3.org/2012/ldp/track/issues/89
15:37:00 <Zakim> +Sandro.a
15:37:05 <Zakim> -Sandro
15:37:17 <Zakim> +ericP
15:37:34 <JohnArwe> (from agenda) PROPOSED: define the containment relationship as proposed by Alexandre Issue-89 Proposal 3
15:38:07 <sandro> betehess, where are you?
15:38:16 <bblfish> do you have a normal lnadline phone betehess?
15:39:28 <bblfish> http://www.w3.org/2012/ldp/wiki/Issue-89
15:39:33 <JohnArwe> Arnaud: summarizes proposal 3 ... formally define a relationship already in spec today: containment, as ldp:contains
15:40:01 <JohnArwe> ...summarizes proposal 4
15:42:55 <JohnArwe> ...notes that proposal 3 implies (for a simplecontainer) no change in # triples (membership=contains), for an indirect container also members!=contains, for direct containers members=contains-set so 2x as many triples which people were not crazy about.
15:43:51 <JohnArwe> ...summarizes proposal 5, which provides a way to filter out the subset of the links you don't want/like (so in the 2x for direct containers case, clients can get only the subset of the triples that they really want)
15:44:33 <JohnArwe> Alexandre confirms summary, since he cannot speak (bad connection)
15:44:45 <JohnArwe> EricP: how does proposal 5 differ from what we have now?
15:44:48 <bblfish> q+
15:44:56 <Arnaud> ack bblfish
15:45:03 <JohnArwe> Arnaud: if we reject 3, 5 is irrelevant
15:45:26 <SteveS> q+
15:45:50 <betehess> PROPOSAL 5 is about how to opt-in or opt-out and choose from the following types of triples being returned: membership triples, containment triples, other server-managed triples, inlined triples, application specific triples, etc.
15:46:02 <betehess> should be adapted depending on the use-cases
15:46:47 <JohnArwe> bblfish: defining containment should be non-controversial, renaming :created ditto, then rest can be "reliably" discussed once you agree on the terms you're using
15:47:12 <Arnaud> ack SteveS
15:47:20 <JohnArwe> henry pls make sure I got all of your thoughts correctly, my parser not quite as fast as your speaking
15:48:01 <JohnArwe> SteveS: some of wiki content is outside proposal but seems to bear on this, like replacing :member with :contains
15:48:09 <betehess> right, containement and membership are different things, do not remove membership at all
15:49:17 <JohnArwe> SteveS: so accepting any of these proposals as currently written would not incorporate (from the wiki) the stmt: replaces ldp:member with ldp:contains to align the containment triples and the membership triples in the case of the SimpleContainer.
15:50:17 <JohnArwe> @betehess, that phrase was simply placed outside the proposal headers so Steve apparently was unsure if the intent was to incorporate it in one of the them (as a simple reading might imply) or not
15:50:54 <JohnArwe> @betehess, can you state your intent (on IRC since that's all we have for you)?
15:51:41 <betehess> JohnArwe, yes, we should align the triples
15:51:49 <JohnArwe> bblfish: if we used rules/sparql, we could do that in either direction.  it shows that the concept is important and belongs in the spec.
15:52:08 <JohnArwe> ...how we deal with inferencing etc is a separate question.
15:53:04 <JohnArwe> Arnaud: agree value in clarifying spec.  maybe accepting proposal 3 is a first step, since that does not talk about how/if to materialize the concept
15:53:07 <JohnArwe> q+
15:53:12 <Arnaud> ack JohnArwe
15:53:40 <ericP> JohnArwe: i asked of the list: what is the intent of proposal 3?
15:53:56 <ericP> ... is it to say that they MUST be exposed? MAY be exposed?
15:54:28 <betehess> those triples must be exposed if they resulted from the LDP interactions, or can be enforced eg. something contained can be DELETEd
15:54:29 <JohnArwe> @betehess, can you speak to your intent?  i.e. answer the questions I posed on the list?
15:54:49 <JohnArwe> ok so "MUST" is the intent?
15:54:54 <betehess> yes
15:55:02 <bblfish> I'd say that to start with whether they get exposed always, should not be an issue.
15:55:20 <bblfish> The ldp:contains, really helps to write down rules.
15:55:32 <SteveS> and I say it is, ldp:contains can be inferred
15:55:32 <JohnArwe> Arnaud: we can separate them.  as written, proposal 3 does not force materialization.
15:55:39 <betehess> you don't know if you can DELETE a member in the general case, for example
15:56:12 <JohnArwe> Arnaud: first step would be to define and talk about "containment" as a concept, and separate off the materialization aspect
15:56:30 <JohnArwe> EricP: not convinced there is value in having a name for the concept, but not opposed
15:57:12 <JohnArwe> Arnaud: could use the sparql queries we used for the discussion, even if not normative.  could be appendix/whatever.
15:57:51 <bblfish> Here I show how one goes from one to the other:
15:57:52 <bblfish> http://lists.w3.org/Archives/Public/public-ldp-wg/2013Dec/0043.html
15:57:57 <TallTed> Zakim, unmute me
15:57:57 <Zakim> TallTed should no longer be muted
15:58:05 <JohnArwe> Arnaud: anyone disagree that we have been talking about 2 distinct relationships?  defer for now which are represented explicitly.
15:58:09 <bblfish> CONSTRUCT { ?subject ldp:contains ?ldpr }
15:58:09 <bblfish> WHERE{
15:58:09 <bblfish>   { ?ldpc a ldp:DirectContainer;
15:58:11 <bblfish>           ldp:containerResource ?subject;
15:58:13 <bblfish>           ldp:containsRelation ?predicate.
15:58:15 <bblfish>     ?subject ?predicate ?ldpr.
15:58:17 <bblfish>   }
15:58:19 <bblfish>    UNION
15:58:21 <bblfish>  {
15:58:23 <bblfish>      ?ldpc a ldp:DirectContainer;
15:58:25 <bblfish>            ldp:containerResource ?object;
15:58:27 <bblfish>            ldp:containedByRelation ?predicate.
15:58:29 <bblfish>      ?ldpr ?predicate ?object .
15:58:31 <bblfish>   }
15:58:33 <bblfish> }
15:58:34 <betehess> both notions are important, just solve different problems
15:58:35 <bblfish> CONSTRUCT { ?subjet ?predicate ?object }
15:58:37 <bblfish> WHERE {
15:58:39 <bblfish>  { ?ldpc a ldp:DirectContainer;
15:58:41 <bblfish>           ldp:containerResource ?subject;
15:58:43 <bblfish>           ldp:containsRelation ?predicate;
15:58:45 <bblfish>           ldp:contains ?ldpr.
15:58:47 <bblfish>     BIND (?ldpr AS ?object)
15:58:49 <bblfish>   }
15:58:51 <bblfish>    UNION
15:58:53 <bblfish>   {
15:58:55 <bblfish>      ?ldpc a ldp:DirectContainer;
15:58:57 <bblfish>            ldp:containerResource ?object;
15:58:59 <bblfish>            ldp:containedByRelation ?predicate;
15:59:01 <bblfish>            ldp:contains ?ldpr.
15:59:03 <bblfish>    BIND (?ldpr AS ?subject)
15:59:05 <bblfish>   }
15:59:07 <bblfish> }
15:59:11 <bblfish> one rule to go from membership triples to ldp:contains and the other way.
16:00:02 <JohnArwe> TallTed: which of the 2 is most important is context-specific.  I don't think we can say either is primary.  If it's equally easy to transition from one to the other, define both and how to transition.
16:00:06 <bblfish> Tall Ted that's why we're trying to define ldp:contains :-)
16:00:18 <bblfish> because ldp:conains is not clearly defined yet.
16:00:28 <JohnArwe> ...within any WG, you'd never get real consensus if the conditions above apply.
16:00:35 <TallTed> Zakim, mute me
16:00:35 <Zakim> TallTed should now be muted
16:00:49 <JohnArwe> ...real consensus on *this one* being primary, that is
16:01:34 <Arnaud> PROPOSAL 3: define the containment relationship (whether materialized or not)
16:01:48 <codyburleson> +1
16:01:50 <pchampin> +1
16:01:53 <betehess> +1
16:01:53 <bblfish> +1
16:02:06 <TallTed> +1
16:02:15 <SteveS> +0.5
16:02:22 <ericP> +0
16:02:30 <JohnArwe> +0.5 (seems useful in some cases, just not those I'm after, but nothing wrong with it for sure)
16:02:42 <roger> -0.5 i don't really like where this could end up
16:03:10 <Zakim> -Roger
16:04:03 <Arnaud> RESOLVED: define the containment relationship (whether materialized or not)
16:04:07 <SteveS> roger, perhaps you could -1 whatever thing that might come up in the future that rubs you the wrong way
16:04:23 <bblfish> And add it to the ontology :-)
16:04:25 <Zakim> +Roger
16:06:42 <JohnArwe> Roger: wanted to say something but hit wrong button; understand all this for sure, can see doing it piece by piece, so I should be ok with just this much.  I didn't -1 it for that reason.  I think what's important is what's returned in the hypermedia to clients, the filesys case is a niche.  Complicating spec, harder to understand, can't imagine anyone else wanting to implement it.
16:07:36 <Arnaud> PROPOSED: replace ldp:created/ldp:memberResource with ldp:contains
16:07:38 <codyburleson> +1
16:07:47 <bblfish> +1
16:07:51 <SteveS> +1
16:08:03 <Ashok> +1
16:08:06 <betehess> +1
16:08:29 <ericP> does contains have any implications re: deletion of the container?
16:08:35 <JohnArwe> Arnaud: agree there is a slight difference (created-only originally, now contained regardless of how created)
16:08:39 <bblfish> ( It's not quite the same link but, we don't need the subtlety of ldp:created - I iniitially put ldp:created because I was trying to go for something that would be clearly HTTP based, )
16:09:30 <JohnArwe> Ericp: if I have a system that allows creating members but deleting the container does not result in the container deleting created-members, does this proposal change that?
16:09:45 <TallTed> Zakim, unmute me
16:09:45 <JohnArwe> Arnaud: I think it would
16:09:47 <Zakim> TallTed should no longer be muted
16:10:21 <SteveS> +1 to ldp:created with ldp:contains, the ldp:memberResource is a different part and only for ldp:SimpleContainer
16:10:24 <bblfish> q+
16:10:31 <Arnaud> ack bblfish
16:10:31 <JohnArwe> TallTed: membership and containment are 2 different things, that we both need
16:10:31 <pchampin> q+
16:11:14 <pchampin> q-
16:12:22 <JohnArwe> bblfish: same as above I put in IRC.  :contains is core of the spec.  spec already says that delete has side effects, so if you believe a correspondence exists with membership, this is not a new consequence.
16:12:53 <betehess> the proposals don't say anything about that, but invariants are the answers: containment means that you have the triples *and* the contained resources, so if you remove the containment triples (DELETE on Container), then you should recursively delete the contained resources
16:13:05 <Zakim> +[IPcaller]
16:13:17 <codyburleson> Zakim, IPcaller is me
16:13:17 <Zakim> +codyburleson; got it
16:13:23 <Zakim> -cody
16:13:30 <betehess> DELETE on Container, or even a PATCH to delete the triple I guess :-)
16:13:53 <JohnArwe> bblfish: I don't think this changes anything for the moment.  in my sys, you cannot delete a non-empty container.
16:14:05 <betehess> I'd say that we ignore that for today, and I can write a proposal for next week
16:14:33 <JohnArwe> SteveS: actually already covered
16:14:46 <JohnArwe> ...link coming
16:15:12 <codyburleson> (I'm now in as codyburleson rather than cody because I switched from cell phone to Skype)
16:15:21 <JohnArwe> SteveS: 5.6.4 has it
16:15:27 <SteveS> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpc-HTTP_DELETE
16:16:29 <betehess> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpc-5_6_4
16:16:56 <JohnArwe> SteveS: on your proposal you listed memberResource; I thought that was only for SimpleContainer
16:17:20 <JohnArwe> Arnaud: nononononono memberResource is something else
16:17:47 <JohnArwe> ...link to document, and link to member
16:18:13 <JohnArwe> Ericp roots for "document" here
16:18:23 <roger> +1 to memberDocument
16:18:36 <JohnArwe> Arnaud: containment is all about the documents, membership is not (always)
16:19:03 <ericP> how about this? containment is about the docs, membership is about RDF nodes
16:19:36 <bblfish> yes, ldp:contains is relationship between HTTP resources. membership extends outside into the real world
16:19:38 <JohnArwe> @ericp worth you proofing the draft for this ;-)
16:19:55 <ericP> oops. roger that
16:20:06 <bblfish> but since our protocol is about HTTP interactions, it is very important to have the ldp:contains relation
16:20:48 <betehess> eric's question was about deleting in cascade, wasn't it?
16:21:30 <betehess> right, you can't do that for members, only for contained resources
16:22:14 <roger> +q
16:22:17 <JohnArwe> EricP: in our discussions, not in spec, in containment rel when you delete the container you "must" delete any remaining members. if we're changing that, maybe variations on contained get ugly.
16:22:25 <Ashok> That's my understanding of Eric's point
16:23:03 <JohnArwe> bblfish: would the proposed replacement result in some new consequence ?
16:23:35 <JohnArwe> EricP: hard to tell on the fly, since not all of what we discussed was directly reflected in the spec
16:23:39 <betehess> where does the spec *today* defines what ericP is talking about?
16:24:23 <JohnArwe> @betehess, EricP said earlier that this is how we've discussed things, differentiating from what spec says.
16:24:33 <JohnArwe> ...realizing you still have white noise
16:25:19 <JohnArwe> TallTed: that is where spec is today, leaves things open because when we discussed earlier we realized that specifying this would require lots of new careful definition that we didn't otherwise need
16:25:48 <betehess> I disagree with ericP: if the server says that { X ldp:contains Y } then DELETEing X, or even deleting { X ldp:contains Y }, then Y must disappear as well, same than DELETEing Y must remove the triple. They are bound together, it's an invariant
16:26:20 <betehess> not implementation specific
16:26:25 <JohnArwe> EricP: we were worried about, if we accepted new reqts/refinements on :contains, we'd either rule out certain use cases or need lots of new definitions
16:27:04 <betehess> Containment is an invariant managed by the server
16:27:22 <JohnArwe> bblfish: http delete has to operate on resources with uris.  created has to be a subset of contains as the spec is today, so why not simplify and remove the overly-precise one.
16:27:56 <JohnArwe> EricP: historically we've used "containment" to mean: if you delete a non-empty container, those members must be deleted
16:28:08 <JohnArwe> TallTed: disagree; we've used 'containment' several ways
16:28:54 <JohnArwe> EricP: as long as we're not committing to specify deletion of non-empty container... ericp help pls... doesn't limit future
16:29:23 <JohnArwe> Arnaud: need to be sure of the effects before agreeing to this.
16:29:25 <JohnArwe> q+
16:30:01 <JohnArwe> Arnaud: people should look at EricP's case
16:30:03 <Arnaud> ack roger
16:30:17 <JohnArwe> Roger: will paste
16:30:19 <Arnaud> ack john
16:30:23 <roger> I think if we use "containment" a lot less, and "document" (in conjunction with member) a lot more - then it might be a better
16:30:28 <ericP> s/... ericp help pls.../, for which we historically used the term "containment"/
16:31:28 <JohnArwe> JohnArwe: was this incorporated as part of proposal 3 approval?  as SteveS noted, not really within its scope: replaces ldp:member with ldp:contains to align the containment triples and the membership triples in the case of the SimpleContainer.
16:31:59 <JohnArwe> Arnaud: no; we're sticking with proposal 3 strictly as written, so it's a pure add at this point
16:32:10 <JohnArwe> Ericp: why can't we do that?
16:32:20 <JohnArwe> Arnaud: the document != member in all cases
16:32:29 <JohnArwe> EricP: ok
16:32:32 <roger> +q
16:32:54 <Arnaud> ack roger
16:33:21 <JohnArwe> so is ericp's rename proposal to be handled as a new issue?
16:33:32 <codyburleson> What is a "document"? Do you mean an LDPR? Versus some subset of an entire LDPR?
16:33:40 <JohnArwe> Roger: document instead of member would be useful to clarify spec.
16:33:50 <Arnaud> PROPOSED: rename ldp:created with ldp:memberDocument
16:34:30 <betehess> I don't see the point, as PROPOSAL 4 will rename it as ldp:contains
16:34:34 <SteveS> and also add 'document' to terminology
16:34:49 <JohnArwe> @cody: in REST-speak, "document" is a less-scary way of saying "information resource".  vs "resource" which can be a document OR a cat/person/concept
16:36:17 <Zakim> -Ashok_Malhotra
16:36:23 <bblfish> happy new year
16:36:31 <Zakim> -TallTed
16:36:32 <Zakim> -SteveS
16:36:33 <Zakim> -bblfish
16:36:34 <Zakim> -Sandro.a
16:36:35 <Zakim> -Roger
16:36:35 <Zakim> -Alexandre
16:36:36 <Zakim> -ericP
16:36:37 <codyburleson> @JohnArwe - Thanks, got it
16:36:38 <JohnArwe> Arnaud: at some point we need to make decisions on some time-bounded issues like next F2F
16:36:38 <Zakim> -Arnaud
16:36:38 <Zakim> -pchampin
16:36:43 <Zakim> -JohnArwe
16:36:45 <Zakim> -codyburleson
16:36:47 <Zakim> SW_LDP()10:00AM has ended
16:36:47 <Zakim> Attendees were +1.214.537.aaaa, Sandro, Ashok_Malhotra, pchampin, Arnaud, SteveS, Roger, Alexandre, JohnArwe, TallTed, bblfish, cody, ericP, codyburleson
16:51:56 <jmv> jmv has joined #ldp
16:54:21 <codyburleson> codyburleson has left #ldp
17:07:50 <jmvanel> jmvanel has joined #ldp
17:13:59 <Arnaud> sandro? help! http://www.w3.org/2013/meeting/ldp/2014-01-06?edit=1 Internal Server Error
17:43:32 <sandro> checking
17:44:30 <sandro> RRSAgent, pointer?
17:44:30 <RRSAgent> See http://www.w3.org/2014/01/06-ldp-irc#T17-44-30
17:45:08 <sandro> ohhhh, I bet 2013 is hardcoded somewhere.     heh.
17:45:11 <sandro> checking.
17:46:56 <sandro> fixed.   sorry about thatr.
17:47:00 <sandro> Arnaud,
17:47:07 <Arnaud> I tried with http://www.w3.org/2014/meeting/ldp/2014-01-06?edit=1 but that gave me a 404
17:47:24 <sandro> refresh?
17:47:48 <Arnaud> ah!
17:47:50 <Arnaud> it works
17:47:51 <Arnaud> thanks
17:48:00 <Arnaud> https://www.w3.org/2013/meeting/ldp/2014-01-06?edit=1
17:48:08 <Arnaud> what was it?
17:51:24 <sandro> I had a regexp in the code for finding relevant files and it hardcoded 2013.    (it was supposed to be short lived.  :-)
17:51:33 <Arnaud> :)
17:51:45 <Arnaud> it's always like that, isn't it?
17:52:10 <Arnaud> those temporary quick fixes tend to linger around until they bite you
17:52:46 <sandro> Well, sometimes it's shortlived because the whole project gets abandoned.  :-)     [ "Half of marriages end in divorce.  Which isn't so bad if you consider the other half end in death."]
17:54:41 <Arnaud> hmm, there seems to be another problem now
17:54:54 <Arnaud> every time I try to save it claims there is a conflict
17:55:07 <sandro> looking
17:57:12 <sandro> try again, pleasre
17:57:21 <Arnaud> ok
17:57:51 <sandro> okay, that didnt do it.  :-(
17:59:45 <Arnaud> nope
18:01:01 <sandro> odd.     it did for me.  I can edit https://www.w3.org/2013/meeting/ldp/2014-01-06  :(
18:01:11 <Arnaud> ok, let me try again
18:02:05 <Arnaud> ok, it worked this time
18:02:10 <Arnaud> don't know why
18:02:20 <Arnaud> but I can live with that :)
18:02:45 <sandro> phew.     The error was that the date part of your URL couldn't be split on the '-' char.    Strang.
18:03:19 <Arnaud> oh
18:08:52 <Arnaud> well, it works now, thanks!
18:45:33 <Zakim> Zakim has left #ldp
19:25:31 <gavinc> gavinc has joined #ldp
20:38:33 <bblfish> bblfish has joined #ldp