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

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

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

> `Link: <http://www.w3.org/ns/ldp#Resource>; 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: <http://www.w3.org/ns/ldp#Container>; 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.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group