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 Arnaud,

sorry for the late response :-/

On 11/27/2013 11:58 AM, Arnaud Le Hors wrote:
> Hi Alexandre,
> I think I understand what you're saying but you need to be more careful
> about how you write about this stuff or I'm afraid the conversation is
> going to remain very difficult.
> What you're saying is that there is a difference between the RDF type of a
> resource and its interaction model so you ought to be precise as to which
> you're referring to.
> Let me try to clarify and correct me if I didn't get it right.
>> Right, LDP currently requires the type-rel (Link Relation Type) only
>> as a response header. So to be clear, with this proposal, the type-rel
>> would be required for both directions (response and request header),
>> and would become the one signaling mechanism for a client or server to
>> identify an LDPR and an LDPC.
> This should read: "to identify a resource with the LDPR and LDPC
> interaction models".

Right. In my mind, the only kind of resource with an LDPR/LDPC
interaction model is something that itself is an LDPR/LDPC.

>> With my proposal, adding { <> a ldp:Container } to an existing LDPR is
>> very-well specified: it just adds the triple and does not change the
>> nature of the resource.
>>From an RDF point of view adding that triple definitely changes the
> "nature" of the resource. It sets its type. What you mean is that it "does
> not change the interaction model of the resource".

Right. The type information alone cannot define the interaction model
of the resource.

>> `Content-Type: text/turtle` just means: this is Turtle, trigger the
>> right parser. A client/server can decide if it is valid by actually
>> parsing it. There is no other associated semantics to it, especially
>> no interaction.
> Content-Type: text/turtle tells you it's RDF so you can't say that there
> is no associated semantics. RDF is all about semantics. The associated
> semantics is whatever the semantics of the RDF vocabulary used is. What is
> true is that it doesn't tell you anything about the interaction model.

Aren't you contradicting yourself? The current spec basically says
that if <xyz> has type ldp:Container, then its interaction model is
the LDPC one, meaning that the RDF vocabulary drove the interaction.

>> `Link: <>; rel="type"` means that the
>> resource is an LDPR and that it supports the associated semantics (the
>> interactions defined by the specification). At this point, it's not a
>> problem to say that an LDPR can be an RDF resource or a Binary one,
>> you'd know just by looking at the media-type.
>> `Link: <>; rel="type"` means that
>> the resource is an LDPSimpleContainer. To be valid, the spec enforces
>> the representation for an LDPR to be some RDF, with some additional
>> triples (eg. RDF type, membershipXXX triples, etc.).
>> About the "potential conflicts in their headers and data". I don't
>> think there is any problem. RDF does not mean that every triple you
>> see is true, or that it should drive the interaction. It's actually
>> left open to Interpretation (the I function in RDF Semantics). The
>> conflict you're talking about is just another notion of truthfulness.
> What you're saying is that there is a difference between the type of a
> resource and its interaction model, and we should have a way to specify
> each independently. This is something Erik and others tried to say for a
> while and they were shut down by quite a few people who thought we didn't
> need that. We eventually agreed to add a Link header to indicate when the
> LDP interaction model applies.


> Because that's currently all we have, we still rely on the rdf:type of the
> resource to figure out which of the LDPR and LDPC interaction model
> applies.
> What you're now proposing is that we go one step further and allow one to
> specify which of the two interaction models applies to a resource with the
> Link header.


> Given that we now have three different types of containers, what I wonder
> is whether we also have three container interaction models that need to be
> exposed via the Link header or one for all containers is enough. I think
> the latter is enough.

Except for the SimpleContainer, I don't know how to solve that
problem, or even if it's possible to solve it, because of the


> --
> Arnaud  Le Hors - Software Standards Architect - IBM Software Group

Received on Monday, 2 December 2013 14:49:04 UTC