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

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.

  pa





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<http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe>
> Tivoli OSLC Lead - Show me the Scenario
>
>