Re: How to find the members of an LDPC?

Hi Alexandre,

As Henry pointed out we have ldp:created. See 
http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpc-5_4_14
Doesn't that address your problem?

In your example after the POST you would have:

$ GET http://example.com/shopping/cart/
[[
</shopping/cart/> a ldp:Container;
    ldp:containerResource <#>;
    ldp:containsRelation order:contains;
    ldp:insertedContentRelation foaf:primaryTopic;
    ldp:created <the_url_of_the_resource_that_was_created>.

<#> order:contains <urn:isbn:0470396792>.
]]

$ GET <the_url_of_the_resource_that_was_created>
[[
<> foaf:primaryTopic <urn:isbn:0470396792> .
]]

Best regards.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group




From:   Alexandre Bertails <bertails@w3.org>
To:     Steve Speicher <sspeiche@gmail.com>, 
Cc:     Linked Data Platform WG <public-ldp-wg@w3.org>
Date:   11/07/2013 08:47 AM
Subject:        Re: How to find the members of an LDPC?



On 11/06/2013 09:01 AM, Steve Speicher wrote:
> Hi,
>
>
> On Tue, Nov 5, 2013 at 7:49 PM, Alexandre Bertails <bertails@w3.org
> <mailto:bertails@w3.org>> wrote:
>
>     Hi guys,
>
>     I understand ldp:containerResource, ldp:containsRelation and
>     ldp:insertedContentRelation as a _set of instructions_ for the LDPC 
to
>     manage some domain-based relations, but I don't see a way to find 
the
>     LDPRs created by the LDPC.
>
>     Please consider the following example:
>
>     $ GET http://example.com/shopping/__cart/
>     <http://example.com/shopping/cart/>
>
>     [[
>     </shopping/cart/> a ldp:Container;
>         ldp:containerResource <#>;
>         ldp:containsRelation order:contains;
>         ldp:insertedContentRelation foaf:primaryTopic.
>     ]]
>
>     $ POST http://example.com/shopping/__cart/
>     <http://example.com/shopping/cart/>
>
>     [[
>     <> foaf:primaryTopic <urn:isbn:0470396792> .
>     ]]
>
>     $ GET http://example.com/shopping/__cart/
>     <http://example.com/shopping/cart/>
>
>     [[
>     </shopping/cart/> a ldp:Container;
>         ldp:containerResource <#>;
>         ldp:containsRelation order:contains;
>         ldp:insertedContentRelation foaf:primaryTopic.
>
>     <#> order:contains <urn:isbn:0470396792>
>     ]]
>
>     Question: from the last GET, what is the LDPR for 
<urn:isbn:0470396792>?
>
>
>     If the ldp:member relation does not exist, how would a client deduce
>     the members that were created
>
>     ?
>
>
> One would assume that the POST would return a 201-Created status message
> and Location header of the URL for the new resource created.  The server
> may produce another triple to link the created resource (LDPR), not sure
> what it might be:
>      <> ex:describes <#>.

For any Web API I have played with, listing (or querying) a
container/collection to retrieve the members it created was a basic
feature.

Adding an ldp:member predicate which makes explicit the membership
relation between an LDPC and its LDPRs. But the ldp:containerResource
+ ldp:containsRelation + ldp:insertedContentRelation thing (can we
have a name for _what_ this is?) is something different. I'm not
saying this is useless, but it addresses a different problem and it's
hard to justify why all application developers would have to deal with
that while simple interactions are not there.

>
>     What really matters as client is to know what interactions are
>     possible. If an interaction model were to be defined, I would expect
>     to see something like that:
>
>     1. HTTP HEAD on </foo/> tells client "I am an LDPC" as it returns a
>     header
>         Link: <http://www.w3.org/ns/ldp#__Container
>     <http://www.w3.org/ns/ldp#Container>>; rel="type"
>
>     2. from a GET on </foo/>, a client finds/deduces the LDPRs managed 
by
>         </foo/> eg. with triples like { </foo/> ldp:member </foo/bar> }
>
>     3. HTTP HEAD on </foo/bar> tells client "I am an LDPR" as it returns
>     a header
>         Link: <http://www.w3.org/ns/ldp#__Resource
>     <http://www.w3.org/ns/ldp#Resource>>; rel="type"
>
>     4. HTTP DELETE on </foo/bar> MUST remove the LDPR and remove
>         { </foo/> ldp:member </foo/bar> } from the LDPC
>
> This is the interaction model defined by LDP ... with the exception of
> ldp:member this isn't defined but think you are saying
> ldp:containsRelation.  I can't tell if you are saying there is something
> missing or you are just describing roughly how it works.

We already know that the interaction is not hypermedia driven as we
agreed not to define a new media-type for LDP. Instead we have a Link
header for Resource. But I still need to look at the payload to know
about what interaction is possible with the resource. That means that
1. and 3. don't really work like in my example.

ldp:containsRelation is just an instruction targeting the LDPC to
manage some domain-related triples. So 2. just doesn't hold at all.

Finally, 4. is really odd as I have no way (in the general case) to
know that an LDPC manages an LDPR or not.

So yes, there are apparently several people believing that there are
basic missing things, and some incidental complexity which is hard to
justify.

Alexandre.

>
> - Steve
>
>     Alexandre.
>
>