Re: Obscure section 5.2.3.4 and concept of "interaction model"

Hi Steve

Thanks for your answer.

I see three aspects:

- Lack of clarity/definition of "interaction model", replacing the term
with "semantics" doesn't help imho. Whichever term is used, it should be
defined and the headers should be introduced.

- I understand that if the "interaction model" indicates a resource is not
an LDPC than it must not be treated as LDPC. However if LDPC is a subtype
of LDPR then the statement "[...] as if it is a[n] LDPR" is as least
confusing. (Like saying "a student who fails to present a student id has to
pay as if she is a person", this implies or at least suggests that a
student is not a person).

- After all wording problems I think it is wrong of LDP to have this focus
on headers, in my opinion headers should allow to optimize the
communication (like for getting shorter responses, etc.) they should not
overrule the semantics of the actual message body.  If header determines if
an LDPR is an LDPC and this may contradict the information in the RDF data
this means that the implementation has to store this information
separately. It is no longer possible for an implementation to store all its
state in a single graph and we are not far from having RDF-free LDP
implementation. If an LDP implementation is explicitly allowed to lie about
the type of a resource in the returned RDF why shouldn't it be allowed to
lie about membership too? So consequently membership statements should be
transformed into headers too.  With this change usage of RDF could become
optional altogether (to avoid misunderstanding: this is supposed to be a
reductio ad absurdum).

Cheers,
Reto

On Fri, Sep 26, 2014 at 8:14 PM, Steve Speicher <sspeiche@gmail.com> wrote:

> Hi Reto,
>
> On Mon, Sep 15, 2014 at 5:56 PM, Reto Gmür <reto@apache.org> wrote:
>
>> Hello,
>>
>> Section 5.2.3.4 specifies that server “MUST honor the client’s requested
>> interaction model(s)”. Sections 4.2.1.4 and 5.2.1.4 are linked for the two
>> mentioned interaction models. These two sections specify a response header
>> that the server should send in reponse to indicate that a resource is an
>> LDPR respectively an LDPC.
>>
>> What confuses me is:
>>
>>    -
>>
>>    I don’t find a proper definition of “interaction model”. Apart from
>>    section 5.2.3.4 it is only mentioned once in the introduction.
>>
>> This was a widely used term ("interaction model") in the WG when
> discussing the feature.  Some proposals to clarify the meaning...
>
> 5.1
> 1. Replace "interaction models" with "semantics"
>
>>
>>    -
>>    -
>>
>>    In a normative section about requests I’m pointed to a section
>>    defining response headers
>>
>> 5.2.3.4
> 2. Replace "client's requested interaction model (s). If any requested
> interaction model cannot be honored," with
> "client's requested LDP semantics.  If any requested LDP semantics cannot
> be honored,"
>
> 3. Replace "If the request header specifies a LDPR interaction model
> <https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpr-gen-linktypehdr>, "
> with
> "If the client request LDPR semantics (by setting request header Link: <
> http://www.w3.org/ns/ldp#Resource>; rel="type"),  ".
> Append  "See 4.2.1.4 for additional details on the Link: rel='type'
> header"
>
> 4. similar to #3 above for bullet on LDPC
>
> 5. replace last occurrence of "interaction model" with "semantic"
>
>>
>>    - LDPC is a subtype of LDPR (see Fig. 3). So for an LDPR it shouldn’t
>>    be wrong to specify the LDPR “interaction model”. However the sentence
>>    “request header specifies a LDPR interaction model
>>    <http://www.w3.org/TR/ldp/#ldpr-gen-linktypehdr>, then the server
>>    MUST handle subsequent requests to the newly created resource’s URI as if
>>    it is a LDPR. (even if the content contains an rdf:type triple indicating a
>>    type of LDPC).” sound as if LDPC and LDPR are disjoint classes.
>>
>> According to the client specified "interaction model" (aka semantic), if
> the client specified LDPR then the resource is not a LDPC.  It just happens
> to be a LDPR, which has a triple of <s, rdf:type, ldp:Container>.
>
> Let us know if this helps with the clarity on this and then I can fold in
> the changes.
>
> - Steve
>
>
>
>>
>>
>> Cheers,
>> Reto
>> ​
>>
>
>