Re: TWO PROPOSALs involving Prefer - volunteering for the army -> ldp:index PROPOSAL

On 1 Mar 2014, at 02:31, Sandro Hawke <sandro@w3.org> wrote:

> On February 28, 2014 12:08:21 PM EST, "henry.story@bblfish.net" <henry.story@bblfish.net> wrote:
>> 
>> On 28 Feb 2014, at 16:32, Sandro Hawke <sandro@w3.org> wrote:
>> 
>>> On February 28, 2014 9:42:05 AM EST, Roger Menday <roger.menday@uk.fujitsu.com> wrote:
>>>>>>>> 
>>>>>>>> Why? Because I think the client that wants to POST to an ldp:DirectContainer or an ldp:IndirectContainer will want to do a conditional POST. Otherwise how does the client know that the server has not changed the membership properties between the time it read the content and the time the POST arrived? 
>>>>>>>> I wonder if this has been thought through enough? It seems to suggest that an ldp:(In)directContainer should not have its etag change unless those properties  change.
>>>>>>> 
>>>>>>> The Working Group has not accepted your proposal that clients MUST understand the membership triples before POSTing. I'm pretty sure manyof us would formally object to such a proposal.
>>>>>> 
>>>>>> I disagree. this is already in the current spec. I am just making what is there a bit more explicit by taking a admittedly extreeme example.
>>>>>> If you want to formally object what would be your  grounds for doing so?
>>>>> 
>>>>> My grounds would be that it would require clients to do things I do not believe they will do.   I could be persuaded by evidence of what real clients actually do.
>>>>> 
>>>>> Your examples are constraints on the server not the client.   When I buy something from the grocer, it precipitates a whole chain of events, some of which are visible to me and some of which are not.   I don't need to understand them all before I buy something.    If I were required to understand them all, I probably wouldn't buy as much.
>>>>> 
>>>>> You want every client to hard code the membership predicate it's going to find in a container and refuse to post if it's not there?  
>> 
>> Only for Direct and Indirect Containers.
>> 
> 
> Sure.
> 
>>>> A client will need to understand (and like) what will be created and
>>>> how it will be linked to decide if it wants to go ahead. 
>>>> 
>>> 
>>> I'm not sure what you mean by "understand" and "like" if you don't mean the client MUST get fetch the membership configuration and MUST match a pattern hardcoded into the client software, including the predicate URI.
>>> 
>>> I think that's overly restrictive, by quite a bit.     It could be useful to prevent a class of error, I suppose, but I think it will cause more problems than it solves.
>>> 
>>> I'm fairly sure most client implementors will ignore this rule, because it's easier on them and will probably result in fewer user complaints.
>> 
>> If we assume that clients are going to ignore all the Direct and IndirectContainer rules, then we should
>> not be trying to specify them. It would make the spec a lot simpler without them. 
>> 
> 
> I'm only saying they will ignore the rules if the rules are excessive.  

But the rules are not excessive. The rule is that the client understand the meaning of the membership triples that will be added as a consequence of the POST. It can gain this understanding by asking a human agent of course (as browsers currently do on an html form), or the client can be specialised on specific vocabularies, ( a meeting organiser for example ), or it can work with relations that are well understood to have little dangerous implications, such as ldp:contains. And since there exists an ldp:BasicContainer that clients can work with without danger, those that do not wish to take risks should use only that.

> 
> 
>> If we have them then we must assume clients do not ignore them, and that means that servers
>> can create services where they rely on the client understanding these relations. IF this takes
>> off and it is helpful then people will rely on their clients following the protocol correctly.
>> They will then be complaining in court if clients do ignore the rules. For example when a "ignore
>> the rules client" just POSTs something to an auction collection, which would be correctly 
>> interpretable as binding them to selling their goods.
>> 
>> 
> 
> I think this reflects an unrealistic, perhaps idealistic, expectation of how these systems will work.   
> 
> I'll back off the suggestion I would formally object, mostly because I have no plans to use direct or indirect containers.   It seems like a bad idea, but if everyone who uses these containers wants to say clients MUST recognize the member predicate, I won't stand in the way.

Ok so we can come back now to your TWO PROPOSALS which I started replying at here http://lists.w3.org/Archives/Public/public-ldp-wg/2014Feb/0124.html .

I agreed with your point that it would be very useful to have a URL for the resource that did not have either membership or contains relations triples. I agree with all these reasons you put forward there:

> It makes updating the empty-container triples easier, because you can just PUT or PATCH to them, without worrying about the membership triples changing at the same time.   It might make change notification and access control easier, since there's a clear way way to refer to the empty-contain triples separately.   It's a step toward allowing one set of clients access to to modify them but not another, etc.

And I'll add that I have wondered in my implementation how a client would be able to correctly to a PATCH in the current setup.

But to this I would like to add the additional use case, that comes from the existence of Direct and Indirect Containers, and that is that clients need to be able to do conditional POSTs. 

Since the important part of conditional POSTs is that the type of the container and the membership predicates don't change, and since the POST must be done on the LDPC, it follows that the content of the LDPC itself should be the empty container itself, or that the etag of the container be such that it only change when the non content and not membership triples don't change.

So we should try therefore to see if we can find an answer that satisfies both these requirements simultaneously.

PROPOSAL
-------

I can think of the following simple answer: create an ldp:index property

ldp:index a rdf:Property;
   rdfs:domain ldp:Container;
   rdfs:range ldp:RDFSource;
   rdfs:comment """
     relates an LDPC to a document that lists all the LDPCs ldp:contains relations
   """ .

for the membership properties there is already the ldp:membershipResource which if it points
to another LDPR solves the problem .

Advantages:

• The document pointed to can then be paged nicely like any other. 
• Clients can do meaningful PUT or PATCHes on an LDPC, to say change an LDP membership property
• Conditional POST on an LDPC now makes sense
• an LDPC would contain no ldp:contains directly - which was a problem for Roger Menday in the past
• It's easier to write access control rules on the LDPC: one can allow everybody to see the LDPC key properties, 
and limit access to the index to a smaller group of people ( or vice-versa )
• It's easy to defined ldp:index

That's all I can think of for the moment.


Social Web Architect
http://bblfish.net/

Received on Saturday, 1 March 2014 09:24:20 UTC