Re: 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]

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