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

Hi Reto,

Thanks for you feedback,

On Thu, Oct 2, 2014 at 5:55 AM, Reto Gmür <reto@apache.org> wrote:
> 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 believe that is what I was proposing be done, elaborate on the
definition and clarify the headers that should be used.

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

I can see how some might find it confusing.  I'm at a loss of how to
change the words to satisfy a wider audience, while not confusing a
different segment at the same time.  I wonder if adding a little more
non-normative content to help with the motivation scenario and what it
"means" to support LDPR interaction semantics instead of LDPC, such
as:
POST does not create contained resource and update containment and
membership triples, DELETE of contained resources does not affect
containment triple and so on.

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

Implementations may choose to support this feature and need to store
this information somewhere, yes.  It could be possible that an
implementation would choose to add it into a single graph, another
graph (this is what my impl chose), a global graph for all resources,
a spreadsheet ;), whatever makes sense for that implementation.  As
long as the client-server LDP interaction matches that of the LDP
spec.

There is a line between what needs to go into headers and what goes
into content.  We have looked at how various groups have used headers
(IETF HTTP, AtomPub, ....) and reached out to a number of this current
and past WG members for guidance on cases like this.  In fact, I
recall a F2F meeting where your point was talked about as a side
discussion but didn't gain any traction.  The case for LDPC's with
interaction model/semantics of LDPR's was pushed by a number of LDP WG
members who saw the need to have many "archived" or "backed up" LDPCs
that operate as read-only resources.  So there would be multiple LDPCs
that have the same containment resources.  Deleting of the contained
resource should not affect the LDPC's with LDPR's interaction
semantics.

Regards,
Steve Speicher

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

Received on Monday, 6 October 2014 13:44:44 UTC