14:56:46 RRSAgent has joined #ldp 14:56:46 logging to http://www.w3.org/2013/11/11-ldp-irc 14:56:48 RRSAgent, make logs public 14:56:48 Zakim has joined #ldp 14:56:50 Zakim, this will be LDP 14:56:50 ok, trackbot; I see SW_LDP()10:00AM scheduled to start in 4 minutes 14:56:51 Meeting: Linked Data Platform (LDP) Working Group Teleconference 14:56:51 Date: 11 November 2013 14:59:38 SW_LDP()10:00AM has now started 14:59:45 +[IPcaller] 14:59:53 Ashok has joined #ldp 14:59:53 Zakim, IPcaller is me. 14:59:53 +codyburleson; got it 15:00:15 +Arnaud 15:01:06 + +1.857.928.aaaa 15:01:28 Zakim, aaaa is Alexandre 15:01:28 +Alexandre; got it 15:01:47 +??P5 15:01:57 +Ashok_Malhotra 15:02:02 +JohnArwe 15:02:03 stevebattle7 has joined #ldp 15:02:07 + +33.4.73.28.aabb 15:02:12 JohnArwe has joined #ldp 15:02:24 +[IBM] 15:02:30 Zakim, [IBM] is me 15:02:30 +SteveS; got it 15:02:40 zakim, who's on the phone? 15:02:40 On the phone I see codyburleson, Arnaud, Alexandre, ??P5, Ashok_Malhotra, JohnArwe, +33.4.73.28.aabb, SteveS 15:03:01 zakim, aabb is me 15:03:01 +stevebattle7; got it 15:04:02 zakim, ??P5 is EricP 15:04:02 +EricP; got it 15:04:06 +bblfish 15:04:23 Did I grab the wrong number? 15:04:30 bblfish has joined #ldp 15:04:44 hhihi 15:04:53 we can give them other things to do 15:05:09 stevebattle7, aabb was for +33.4.73.28.aabb 15:05:31 maybe aabb was ericP 15:05:33 Yep - four + one + pound to raise hand 15:06:05 scribenick: ericP 15:06:11 Zakim, untangle this mess 15:06:11 I don't understand 'untangle this mess', stevebattle7 15:06:55 PROPOSED: accept http://www.w3.org/2013/meeting/ldp/2013-11-04 as a record of the 4 Nov meeting 15:06:59 APPROVED: accept http://www.w3.org/2013/meeting/ldp/2013-11-04 as a record of the 4 Nov meeting 15:07:26 +Sandro 15:07:27 next call: 18 Nov 15:07:36 topic: Tracking of actions and issues 15:07:59 Ah I still have to review the primer 15:08:40 I have an action 111, I haven't really had time to look into yet, but I can do that this week (finally got some breathing room). 15:08:47 the primer of Access control will do this soon. Have been working on WebID and many other things. 15:08:56 Arnaud: c'mon people. do your actions. 15:09:07 -> http://www.w3.org/2012/ldp/track/actions/open open action items 15:09:37 +??P13 15:09:44 topic: Paging 15:09:49 https://www.w3.org/2005/06/tracker/users/my YOUR ACTIONS 15:10:20 Arnaud: we've moved the paging stuff into headers per TimBL's comments 15:10:53 ... John started adding this to the spec, but there was a question about having a MUST 15:11:04 ... also questions about having last and prev 15:11:43 -> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpr-PagingGET Section 4.10.2 HTTP GET 15:11:59 JohnArwe: I heard "hell no" re: required reverse linking 15:12:24 ... as I was drafting this AM, I reallized we'd includes the link="collection" header on the tail end of the discussion with ericP 15:12:46 ... after our 303->200 decision, there's no diff between the collection and the first page 15:12:58 q+ 15:13:11 q- Yep 15:13:16 q- - 15:13:28 q- four 15:13:28 q- + 15:13:28 q- one 15:13:30 q- pound 15:13:35 q- to 15:14:17 BTW: I did read RFC 5005 which defines the link headers; section 3 says (wrt MUST/MAYS) Paged feed documents MUST have at least one of these link relations 15:14:17 present, and should contain as many as practical and applicable. 15:14:37 ...i.e. it does not even go so far as to require any particular one ;-) 15:15:00 a previous link would require the server to maintain an immutable iterable vs just a simple iterator 15:15:06 that's a strong requirements 15:15:14 s/requirements/requirement/ 15:15:24 Zakim, ??P13 is me 15:15:24 +nmihindu; got it 15:15:25 q+ 15:15:33 Zakim, mute me 15:15:33 nmihindu should now be muted 15:16:37 +OpenLink_Software 15:16:43 Zakim, OpenLink_Software is temporarily me 15:16:43 +TallTed; got it 15:16:44 Zakim, mute me 15:16:44 TallTed should now be muted 15:16:48 ack Ashok 15:17:03 FWIW I think the "last this server knows about" is consistent with 5005 15:17:16 ericP: [single/double-linked, last last] 15:17:35 Ashok: making PREV optional seems like a poor idea. 15:17:38 q+ 15:17:43 ack betehess 15:18:01 ... if i'm i page 48 and i forgot a page, do i have to start from 1 again 15:18:18 s/poor/terrible/ 15:18:36 betehess: nothing is optional 15:19:17 ack steves 15:19:22 bertails: if it's optional on the server then it is necessary on the client, then he had some reason why it was a bad idea for why it was bad for the client 15:19:24 -Alexandre 15:19:25 1. a MAY on the server is a MUST on the client 15:19:38 s/bad/optional/ 15:20:21 +Alexandre 15:20:22 s/bad/optional/ <- change the last one in my last statement summarising bertails intervention 15:20:36 SteveS: in the scenarios i've seen, we don't go part way through and rewind 15:20:46 ... and if you did, you'd still ahve the chain in memory 15:20:49 2. supporting previous means having to maintain everything in memory 15:21:04 ... a MAY on the server means a MUST on the client 15:21:28 3. what's important is go through the triples, not navigating in the triples 15:21:39 ... if they server includes a PREV and the client doesn't look for it, the client can still use the forward traversal 15:22:36 s/a MAY on the server means a MUST on the client/re: "a MAY on the server means a MUST on the client", that doesn't apply here 'cause.../ 15:22:39 Perhaps what should be made clear is that forward paging MUST be supported by servers and clients. 15:22:43 this is breaking existing clients like Jena: they won't find *all* the triples 15:23:12 Arnaud: i don't see what program is going to need to go backwards and if it does, it can cash them and rewind from that. 15:23:13 q? 15:23:14 agree with Arnaud: client can do the caching 15:23:53 http://tools.ietf.org/html/rfc5005#section-3 15:23:57 :-) 5005 backwards is 5005 15:24:07 it's a pun 15:24:14 JohnArwe: RFC5005 says you only need one of these headers 15:24:33 ... and it says ANY one, it does not pick even one winner 15:24:43 Do we not have ordering now in collections now? If we do, then can one not just get the reverse order? 15:25:01 betehess: if you're using e.g. Jena, the client will be able to parse the first page but won't find anything else 15:25:11 bblfish, we do and a good way to do it 15:25:35 @bblfish: we allow servers to Express order. we do not define any way for clients to Request a particular order. 15:26:51 sure, but this is breaking this assumption if a client see "text/turtle" 15:27:04 ... if you have some client that doesn't support paging, it will see only page one. it would be nice to have a way to switch off paging 15:27:57 Were we not going to have another 20x error code? 15:28:04 for paging? 15:28:05 q+ 15:28:05 So is the problem you're poking at Alex that Jena is not giving the app access to the HTTP headers? 15:28:27 ack betehess 15:28:43 Arnaud: the fact that an existing client wouldn't reallize that this is only the first page is why some of us thought 303 was a better. but now we've decided on 200. 15:28:46 Ok. Should be on the todo list to look for someone to do 20x for paging perhaps. 15:29:13 @bblfish see minutes from 11/4 (I think - else 10/28) 15:29:37 betehess: with the current behavior, we're only talking to LDP clients instead of generic RDF clients 15:29:56 ... this is at odds with using "text/turtle" as the media type 15:30:12 it's all ok if everybody talk LDP tomorrow, I'm fine with that 15:30:16 yes, it's a good point that we are breaking existing RDF clients... One needs a good reason at least in the spec to make this clear. 15:30:17 5005 headers can be used with any HTTP interaction. 15:30:51 I'll live with it, I want the world to move to LDP anyway 15:30:58 Arnaud: i agree that it will surprise many people that would expect 200 means you get everything, but we got feedback from HTTP experts saying that page1 *is* the representation 15:31:13 anyway, it's a MUST :-) 15:31:53 regarding paging 15:32:59 Arnaud: people who want to change this need to make a concrete proposal 15:33:09 Arnaud: people need to send concrete proposals to the mailing list if they want ot change the status quo. 15:33:23 topic: regarding ISSUE-81 Part II: Keeping the simple case simple 15:33:26 Issue-81? 15:33:26 Issue-81 -- Confusing membership* predicate names and other possible improvements -- open 15:33:26 http://www.w3.org/2012/ldp/track/issues/81 15:33:40 Arnaud: issue is around trying to keep the simple case simple 15:33:50 we had discussions in the past about default breaking monotonicity 15:34:12 ... because we've added all these properties without defaults so the simple case is bloated. 15:34:27 Arnaud: SteveS proposed ldp:created 15:34:30 q+ 15:34:36 ldp:created is a different issue 15:34:46 ack bblfish 15:34:50 -Alexandre 15:35:20 Arnaud: there is a proposal to make ldp:insertedContentRelation optional, default is ldp:MemberSubject 15:35:32 +Alexandre 15:35:45 bblfish: re: simplifying everything, we could make the whole thing optional 15:36:12 http://www.w3.org/2012/ldp/wiki/ISSUE-81#Proposals_--_Part_I_bis 15:36:24 Arnaud: you want to discuss LDP membership rule? 15:36:34 ldp:membershipRule 15:36:43 bblfish: yes, can make everyhing optional with this one link to a blank node 15:36:56 q+ to ask for use cases around open world and how they'd differ 15:37:19 Arnaud: henry asked what if we mapped all of these properties into a bnode? 15:37:22 <> a ldp:Container; 15:37:22 ldp:creationRule [ ldp:subject <../card#me>; 15:37:22 ldp:predicate foaf:knows; 15:37:24 ldp:rangeSelector foaf:primaryTopic ] . 15:37:39 ... if you close the world at that level, you end up with optional without nonmon issues 15:37:52 -Alexandre 15:38:05 ack ericP 15:38:05 ericP, you wanted to ask for use cases around open world and how they'd differ 15:38:28 +Alexandre 15:39:44 -Sandro 15:39:48 ericP: is the assumption that if i see ldp:creationRule _:b1, i can't see ldp:creationRule _:b2 later on? 15:40:58 bblfish: if we have a ldp:created arc, the monotonicity issues go away 15:41:31 ?ldpc ldp:created ?member 15:42:25 q+ 15:43:03 ack steves 15:43:14 Arnaud: not understanding what it means to "remove the membership rule" 15:43:26 -Alexandre 15:43:41 SteveS: as i understand henry's proposal, the memebership property is a consequence of creating a resource. 15:44:00 betehess has joined #ldp 15:44:16 +Alexandre 15:44:22 q+ 15:44:42 ... there are a number of existing data structures that, when i bring them online [in LDP], i didn't create anything 15:44:45 ack bblfish 15:45:12 I thought that "membership triples" today were there to tell clients how to enumerate members of the container; does not matter how they came to be members (post, put,... , out of band). 15:45:57 bblfish: we needed 3 relations 'cause we had monotonicity issues. 15:46:24 ... we can get the same behavior that we had before. 15:46:48 Arnaud: i sense a disconnect between what people consider to be a member 15:46:55 I thought Sandro said in Boston (very clearly) that monotonicity is not the black death; we can choose to have it or not. 15:47:21 ... some say it's whether it was created, others simpy whether it is listed. 15:47:49 -Alexandre 15:48:34 It sounded to me like Henry just agreed that how something came to be a member does not matter. Did I hear that wrong? 15:49:01 q+ to ask what use cases impose monotonicity -- to be acked if the chair thinks it's on topic 15:49:25 q+ 15:49:26 I don't see a problem with blank nodes. 15:49:29 ack ericP 15:49:29 ericP, you wanted to ask what use cases impose monotonicity -- to be acked if the chair thinks it's on topic 15:50:14 bblfish, does it really matter it have to be a blank node or grouping all of them and referring them to using one relation is enough ? (just thinking) 15:51:05 ack stevebattle7 15:51:12 ok, but we'd like not to drop inferencing later. 15:51:15 ack steveb 15:51:30 if I'm a client and I see a partial rule, how long do I need to wait until I can decide if <> ldp:contains is true or not? 15:51:38 ericp, can you minute your stmt? 15:51:39 stevebattle: i don't see how a client will know what will happen when a new resource gets added 15:51:49 with a default, it's true until being said otherwise... 15:51:57 I find this all confusing, frankly. 15:52:14 +Alexandre 15:52:40 bblfish: i'd say that new resources go into the LDPC, but it's a different question 15:53:20 stevebattle: when a client creates a new resources, they need to include the member relationship in the POST 15:53:40 betehess, a client can ask for the non-member properties upfront (like my proposal says) if it cares about monotonicity. If it doesn't, it can just fetch pages and then find 15:54:58 SteveS, how would a client know what to search? how long would it have to search for what's potentially missing or just does not exist? 15:55:10 Remember, this wasn't a last call comment....so it isn't blocking us, it was a WG member (me) who was trying to help modify what we have 15:55:40 Arnaud: i thought we were talking about how ldp:membershipRule could use a bnode and that the properties from that bnode could have defaults 15:55:46 I'm confused how a defaults are ok now 15:56:25 q+ to say that any use case for monotonicity would be screwed by having default on a blank node 15:57:25 ack ericP 15:57:25 ericP, you wanted to say that any use case for monotonicity would be screwed by having default on a blank node 15:57:42 I *think* Henry is saying: once you have a required relation (today: called ldp:created), that's the min. *In addition* to that, you can add other assertions that correspond to today's membership rule. 15:58:00 ...adding those other assertions is optional. 15:58:11 agree with ericP, the blank node thing does not solve anything 15:58:33 agree to what ericP is saying, not sure how making blank node or making it optional fixes it 15:58:36 JohnArwe, yes, that's the spirit 15:59:42 fine with me 16:00:39 [Proposal to extend for 15 mins] 16:01:28 Ashok: if you [trouble makers] can get together and document the issues, it would help me understand use cases, etc. 16:02:11 Arnaud: there are two proposals, one to make some stuff default, and the other to put it on a bnode. 16:02:19 ... ericP says that the bnode doesn't make any difference 16:02:21 -Ashok_Malhotra 16:02:43 topic: ldp:created 16:02:47 brb 16:03:17 Arnaud: when we introduced ldp:insertedContentRelation, we lost the direct link to the created resource 16:03:43 ... 'cause now it may reference some other resource. 16:04:28 yes 16:04:45 http://lists.w3.org/Archives/Public/public-ldp-wg/2013Nov/0035.html 16:05:08 ... there's no guarantee that the created resource is the same as the document 16:05:12 betehess_ has joined #ldp 16:05:32 ... I said that we have ldp:created, but the spec says that ldp:created is a MAY 16:06:00 q+ 16:06:03 ... we can: 16:06:14 ... .. leave it as is and say that there's a gap 16:06:37 ... .. make ldp:created but make it mandatory (some pushback on that) 16:07:11 ack betehess 16:07:27 ... .. fill the whole by making ldp:created mandatory when ldp:insertedContentRelation does not point to the created document 16:08:00 betehess: we wanted to have access to all the created resources including the binary resources (which are not currently LDPRs) 16:08:05 q+ 16:08:14 Arnaud: sounds like you're saying there's another hole 16:08:49 ... which leads to saying that a mandatory ldp:created would solve it all 16:09:20 ... but we agreed the that in the binary case, the ldp:insertedContentRelation link is to the created binary 16:09:35 ack bblfish 16:09:38 ... so i think you want to have all the ldp:created uniformly listed 16:10:25 bblfish: Arnaud's proposal to fill in the hole makes sense 'cause we can use the membershipXXX to find the members of the container, right? 16:10:28 Arnaud: right 16:11:15 bblfish: so once a container's created, you should never change any of the ldpmemberXXX relations 16:11:24 q+ 16:11:28 SteveS: or if you change them, update your database accordingly 16:11:41 Arnaud: but this is an issue in general 16:12:29 bblfish: don't think of these as rules, think of them as consequences of the speach act 16:12:51 Arnaud, your remark about the LDPR associated with the binary resource is discussed in 5.9.2. It's consistent with the idea that a binary resource is not an LDPR. I don't really understand from the rest of the spec why this is that way. 16:13:04 an LDPR should be anything that is managed by an LDPC 16:13:11 Arnaud: there are things that are linked from a container and things that were created by the container 16:13:20 including the binary resource, as you can POST it to the container 16:13:26 @betehess, one can use LDPRs without touching LDPCs 16:13:28 ... we keep arguing about those lists. 16:13:46 JohnArwe, what is "use" here? 16:13:56 the interactions are what matters :-) 16:14:18 betehess_, I think LDPR is what we define it to be...which is RDF-based resources, members of LDPCs are just web resources 16:14:22 @betehess: write a client whose job is completely satisfied by LDPRs. TimBL's case is one. 16:14:52 q- 16:15:01 ... SteveS said he doesn't care how it was created; he just cares that it's listed. 16:15:03 just for the record, all implementations close to LDP do consider binary resources are LDPRs, not something different 16:15:29 I mean, the ones about the Read Write Wer 16:15:31 s/Wer/Web/ 16:15:36 Arnaud: the spec is the way it is. no spec is perfect. the default is to stay with what we have. 16:15:58 Arnaud, would you prefer us to post formal comments to the LC instead of discussing here? 16:16:01 ... i'm concearned about the disposition of comments, e.g. Mark Baker's 16:16:11 @betehess, "are LDPRs" there seems incoherent. Can you be more precise about what you're saying? 16:16:35 ... (and i haven't seen mail to the public list or proposals to the group list about how to address them) 16:16:39 ADJOURNED 16:16:40 betehess_, LDP spec defines what LDPRs are, it seems like you are talking about the general term of resources...which is already defined 16:16:40 for us, being an LDPR means being a resource managed by the LDPC 16:16:42 codyburleson has left #ldp 16:16:43 bye 16:16:43 -SteveS 16:16:44 -Arnaud 16:16:46 -TallTed 16:16:48 -EricP 16:16:48 -codyburleson 16:17:02 SteveS, that's possible 16:17:03 @betehess: formal LC comments as the mechanism will not get them resolved any faster. so what advantage would you see in that route/ 16:17:04 -stevebattle7 16:17:08 -JohnArwe 16:17:09 -Alexandre 16:17:11 -bblfish 16:17:18 -nmihindu 16:17:19 SW_LDP()10:00AM has ended 16:17:19 Attendees were codyburleson, Arnaud, +1.857.928.aaaa, Alexandre, Ashok_Malhotra, JohnArwe, +33.4.73.28.aabb, SteveS, stevebattle7, EricP, bblfish, Sandro, nmihindu, TallTed 16:17:38 JohnArwe, because Arnaud's role is to care about those comments? 16:17:55 more than our "internal" comments 16:18:22 Chair's role is to achieve consensus on all comments (speaking as a former w3c chair) 16:18:39 betehess_, because some web resources aren't LDPRs doesn't mean they can't play or not 1st class web resources or resources in a LDP server...we could give them a name, non-LDPRs?, but not sure that is good 16:19:38 SteveS, why not having LDPC-Member, which can be either an LDPR or a Binary resource? 16:20:10 it's important to convey the relationship with the LDPC which manages the resource 16:20:56 but for many people, LDPR already conveys that idea 16:21:12 those who did that kind of stuff pre-LDP 16:22:05 "member" might be re-purposing a term that people already have opinions about, so I'd tend to pick wholly new ones at first and then have the traditional completely enjoyable (not) naming party later. but that's just me. 16:23:13 agree with JohnArwe - don't get confused about the names 16:23:29 JohnArwe, our issues today are related to that "member" being loosely defined in LDP 16:23:44 yes 16:23:57 It certainly seems reasonable on the surface to say that there "should" be some way to follow links from a LDPC to anything that LDPC "manages". I think the defn of "manages" might be hard to nail down. I have a sense of lifecycle control/knowledge in my head, but I also expect other cases (read-only LDPCs as views over others, pet containers, etc) 16:24:23 JohnArwe: the LDP spec specifies what manages means. You can delete thigns, etc... 16:24:28 "manages" == entailed by the REST interactions 16:24:28 that is very simple 16:24:48 the REST thing in the abstract was forgotten too often... 16:26:27 if an LDPC accepts a POST, it means it accepts to manage the new resource. if an LDPC says ldp:created , it means it manages , and that a DELETE on will remove the relation, etc. 16:26:41 +1 16:26:53 that's in the spec even 16:27:05 no need for the complex membershipXXX, at all 16:27:29 that's a different use-case, when we want the server to manage some extra triples *derived* from the interaction 16:27:37 does not mean that it's equivalent 16:28:07 "the LDP spec specifies what manages means" ... speaking as an editor, I am 100% sure that is not literally true. There is no such explicit definition. That said, if we can agree on one well sure we could add one. 16:28:28 JohnArwe, don't listen to bblfish ;-) 16:28:51 sorry, I try to listen to everyone. 16:28:55 heh 16:29:01 thanks 16:29:14 sometimes this icky natural language gets in the way, sadly 16:29:44 What does 'icky' mean? (is one example) 16:29:57 this feels like the sort of discussion that would be much better solved in person, or at least with a semantically higher bandwidth medium than IRC+phone 16:30:06 wiseacre 16:30:28 I agree 16:30:38 we can have a call 16:31:17 the thing is that we've started to implement LDP for real, and we have many issues with how to write applications 16:31:38 @betehess: well see, taking your created=>manages example. I could as easily say that the container "managing" it means that the container "encapsulates" it - all lifecycle interactions have to "go through" the container. But clearly that is not what the spec says, nor what you want, as both agree on how delete works. 16:32:18 you're not the only one(s) who have real implementations of LDP - promise 16:32:28 by the way, as the editors are around, can you guys give me the name for the whole membershipXXX thing and a short description of what it is? for now, this is spread in the spec in different places 16:32:28 :-) 16:32:32 JohnArwe: the spec says that wehn you delete an LDPR the statments generated by the ldp:memberXXX "rules" have to be removed 16:33:08 so the spec does imply a management relation 16:33:25 I agree - said that already. My point was, that I could apply a different, yet still wholly reasonable, meaning to 'manages' absent come explicit definition. 16:33:36 JohnArwe, not all interactions have to go through the container to be RESTful 16:33:42 never the case, eg. DELETE 16:33:58 ...just saying "it means what we say it means" helps no one outside our little band 16:34:39 agree with betehess the whole memberXXX relations are spread around the spec. 16:34:53 JohnArwe, in practice, if a POST succeeds, it means that the LDPC manages something new, right? 16:34:58 (POST on LDPC) 16:35:51 it would really help to have a name for the feature 16:36:07 we speak about "LDPC-managed resources" for the ldp:created thing 16:36:28 I avoid member as I don't know what people mean by it 16:36:38 apparently, many people conflate the two notions 16:36:50 "name for the whole membershipXXX thing and a short description" = there is no spoon. There are two distinct membership triple patterns involved, and then options for how to recognize the constant subset of those patterns. One cannot use all the XXX relations concurrently and be coherent. 16:37:34 what does "being a member" mean? 16:37:36 wrt being spread around the spec, I think this is issue-37 again. 16:38:20 http://www.w3.org/2012/ldp/track/issues/37 16:38:30 @betehess, I think membership is actually a well-defined concept in the spec (assuming you are willing to make the jump from "membership triple" to member) 16:39:30 I think it is confused JohnArwe very very confused 16:39:42 I don't understand :-/ 16:39:50 But it does not need much to get out of the confusion. 16:40:01 I'm willing to make any jump 16:41:53 the membermshipXXX are thought of as rules, they should be thought of consequences of creation. Then one needs to add ldp:creates or ldp:member to the LDPC and everything is fine. 16:42:10 my sense is that to make progress we need a Very Specific, Very Simple, instance example. To help show people all the cases, for one thing. Probably 2-3 in reality, sigh, as similar as possible but showing the various membership triple patterns, and each having at least 3 members ... or 6, 3 created through the container and 3 twins that the container simply adopted on its own: LDPR, binary, foaf:PrimaryTopic 16:42:42 Then ask whatever questions you want about each, and show the result. 16:42:49 1: members 16:42:56 2: created 16:43:12 3: managed (if that's different from created - I'm not positive of your meaning) 16:43:15 that's what we do in read-write-web 16:43:31 maybe there are others, but we've talked at least about those 3 16:45:32 @bblfish: perhaps narrow, but I was talking simply about membership triples. Given the representation of an LDPC, the spec today [I assert] tells you unambiguously how to find its membership triples, and (by knowing the pattern from our friendly predicates) therefore a well-defined notion of membership. 16:46:09 I am taking 'member' to mean the variable in those membership triples. 16:46:28 ok so why not define ldp:member as the relation between a container and an LDPR such that you can deduce from the other statements and the ldp:membershipXXX statements those ldp:member statements 16:47:06 Maybe people don't think that's the right definition - I allow that this can be true. All I argue is that "membership" in that sense is well-defined today. 16:47:45 ok. so if you can help us write a rule using ldp:membershipXXX to an ldp:member statement then we can define ldp:member using the current spec 16:49:23 @bblfish: I allow that such a definition might be possible. When you open with "why not..." I'm never sure if you're thinking our loud or what. 16:50:11 { ?ldpc ldp:membershipSubject ?subj; ldp:memberhshipPredicate ?pred; ldp:membershipObject ?rel . ?subj ?pred ?ldpr. ?ldp ?rel ?obj } => { ?ldpc ldp:member ?obj } . 16:50:22 @bblfish: and the intent of ldp:member is to express exactly the same thing as XXX does today? or something different (how does it differ)? 16:50:24 something like that 16:50:56 I am trying to show how you can go from the membershipXXX and other statments to information about the resource that the LDPC manages . 16:51:16 I think the spec is full of those types of definitions. 16:51:59 we already know that Alex's desire to "find" the LDPRs corresponding to binary members created through the LDPC (linked via type=meta today in the 201 response) would not be satisfied by the current definition of 'member' 16:52:58 until I understand the boundaries of your use of 'manages' ... what's inside, what's outside it... it's incredibly easy to think we agree even if we don't. 16:53:04 The spec requires such a definition of ldp:member. The problem is that it's not workable. 16:53:21 because of the point alex made. 16:53:28 in his email. 16:53:54 so you need to take ldp:member as basic 16:54:24 ?ldpr ldp:member ?ldpr . is true iff 16:54:46 1. ?ldpc created the ?ldpr with POST 16:54:58 2. deleting the ?ldpr makes the statement false. 16:56:07 currently some people deny 1, because they believe they can have the rule I wrote up above. 16:56:12 but they can't 16:58:17 Chasing all the indexicals here is exhausting. Perhaps we can use some combination of wiki/email to more precisely articulate things. 17:00:27 fine 17:00:43 What wiki page do you suggest? 17:01:22 I have no pref. use 81 if you want, you've already got some content there. or new one, if you want to do this semi-privately for a while. 17:01:54 I suspect that until it's at some level of maturity, the rest of the WG won't really be appreciative of what might seem to them like spam. 17:03:03 yes, it's really difficult to get this right. 17:03:24 I think Alex makes the point very well in his e-mail to be frank. 17:03:57 It should be obvious that there is a problem, because the more we point out issues the more complex the spec becomes 17:04:10 and we are in fact trying to simplify the spec. 17:55:25 SteveS has joined #ldp 18:20:57 SteveS, JohnArwe, 5.3 GET: membership triples has a bad href 18:28:38 ericP, IRC is not a reliable source to get editors to fix things. Having said that, I'll fix it 18:37:01 yeah, but how do you know that IRC is a good way to get me to improve my behavior? 18:37:12 noted. signing off for dinner 18:50:58 Zakim has left #ldp 19:00:25 JohnArwe: does this definition help http://www.w3.org/2012/ldp/wiki/Member ? 21:48:21 bhyland has joined #ldp 21:59:59 gavinc has joined #ldp 23:36:15 davidwood has joined #ldp