Re: volunteering for the army

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 
>>>>> <mailto: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.

How does that fall short of what you want?

        -- Sandro

> Roger
>