Re: ldp-ISSUE-58 (membersInlined): Property for asserting that complete description of members is included [Linked Data Platform core] from Pierre-Antoine Champin on 2013-04-15 (public-ldp-wg@w3.org from April 2013)

From: Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr>
Date: Mon, 15 Apr 2013 17:47:12 +0200
To: Linked Data Platform Working Group <public-ldp-wg@w3.org>
Message-ID: <CA+OuRR9nQL2K6y0ky-wxeZtVBtW8mK9=1nmiCwzX3A1veuSkbg@mail.gmail.com>
Hello,

As discussed today during the conference, I feel a bit uncomfortable with
Richard's proposal,
because the "completely inlined" thing is not a property of the involved
resources (neither the container nor its items), but rather of the
*description* one gets. So this information seems to belong to the HTTP
header, rather than the RDF payload.

Furthermore, Richard's point is really about HTTP ("clients SHOULD NOT do
GET..."), so why not handle it at the HTTP level?

Proposal1: when a container inlines a complete description of some of its
members in its own description, it SHOULD include for each such member an
HTTP Header "X-Cacheable-For" whose value is the URI of the member. The
semantics of "X-Cacheable-For" is that the payload can be cached under that
URI, with the same cache attributes (max-age, etc.) as for the original URI.

"X-Cacheable-For" could be another name of course. I didn't find any HTTP
header with that semantics (or something close enough), but I may have
missed something.

An advantage is that it "naturally" addresses Ted's point about the need to
express "inline-ness" at the resource level rather than the container level.

Another advantage of this approach is that, if it is not implemented by the
client, it could still be implemented by a proxy between the client and the
server, thus "protecting" the server from careless clients.

An (minor) inconvenience is that a naive client would still have to parse
the representation for each member after GETting it back from the cache (as
we are working at the HTTP level, not at the triple level). But a smart
client could optimize that.

Another inconvenience is interference with PUT, because clients could then
be tempted to PUT the whole container description to the inlined member.
This can be avoided by requiring If-Match on PUT requests, and ensure that
the container's representation's etag do not match the member's.

  pa


On Mon, Apr 15, 2013 at 4:21 PM, Ted Thibodeau Jr <tthibodeau@openlinksw.com
> wrote:

>
> On Apr 15, 2013, at 09:46 AM, Henry Story wrote:
>
> >
> > On 15 Mar 2013, at 18:51, Linked Data Platform (LDP) Working Group Issue
> Tracker <sysbot+tracker@w3.org> wrote:
> >
> >> ldp-ISSUE-58 (membersInlined): Property for asserting that complete
> description of members is included [Linked Data Platform core]
> >>
> >> http://www.w3.org/2012/ldp/track/issues/58
> >>
> >> Raised by: Richard Cyganiak
> >> On product: Linked Data Platform core
> >>
> >> The spec already allows adding partial descriptions of members to the
> container representation. If these descriptions happen to be *complete*,
> then it would be nice to be able to indicate that fact. So that a client
> doesn't have to dereference each member in order to be sure that it has
> complete data.
> >>
> >> PROPOSAL: Add a property ldp:membersInlined true/false. The default (if
> not specified) is false. If true, it means that a complete description of
> all members [on the current page] are inlined with the container document
> [or page], and therefore clients SHOULD NOT do GET on the member URIs to
> retrieve additional triples.
> >
> > so this would be something like
> >
> > @prefix log: <http://www.w3.org/2000/10/swap/log#> .
> >
> > <> rdfs:member <mbr1> .
> > <> log:includes <mbr1> .
> >
> > And the log vocabulary is described here:
> > http://www.w3.org/2000/10/swap/doc/CwmBuiltins
> >
> > I am not sure if <> is a formula under that definition or if mbr1 is.
> But it is close. What is sure is the object of the log:includes relation,
> or the object of the proposed ldp:membersInlined relation must be an
> information resource  otherwise this won't work: if it is a pysical object
> object such as the Eiffel Tower or the Well in my garden, then you can't
> make statements in an open world limiting the number of relations such an
> object has. On the other had it is quite possible to limit the relations in
> a document.
>
> Henry --
>
> The "complete description" isn't meant as "all attributes of the
> entity being described are included here", but "all attributes of
> the entity being described *of which the server is aware* are
> included here."
>
> The point being, the client need not (and should not, to avoid
> putting excessive load on the server) request a description of
> entities with such inlined description -- because everything the
> client will receive on that following GET will echo what it's
> already received in the container description.
>
> All --
>
> I believe that any such ldp:membersInlined true/false attribute
> should be associated with each *member description* so the server
> could include the entirety of several short-descriptions but might
> also include partial long-descriptions -- and the client may not
> need further descriptions of anything, but if it does, then it will
> only benefit by GETs on the resources with long descriptions (which
> were partially delivered) -- and need not and should not GET on the
> resources which descriptions were already fully delivered.
>
> I believe that having only a *container*-based ldp:membersInlined
> true/false attribute will substantially lower its utility (as it
> will only be useful when all such "inlined descriptions" are short,
> and/or there are only a few entities having such).
>
> Having that container-based attribute *in addition to* a member-
> based attribute would be fine.
>
> Regards,
>
> Ted
>
>
> > Perhaps it would be better to use that log:includes relation? As to
> having a relation ldp:membersInlined be a relation to a string "true" or
> "false" seems a bad idea. It brings truth into the picture which is not an
> easy thing to do correctly, as truth should be a relation on graphs or
> documents too. log:includes at least makes the relation between the correct
> types of entities.
> >
> > Henry
> >
> >
> >>
> >>
> >
> > Social Web Architect
> > http://bblfish.net/
> >
>
> --
> A: Yes.                      http://www.guckes.net/faq/attribution.html
> | Q: Are you sure?
> | | A: Because it reverses the logical flow of conversation.
> | | | Q: Why is top posting frowned upon?
>
> Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
> Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com
>                              //              http://twitter.com/TallTed
> OpenLink Software, Inc.      //              http://www.openlinksw.com/
>          10 Burlington Mall Road, Suite 265, Burlington MA 01803
>      Weblog   -- http://www.openlinksw.com/blogs/
>      LinkedIn -- http://www.linkedin.com/company/openlink-software/
>      Twitter  -- http://twitter.com/OpenLink
>      Google+  -- http://plus.google.com/100570109519069333827/
>      Facebook -- http://www.facebook.com/OpenLinkSoftware
> Universal Data Access, Integration, and Management Technology Providers
>
>
>
>
>
>
>
>
Received on Monday, 15 April 2013 15:47:41 UTC