Re: volunteering for the army

On 25 Feb 2014, at 18:06, Sandro Hawke 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.
> 
> How does that fall short of what you want?


First of all, what you describe above isn't something familiar from the HTML experience. We don't need to re-factor HTML pages to support adding (via create) a new thing to an existing list. I think we have implicit creators (containers if you like) which become the endpoints for form submission. 

LDP-wise I think it is possible to define a procedure which would re-factor IndirectContainers to BasicContainers, in a manner similar to what you say above. This re-factoring makes every container explicit in the model.  

[project] --bgs:hasbug--> [bugs]* 
  becomes 
[project] --doap:bug-database--> [basiccontainermanagingbugs] --contains--> [bugs]*

These explicit containers need new vocabulary. 

This then makes it very difficult to wrap LDP APIs around existing data, and to re-use existing vocabularies. It can also make SPARQLing more convoluted. 

Actually, I think it is less lossy to re-factor BasicContainers into IndirectContainers ... 

Roger