Re: Comments on the LDP Spec: Creating new Resources

I think that the question that the specification needs to address is the
precedence of the Slug header and a relative URI in the request body when
creating a new resource.

If an LDP server receives a POST to a container /objects/ with the header:
  Slug: a
and the body:
  <b> a ldp:Container.

Should it create:
1.  /objects/a  and the <b> is renamed
2.  /objects/a and the resource created doesn't have any description about
a, it returns information about a non-existant <b>
3.  /objects/b and the slug is ignored
4.  /objects/ab by following the slug and then appending the name in the
body ala #me
5.  Nothing because this is an error

Thanks!

Rob



On Thu, Oct 9, 2014 at 12:42 PM, David Wood <david@3roundstones.com> wrote:

> On Oct 9, 2014, at 15:11, Steve Speicher <sspeiche@gmail.com> wrote:
>
> On Thu, Oct 9, 2014 at 3:05 PM, Miguel Aragón <miguel.aragon@base22.com>
> wrote:
>
>> Hi Nandana, thanks for responding.
>>
>> Null URIs are actually very problematic, and (not null) relative URIs
>> just make the problem worse. With the approach that we have: Generic
>> Request URIs, hash URIs can be used in the same way:
>>
>> *Method:* POST
>> *URL:* http://example.org/container/
>> *Slug: *miguel
>> *Body:*
>> @base <http://example.org/generic-requests/123123123123>.
>> <> a foaf:PersonalProfileDocument;
>> foaf:primaryTopic <#me>.
>>
>> Is resolved to
>>
>> <http://example.org/container/miguel> a foaf:PersonalProfileDocument;
>> foaf:primaryTopic <http://example.org/container/miguel#me>.
>>
>> I honestly don’t see the case for using relative URIs (null or not null)
>> at all. They bring many problems to the server and make the request
>> document an invalid RDF document.
>>
>> I believe this is a general misconception, the base URI to use for
> resolution just instead carried outside the entity body.  Many RDF
> libraries allow you to supply the absolute base URI to use for resolution
> when handing off the model, this topic was discussed on the list some time
> ago [1].
>
> Since it is a common stumbling block and not that clear, I would suggest
> we include additional guidance in the best practices and guidance document
> [2].
>
>
>
> For what it is worth, we just love relative URIs. This is because they
> allow us to easy move applications from one service to another. We would be
> quite unhappy if we could not both use relative URIs and be LDP compliant.
>
> Regards,
> Dave
> --
> http://about.me/david_wood
>
>
>
> - Steve
>
> [1]: http://lists.w3.org/Archives/Public/public-ldp-wg/2014Apr/0008.html
> [2]:
> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html#use-relative-uris
>
>
>> On Oct 9, 2014, at 1:55 PM, Nandana Mihindukulasooriya <
>> nmihindu@fi.upm.es> wrote:
>>
>> Hi Miguel,
>>
>> I guess the most common use case for the (not null) relative URIs is
>> usage of hash URIs. For example, something like this.
>>
>> <> a foaf:PersonalProfileDocument;
>>    foaf:primaryTopic <#me> .
>>
>> I think this case is less problematic because typically the profile
>> document <> will become something like  <http://ex.org/container/miguel>
>> and the <#me> becomes <http://ex.org/container/miguel#me>.
>>
>> But if you have something like
>>
>> <> a foaf:PersonalProfileDocument;
>>    ex:property <anotherResource> .
>>
>> This is a bit problematic because the resolution of it is a bit dependent
>> of ending slash. The above snippet resolved against the base <
>> http://ex.org/container/miguel> will become
>>
>> (a) <http://ex.org/container/miguel> a foaf:PersonalProfileDocument;
>>    ex:property <http://ex.org/container/anotherResource> .
>>
>> and the same is resolved against the base <
>> http://ex.org/container/miguel/> will become
>>
>> (b) <http://ex.org/container/miguel/> a foaf:PersonalProfileDocument;
>>    ex:property <http://ex.org/container/miguel/anotherResource> .
>>
>> However, I think LDP clients should never use the (a) with the slug to
>> refer to itself because it can always use the null URI to refer to itself.
>> We also discourage the use of dot segment relative URIs in the LDP BP. I
>> wonder what are practical usages of non-hash relative URIs in POSTed
>> content (before creation when the base of the document is unknown still).
>>
>> Best Regards,
>> Nandana
>>
>> On Thu, Oct 9, 2014 at 6:25 PM, Miguel Aragon <miguel.aragon@base22.com>
>> wrote:
>>
>>> 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.
>>>
>>
>>
>>
>
>


-- 
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305