- From: Alexandre Bertails <bertails@w3.org>
- Date: Mon, 02 Dec 2013 09:49:02 -0500
- To: Arnaud Le Hors <lehors@us.ibm.com>
- CC: "Linked Data Platform (LDP) Working Group" <public-ldp-wg@w3.org>
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: <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.
Right.
> 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.
Exactly.
>
> 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
indirections.
Alexandre.
> --
> Arnaud Le Hors - Software Standards Architect - IBM Software Group
>
Received on Monday, 2 December 2013 14:49:04 UTC