Re: Binary resources and containment triples

On 05/05/2014 06:45 AM, Nandana Mihindukulasooriya wrote:
> Hi,
>
> This is regarding how to handle containment triples when creating 
> binary resources.
>
> As per the current spec (5.2.3.12), upon creating an LDP-NR the 
> servers may create an LDP-RS to maintain metadata about the newly 
> created LDP-NR and advertise that using a Link Header. E.g.
>
> HTTP/1.1 201 Created
> Location: /image.jpeg
> Link: <http://www.w3.org/ns/ldp/Resource>; rel="type"
> Link: <http://example.org/metadata>; rel="describedby"
>
> The question is after the creation, which triples should be added to 
> the container.
>
> (1) Is it only the newly created LDP-NR ?
>
> <ldpc> ldp:contains <image.jpeg>
>
> or
>
> (2) or both LDP-NR and LDP-RS ?
>
> <ldpc> ldp:contains <image.jpeg>
> <ldpc> ldp:contains <metadata>
>

My understanding is the intent is (1).   I also think (1) is the right 
choice.

> This relevant text in the spec about the containment triple.
>
> [[ 5.2.3.2 When a successful HTTP POST request to a LDPC results in 
> the creation of a LDPR, a containment triple must be added to the 
> state of the LDPC whose subject is the LDPC URI, whose predicate is 
> ldp:contains and whose object is the URI for the newly created 
> document (LDPR). Other triples may be added as well. The newly created 
> LDPR appears as a contained resource of the LDPC until the newly 
> created document is deleted or removed by other methods. ]]
>

This is where our "well, what if the server wants to, for reasons we 
don't know about?" confusion bites us.

How about we just drop "Other triples may be added as well." since of 
course that's always true, but it's misleading.   We could also add a 
sentence to 5.2.3.13 like "The server MUST NOT consider the associated 
LDP-RS to be automatically in the container."

Also, it would be good to add a test case on this.

          -- Sandro

> Best Regards,
> Nandana
>
>

Received on Monday, 5 May 2014 12:35:39 UTC