- From: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>
- Date: Mon, 13 Oct 2014 15:47:50 +0200
- To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <CAAOEr1mipgYGq6TYzjjOnyA7XC2EWGctf=u5GnEh952u8v3y2A@mail.gmail.com>
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
Received on Monday, 13 October 2014 13:48:38 UTC