Re: LDPR Interaction Model on Create

Hi James,

On Thu, Oct 9, 2014 at 11:08 AM, James Leigh <james@3roundstones.com> wrote:

> Hi Steve,
>
> Section 5 makes a lot of references to section 4. Just saying LDPR, but
> not LDPC is not enough (aside from a minimal implementation). I would like
> to see an explicit list of behaviour that is prohibited in this mode.
>

Taking this suggestion to the extreme, this sounds like restating every
clause in section 5 and making a paired counter negative normative clause.
I don't think we want this.  Well I don't want this.  Perhaps instead we
could make a single statement (watering it down here) "don't do things in
section 5" and make a list of a couple key ones (like affecting containment
and membership triples on create (5.2.3 HTTP POST) and delete (5.2.5 HTTP
DELETE) ).

Regards,
Steve


> This is important to me because it is a MUST requirement. I think a lot of
> implantations will have more functionality then what is in the spec. It is
> not clear if externally defined behaviour (not in the spec) would break
> this requirement unless it is explicitly listed as prohibited.
>

> Thanks,
> James
>
>
>
> *From:* Steve Speicher
> *Sent:* Thursday, 09 October, 2014 09:10
> *To:* James Leigh
> *CC:* public-ldp-comments
> *Subject:* Re: LDPR Interaction Model on Create
>
> 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].
>
> - Steve
>
> [1]: http://lists.w3.org/Archives/Public/public-ldp/2014Oct/0002.html
>
>
>>
>> Regards,
>> James Leigh
>> ---
>> http://www.w3.org/TR/ldp/#h5_ldpc-post-createrdf
>>
>> 5.2.3.4 LDP servers that successfully create a resource from a RDF
>> representation in the request entity body MUST honor the client's
>> requested interaction model(s). If any requested interaction model
>> cannot be honored, the server MUST fail the request.\
>>
>>       * If the 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).
>>       * If the request header specifies a LDPC interaction model, then
>>         the server MUST handle subsequent requests to the newly created
>>         resource's URI as if it is a LDPC.
>>       * This specification does not constrain the server's behavior in
>>         other cases.
>>
>>     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.
>>
>>     Note: A consequence of this is that LDPCs can be used to create
>> LDPCs, if the server supports doing so.
>>
>>
>>
>>
>>
>