Re: ldp-ISSUE-58 (membersInlined): Property for asserting that complete description of members is included [Linked Data Platform core]

Roger,

On Mon, Apr 15, 2013 at 6:03 PM, Roger Menday
<roger.menday@uk.fujitsu.com>wrote:

>
> hi Pierre-Antoine,
>
> So in your proposal there would be "X-Cachable-for" header elements for
> each linked resource which is served 'complete' (from the point of view of
> the server) ?
>

yes

>
> Secondly, I get your point in your first paragraph about it not being a
> property of the involved resources, but, by the same token, neither is
> ldp:next for when it comes to pagination (??)
>

ldp:next is different, IMO, as it is not applied to the container URI
directly, it applies to other URIs (e.g. <?firstPage> of <?p=2>). The fact
that those other URIs can be derived from the container URI does not change
the fact that they are distinct from it, so they (can) denote different
resources; in this case, I would consider that they denote "pages", and one
page is indeed the next of another one.

  pa


>
>
> Roger
>
> On 15 Apr 2013, at 16:47, Pierre-Antoine Champin wrote:
>
> 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
>>
>>
>>
>>
>>
>>
>>
>>
>
>