Some reflections on creating new resources with POST on LDPCs

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.

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

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.

Best Regards,
Nandana