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]

Hi Steve,

On 11/26/2013 08:25 AM, Steve Speicher wrote:
> Hi,
>
> On Fri, Nov 22, 2013 at 5:28 PM, Linked Data Platform (LDP) Working
> Group Issue Tracker <sysbot+tracker@w3.org
> <mailto:sysbot+tracker@w3.org>> 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
>
>     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.
>
>
> "This is wrong" needs more elaboration in this context.  By creating it
> with this type, the client is stating it is that and what the
> interaction model is.

"This is wrong" regarding what REST is about [2].

[2] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

We are already playing with the hypermedia thing, some people would
argue that we should not say we do REST... Just remember what happened
to "SPARQL 1.1 Graph Store HTTP Protocol", which removed all mentions
of REST from the specification.

We have already decided to use the type-Link header for LDPR, and I
just propose here to extend this approach to the LDPC.

>  There are very few cases where there are
> differences, POST only.

I would argue it's not only POST:

* GET-on-LDPC and GET-on-LDPR don't have (yet) the same exact
   semantics (see ISSUE-90).

* PUT-on-LDPC has overridden semantics regarding the membership
   triples.

I don't know how people are planning to implement that in
practice. For what I'm concerned, there is a disjunction between the
LDPR and LDPC logics, and I suspect that most of the implementations
will reflect that. I may be wrong of course.

>     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>; rel="type"
>
>     For an LDPC:
>     Link: <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.
>
>
> Please elaborate on this motivating use case "backup purposes".  What
> LDPC interactions cause problems? The only "real" difference would be
> POST behavior...right?  If if is a backup, wouldn't the ACL be set to
> prohibit writing to it, so POST, PUT, PATCH wouldn't be supported.

It has nothing to do with ACLs.

Here is a full example.

[[
$ curl -i http://example.org/container1/
...
Content-Type: text/turtle; charset=UTF-8
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
...
<>
    a ldp:Container;
    ldp:containerResource <> ;
    ldp:containsRelation rdfs:member;
    ldp:insertedContentRelation ldp:MemberSubject;
    dcterms:title "A very simple container";
    rdfs:member <member1>, <member2>, <member3>.
]]

Now, I want to save that content somewhere else.

[[
$ curl -X POST -i \
  -H 'Content-Type: text/turtle; utf-8' \
  -H 'Slug: container1/' \
  -d @./container1.ttl \
  http://betehess.example.org/myContainer/
]]

In this case, I didn't want `myContainer` to create a real Container,
just a plain regular LDPR-RDF, which just happens to have { <> a
ldp:Container } in it.

With my proposal, you would do the following to create an LDPC:

[[
$ curl -X POST -i \
  -H 'Content-Type: text/turtle; utf-8' \
  -H 'Link: <http://www.w3.org/ns/ldp#SimpleContainer>; rel="type"' \
  -H 'Slug: container1/' \
  -d @./container1.ttl http://betehess.example.org/myContainer/
]]

And you can see here why the indirection of the DirectContainer (and
of course the IndirectContainer as well) is problematic.

> I'm not sure this added complexity really fixes anything.  A client
> would request LDPR semantics on a LDPC, say for a POST request, though a
> server could reject it.  How does this help the client out?
>
>
>     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).
>
> Creating an LDPC was easy before, you just POST the LDPC representation.
>   Would you expect the Link header to possibly be different from the
> rdf:type in the LDPR?

The rdf:type would be used for validation only, just like the rest of
the body. If the nature of a POSTed resource was defined by what's in
the body, that would be a precedent in the REST world.

>  Would it be expected that the server maintain the
> value of the link header as the preferred default semantics of the
> resource, instead of derived from rdf:type?

Totally. In our case, the type-Link header (plus the real
Content-Type) behave like a new media type.

> An advantage I see with this Link header is that I server wouldn't have
> to parse the request document to locate the rdf:type, unless it wanted
> to do some additional validation.

I have made this argument so many times :-)

Note that the "additional validation" has nothing to do with LDP, as
LDP is only about the interactions (well, almost :-).

> If you want to "turn off" membership triple creation when a new resource
> is created via POST to LDPC, it would be good to understand if that is
> what this issue is trying to accomplish as it seems like it is.  If so
> or not, then it would help me understand it better.

It's not that much about the membership triple creation. It's more
about the nature of the resource, as the resource would not be an LDPC
to begin with.

Alexandre.

>
>
> - Steve Speicher
>
>
>     Alexandre.
>
>     [1] https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpr-4_2_10
>
>
>
>

Received on Tuesday, 26 November 2013 15:18:21 UTC