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

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