ISSUE-81: Confusing membership* predicate names and other possible improvements

I have added the following to the wiki: http://www.w3.org/2012/ldp/wiki/ISSUE-81 

This proposal is a suggestion for an improvement to build on top of whatever comes out of Part I. This is a structural improvement that would reduce the redundancy found in 1. The proposal is to not have 3 relations from the LDPC, but rather have 1 relation from the LDPC to a blank node which itself then has 3 relations.
<> a ldp:Container;
    ldp:creationRule [ ldp:subject <../card#me>;
                       ldp:predicate foaf:knows;
                       ldp:rangeSelector foaf:primaryTopic ] .
The names for ldp:subject, ldp:predicate, ldp:rangeSelector, can be taken to be those people prefer in Part 1 above.
By default creation in an LDPC ?c of an LDPR ?r makes the following statement true:
 ?c ldp:created ?r .
The creationRule is just the statement of a pragmatic consequence of creating a resource in that particular LDPC. There could be one or more such rules, and so also the ldp:creationRule could be missing ( a vanilla server? ) This makes it easier to understand what the membershipXXX rules are about: they don't specify new membership predicates, but they specify a rule that makes it possible to deduce some things from the existence of an ldp:created relation - and it seems this groups wants the relation to be an if and only if relation: that is that if the ldp:created relation is not to be found but the other relations exist one can deduce the existence of the ldp:created relation.
This does not I think have the problems of monotonicty that were found to be existing in the original ldp:membershipXXX relations.



Social Web Architect
http://bblfish.net/