Re: How to find the members of an LDPC?

Yes, I expected you to say that actually. :-)

One possible solution would be to make ldp:created mandatory when 
ldp:insertContentRelation is anything other than ldp:MemberSubject.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group


Alexandre Bertails <bertails@w3.org> wrote on 11/07/2013 05:33:44 PM:

> From: Alexandre Bertails <bertails@w3.org>
> To: Arnaud Le Hors/Cupertino/IBM@IBMUS, 
> Cc: Linked Data Platform WG <public-ldp-wg@w3.org>
> Date: 11/07/2013 05:33 PM
> Subject: 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.
> >  >
> >  >
> >
> >
> >
>