Re: Some reflections on creating new resources with POST on LDPCs

Hi Nandana,

Agree with John that it would be good to capture this in Best
Practices.  I have some thoughts below.

Thanks,
Steve Speicher
http://stevespeicher.me

On Mon, Oct 13, 2014 at 9:47 AM, Nandana Mihindukulasooriya
<nmihindu@fi.upm.es> wrote:
>
> Hi,
>
>
> As we discussed several related but partially orthogonal aspects in the thread started by Miguel Aragon, I thought of sharing some reflections on resource creation using the POST method.
>
>
> When a POST operation is done on an LDPC, typically there are several things that need to happen.
>
>
> A.) A URI has to be minted to name/identify the new resource.
>
> B.) The POSTed content in a format such as Turtle or JSON-LD has to deserialized to build the RDF graph.
>
> C.) The interaction model of the resource has to be decided.
>
> D.) The created resource has to be persisted or any business-level actions related to the resource creation has to be carried out.
>
(for completeness I'd add):

E.) Containment and possibly membership triples need to be created and
persisted.

F.) Server responds with 201 and header of Location: with newly minted URI

>
> Of course, the order of the four items will differ based on different applications.
>
>
> A). Minting a new URI for the created resource
>
>
> LDP: 5.2.3.10 says servers may allow clients to provide hints using the Slug header.
>
>
> Implementation-specific: Implementations can have their own policies for minting the new URIs for the created resources and LDP doesn’t enforce them to follow the  ‘container URI + newID’ pattern though it would be the intuitive way to do it. The implementations are also free to look in to the content of the posted resource (e.g., an explicit @base defined in the resource) but all these are implementation specific and the clients can not / should not depend on these mechanisms to be interoperable.
>
>
> B.) Deserialization
>
> At the time of the deserialization most of the RDF libraries require to specify the base of the document so that they can resolve the relative URIs before building the RDF graph.
>
>
> LDP: 4.2.1.5 says default base-URI MUST be the URI of the created resource when the request results in the creation of a new resource and 5.2.3.7 says null relative URI for the subject of triples must be interpreted as identifying the entity in the request body.
>
>
> Implementation-specific: Some implementations might want to step B before step A (e.g. if the application is based on JAX-RS and wants to use MessageBodyReader for the deserialization). In that case, either building the graph can be delayed just passing the RDF as a string or the graph can be built using a temporary base which can be later replaced by the real base. In the latter case, one should carefully handle the corner cases where the temporary base can clash with the data.
>
>
> C.) Interaction model
>
>
> LDP: 5.2.3.4 says the server must honour the interaction model specicifed using the rel='type' Link relation header.
>
>
> Implementation-specific: If the client doesn’t specify the interaction model, the server can use different heuristics or the POST content to determine the interaction model but these are not interoperable and the clients won’t have any guarantee. Another consequence of separating the interaction model from the content is that the server will have to maintain this information as metadata in addition to the content of the resource itself (how the server does it is entirely up to the server).
>

Want to be clear, the interaction model is set at the container level
(the thing you are POSTing to).  In other words, you can only set the
interaction model when you create a container and not on a per-request
basis.

> D.) Persistence / business object creation
>
>
> LDP: The LDP spec doesn’t place any constraints on how the resource is persisted or what happens in the application when a resource is created.
>
>
> Implementation-specific: How the resource is created / persisted is entirely application specific. For example, the implementations can decide to store the resource as a named graph or as multiple named graphs one for the resource content and one for resource metadata etc or convert the RDF graph into to a application specific data model.
>
E.) Persistence
LDP: There are no constraints on where these triples are stored or
computed, just which responses should include them based on client
preferences (Prefer: header).

Implementation-specific: Each implementation may find it best to
explicitly store membership and containment triples or run queries or
have some inferencing based on application-specific model.  These
triples could be persisted within a graph for the LDPC, within each
member LDPR or other a separate graphs just for containment and
membership triples.

Thanks good list,

- Steve

> Best Regards,
> Nandana

Received on Tuesday, 14 October 2014 14:06:00 UTC