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,

On Fri, Nov 22, 2013 at 5:28 PM, Linked Data Platform (LDP) Working Group
Issue Tracker <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.  There are very few cases where there are differences, POST only.


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

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

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.


- Steve Speicher



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