Re: How to find the members of an LDPC?

On 11/07/2013 02:21 PM, Arnaud Le Hors wrote:
> 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?

Yes it does, but the fact it is optional is an issue, especially when
ldp:containsRelation is required. How does a client know that there is
no member?

Alexandre.

>
> 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.
>  >
>  >
>
>
>

Received on Friday, 8 November 2013 01:33:50 UTC