Re: LDPR Interaction Model on Create

Thanks for your quick reply!

On 10/09/2014 12:21 PM, Nandana Mihindukulasooriya wrote:
> Hi,
> 
> On Thu, Oct 9, 2014 at 4:09 PM, Andrei Sambra <andrei@w3.org> wrote:
> 
>> Hi,
>>
>> On 10/09/2014 09:10 AM, Steve Speicher wrote:
>>> Hi,
>>>
>>> Thanks,
>>> Steve Speicher
>>> http://stevespeicher.me
>>>
>>> On Tue, Oct 7, 2014 at 3:48 PM, James Leigh <james@3roundstones.com>
>> wrote:
>>>
>>>> Hello,
>>>>
>>>> Section 5.2.3.4 (copied below) could use some more explanation. In
>>>> particular the first bullet point is not clear. The example given is
>>>> when the created content contains an rdf:type triple indicating a type
>>>> of LDPC, but specifies a LDPR interaction model.
>>>>
>>>> Given section 5.2.1.1 (each LDPC MUST also be a conforming LDPRS) and
>>>> section 4.3.11 (each LDPRS MUST also be a conforming LDPR), I don't
>>>> understand under what conditions a LDPC could NOT also be a LDPR
>>>> interaction model.
>>>>
>>>> Furthermore given the LDP schema, I would expect a POST to a container
>>>> with a Link:<http://www.w3.org/ns/ldp#Resource>;rel="type" that created
>>>> a LDPC member to be successful, since ldp:Container rdfs:subClassOf+
>>>> ldp:Resource and with RDFS entailment all ldp:Container members are also
>>>> ldp:Resource members.
>>>>
>>>
>>> Perhaps it could be clarified that specifying the "interaction model" on
>>> creation of the resource using
>>> Link:<http://www.w3.org/ns/ldp#Resource>;rel="type",
>>> that the created resource will ONLY have LDPR interaction model and not
>>> LDPC (ie containment and membership triples will not be affected by
>> POSTing
>>> to it or DELETE'ing any of the member resources) even though the entity
>>> body may have a triple where rdf:type of ldp:Container [1].
>>
>> I also have a small comment that I've been meaning to send regarding the
>> interaction model.
>>
>> 5.2.3.4 states that "Clients use the same syntax, that is HTTP Link
>> headers, to specify the desired interaction model when creating a
>> resource as servers use to advertise it on responses."
>>
>> I noticed that in the primer, the POST request to an LDP-BC does not
>> contain a link header expressing the type of the resource to be created.
>> That also seems to be the behaviour of test suite. However, the POST
>> request to an LDP-DC *contains* the Link header Link:
>> <http://www.w3.org/ns/ldp#Resource>; rel="type", while *none* of the
>> examples in the LDP spec show a Link header being sent with POST requests.
>>
>> Is there any reason for this behaviour? I would expect that clients
>> would normally send a Link header with the type of resource to be
>> created with every POST request. The way it is now, a person
>> implementing the spec will assume that by default, a POST request will
>> only create LDPRs (maybe that was intended but it never got documented?).
>>
> 
> After reading 5.2.3.4, I was also in the opinion that clients should send a
> Link header with the interaction model when creating resources because it
> says "This specification does not constrain the server's behavior in other
> cases." i.e. in cases where the interaction model is not specified.
> 
> There was a comment to the editors of the primer and we discussed whether
> we need to send the interaction model header in cases where the server can
> guess it easily. For example, non-RDF resources in which only the LDPR
> interaction model is applicable. Except for the case where we want to treat
> an LDPC content with LDPR interaction model (for archiving etc) the most
> other cases, the server can correctly guess the interaction model looking
> at the content. However, I still think according to the spec it is better
> to include the interaction model header in creation requests according to
> the spec.

My concern is mainly about forward compatibility, where a generic POST
may be misinterpreted as something other than an LDP interaction -- i.e.
where some (myself included) have also treated POST as an "append"
operation (albeit not a standard way of doing append).

-- Andrei

> 
> We would like to know what others think so we can do the necessary changes
> before republishing the the Primer draft.
> 
> Best Regards,
> Nandana
>