- From: Alexandre Bertails <bertails@w3.org>
- Date: Tue, 26 Nov 2013 11:39:29 -0500
- To: Steve Speicher <sspeiche@gmail.com>
- CC: "Linked Data Platform (LDP) Working Group" <public-ldp-wg@w3.org>
On 11/26/2013 08:08 AM, Steve Speicher wrote: > Hi, > > On Sat, Nov 23, 2013 at 11:51 AM, Alexandre Bertails <bertails@w3.org > <mailto:bertails@w3.org>> wrote: > > Actually, the more I think about it, the more I'm puzzled with what it > means being an LDPC. > > Sometimes, the LDPC is the RDF resource that has the type > ldp:Container (5.2.7). It is also the subject of the ldp:membershipXXX > triples. > > But I can also GET its representation (5.3.X). And I can POST to it > (5.4.X). > > This tension is well illustrated with Example 5 [2] as you're expected > to interact (GET, POST, etc.) with > <http://example.org/netWorth/__nw1/ <http://example.org/netWorth/nw1/>> > but not with <http://example.org/netWorth/__nw1/assetContainer/ > <http://example.org/netWorth/nw1/assetContainer/>>. > > <http://example.org/netWorth/nw1> is the LDPR, so you interact with it > if you want to do LDPR things to the resource. > <http://example.org/netWorth/__nw1/assetContainer/ > <http://example.org/netWorth/nw1/assetContainer/>> is the LDPC, > associated with the LDPR above to manage the same subject and same > predicate triples that identify the member resources (assets). With this example, I'm not sure what resource the membership triples belong to. Is it <http://example.org/netWorth/nw1/> because it's the subject of the membership triples? Or is it <http://example.org/netWorth/nw1/assetContainer/> because it's the LDPC? Or maybe both? It would be good to add a POST/GET scenario along with this example to answer that question. > I take your point from the other thread/issue, that may not be ideally > how you'd model this example especially with named graphs in your > toolbox. The example could be rewritten as follow: [[ $ curl -i http://example.org/netWorth/nw1/ ... Content-Type: text/turtle; charset=UTF-8 Link: <http://www.w3.org/ns/ldp#Resource>; rel="type" ... <> a o:NetWorth; o:netWorthOf <http://example.org/users/JohnZSmith>; o:asset <assetContainer/a1>, <assetContainer/a2>; o:liability <liabilityContainer/l1>, <liabilityContainer/l2>, <liabilityContainer/l3>. $ curl -i http://example.org/netWorth/nw1/assetContainer/ ... Content-Type: text/turtle; charset=UTF-8 Link: <http://www.w3.org/ns/ldp#Container>; rel="type" ... <> a ldp:Container; dcterms:title "The assets of JohnZSmith"; ldp:containerResource <..>; ldp:containsRelation o:asset; ldp:insertedContentRelation ldp:MemberSubject. $ curl -i http://example.org/netWorth/nw1/liabilityContainer/ ... Content-Type: text/turtle; charset=UTF-8 Link: <http://www.w3.org/ns/ldp#Container>; rel="type" ... <> a ldp:Container; dcterms:title "The liabilities of JohnZSmith"; ldp:containerResource <..>; ldp:containsRelation o:liability; ldp:insertedContentRelation ldp:MemberSubject. ]] > The example was to illustrate the pattern I just described > which is one we've seen, perhaps a better one can be given. Though > since it has been there for well over a year, I thought people were > comfortable with it, perhaps not. Now, what I'm interested in, is to see what people think about the following scenario (just a variation on [2]): [[ $ GET http://example.org/shopping/cart/ <> a ldp:Container; ldp:containerResource <https://amazon.example.com/betehess#realShoppingCart>; ldp:containsRelation order:contains; ldp:insertedContentRelation foaf:primaryTopic. ]] $ POST http://example.com/shopping/cart/ [[ <> foaf:primaryTopic <urn:isbn:0470396792> . ]] $ GET http://example.com/shopping/cart/ [[ </shopping/cart/> a ldp:Container; ldp:containerResource <#>; ldp:containsRelation order:contains; ldp:insertedContentRelation foaf:primaryTopic. <https://amazon.example.com/betehess#realShoppingCart> order:contains <urn:isbn:0470396792> ]] So we have triples about the membership subject and the membership objects which are totally uncorrelated with the LDPC and the LDPR. [2] http://www.w3.org/mid/52799228.4080506@w3.org > Looks like the confusion was introduced with > ldp:containerResource. And that being of type ldp:Container does not > entail the LDP interactions. > > Are LDPC and ldp:Container two different beasts? > > No. LDPC is a short name in the spec for Linked Data Platform > Container. ldp:Container is the rdfs:Class defining the Linked Data > Platform Container. Per discussion yesterday [1] though, this question > may be moot. So we agree that the subject of the membership triple is _not_ the Container. The same than the object of the membership triple is _not_ the resource managed by the container. And that the membership triple may have very little to do with membership (eg. foaf:friend). Alexandre. > > [1] - http://www.w3.org/2012/ldp/wiki/Containers > > - Steve Speicher > > > Alexandre. > > [2] > https://dvcs.w3.org/hg/ldpwg/__raw-file/default/ldp.html#__ldpc-ex-membership-full > <https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpc-ex-membership-full> > > > > On 11/22/2013 05:28 PM, Linked Data Platform (LDP) Working Group > Issue Tracker wrote: > > ldp-ISSUE-91 (rel='type' Link-based interaction): The LDP (REST) > interactions must be driven by the rel='type' Link header > [Linked Data Platform Spec] > > http://www.w3.org/2012/ldp/__track/issues/91 > <http://www.w3.org/2012/ldp/track/issues/91> > > Raised by: Alexandre Bertails > On product: Linked Data Platform Spec > > We have already agreed that LDP interactions are not strictly > hypermedia driven, as we agreed not to define a new media-type > for LDP. Instead we have a Link header for Resource [1]. > > The problem is that 4.2.10 [1] does not really advertise the LDP > interaction, just the "LDP support" for the resource, and the > interaction is currently derived from a { <> a ldp:Container } > triple (or its absence). That means than I cannot create a > simple LDPR with that triple _without_ the related interaction > model. This is wrong. > > My proposal is to say that the interaction model is directly > (and solely) derived from the "type" Link header, having one for > the LDPR and one for the LDPC. This is aligned with the previous > proposal of not defining a new media type but to extend the > existing RDF ones with the rel='type' Link header. > > For an LDPR (and ideally for Binary if it also were an LDPR): > Link: <http://www.w3.org/ns/ldp#__Resource > <http://www.w3.org/ns/ldp#Resource>>; rel="type" > > For an LDPC: > Link: <http://www.w3.org/ns/ldp#__Container > <http://www.w3.org/ns/ldp#Container>>; rel="type" > > Now, I can copy the content of an LDPC (eg. for backup purposes) > into a new LDPR, without inheriting the LDPC interactions. > > Also, creating an LDPC is now easy to define (and implement): > you POST a document *with* the corresponding Link header > (otherwise, it's an LDPR, or a Binary). > > Alexandre. > > [1] > https://dvcs.w3.org/hg/ldpwg/__raw-file/default/ldp.html#__ldpr-4_2_10 > <https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpr-4_2_10> > > > > > > >
Received on Tuesday, 26 November 2013 16:39:42 UTC