- From: Sandro Hawke <sandro@w3.org>
- Date: Wed, 19 Feb 2014 18:58:13 -0500
- To: Steve Speicher <sspeiche@gmail.com>
- CC: Linked Data Platform WG <public-ldp-wg@w3.org>
- Message-ID: <53054515.6000201@w3.org>
On 02/19/2014 04:50 PM, Steve Speicher wrote:
> On Wed, Feb 19, 2014 at 4:16 PM, Sandro Hawke <sandro@w3.org
> <mailto: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
>> <mailto: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.
Yeah, that seems like a case where your server should say "sorry I don't
do PUT on containers" rather than as now, where the spec says ALL
servers SHOULD NOT allow it.
> 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.
Indeed. I expect I was on the calls, but frankly I've found most of
this stuff too abstract for me to understand until I started
implementing it.
> 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?
Well, today I'm trying to design an client library that makes LDP
servers easy to use from a client. Having membership and containment
be separate, partially overlapping concepts complicates things, and I
don't really see the motivation, but I guess the group does. I'm going
to reply to Arnaud with more on that.
-- Sandro
> - 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> |||||
>>> |
>>
>>
>
>
Received on Wednesday, 19 February 2014 23:58:21 UTC