Re: clarifying containment vs membership

On Wed, Feb 19, 2014 at 4:16 PM, Sandro Hawke <sandro@w3.org> wrote:

>  On 02/19/2014 02:09 PM, Steve Speicher wrote:
>
>
>  On Wed, Feb 19, 2014 at 12:34 PM, Sandro Hawke <sandro@w3.org> wrote:
>
>>  On 02/19/2014 12:18 PM, Sandro Hawke wrote:
>>
>> As I read the spec, it seems to me that normally a container contains
>> exactly the same resources it has as members.
>>
>> The one circumstance I can see where this would not be true is when
>> ldp:insertedContentRelation is used.
>>
>> I think this is reasonable, but I'm not at all sure I'm reading things
>> right.
>>
>>
>>  To be clear, some people think I'm not.   The spec says, very
>> cryptically:
>>
>> A LDP Direct Container or LDP Container's membership triples MAY also be
>> modified via through other means.
>>
>> Like what?     It also says, "LDP servers SHOULD NOT allow HTTP PUT to
>> update a LDPC's membership triples", so... what are those other means.   Is
>> it the cases of the server violating the "SHOULD NOT"?
>>
>
>  PATCH or application specific behavior (like membership triples may just
> appear, such as events in a log on the server).  I wonder if SHOULD NOT is
> right after the containment resolution.  Personally I'd like to just
> generalize it to say "LDP servers SHOULD NOT allow HTTP PUT to update a
> LDPC but instead use PATCH." and we'd avoid other problems.
>
>
>
> Ah.   What's wrong with PUT, then?     PUT is semantically the same as
> PATCH, just slower.     I took the prohibition on PUT to be a prohibition
> on changing the membership triples.
>
> That is because you are a quad-store thinking kind of guy.  I have a
product built on various storage technologies (including quad-stores) that
exposes its resources as LDP resources.  There is a hefty amount of
application code (access control, pulling from multiple data sources,
inter-resource dependencies, ...) that goes it in front of what an exposed
LDP R or C are.  So in order to properly (and efficiently) handing PUT, we
need to run it through the modify action of each requested change.  We
could diff the PUT request with current state of the resource and make up
our on PATCH, but as you can see there is inefficiencies in having to get
the resource and then diff it with the incoming entity body content.


> FWIW, given my current understanding, I strongly support a prohibition on
> changing membership triples.    The only way to put something in a
> container should be POST, or PUT to the container's declared URL space.
> And the only way to take it out should be to DELETE it.
>
> At the moment, I'm seeing a lot of cost and no value to letting things
> randomly and unpredictably make containment and membership not align with
> each other.
>

re: lot of cost and no value
Perhaps this is a case where you were unable to participate in some of the
recent discussions that has let us to the resolution of where we are at.
 See above for some of the sampling of LDP implementations

re: letting things randomly and unpredictably ... not align
Could this just be a limitation you impose on your server?  Allow header on
your container doesn't include PATCH/PUT?  Or you server cracks open the
PUT/PATCH request and rejects it if the client is trying to touch
membership and containment triples?

- Steve


> (I do support them being different for non-information resources.   In
> that case, the non-information resource is a member, and the information
> resource is contained.     There's probably a more-efficient way to
> represent that case, but whatever.)
>
> Of course people want membership-only "containers", but those are just RDF
> Collections or Containers  (Seq and List), or things that look like LDP
> containers, but there's no need for the server to know about them.   It
> just needs to know about containment so it can manage the lifecycle.
>
>       -- Sandro
>
>
>
>
>> The spec also says cryptically:
>>
>> This ldp:contains triple can be the only link from the container to the
>> newly created resource in certain cases.
>>
>>  which threw me off for a bit.   I think "in certain cases" should be
>> replaced by "until or unless more links are made."
>>
>
>  Yes, your suggestion is better.  Thanks.
>
>  - Steve
>
>>
>>
>>        -- Sandro
>>
>>
>>
>>   Is there some other circumstance where it's possible to have a resource
>> that is a member but is not contained, or is contained but is not a member?
>>
>> (I guess the current spec doesn't rule out the server making these sets
>> different for its own reasons, but I think the clients can't make it
>> happen, so I'm not too worried about it.   It would probably be best if
>> servers were forbidden from doing it, too.)
>>
>> BTW, I have an alternative proposal for ldp:insertedContentRelation
>> (which I think has some problems), but I want to make sure I understand the
>> context before I get into that.
>>
>>          -- Sandro
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>