volunteering for the army

Sorry all for not being available the last two weeks. I have been thinking
a bit more about the ldp:membershipXXX relations as they are in the spec.
This builds on the ideas I put up in the proposals wiki
  http://www.w3.org/2012/ldp/wiki/ISSUE-81#Proposals_--_Part_1_.28a.29


So in summary I think one can defend the ldp:membershipXXX predicates on
good theoretical ground. I'll first explain what some of the current problems
are. Then I'll give an example that tries to explain clearly what the interaction
between a client and a server is like when ldp:membershipXXX are used. Finally
I'll propose a solution that will be both much clearer than what we have now,
whilst allowing us to treat the use cases people have fighting for.

Some initial problems 
----------------------

The best way to think of the ldp:membershipXXX relation is not as
they are thought of currently: as a way of creating relations on a container.
This won't do because:
 
 1. you can create a relation from another subject 
that is not an LDPC to another object that is not an LDPR. So at best the
membership on the container is a special case. It is not good to name something
by a special case.

 2. You can't even tell in all circumstances what the LDPR that is connected
 to the LDPC is, as Alexandre Bertails showed recently
    http://lists.w3.org/Archives/Public/public-ldp-wg/2013Nov/0018.html

But that DOES NOT MEAN they are not very important! It is just we need to think
about them differently. If we can work out what they do, then we'll have
a lot more chance to name them correctly, and also to make it a lot easier
to understand what they are for. 

  So on the wiki I thought of them as rules for going from ldp:created relations
to other relations. But that does not quite capture what is going on. If we think 
of the interactions between a client and a server  I think things will become a 
lot more obvious, and it will be easy to understand what one should use them for.

Volunteering for the Army
-------------------------

 So let us go through a simple example. We imagine a LDPC that you can post 
a description of your identity to.  But if you do that you are officially 
registered for 3 years military service.

Imagine a client sees something like this:

$ GET http://service.mil/signup

<> a ldp:Container;
   ldp:containerResource </2013/volunteers#w>;
   ldp:containsRelation mil:signup;
   ldp:insertedContentRelation foaf:primaryTopic.

The client reading this should understand that if it POSTs a
description to that collection with perhaps the following content

{ <> foaf:primaryTopic joe:blogs . }

the following things will happen:

1. a new LDPR will get created with some new name containing the
  content of the POSTed document such that 
  { <http://service.mil/signup> ldp:created ?newDoc } a log:Truth .

2. the LDPC will contain the following relation 
  { <http://service.mil/2013/volunteers#w> mil:signup joe:blogs . > } 

So a client that sees the above should ask itself if it agrees with 
those two statements that are the explicit consequences of its action.
In this case does it agree with: 

  (1) { <http://service.mil/signup> ldp:created ?newDoc } a log:Truth .
    presumably this is not much of an issue. The only thing the client should
    consider at that point are what the access control rules on the created document
    will be and if he can agree with those. ldp:created only has 2 consequences:
      - that the object of the relation exist
      - that deleting the object remove that relation from the LDPC

  (2) { <http://service.mil/2013/volunteers#w> mil:signup joe:blogs . > } 
     A client that considers this should be a lot more careful. If it does not
    understand the meaning of the mil:signup relaitonship then 
              IT SHOULD NOT POST!!!!
    If it does and agrees with the consequences then it is the right thing for 
    it to do. Otherwise it may have some time to reflect on its actions by listening
    for 3 years to http://www.youtube.com/watch?v=GXpF2xMlZyQ

So it follows from this that a client that does not understand the objects
of the ldp:membershipXXX relations should not POST to that container.


Theory
------

   The theoretical space we can look for guidance here is the
theory of speech acts. http://plato.stanford.edu/entries/speech-acts/
Dan Connolly had written up something along those lines:
  http://www.w3.org/2001/tag/dj9/story.html

In a marriage ceremy the priest saying "You are man and wife"
makes this the case. The same is happening here when one POSTs
to a container. The actions have consequences that the agent
doing the action needs to understand.

  What is happening. We could think that the client is binding
itself to the truth of the relations created by the ldp:membershipXXX
relations. 

Hence instead of my proposal on the wiki at
http://www.w3.org/2012/ldp/wiki/ISSUE-81#Proposals_--_Part_1_.28a.29

<> a ldp:Container;
    ldp:membershipRule [ ldp:subject <../card#me>;
                       ldp:predicate foaf:knows;
                       ldp:rangeSelector foaf:primaryTopic ] .

we might want to have

<> a ldp:Container;
    ldp:bind [ ldp:subject <../card#me>;
               ldp:predicate foaf:knows;
               ldp:rangeSelector foaf:primaryTopic ] .

Or perhaps 

<> a ldp:Container;
    ldp:postImplies [ ldp:subject <../card#me>;
                      ldp:predicate foaf:knows;
                      ldp:rangeSelector foaf:primaryTopic ] .


If you can think of a better name, please let me know.

Summary
-------

The problem of the current proposals:

1. There is no default, which means there are a number of relations that
have to be specified for each LDPC. This is heavy.
2. The reasons behind theses ldp:membershipXXX relations is unclear
3. One can only have one implicature
4. One cannot always deduce that LDPR created by a LDPC from the existing
relations

My proposal fixes all of those problems, while at the same time showing
why this is such a useful tool. It also gives a theorectical underpinning
for why we at LDPC are the first to have to deal with this: we are working
with the equivalent of speech acts in the web space which we could call 
document acts. In philosophy speech acts came to be recognised only around 40 years
after the logical foundations had been decided upon. We on the other hand
can use those discoveries to make our spec a lot easier to understand.


All the best,

	Henry


Social Web Architect
http://bblfish.net/

Received on Wednesday, 6 November 2013 14:35:55 UTC