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

On Mon, May 6, 2013 at 8:42 PM, Steve Speicher <sspeiche@gmail.com> wrote:

> 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?
>

Yes, but that is equally true of someone having a stale representation of
the resource, and wanting to update it.
My point is: there are already cases when you need an extra GET before you
can do a PUT. This proposal just adds one to the list.


> 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 ;)
>

Exactly :) It appears, after this discussion, that inlining is no silver
bullet. It can prevent unnecessary GETs in *some* situations, but not all,
whichever option we chose.

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"
>

Do you expect these ETags to be "recognized" by the member when GETing ot
PUTing its URI?
About GET, this seems farfetched, as it is not *really* the same content.
About PUT, this seems also risky, as you trust the client for pruning all
the irrelevant triples...

I would rather have no ETag attached to the cache entries generated by
option D,
so that subsequent requests to the member URI will set things straight.

  pa


> - 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
> >>
> >
>