Re: volunteering for the army

On 25 Feb 2014, at 19:06, Sandro Hawke <sandro@w3.org> wrote:

> On 02/25/2014 12:19 PM, Roger Menday wrote:
>> 
>> On 25 Feb 2014, at 16:41, Sandro Hawke wrote:
>>> On 02/25/2014 11:35 AM, Roger Menday wrote:
>>>> 
>>>> On 25 Feb 2014, at 16:22, Sandro Hawke wrote:
>>>>> On 02/25/2014 08:38 AM, henry.story@bblfish.net wrote:
>>>>>> 
>>>>>> On 25 Feb 2014, at 11:36, Sandro Hawke <sandro@w3.org> wrote:
>>>>>> 
>>>>>>> I didn't want to talk about this more since I didn't think it was critical to the current decisions the WG has to make, but in arguing with Henry during the meeting yesterday I expressed a solution that I want to express here:
>>>>>>> 
>>>>>>> Clients (and their users) doing POST are responsible only for the statements actually made in the posted representation.  If the server chooses to publish other triples in response to the POST, eg membership triples in the container, those are the responsibility of the server, not the client, even if the client had reason to believe the server would add those membership triples in response to the POSTing.
>>>>>>> 
>>>>>> This completely goes against the way the protocol has been built up to now.
>>>>> 
>>>>> There are lots of different pieces built up.    It doesn't necessarily align with all of them, but it doesn't contradict any of them.
>>>>> 
>>>>>> It does not really make sense
>>>>>> to have a type of container such as a ldp:DirectContainer which 
>>>>>> 
>>>>>>  1) MUST have the membership properties, 
>>>>>>  2) makes explicit the relation between those membership properties and how a POST action to the LDPC 
>>>>>>      creates a membership statements.
>>>>>> 
>>>>>> and then to say that 
>>>>>> 
>>>>>>   3) a client  need only understand the content of the POSTed graph, and not the necessarily
>>>>>> subsequent creation of the membership triple. 
>>>>>> 
>>>>>> What then would be the point of the membership triple?
>>>>> 
>>>>> It's the difference between (1) me signing a legal form as part of the process of walking into a room and (2) someone writing down the names of the people in a room.    In first case I'm obligated by whatever the form says; in the second I'm not obligated in any way.  Both are things that happen in human society.
>>>>> 
>>>>> I'm suggesting we don't *need* LDP to enforce the semantics of the first.   Personally, I think it's a lot more complicated to say LDP requires this obligation framework.
>>>>> 
>>>>>> It is always possible for the server to
>>>>>> add triples somewhere else on creation of a container, without all the membership triple framework.
>>>>> 
>>>>> Yes.    The people who've argued for membership triples are not, I think, arguing because they want the client to be obligated purely by dint of posting an empty message.   If they are, I'd like to talk them out of that position.
>>>>> 
>>>>>> A normal ldp:BasicContainer can do that.
>>>>>> 
>>>>>>> Since I think it's good practice for the post to include the membership triples, there wouldn't normally be any issue -- both client and server would be taking responsibility for the membership triples.
>>>>>> Here you seem to be contradicting what you said above. You can't both have the client be responsible for it, and 
>>>>>> not be responsible for it. 
>>>>> 
>>>>> There is no contradiction.    The client is responsible for the triples in the body of its posting and thus in the representation of the new Resource.  The server is responsible for the triples in the representation of the container.   If the same triple appears in both places, then both of them are accepting responsibility for it.   If it only appears in one, then only one of them is.  If it appears in neither, then, of course, neither of them is.
>>>>> 
>>>>> The examples of membership triples we've seen are things that would make sense, logically, to have in the member resource as well.    If they appear in both places, then both client and server would be taking responsibility for them.  Of course, a sensible client is only going to put them there if it understands them.
>>>>> 
>>>>> This is only part of the whole responsibility story, but I think it's enough to prove clients don't need to understand membership configurations in order to post.
>>>>> 
>>>>>     -- Sandro
>>>> 
>>>> hello Sandro, 
>>>> 
>>>> I think that a client does need to understand the membership configurations in order to POST. 
>>>> 
>>>> Of particular importance is the configuration previously known as "membershipPredicate". On a page with multiple <form>s, the membershipPredicate can be used to figure out which <form> to complete. 
>>>> 
>>> 
>>> The HTML analogy doesn't tell me enough.   What are the ldp clients in your scenario actually trying to do?
>>> 
>> 
>> All the usual stuff:
>> - add a bug to a bugsystem 
>> - add a new (sub)directory to a directory (?)
>> - add a new asset or liability to a networth  
>> 
>> I'm saying that for discovering the interaction possibilities of an application one needs to know both what the <form> processor is saying it will create (and how), as well as the link it will add between the creator and the created. 
>> 
> 
> Okay, can you dig a little farther into a simple one, like add-a-new-bug-report?
> 
> I'd think the application would be given the URL of a software project.  From there, it would follow some sort of link like doap:bug-database to an ldp:Container, which it would presume contains bug report, since this thing was referred to as a bug database.  When the user clicks 'submit new bug report', the client some RDF using some bug-describption vocabulary and POSTs it to that container.   If the server accepts that, the bug is now reported.

Let me give one answer in defence of Roger.

Relating to the following the links part of your story: We are on the web and so we want to be able to follow a link from any site to the bug report database. There may be links from sites that just list LDPCs, and there may be links that pointed to a LDPC that was once an insect collection service, but is now the bug database for the insect collection software. Ie links can be dead, or wrong. So it is important that the LDPC itself say what type of LDPC it is. 

Ways of a collection specifying how to limit what should be POSTed to it:

(1) There was a RDF Validation Workship last September [1] that is one way to specify what types of graph shapes a LDPC allows one to POST to it.
(2) The LDPC could indicate what the consequences of POSTing are:

   <> a ldp:DirectContainer;
        ldp:membershipResource <new#pile> ;
        ldp:isMembershipOfRelation baetle:state .

 if battle:state is defined as
 
  baetle:state a rdfs:Property
     rdfs:domain baetle:IssueDocument;
     rdfs:range baetle:State .

then a client would know that before POSTing something here it has to understand what an IssueDocument is,
and what a baetle:State is, and it has to accept that the relation of baetle:state from the 
baetle:IssueDocument to the <new#pile> be true.

 A client that did not understand that would not POST there for fear of sending his loving owner to the
Army.  ( But beware of robot upheavals predicted by  RFC4287 example 1.1 )

   Henry


[1] http://www.w3.org/2012/12/rdf-val/


> 
> How does that fall short of what you want?
> 
>        -- Sandro
> 
>> Roger
>> 
> 

Social Web Architect
http://bblfish.net/