Re: On ISSUE-58: Property for asserting that complete description of members is included in LDPC representation

On Mon, May 6, 2013 at 12:04 PM, Pierre-Antoine Champin
<pierre-antoine.champin@liris.cnrs.fr> wrote:
> John, all,
>
> granted, the X-Cacheable-for is a hack, in a way, because the container's
> representation (CR) is *not* the representation that you would get for the
> member (MR). My intuition was that, since the CR inlines the MR (my reading
> of that being: it parses to a superset of its triples), it can be used *in
> place* of the MR.
>
> True, this assumes that the client will know what to *look for* in the MR,
> and will gracefully ignore spurious triples from the CR. This might be too
> strong an assumption in the general case, but I think it also affects other
> solutions. Granted, other solutions are less opaque (operating at the RDF
> level, and not the HTTP level), but still, they can't tell the client which
> triples belong to which representation.
>
> True also, a client might want to PUT the CR back to the member URI -- which
> would be perfectly valid from an HTTP point of view, but may lead to
> undesirable results. I confess I had overlooked that point. This won't be a
> problem if the server requires If-Match: with a correct etag for PUT
> requests, but as this is only a SHOULD in the LDP-REC, but LDP-server are
> not mandated to require that.
> So if we adopt the X-Cacheable-for solution, we should probly state that
> servers using it MUST require If-Match: headers in PUT requests.
>

This would seem to imply that in order to get the correct etag, the
client would need to GET first the resource and then PUT back with
updates and If-Match.  Though if I had a PATCH solution, I might want
to use the etag without the full resource?

Separately, I think it is fair to say that it is questionable whether
the MR within the CR could accurately use this to update an HTTP local
cache.  Though it may have a LDP-R cache where it could help.
Obviously Richard thought so, that is why he opened the issue to begin
with ;)

So something like this could evolve for D (and possibly others):

LDP-Inlined-Member: <http://example.org/netWorth/nw1/a1>;
ETag="737060cd8c284d8af7ad3082f209582d"
LDP-Inlined-Member: <http://example.org/netWorth/nw1/a2>;
ETag="737060cd8c284d8af7ad3082f209582e"

- Steve

>
>
> On Mon, May 6, 2013 at 4:15 PM, John Arwe <johnarwe@us.ibm.com> wrote:
>>
>> > This issue of knowing which triples belong to which resource applies
>> > to equally to all the four options, right ? Though we discuss it in
>>
>> The options are asserting markedly different things.
>>
>> All of them do assert (at the RDF level) that the response triples include
>> all the triples one would get by retrieving the named members as well.
>>
>> None of them make any assertion about the correspondence between HTTP
>> resources and triples returned.
>>
>> That is sufficient for the simplest container-client case (query).  I
>> think it wholly insufficient for any scenario involving later replacement
>> (PUT) of the intervening resources, in the absence of assumptions about the
>> relationship between triple subjects and HTTP resources (other thread).  In
>> other words, if you intend to replace the members later I do not see how you
>> are going to avoid getting those members first.  PATCH, being more
>> incremental, might be less of an issue.
>>
>> Best Regards, John
>>
>> Voice US 845-435-9470  BluePages
>> Tivoli OSLC Lead - Show me the Scenario
>>
>

Received on Monday, 6 May 2013 18:43:00 UTC