Re: Proposal for containers

On 31 Jan 2013, at 11:25, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:

> hello all.
> 
> On 2013-01-31 9:51 , "Henry Story" <henry.story@bblfish.net> wrote:
>> On 30 Jan 2013, at 16:23, Ashok Malhotra <ashok.malhotra@oracle.com>
>> wrote:
>>> D. If you GET all members of a
>>> container that has nested components, you get all the contents,
>>> members and containers at the top level.  That is, you do not get nested
>>> components.
>> That is also very vague. I assume you mean "If you GET an LDPC resource"..
>> yes, that is how one expects containers to behave, but
>> I think that is somewhat beyond the scope of what needs to be defined.
>> When you GET a LDPC you get information about its contents (LDPRs and
>> LDPCs, 
>> and other). Minimally, you could get just a link to the members. Of course
>> the risk is that in order to work out what these are pointing to
>> a client would have to download each resource to find out.  So it is a
>> pragmatic thing to do to give some of the metadata needed for each
>> resource.
> 
> i think what ashok was saying was that if you GET a container, expect to
> GET representations of that container and its entries, which can be
> members or other containers. but do not expect to also GET the
> representations of these containers' content. instead, you'll find a link
> and if you follow this, you will GET that additional info. at least that
> was how i understood it, essentially a definition of where the graph you
> GET is cut of and instead contains links, and then the protocol tells you
> what you'll GET when you follow those links.
> 
> if i understand this correctly, then this will need to be defined by the
> protocol, because it defines the extent of the representations that are
> served (which graph to you GET), and those that are made available for
> subsequent protocol interactions (which links will you find to GET more
> information about things that were cut off in the previous representation).

So I think we have worked out that a requirement for an AtomPub 
application of LDP is going to be a notion of profiles. Which I 
detailed here:

http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0339.html

This is clearly not currently in the spec we have now. 
There is no way to define this clearly in RDF as is, though I suggest
a way to do it in the above mail.

So you should put that forward as a new issue.

Henry


> 
> cheers,
> 
> dret.
> 

Social Web Architect
http://bblfish.net/