MembershipInferencing

There is a major problem with the LDP spec which comes down to confusing logical and causal consequences.
Understanding this problem can resolve this Gordian Knot. But it requires escaping from the Status Quo.

This rule is meant to be read as being activated by a POST, which creates a resource named ?member, the rest being usual
SPARQL CONSTRUCT. That is that this rule is triggered by an action, it is not a logical rule that can be applied over existing
triples.

2 Problems

2.1 missing function from object to LDPR member

This problem arises from the "membership triple" => ldp:member rule described above.

In only some cases is it possible to find the LDPR that contains the ?object. This is when the ?object
is for example a relative <#uri> to the document. But when it is not such a URI it is not possible to
find the member ( )

2.2 Changing the LDPC membership relations

This problem arises from the "membership triple" <=> ldp:member rules described above, but not for the Causal/Contractual rule.

If any of the membership relations changes then the spec does not describe what
should happen to the membership triples. They need to all change or else the
client won't be able to find the ldp:member. The spec does not explain what the
consequences of changing this rule is.

2.2.1 ldp:member => membership triples

For example start with the following LDPC and applying the rule from ldp:member to

If one then changes the ldp:containsRelation to rel:loves
then a client may no longer infer any ldp:member relation.

2.3 superfluous

When adding a feature to a spec there needs to be good reason to do so.
But if one can go from membership triples to ldp:member properties - which
is getting to be quite a complex piece of reasoning for the client - then
it will be much easier to run the inverse reasoning starting from ldp:member relations
+ a rule to the membership properties. Why not just make the life easier
for the client and have the inverse reasoning take place? But then we might
as well leave that to a later spec.

This reason problem does not apply to the "causal/contractual consequence rule".

3 Simpler Solutions

3.1 list ldp:member explicitly

3.1.1 Advantages

requires no reasoning on simpler clients to find the ldp:members

no membership triples for each container required: when they don't exist one just can't infer any membership triples

removes an extra binding between the LDPR and the created membership properties ( when someone edits the object in an LDPR that is pointed to by the ldp:insertedContentRelation relation )

if one thinks of ldp:membershipXXX triples in terms of reasoning ( as above ) one could still deduce the membership triples with a rule such as the following which could be applied to a graph that only contains ldp:member relations.

3.2.2 Disadvantages

If one wishes to keep the membership rules then think of them not as rules to find ldp:members
but instead of as rules to help the client know what he is committed to when POSTing, ie in terms of
a request for state change as Erik Wilde would put it.
( note: that you can't request something without being in agreement with the consequences of what you request )

So instead of the above rule one would think of the membershipXXX statements as
describing the consequences of what one is committed to when POSTing. (Not all consequences, but as with
a contract, the consequences the client needs to be aware of). The server
still lists all the ldp:members as in the previous solution but when it finds ldp:membershipXXX
properties then it knows that on creation the certain relations will appear.
This could perhaps be described by a rule such as:

This way of looking at the situation allows all of the membership triples to be dropped on vanilla
servers, because all they say is what consequences follow on LDPR creation. LDPR Creation still always
add an ldp:member relation to the created LDPR, so there is no breaking of monotonicity.

Furthermore there is good reason to have such a feature: it is not superfluous. When someone
POSTs something to a shopping cart they do bind themselves to some action ( that of buying ).
Same when someone POSTs a form to buy an airplane ticket. It makes sense to have similar
functionality in LDP. See also "Volunteering for the army" example.

3.3.1 Theoretical Underpinning

Since the LDP spec is about communication acts over HTTP - what does a GET, PUT, POST, etc... mean - the theoretical space to look at this is the Theory of Speech Acts,
whose most famous American expositor is John Searle, Professor at Berkeley. His most recent book Making the Social World: The Structure of Human Civilisation" summarises
his work over the past 50 years. Most interactions in human civilisation are based on speech acts, that tie the speaker to something: be it the truth of what he says, or to
a contract he is signing, or to a promise he made, etc... In the Web these types of actions are tied to POST semantics - which are non-indempotent. They have consequences.
This is not new to the W3C. Dan Connolly, one of the founding contributors of the Web, wrote up something on the subject A Model of Authority in the Web.

3.3.2 Advantages

save us from specifying all these corner cases that we have currently and that need to be added if one is to fix the above issues

requires no reasoning on simpler clients to find the ldp:members

no membership triples for each container needed ( when they don't exist one knows there is no more consequences other than the creation of an ldp:member )

One can change the membershipTriples over the course of a container's lifetime. Consequences of previous POSTs need not affect consequence of future POSTs. ( Just as changing the law does not make previous behavior that might have falled under the law illegal)

It seems to be useful thing to have

If this is useful, then it is necessary to have it now, and not to put it in later (because otherwise clients developed now, will not know the consequences of their actions in future versions of LDP ( eg: "Volunteering for the army" )

3.3.3 Notes

A Client that does not understand the ldp:membershipXXX relation objects, MUST NOT POST to the container, as this would otherwise bind the user of the client to the statement that is the consequence of the POST. See theVolunteering for the Army email.

Not all consequences of a POST are important: only those that bind the user when POSTing. That is the one described by the membershipXXX relations.

3.4 Generalisation: multiple consequences

Once one thinks in terms of causal consequence, in terms of the consequence of actions ( especially POSTing ) then one can
see that limiting oneself to one state change is somewhat arbitrary. This can be made clear by having a relation to the
rule such as ldp:creationConsequence that could be written out like this: