updated ISSUE-71: membershipX description

I have now updated the ISSUE-71 description as promised summarising the work of the past
2 weeks:
-----------------

There are a lot of arguments against membershipXXX relations:

- ISSUE-75 monotonicity: there is a deep semantic problem with the default values of the properties. Removing default values won't solve the problem, as then there is a modelling problem: these relations should be thought of as rules that help one to conclude to the ldp:contains relations - but in that case they need to be modelled via blank nodes
<> a ldp:Container;
ldp:membership [ predicate x:attachment; subject <..> ]
as explained in http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0335.html

- ISSUE-78 inferencing: but if these are disguised inferencing rules then we are probably going beyond the minimal desirable requirement on clients expressed in the spec. 

- ISSUE-72 membershipObject: without an object version of the properties one is seriously limiting what can be expressed by the rule, and one shoehorns developers into failing to distinguish LDPRs from non information resources, ie fails to distinguish documents from what they are about. This means that one makes it difficult to express document authorship and copyright properties.

The above arguments show that one needs to remove the ldp:membershipXXX relations.

Replacing the lost functionality:
---------------------------

The question then is with what does one replace the lost functionality. ( This should perhaps be a new issue ). For that one needs to be very clear as to what the use cases for these relations are. The best use case I have seen so far is Steve Speicher's bug example:
http://lists.w3.org/Archives/Public/public-ldp-wg/2013May/0250.html
which shows that the aim has been to allow an ldpr to tell the user how by POSTing to an LDPC he can create a relation from the ?ldpr ( or a resource defined within it ) to the newly created resource ( or with ISSUE-72 to a newly created resource defined within it )

But this is compatible with it being possible for non-reasoning clients ( ISSUE-78 ) to read LDPCs and work out what the ldpc's members are ( ISSUE-73 (rdf:member) and ISSUE-79 (ldp:contains)), without needing to do that reasoning. Ie: it would be better to list the ldp:members in LDPCs clearly, and have the reasoning be there to tell clients what the effect of POSTing a new resource will be: create a new relation ( and if possible do this declaratively ). Currently it is the opposite that is happening: reasoning is required to tell what the members of an ldpc is.

One should perhaps also consider that one could do without the rules telling a client how to add a new relation by POSTing to a LDPC. That is one could allow the client to 
1. Create a new LDPR by POSTing to an LDPC
2. Add a relation from some LDPRs to the LDPC using PATCH

Or one could define consistency spaces. Ie the client could POST information with the required links, and the server would add bidirectional relations POSTed by the client. Ie perhaps in the bug example the client can POST relations with links to the existing LDPR. 

~~~~POST /ldpc/ HTTP/1.1 ~~~~~~~~~~
<otherbug#bug> beatle:relatesTo <> .
<> a beatle:BugReport;
dc:title "Another silly bug";
dc:author </joe#me> ;
...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

And the client would know that the server is going to add

<otherbug#bug> beatle:relatesTo <> . 

to <otherbug>

There may be other ways to get the same functionality and better if one starts to think
about this problem afresh. 



Social Web Architect
http://bblfish.net/

Received on Monday, 3 June 2013 06:49:56 UTC