Comments on the LDP Spec: Creating new Resources

Hello to everyone
Based on the design and implementation process that my team and I have
experience, I've several comments about the LDP Spec that I'd like to share
with you. But first lets make sure that we talk in the same language:

*Concepts*
*Note: Keep in mind that these are the concepts that are working for us. By
no means I'm criticising the "Academic point of view"*

   - *Relative UR*I: A relative URI that was not resolved to an absolute
   URI because the document didn't specified a base URI (@base).
   - *Null URI*: an empty, relative URI.


*Creation of LDP RDF Sources (LDPRS)*
There are several key points in section 5.1 Introduction
<https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpc-informative> that
need to be considered:

   - An LDPRS can be created by issuing a POST to an LDPC.
   - The client can specify a Slug header to provide a hint of the URI
   desired for the new resource.
   - The examples show that a *null URI* can be used for the resource to be
   created. The resulting URI will be forged by the server.
   - The LDP test suite goes beyond this and uses relative URIs in the
   resources that are POSTed to the server. (ex. <something> a ldp:RDFSource.
   ).

At first we followed this approach, but when we started using JSON-LD as
our main RDF format, we started encountering several problems with it:


   - If non empty, *relative URIs (ex. <something>)* are accepted, it
   doesn't make much sense to support the Slug header. What would happen if
   both of them were used?

   Example:
   Slug: something
   <somethingElse> a ldp:RDFSource.

   - By allowing the client to send both *null URIs *and non empty, *relative
   URIs*, a weird behaviour would be expected:
   - If a *null URI* was used, forge a slug for the new resource and take
      the LDPC URI as a base for the URI of the resource to be created.
      - If a non empty,* relative URI* was specified, treat that as a hint
      for the desired slug and use the LDPC URI as a base for the URI of the
      resource to be created.
   - The logic needed for this behaviour will impose an unnecessary
   overhead for each request.
   - As far as we know, specifying *relative URIs* and not defining a base
   URI results in an invalid RDF document.
   - If the server supported the creation of multiple resources on a single
   request,* null URIs* will overlap with each other.
   - Common parsers (like Jena) don't treat *null URIs* and *relative URIs*
    consistently.

Some of the possible approaches for addressing these problems are:

   1. The obvious solution would be to use fully qualified URIs on every
   request. But the client doesn't always know what the resulting URI will be.
   2. Another approach would be to use a placeholder, a fully qualified URI
   that the server knows it's acting just as a placeholder (Ex. <
   http://example.org/placeholder>). But that would mean the client is
   constantly specifying new triples for the same resource (in an academic
   point of view). And the problem of multiple resources on a single request
   wouldn't be solved by this approach.

After some thought, we came with the concept of "Generic Request URI".

*Generic Request URI*
A URI that has as a base, a known and never changing URI, and that ends
with a slug that is different for every Generic Request URI created (in our
case a timestamp).
*Example*
A template of the form: *http://example.org/generic-requests/
<http://example.org/generic-requests/><timestamp>* would create URIs like:

   1. <http://example.org/generic-requests/*1412868212000*>
   2. <http://example.org/generic-requests/*1412868258000*>
   3. <http://example.org/generic-requests/*1412868262000*>

Using a Generic Request URI when creating resources covers the following
problems:

   - It standardises the URIs the server will receive.
   - If the client wants to specify a hint, it would do so by passing a
   Slug header.
   - Each request describes a unique resource and thus it is academically
   correct.
   - Multiple resources can be created by declaring each one with a
   different Generic Request URI.



So an LDP server would accept requests with the following forms:

   1. A resource with a fully qualified URI. In this case the client
   attempts to create a resource with a known URI so a Slug header isn't
   allowed and if the URI is already in use the server would respond with 409
   Conflict.
   2. A resource with a *Generic Request URI* and no slug specified. The
   server would use the URI of the parent resource as a base and forge a slug
   for the new resource however the server is configured to do so.
   3. A resource with a *Generic Request URI *and a Slug header. The server
   would use the Slug header as a hint for the URI of the new resource to be
   created.

I've more comments and concepts to share, but I will write another email
for them.

-- 
Miguel Aragón[image: base22] <http://base22.com/>Mobile: +52 (811) 798 9357
Skype: *miguel.araco*
Email: miguel.aragon@base22 <luke@base22.com>.comCONFIDENTIALITY NOTICE:
This e-mail message, including any attachments, is for the sole use of the
intended recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.