W3C home > Mailing lists > Public > public-ldp@w3.org > February 2014

Re: volunteering for the army

From: Sandro Hawke <sandro@w3.org>
Date: Tue, 25 Feb 2014 11:41:09 -0500
Message-ID: <530CC7A5.5020405@w3.org>
To: Roger Menday <roger.menday@uk.fujitsu.com>
CC: "henry.story@bblfish.net" <henry.story@bblfish.net>, Soiland-Reyes Stian <soiland-reyes@cs.manchester.ac.uk>, Steve K Speicher <sspeiche@gmail.com>, public-ldp <public-ldp@w3.org>
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?

         - s

> Roger
Received on Tuesday, 25 February 2014 16:41:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:16:36 UTC